Android debugging tools to find noise source on Wi-Fi wireless bridge with Windows

The RTL SDR was a cheap Software Defined Radio device, for learning about how to examine things that are broadcasting on the air. The tuner on the thing, only went up to about 1700MHz, which isn't high enough for the two major Wifi bands. But the device would only cost 30-40 bucks or so.

This one on the other hand, the front end goes from close to 0 to 6GHz, and covers at least the two Wifi bands. It also has a slightly wider sampling bandwidth. This still isn't enough to analyze every interesting modulation out there, but it's a start. Currently this is about $340 or so. (Devices like these can be manufactured in batches, so who knows whether any are left.)

You can see the device being used here, without much in the way of Software Defined Radio. It's not attempting to demodulate anything. The picture depicts a near field antenna being used to "sniff" for an emitter which is interfering with Wifi. Now, USB3 cables are known to do that. A USB3 cable with a hard drive enclosure on the end, can wipe out an adjacent wireless mouse and wireless keyboard. Regular USB3 at 500MB/sec, leakage from the cable is broadband and centered at 2.5GHz. There is a zero at 0Hz and 5GHz. Something like that. USB2 doesn't interfere with Wifi.

Using a far field antenna (like a small parabolic dish), you could sweep the area in 3-space, to try to pinpoint sources at a frequency of interest. That does not guarantee you'll figure anything out. Being able to demodulate, and perhaps being able to see SSIDs broadcast, might help a bit.

The device might not be wide enough to track spread spectrum bluetooth signals. There might be too many bluetooth bins for the device to collect all of them at the same time.

*******

There's probably a way to harness an ordinary Wifi device as a sniffer. But I don't remember the details, the software tool name for that.

Paul

FWIW as a comparison, I have here an old Cisco WRT320N flashed with 'DD-WRT v24-sp2 (12/24/10) big - build 15962' set up as a Client Bridge to connect my bedroom to the rest of my LAN & currently it has symmetric errors of 2 on both Rx & Tx.

As your errors are asymmetric, I might be inclined to suspect a fault in the hardware of the DD-WRT device itself, but, assuming FTM that it's alright, you can view other sources of WiFi by pressing either of the two buttons at the bottom of that page (ie the Status, Wireless page): Site Survey WiViz Survey

Anything interesting come up there?

... RIP Barry :-) ...

Have no knowledge of that particular tool, but the output looks alright. FWIW, my preference is WiFi Analyzer by Kevin Yuan, I'm on v3.11.2, but yours is probably fine.

Here I have Client Bridge obviously.

I can't answer your specific questions above, but the asymmetry between Tx & Rx suggests to me that perhaps the DD-WRT device itself is faulty in some way, but, unless you have another identical or at least similar device you could try in its place, I agree it would be preferable to rule out other possibilities before attacking that, as it might be expensive and would at least require some time spent to setup an alternative as a replacement only then to find the problem still exists. Some suggestions for possible investigation might be ...

1 Listening to an old analog radio to see if that shows an intermittent source of noise. 2 Someone has a faulty or unsuppressed electrical appliance which comes on intermittently such as a fridge &/or freezer, electric drill in a workshop, etc.

... but I can't suggest a particular reason why Tx & Rx might be affected asymmetrically by an extraneous source of noise - perhaps others more knowledgeable than myself might be able to.

It took me a few hours to figure out why Java kept failing as I've never used Java on purpose on a Windows PC before, so I wrote it up for others.

Here are my interference charts running that spectrum analysis survey.

I'm not sure how to interpret the spectrum analysis though, but this helps. Ubiquiti airView Walkthrough The narrator says the top is the waterfall view by energy levels over time. Blue is low energy, yellow more, orange even more & red the highest energy.

The middle is the waveform view of RF energy at each signal strength level. The bottom is the real-time current power, average & maximum power density.

The Java Control Panel on my Windows 10 PC kept failing so I went here.

From that I could open up the Configure Java Control Panel in Windows 10. C:\Program Files\Java\jre-1.8\bin\javacpl.exe Which told me I had Java Version 8 Update 271 (build 1.8.0_271-b09).

But when I tried to run Airview with that, it kept failing on me. Googling, I found a lifesaver video which explains the problem I had.

So I wrote up the steps so that anyone following me can reproduce it in a few minutes instead of a few hours which is how long it took me.

