|
Post by pagerman on Apr 19, 2021 6:45:50 GMT -8
So far I have not been able to get even 24hrs of data from the SkyWeather 2. It crashes often and the only way to get it back is to go outside to where it is and power cycle. Then it may come up for 5 mins or 20 hours. I have replaced the RPi4 already. The original RPi4 has been running a different process for DAYS now with no crash. I have moved the SkyWeather indoors near (in the same room) as my WiFi. Still crashes. I am awaiting a new SDR dongle, as this may be the issue. That's next. After that I will attempt to hardwire the network to it.
I need specific advice as to how to possibly catch what's going on in a log file. I am NOT a python/linux programmer.
I just went out and power cycled it. Came in, connected via VNC, 5 mins later it has already crashed.
Help.
|
|
|
Post by doxidad on Apr 19, 2021 10:26:44 GMT -8
If you are loosing Wifi connection, be aware that the RPI4 has problems with its WiFi - the lack of a big enough antenna and interference from the HDMI interfaces.
Are you connecting via 2.4ghz or 5Ghz Wifi?
If 5Ghz, as a suggestion, try using 2.4Ghz, if it's available. Its slower but has more strength and penetration.
After fighting with this problem a while back, I've given up and disabled the on board WiFi on both of my RPI4s and use USB WiFi dongles.
|
|
|
Post by pagerman on Apr 19, 2021 11:33:55 GMT -8
I am connected via 5G. I use Google Mesh. One SSID for the entire network, no way to give them separate names. And I don't think I want to and then deal with the other 40 items connected successfully with it. The new SDR dongle is here. Will install tomorrow. After that, I'll hardwire the Pi.
|
|
|
Post by pagerman on Apr 19, 2021 15:54:55 GMT -8
New SDR installed
|
|
|
Post by pagerman on Apr 20, 2021 3:20:31 GMT -8
New SDR installed at 7PM. Crashed at 11PM.
|
|
|
Post by pagerman on Apr 20, 2021 3:22:26 GMT -8
And by complete crash, I mean that the Pi is inaccessible via VNC. It also no longer shows up in a network scan.
|
|
|
Post by pagerman on Apr 20, 2021 7:18:53 GMT -8
This is maddening. I am now wired ethernet. I can get to the Pi vis VNC, so it's connected to the network. I can PING 8.8.8.8 I CANNOT access the internet either through the Pi browser or git pull. pi@SwitchDocLabs:~ $ ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.11 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::cca5:fe34:cf5a:c6ee prefixlen 64 scopeid 0x20<link> ether dc:a6:32:a7:24:20 txqueuelen 1000 (Ethernet) RX packets 12665 bytes 1656094 (1.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9098 bytes 7264789 (6.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 3037 bytes 209877 (204.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3037 bytes 209877 (204.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Here is the PING: pi@SwitchDocLabs:~ $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=13.9 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=12.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.4 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=15.4 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=13.5 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=12.0 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=12.6 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=14.4 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=14.10 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=12.8 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=117 time=12.1 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=15.9 ms
Here is what I get when I try the git pull: pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ git pull fatal: unable to access 'https://github.com/switchdoclabs/SDL_Pi_SkyWeather2.git/': Could not resolve host: github.com pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $
Here is what I get when I try the browser: This site can’t be reachedchrome.google.com’s server IP address could not be found. Try:
Checking the proxy, firewall, and DNS configuration DNS_PROBE_FINISHED_BAD_CONFIG
The interfaces file is below and interfaces.d is completely empty. GNU nano 3.2 /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd # For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d
HELP.
|
|
|
Post by pagerman on Apr 20, 2021 7:28:42 GMT -8
dash_app is accessible. WeatherSTEM is not updating (was expected)
|
|
|
Post by SDL on Apr 20, 2021 7:39:32 GMT -8
1) SDR - does the system bomb without the SDR plugged in?
2) DNS. Wow. This is a strange problem. You have a DNS problem. I think you know that. The fact that it does it both wired and unwired says to me that it isn't a Wifi problem (duh).
How are you wiring directly into the Ethernet? What devices do you go to?
We have a google Mesh and everything works. Our Ethernet comes out of the Google Mesh to our switches.
Do you have another SD Card you could load with a generic Raspberry Pi OS? That would narrow it down to a specific configuration problem on one card, or point at the Pi.
Could you run these commands and post the results? These results are from our functional SkyWeather2 system:
pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 303 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0 and
pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ cat /etc/resolv.conf # Generated by resolvconf domain lan nameserver 192.168.1.1
BP
|
|
|
Post by pagerman on Apr 20, 2021 7:49:35 GMT -8
1) SDR - does the system bomb without the SDR plugged in? 2) DNS. Wow. This is a strange problem. You have a DNS problem. I think you know that. The fact that it does it both wired and unwired says to me that it isn't a Wifi problem (duh). How are you wiring directly into the Ethernet? What devices do you go to? We have a google Mesh and everything works. Our Ethernet comes out of the Google Mesh to our switches. Do you have another SD Card you could load with a generic Raspberry Pi OS? That would narrow it down to a specific configuration problem on one card, or point at the Pi. Could you run these commands and post the results? These results are from our functional SkyWeather2 system: pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 303 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0 and pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ cat /etc/resolv.conf # Generated by resolvconf domain lan nameserver 192.168.1.1
BP This was set to 127.0.0.0 in the file. I changed it to 8.8.8.8 and all is well - for now. GNU nano 3.2 /etc/resolv.conf # Generated by resolvconf domain lan nameserver 8.8.8.8
|
|
|
Post by SDL on Apr 20, 2021 7:54:29 GMT -8
1) SDR - does the system bomb without the SDR plugged in? 2) DNS. Wow. This is a strange problem. You have a DNS problem. I think you know that. The fact that it does it both wired and unwired says to me that it isn't a Wifi problem (duh). How are you wiring directly into the Ethernet? What devices do you go to? We have a google Mesh and everything works. Our Ethernet comes out of the Google Mesh to our switches. Do you have another SD Card you could load with a generic Raspberry Pi OS? That would narrow it down to a specific configuration problem on one card, or point at the Pi. Could you run these commands and post the results? These results are from our functional SkyWeather2 system: pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 303 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0 and pi@SwitchDocLabs:~/SDL_Pi_SkyWeather2 $ cat /etc/resolv.conf # Generated by resolvconf domain lan nameserver 192.168.1.1
BP This was set to 127.0.0.0 in the file. I changed it to 8.8.8.8 and all is well - for now. GNU nano 3.2 /etc/resolv.conf # Generated by resolvconf domain lan nameserver 8.8.8.8 What was set to 127.0.0.0 in what file? BP
|
|
|
Post by pagerman on Apr 20, 2021 8:00:01 GMT -8
There seems to be an error in this file. I have no idea how to fix it. After a reboot, the nameserver went back to 127.0.0.0
GNU nano 3.2 /etc/dhcpcd.conf
# A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel
# Inform the DHCP server of our hostname for DDNS. hostname
# Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. # Some non-RFC compliant DHCP servers do not reply with this set. # In this case, comment out duid and enable clientid above. #duid
# Persist interface configuration when dhcpcd exits. persistent
# Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit
# A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Respect the network MTU. This is applied to DHCP routes. option interface_mtu
# Most distributions have NTP support. #option ntp_servers
# A ServerID is required by RFC2131. require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface #slaac hwaddr # OR generate Stable Private IPv6 Addresses based from the DUID slaac private
# Example static IP configuration: #interface eth0 #static ip_address=192.168.0.10/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 #option ntp_servers
# A ServerID is required by RFC2131. require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface #slaac hwaddr # OR generate Stable Private IPv6 Addresses based from the DUID slaac private
# Example static IP configuration: #interface eth0 #static ip_address=192.168.0.10/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 #static routers=192.168.0.1 #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails: # define static profile #profile static_eth0 #static ip_address=192.168.1.23/24 #static routers=192.168.1.1 #static domain_name_servers=192.168.1.1
# fallback to static profile on eth0 #interface eth0 #fallback static_eth0 # nohook wpa_supplicant
|
|
|
Post by pagerman on Apr 20, 2021 8:00:42 GMT -8
This was set to 127.0.0.0 in the file. I changed it to 8.8.8.8 and all is well - for now. GNU nano 3.2 /etc/resolv.conf # Generated by resolvconf domain lan nameserver 8.8.8.8 What was set to 127.0.0.0 in what file? BP /etc/resolv.conf
|
|
|
Post by pagerman on Apr 20, 2021 8:03:45 GMT -8
This was set to 127.0.0.0 in the file. I changed it to 8.8.8.8 and all is well - for now. GNU nano 3.2 /etc/resolv.conf # Generated by resolvconf domain lan nameserver 8.8.8.8 What was set to 127.0.0.0 in what file? BP resolvconf seems to be in control of the DNS. It keeps changing it back. I have seen this online, but the "fixes" have not fixed it. If you manually change the nameserver in the resolv.conf file to 8.8.8.8 it works, however, when the Pi reboots it changes back.
|
|
|
Post by pagerman on Apr 20, 2021 8:06:20 GMT -8
|
|