Folks,
Just to let anyone know, although FlightAware’s site give instructions for manual installation of software relating to Raspian Jessie I have just successfully installed FA and Dump1090 on to Stretch and it is working fine.
Geffers
Thought it was working fine, got a sudden network disconnect around 00:20 hours today and no reconnect.
Geffers
Somehow I have not had that success yet. Fired up a fresh Stretch install on a pi zero w, added piaware, dump1090-fa, lighttpd and pretty soon (between minutes and hours) dump1090-fa would start outputting “No data received from the SDR for a long time, it may have wedged”. rebooted pi or killed dump1090-fa and a short time later “No data …”
Tried a local compile of both the dev branch (v3.5.3) and master (v3.5.1). Did not change anything.
Have now returned to Jessie (same pi w zero, same rtl-stick) and now it runs through.
Somehow I think that rtl-sdr/libusb under Stretch is going to need some debugging as I also got the occasional “weirdness: rtlsdr gave us a block…” before the "No data"s started.
For now I would not yet use Stretch.
charlie
@CharlieAt
Possibly hardware problem:
1 A bad or undersized power supply.
2. A long cable (usb or PoE) from dc side of power adaptor to Pi.
3. A bad USB cable connecting Pi zero to Dongle.
1 Like
Well, I’ve been suffering sudden disconnects but that was happening with Jessie, hence decided on a fresh install of Stretch.
Abcd567 suggested 3 possibilities but mine is same set up that gave me a very stable system at one point going 94 days without issue. Normal operation is using a Zero W but I’ve switched to a Pi3 untill this network unreliability is sorted.
Log files have given no real clue, a reboot always resolves the issue so am making minor adjustments then wait and see.
So far 17 hours and still going.
Geffers
Incidentally, when mine fails I obviously cannot ssh but CAN connect via GPIO pins (uart USB) and Pi still working fine. All servers still listening on all ports but network interface settings all lost and restarting network does not work.
Geffers
@abcd567
thanks, but it is the same hardware (power supply, usb cable, pi zero and rtl-sdr stick). Even the sd card was the same, just went from a fresh stretch to a fresh jessie. Had it along on holiday last week and it ran through the entire week without any problems.
I am wanting to muck around with openwebrx and will try this on a fresh stretch to see how it goes.
@send2gl
I had something similar on one of my remote pi’s where once it lost the wireless connection it would not recover. googled around all over the place and finally found the following script. worked for me
10.0.1.1 is the wifi-router that should be reachable, replace with your routers ip address.
saved the script under ~/bin/checkwifi.sh and added it as a cronjob.
ymmv
if that does not work, then uncomment the reboot and at least it will reboot itself instead of waiting for you to discover that it is no longer connected to the web.
#!/bin/bash
# from: http://weworkweplay.com/play/rebooting-the-raspberry-pi-when-it-loses-wireless-connection-wifi/
# crontab -e
#*/5 * * * * /usr/bin/sudo -H /home/pi/bin/checkwifi.sh >> /dev/null 2>&1
#*/5 * * * * /usr/bin/sudo -H /home/pi/bin/checkwifi.sh | /usr/bin/logger -t checkwifi
ping -c4 10.0.1.1 > /dev/null
if [ $? != 0 ]
then
echo "No network connection, restarting wlan0"
/sbin/ifdown 'wlan0'
sleep 5
/sbin/ifup --force 'wlan0'
# if wlan up/down does not work, we can also do a reboot
#/sbin/reboot
else
echo "Ping went well"
fi
Charlie,
I had that script running (or similar) without the reboot option. Had it running via a crontab and it checked every five minutes.
Everything would be going fine then I’d get this in syslog - just the relevant bit;
Jan 22 00:35:01 PiAware25 CRON[2885]: (pi) CMD (/usr/bin/sudo -H /usr/local/bin/checkwifi.sh >> /dev/null 2>&1)
Jan 22 00:40:01 PiAware25 CRON[2906]: (pi) CMD (/usr/bin/sudo -H /usr/local/bin/checkwifi.sh >> /dev/null 2>&1)
Jan 22 00:44:46 PiAware25 kernel: [29752.614556] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Jan 22 00:45:01 PiAware25 CRON[2926]: (pi) CMD (/usr/bin/sudo -H /usr/local/bin/checkwifi.sh >> /dev/null 2>&1)
Jan 22 00:45:34 PiAware25 avahi-daemon[402]: Withdrawing address record for 10.19.44.25 on wlan0.
Jan 22 00:45:34 PiAware25 avahi-daemon[402]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.19.44.25.
Jan 22 00:45:37 PiAware25 avahi-daemon[402]: Interface wlan0.IPv4 no longer relevant for mDNS.
Jan 22 00:45:37 PiAware25 kernel: [29804.060975] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Jan 22 00:45:40 PiAware25 kernel: [29806.620993] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -110
Jan 22 00:45:42 PiAware25 kernel: [29809.181011] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -110
Jan 22 00:45:45 PiAware25 kernel: [29811.741061] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
Jan 22 00:45:52 PiAware25 kernel: [29819.421051] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -110
Jan 22 00:45:55 PiAware25 kernel: [29821.981070] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -110
Jan 22 00:45:57 PiAware25 kernel: [29824.541084] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
Jan 22 00:46:05 PiAware25 kernel: [29832.231103] brcmfmac: brcmf_cfg80211_disconnect: error (-110)
Jan 22 00:46:08 PiAware25 wpa_supplicant[468]: wlan0: CTRL-EVENT-DISCONNECTED bssid=74:da:38:29:f9:6a reason=3 locally_generated=1
Jan 22 00:46:08 PiAware25 avahi-daemon[402]: Interface wlan0.IPv6 no longer relevant for mDNS.
Jan 22 00:46:08 PiAware25 avahi-daemon[402]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::ba27:ebff:fe5f:305a.
Jan 22 00:46:08 PiAware25 avahi-daemon[402]: Withdrawing address record for fe80::ba27:ebff:fe5f:305a on wlan0.
Jan 22 00:46:08 PiAware25 wpa_supplicant[468]: p2p-dev-wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Jan 22 00:46:13 PiAware25 wpa_supplicant[468]: p2p-dev-wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
Jan 22 00:46:13 PiAware25 kernel: [29840.381159] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
Jan 22 00:46:13 PiAware25 kernel: [29840.381173] brcmfmac: brcmf_cfg80211_reg_notifier: Country code iovar returned err = -110
Jan 22 00:46:13 PiAware25 kernel: [29840.388621] brcmfmac: power management disabled
Then at around the same period PiAware log shows;
Jan 22 00:29:18 PiAware25 piaware[424]: mlat-client(690): Server status: synchronized with 7 nearby receivers
Jan 22 00:29:18 PiAware25 piaware[424]: mlat-client(690): Receiver: 3.3 msg/s received 0.8 msg/s processed (25%)
Jan 22 00:29:18 PiAware25 piaware[424]: mlat-client(690): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
Jan 22 00:29:18 PiAware25 piaware[424]: mlat-client(690): Aircraft: 1 of 1 Mode S, 1 of 1 ADS-B used
Jan 22 00:29:18 PiAware25 piaware[424]: mlat-client(690): Out-of-order timestamps: 1
Jan 22 00:29:25 PiAware25 piaware[424]: 36041 msgs recv’d from dump1090-fa (22 in last 5m); 36041 msgs sent to FlightAware
Jan 22 00:34:25 PiAware25 piaware[424]: 36081 msgs recv’d from dump1090-fa (40 in last 5m); 36081 msgs sent to FlightAware
Jan 22 00:39:25 PiAware25 piaware[424]: 36132 msgs recv’d from dump1090-fa (51 in last 5m); 36132 msgs sent to FlightAware
Jan 22 00:44:18 PiAware25 piaware[424]: mlat-client(690): Receiver status: connected
Jan 22 00:44:18 PiAware25 piaware[424]: mlat-client(690): Server status: not synchronized with any nearby receivers
Jan 22 00:44:18 PiAware25 piaware[424]: mlat-client(690): Receiver: 14.6 msg/s received 2.5 msg/s processed (17%)
Jan 22 00:44:18 PiAware25 piaware[424]: mlat-client(690): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.0kB/s UDP to server
Jan 22 00:44:18 PiAware25 piaware[424]: mlat-client(690): Aircraft: 1 of 1 Mode S, 0 of 0 ADS-B used
Jan 22 00:44:25 PiAware25 piaware[424]: 36173 msgs recv’d from dump1090-fa (41 in last 5m); 36173 msgs sent to FlightAware
Jan 22 00:46:04 PiAware25 piaware[424]: timed out waiting for alive message from FlightAware, reconnecting…
Jan 22 00:46:04 PiAware25 piaware[424]: multilateration data no longer required, disabling mlat client
Jan 22 00:46:05 PiAware25 piaware[424]: fa-mlat-client exited normally
Jan 22 00:46:05 PiAware25 piaware[424]: reconnecting in 54 seconds…
Jan 22 00:46:05 PiAware25 piaware[424]: mlat-client(690): Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Jan 22 00:46:05 PiAware25 piaware[424]: mlat-client(690): Exiting on connection loss
I have a feeling it is something to do with a DNS server issue as I use locally another R-Pi to reduce advertising links, you may have heard of it, Pi-Hole. I’ve disabled it for a while and now Pi|ware seems to be stable.
Geffers
I have Pi-hole running but I use it for removing ads and only for my laptop. I haven’t got it set up to do general DNS.
[Edit] forgot to mention that the FlightAware Pi is running Stretch but ethernet not wireless.
When you think of all the program instructions and internet redirects going on it’s a wonder it works at all - but it seems to 
Geffers
I have PiAware (Debian Package Add-on) 3.5.3 , that I installed for me to see the map directly on the raspberry with a TV, the GUI works fine and piaware is working fine, access the map on the piaware browser, it display fine and all looks fine. BUt after several hours the GUI freezes and I only see the main window and a trash can icon. Only way to reactivate is to disconnect and reconnect the raspberry, all back again fine but it will freezes again after a few hours on the GUI.
I decided to exit the startx to the raspberry command window. So far 24 hours later piaware is still woring fine.
So I think something on the starx GUI will make the raspberry to go to sleep after several hours and then I can’t re-open the GUI again, unless hard reboot. That is my experience. Maybe somebody knows the solution to keep the map up all the time.
“Might” be something to try - another person found it was related to power saving on their Pi wireless adapter - have a look at [SOLVED] Raspbian Stretch - Pi dropping off WiFi
Hi Geffers
actually it is at : brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
that things start going wrong. This seems to be a kernel error/problem with being bombarded by MDNS packets.
TLDR : the ‘fix’ according to the link below is to turn off power management and put the device into promiscuous mode:
sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc
here the long read 
hopefully this helps
charlie
2 Likes
My issue was initially using a Zero, switched to a Pi2 with Edimax WiFi adapter, same problem, now using a Pi3 but I don’t think the device is the issue.
Read in another post about the WiFi power save so switched that off, the promiscuous mode is interesting, haven’t tried that.
Changed a few things in my network and currently 4 days without a problem, hate it when things resolve and you can’t find the reason 
Geffers