1. Note the IP address, port & login/password of the Ubiquiti radio https://192.168.1.20:443 login = ubnt password = ubnt Services > Secure Connection (HTTPS) = Enabled Services > Secure Server Port = 443
2. Connect to the radio from the PC making sure the connection from the PC to the radio is not over the air but via an Ethernet cable. In my case, that was a few hops, but the last hop was via CAT5. a. Windows 10 PC wired to WNR834Bv2 set up as a client bridge repeater b. That connects to an access point which was wired to the main router c. That router was wired to the R7000 set up as a wired access point d. And then the WRT54Gv5 was wired to the switch on that router e. Which finally was wired to the destination PowerBeam M2 radio
3. On the PowerBeam M2, go to PowerBeam: Tools > Launch Airview This downloads a file named "airview.jnlp" which you can execute.
4. The sequence of forms that pops up say: Do you want to Continue? The connection to this website is untrusted. Website: https://192.168.1.20:443 The certificate is not valid and cannot be used to verify the identity of this website. [Continue] Verifying application. Security Warning. Do you want to run this application: Name: AirView Publisher: Ubiquiti Networks, Inc. Location: 192.168.1.20:443 [x]I accept the risk and want to run this application [Run] Unable to launch the application.

At this point I googled and found this lifesaving video instruction. Airview Java 8 Failed to Certificate Validation Solved

provided the solution so that I could continue as follows.

1. If that fails, start the "Configure Java" control panel C:\Program Files\Java\jre-1.8\bin\javacpl.exe Security > Edit Site List > https://192.168.1.20:443 [Add]
2. Now try again: PowerBeam: Tools > Launch Airview > airview.jnlp That also failed, which the video said might happen.
3. Notepad.exe C:\Program Files\Java\jre-1.8\lib\security\java.security The suggest we comment out this line (and even change the key size). jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \ include jdk.disabled.namedCurves
4. Then, everything worked just fine as shown below. Waterfall Graph:
   formatting link
   Channel Graph:
   formatting link
   Does anyone have an idea how to interpret what the graphs are telling me?

I made a mistake on the prior upload so here it is corrected. Here are the results for frequency range 2.402 to 2.497 (channels 1-14).

Waterfall:

Can someone who knows what all this means help me interpret those results?

Thanks for that suggestion where the Site Survey came up with only one neighbor on the network but that WiViz Survey made my head spin a bit!

It seems there is only a single Wi-Fi channel from a neighbor in that. At least for the 2.4GHz Wi-Fi channels.

That WiViz survey is hard to read. What's all that bouncing around?

I like the Ubiquiti Wi-Fi Man debugger, but is this the one you use?

Or is it this WiFi Analyzer?

When I logged into each of my radios, I realized they had firmware from about 2021 so I updated all the firmware and now the TX/RX is symmetric!

However, take a look at the TX/RX values!

Notice the values are already much better? Almost symmetric now.

The only thing I did was burn the latest firmware for every access point including the Ubiquiti access point that the WNR834Bv2 wireless client repeater bridge was WNR834Bv2 connected to.

Yes, it's a bit manic, but you can alter that in the options.

It's neither of those. In fact, I've just searched for it and can't find it in the App Store any more, I don't know why not but perhaps the original developer lost interest in updating it. The only 'versions' of it around now seem to be from unreliable sites which I wouldn't wish to recommend because at least some of those 'versions' seem to be flagged as potential malware. I bought my first android smartphone in 2012 and a year or two later found WiFi Analyzer (the one we're discussing, by Kevin Yuan) in the App Store and installed it on that phone; AFAICR without actually checking, my current phablet is about 5 or 6 years old, and the app was still in the App Store when I was setting up that tablet, or perhaps I just copied it from the phone; in neither of these cases were there any problems from malware using the original app from the App Store. I suppose what has happened since is that malware writers have hijacked a clean original version from when it was widely available and adulterated it.

So if the one you are using is working satisfactorily, I wouldn't bother about trying to find another.

That at least is a significant improvement, but it's still not symmetric, although it now may well be liveable with, only you can decide that. Also it does suggest that I was on the right track to suggest a problem with the system rather than extraneous noise. Did you check whether you are using the latest version of DD-WRT for that device as well as the latest firmware for the other parts of the system? I wonder is there's some intermittent hardware problem somewhere with which the updated firmware is better at coping.

Thanks for that hint. I froze that geospacial WiViz with screenshots but I see now that you mentioned it that it can be made to be static.

I'm guessing this image is trying to geospacially locate (so to speak) the Wi-Fi access points, relative to the location of the WNR834Bv2 bridge.

