[Fixed IPV6 problem] was WiFi adventures

My setup is fairly simple. I have an RPi 4 debian Bullseye (64-bit) with the piaware package version 8.1. Also feed ADSBExchange. I ssh into the RPi from a desktop Mac using WiFi on my LAN.

Since I first set this up a few months ago, I’ve noticed that the WiFi connection is somewhat marginal. This is manifest by slow or balky ssh and missed updates on the local map. The map should update once per second, but occasionally misses. If it misses enough updates in a row a yellow warning comes up saying that dump1090-fa may not be running. But it’s not dump1090-fa, it’s the WiFi connection. This is all episodic in nature and is probably due to interference from neighbor WiFi signals.

The RPi uses the on-board WiFi hardware. Since the RPi is mounted in an aluminum box, WiFi Tx/Rx could be marginal. Response to iwconfig shows an Rx signal level of about -61 dBm and a Tx power of +31 dBm (that’s about 1.25 Watts, so the RPi needs to shout to be heard).

So, I decided to get an external USB WiFi adapter for the RPi to improve WiFi operation. I got a BrosTrend AC3L WiFi adapter and installed the driver. Then added dtoverlay=disable-wifi to /boot/config.txt to disable the onboard WiFi and rebooted the RPi. When you change the WiFi hardware there’s a new MAC address, and the router assigns a new IP address for the RPi. You can find the new IP address with arp -a. Using the new IP address you can ssh back into the RPi.
At first, everything did seem to be better with the USB WiFi adapter. However, I couldn’t directly compare WiFi signal levels because the BrosTrend driver doesn’t show the same information for iwconfig as the built in WiFi shows. More on that later.

I tried switching back and forth between on-board WiFi and USB WiFi several times to see if there really was an improvement with the USB WiFi. I found a nice little utility program called wavemon that displays more information than iwconfig. Now I was able to see at least the receive signal level of about -50 dBm with the USB WiFi, so it was better. But the BrosTrend USB driver seems to provide less information than RPi on-board driver.

After operating awhile with the USB WiFi, all of a sudden ssh dropped, and I couldn’t get back into the RPi. I figured maybe I had screwed up the router with the switching back and forth of IP addresses of the RPi, so I power cycled the router. That allowed me to get back into the RPi. However, I noticed that I couldn’t ping between various computers. But, I could always ping the router itself, and computers could get to the internet. This is also when the connection to FlightAware started to became very sketchy. Many connects and disconnects. An odd thing I noticed on the Stats page is that the MAC address is always the original MAC address (RPi MAC address) no matter which WiFi I’m using (on-board or USB). Don’t know if this matters.

Anyone else have a situation like this, or offer suggestions of how to get things working again? TIA

1 Like

My fix for router instability was to make a static ip for my pi outside of my dhcp range. I later learned that it was not as easy as I thought it should have been.

I shortened the range of my dhcp search (routers differ depending on origin) and declared my pi static ip address outside of that.

It’s been fine, so I won’t tinker too much with channels, etc.

Well this router is provided by the ISP (Spectrum). I’m not sure how to even get into it (password, etc). So this gives me the excuse for getting my own router.

1 Like

You can often find router admin access info on the router itself, by default.

Never, ever use router provided by ISP, always use your own router. Once you buy your own, call ISP and ask to turn their router into dumb pass-thru cable modem. In reality I would recommend to buy your own cable modem as well, but that is different story and probably not needed in your case.

Wi-Fi is almost always a pain in regard to the Raspberry Pi. The Wi-Fi chip itself is usually weak compared to other Wi-Fi recievers and that implies your Pi will have to “shout” in order to be heard.

First thing I would do is to check is the frequency band your Wi-Fi is operating on. 5 Ghz is nice for transfer speeds but not in terms of range ( the higher the frequency, the shorter the coverage.
In order to check that you should have acces to the router from your ISP so you can look at the configuration.
Here’s a nice readup in regard to frequency coverage pro and cons.

When you have acces to the router I would also recommend to set a DHCP reservation for the Pi so it always will have the same IP.
The procedure is dependant on the make and model of your router

If that isn’t possible then you could set a static ip ( outside of your DHCP scope) on the Pi itself.

My personal preference ( and set-up) is wired connections to all equipment ( I have all Pi’s wired) with static IP’s outside of the DHCP scope.
For mobile equipment I use DHCP reservations.

Well I got my setup working again. I’m still using the Spectrum WiFi router. The thing is to reset the router rather than just power cycle it. That sets everything back to the factory defaults. That fixes the problem for now, but eventually I’ll get my own router.

Thanks for the information on setting IP addresses – I’ll read up on this.

Regarding ethernet being more reliable than WiFi. Yes definitely the case. I worked on modems for satellite communications for most of my career. A wire is way more reliable than wireless. The only problem with an ethernet cable is figuring out how to snake it through the walls.

1 Like

If you have mains power at your raspberry, have you ever thought about using a powerline adaptor, this way your mains wiring becomes the data link between router and raspberry cutting out WiFi.

1 Like

Yeah, ethernet over power line might be the way to do it. The fact that the data rate might be a little lower shouldn’t matter since the data rates needed for plane tracking are pretty moderate. I’ll take a look at it.

You will be surprised how fast the data can be on them, I have my feeder in the loft 25ft above the router on the ground floor running TP Link AV-1000 adaptors and its been rock solid.

I’ve had much the same issues as you @jimMerk2.

I came up with two solutions, both as effective as each other:

  • splitting the SSID 2/5ghz frequencies and connecting the pi to the 2ghz SSID which I’ve found travels better between walls

  • using a WiFi extender such as the netgear N300 and either connecting to the extended WiFi SSID or plugging the pi directly into the extender with a cat5 patch

Well my setup seemed to be working fine last night, but this morning it started connecting and disconnecting from FlightAware again. Seems like as soon as traffic picked up it started failing again. The RPi connection is at 2.4 GHz over WiFi with good Rx signal strength. Granted WiFi to an ISP provided router isn’t the greatest solution, but this did work previously, for months. Not sure why it won’t work now.

A simple thing to try is to change the 2.4 Ghz channel as the one currently in use may be affected by interference or overloading from other sources. This does assume your ISP supplied router allows you to make such a change. There was recent post where a user’s ISP kit did not allow it. He ended up getting his own gear and changing the channel.

https://discussions.flightaware.com/t/my-pi-keeps-loosing-wifi-connection

What about power supply? Maybe it doesn’t provide enough power?

3 Likes

Command: vcgencmd measure_volts core
says: volt=0.9260V

That does seem low.
I don’t have a multimeter to physically measure input 5V.

I use a tool to monitor the wifi spectrum and use. It is called InSSIDer and is available from MetaGeek | inSSIDer - Defeat Slow Wi-Fi .

For two days in a row now the connection between piaware and FlightAware is solid when traffic is very low at night. Then when traffic picks up in the morning the disconnects start. I’m thinking the problem might be low voltage to the RPi.

Also looking back at previous posts for problems like this, there was a problem with buffer overflows depending on what’s in the /etc/hosts file. Need to check that.

What OS does inSSIDR run on? It doesn’t say on the first page. Does it run on Mac or Linux? Thanks.

On the download page there are two download buttons with logos - one for Windows and one for Apple (MAC).

Ok, thanks. Usually no mention of OS means Windows only.

I downloaded inSSIDer and ran it. However, it doesn’t start with the first screen shown in the video. Do you have to pay to get everything shown in the video?

Further reading the help screen – on the Mac it’s beta software and doesn’t support everything.