I've noticed a lot of the more powerful apps are being slowly removed from the Google Play Store. I attribute it to them mostly being FOSS where they don't always have the time & energy to keep up with Google's new split-APK rules (which seem to require them to build APKs a different way lately).

You don't need to recommend an iffy APK because, luckily there are many out there that do both Wi-Fi and network analysis on the Android phone today.

What everyone needs in their Wi-Fi debugging folder is 3 types of tools. A. Wi-Fi debuggers (these work for Wi-Fi channels but not interference)

Cellular debuggers (these only work for one carrier's SIM at a time) Network debuggers (these are similar to those on the Windows PC)

There are other tools that I'm not sure of such as heat-map monitors (which I think are used to map out floor-plan coverage for Wi-Fi).

And tools to tell you if you're using the latest patches & router firmware. There are even tin-foil-hat tools to find if insecure protocols are used And for the tin-foil-hat user, tools to find stingrays (IMSI catchers). No app from me will have ads unless I say so; this one does.

You might not know this but, unlike Windows, Android never deletes the original APK installer - it just changes the name to "base.apk" for every app you've ever installed. So you can copy it direct to Windows.

This will give you the unique package name (if "wifi" is in the name). CMD: adb shell pm list packages | findstr /i "wifi" package:com.vrem.wifianalyzer package:com.samsung.android.wifi.softap.resources package:com.google.android.apps.carrier.carrierwifi package:com.samsung.android.wifi.h2e.resources package:com.samsung.android.server.wifi.mobilewips package:com.samsung.android.wifi.p2paware.resources package:com.samsung.android.wifi.softapwpathree.resources package:com.keuwl.wifi package:com.android.wifi.resources package:com.samsung.android.wifi.resources package:com.manageengine.wifimonitor package:com.samsung.android.net.wifi.wifiguider package:com.android.wifi.dialog package:ru.andr7e.wifimonitor

Then you can find the path on Android to any of those packages it finds. CMD: adb shell pm path com.keuwl.wifi package:/data/app/~~17JnPS2TxnX4dB1JH1wezQ==/com.keuwl.wifi-zhco0PcHZ1Z0cImyNCvrMQ==/base.apk

Then you can pull that original installer from Android onto Windows. CMD: adb pull /data/app/(see scrambled eggs above)/base.apk CMD: rename base.apk com.keuwl.wifi.apk

Using this method you can archive every original installer on your Android phone onto the same directory you store Windows archives.

What that means is you never need to download an app twice.

1. You install the app once off the Google Play Store (or from wherever).
2. You save the APK (just like I did above) into your Windows archives.
3. When you get a new phone, you repopulate that phone with the apks CMD: adb install com.keuwl.wifi.apk

The best way to manage an Android phone is always going to be from Windows.

Don't worry. I have plenty of radio and wi-fi debugging apps on my phone.

Take a look as I just ran those commands for you so that I would be absolutely positive that I was providing you the proper correct syntax.

I think you are correct that it's may not be noise as I ran the free spectrum analysis (which will find EVERYTHING in the band, not just inside of Wi-Fi channels) and, while I'm not sure how to interpret what it found, I don't see any smoking gun (but maybe I'm missing it).

Can helpful people let me know what you think of that spectrum analysis?

One of the tools listed above purports to tell you what firmware you need (much like Sumo/Dumo did for Windows) but I just ran a search.

It's always confusing when I go to a DD-WRT site, as I'm expecting it to be as simple to find the latest firmware as it is on the Netgear site. But it's never that easy when you deal with DD-WRT latest firmware. It drives me nuts just trying to find the latest DD-WRT firmware especially for an older device whose firmware is probably a finality. But I'm not the only one who can't find the latest DD-WRT firmware. Even so, I still would like to ask for help interpreting these million frames. What do those million frames tell anyone about Wi-Fi signal interference?

[snip]

Tx, copied all of this to a another folder in case useful for future reference.

Not entirely sure I agree, but will leave it.

I can't, but maybe others can.

I don't consider myself to be an expert at this sort of thing, but to explain further, it's not the fact that the Tx & Rx were, & are still, different that made me think "Hardware problem?", because I would guess that irregular differences of small numbers of errors might randomly occur in normal conditions & most probably not be significant, it's the consistent one-sidedness with significant numbers of errors that makes me suspect some sort of underlying systemic fault.

An off-the-wall idea: I suspect from parts of your posts that you have some sort of mesh system, and am now wondering if the errors occur because the DD-WRT device gets confused as to which device in the mesh it's supposed to be communicating with, and perhaps if you could find a way of linking it to a particular device rather than to the system as a whole, they would go away? Of course, if I'm mistaken and you haven't got a mesh system, the idea goes out-of-the-window rather than off-the-wall :-)

At any rate, at least things have improved, but I suspect I can't help much further now, because I'm already at the edge of my knowledge.

Yes, it's confusing enough that I bricked one of my Cisco WRT320Ns by putting the wrong image on it, but fortunately managed to revive it to put the correct image on it, and it worked ever after. (I used to have two of them, but cabled one of the connections they covered, so that one became a spare, useful for odd situations, but it died quite recently.)

The best way to manage Android is from Windows, generally over Wi-Fi, but if you keep the phone close to the PC, then USB also works almost as well.

Given Android never removes the original APK installer, you can always copy it to Windows, but there are easier ways than adb to collect all of them.

I didn't say "adb" was the best way to manage Android; I said Windows was. APK sucks because it's a command-line tool - but APK enables GUI tools.

For example, you can mirror Android onto Windows and just slide the APK over from your Windows screen onto your Android screen & that installs it.

You can mount Android as a drive letter onto Windows so you can use the Windows File Explorer to manage every installer APK that you've extracted.

But where are you going to get all the hundreds of installed APKs from? Easy. There are so many good (& bad) APK extractors, I'll suggest this.

But if folks are stuck on the Google Play Store, then I'll suggest this application inspector & extractor which does all that abd did, and more. Note that they're called "APK extractors" but all they do is copy/rename the "base.apk" which Android always stores for every app installed on it.

I googled around a bit and I think I'm supposed to just look for unexpected frames of energy in areas either between channels or spanning channels.

There's so much energy out there that I'm not good at finding where it is.

It seems the lower Wi-Fi channels have higher energies so the only real conclusion I could come up with is to assign APs to the higher channels.

I'm going to run a 5GHz spectrum analysis separately but since the Netgear WNR834v2 is only a 2.4GHz bridge client repeater, it will just more data.

Agreed. Why would transmit be different than receive. Of course that happens all the time when there is a nearby source of in-band local interference because the weaker receive signal is greatly affected by local interference but the stronger transmit signal would be less affected.

But in my situation, it was the transmitted signal that wasn't received 86% of the time, so that points to a problem on the other end (ie on the AP).

I don't think for a moment that simply updating the AP's firmware is what solved it, but I do say that it's the only thing that I overtly did.

Right now, the problem seems to be better (where I'm only losing 3% of the TX & 0% of the RX) which is still lopsided, but at least not 14% to 86%.

It's not a mesh system so much as access points that have to cover a few football fields' worth of area - which may play a role in the noise level.

I repurpose a lot of wireless equipment that I get at the local thrift shops and from a friend in the business so I have a lot of radio gear.

However, that shouldn't matter because a lot of people live in close proximity to a lot of other people who have a lot of diverse radio gear.

What should only matter is the what is immediately on both sides of the wireless bridge repeater, which is just this connection to the Internet: PC <===> wireless client bridge <===> AP <===> main router <===> modem

Me too! I've actually fallen off the cliff going well beyond my knowledge. That's why I had asked here - to find the people who know this stuff.

I figured the people who know the most are gonna be on a.e.w & Windows.

Understood. Agreed. I gave up looking for a DD-WRT update for the Netgear WNR834Bv2 because of that reason (plus I already have its 2023 firmware).

Funny story, a friend bricked his Netgear R7000P similarly so he gave it to me to keep or throw away - which - forever reason - wouldn't factory reset.

A few google's later & quite a few tftp's later, I had a "new" router.

Why do I need the "latest & greatest" router for a simple household when last years' latest & greatest router is being thrown away every year?

It started in the days of RS232 cables but I used to have "a box" for spare wall warts & routers and the like but now it's an entire section of boxes.

The beauty of a router is it can be many things (like an AP or switch). The beauty of Android & Windows is they run many free debugging tools.

I made an omission in my last summary of good debugging tools in that I didn't include the network debugging tool that I tend to use the most.

A. Good Wi-Fi debugger (no tool I suggest will have ads unless noted).

Cellular debugger (these only work with one carrier at a time). Network debugger (these are similar to those on the Windows PC) Every tool I suggest will be one of the best but no one tool does everything so take it simply as a recommendation from me for those.

I'm still hoping to find help in debugging the network so I'll keep checking this thread as I'm sure there are better debugging tools.