I'm relatively new to wireless networking & ask you for debug advice.
Everything is working but there are errors I'm trying to figure out.
https://i.postimg.cc/FR3X1FC5/settings.jpg

Where that "wireless bridge client repeater" is bridged 1:1 to an
access point which happens to be on the non-overlapping channel 11.

The debug took I'm using on Android to find the noise sources is this.
https://play.google.com/store/apps/details?id=com.ubnt.usurvey

But of course, that only records Wi-Fi sources, not all nearby radios.
https://i.postimg.cc/Bv809Bxv/channels.jpg

While that only shows wi-fi interference sources, there are
no baby monitors nearby that I know of. No microwave in use.
No airport nearby. No doorbell cameras. Nothing that I know of.

Even the phone, connected to that same channel 11 access point
shows a steady downarrow of 390Mbps but the uparrow flips every
few seconds between 433Mbps and 6Mbps (consistently the same numbers).
https://i.postimg.cc/rw1whtBb/android.jpg

While I'm not at all sure what that even means for the uparrow to
be flipping between over 400Mbps and less than 10 Mbps, below are
the basic wireless settings of the bridge connected to the desktop.
1. Desktop PC 1 floor from the main router has no Wi-Fi. Only Ethernet.
2. So I plugged an old Netgear WNR834Bv2 into that Ethernet RJ45.
3. And I installed DD-WRT onto that Netgear WNR834Bv2 & set it up as
Setup | Advanced Routing | Operating Mode = Router
Setup | Basic Setup | WAN Connection Type = Disabled
Wireless | Basic Settings | Radio Mode = Repeater Bridge
Wireless | Basic Settings | Network Configuration = Bridged

How do I debug the high transmission error rate?
Status | Wireless | Wireless Packet Info | Received (RX) = 100%
Status | Wireless | Wireless Packet Info | Transmitted (TX) = 14%

And how do I investigate the source of this continued interference?
Status | Wireless | Access Points & Clients | Signal = -38 dBm
Status | Wireless | Access Points & Clients | Noise = -81 dBm
Status | Wireless | Access Points & Clients | SNR = 43

There are a few questions related to how do I debug?
a. What Android tool will find noise sources _outside_ Wi-Fi channels?
b. How do I test for where all that noise is coming from?
c. Why am I receiving all but losing almost all my bridge packets?

On 1/28/2024 12:32 AM, Mickey D wrote:
> I'm relatively new to wireless networking & ask you for debug advice.
> Everything is working but there are errors I'm trying to figure out.
> https://i.postimg.cc/FR3X1FC5/settings.jpg
>
> Where that "wireless bridge client repeater" is bridged 1:1 to an
> access point which happens to be on the non-overlapping channel 11.
>
> The debug took I'm using on Android to find the noise sources is this.
> https://play.google.com/store/apps/details?id=com.ubnt.usurvey
>
> But of course, that only records Wi-Fi sources, not all nearby radios.
> https://i.postimg.cc/Bv809Bxv/channels.jpg
>
> While that only shows wi-fi interference sources, there are
> no baby monitors nearby that I know of. No microwave in use.
> No airport nearby. No doorbell cameras. Nothing that I know of.
>
> Even the phone, connected to that same channel 11 access point
> shows a steady downarrow of 390Mbps but the uparrow flips every
> few seconds between 433Mbps and 6Mbps (consistently the same numbers).
> https://i.postimg.cc/rw1whtBb/android.jpg
>
> While I'm not at all sure what that even means for the uparrow to
> be flipping between over 400Mbps and less than 10 Mbps, below are
> the basic wireless settings of the bridge connected to the desktop.
> 1. Desktop PC 1 floor from the main router has no Wi-Fi. Only Ethernet.
> 2. So I plugged an old Netgear WNR834Bv2 into that Ethernet RJ45.
> 3. And I installed DD-WRT onto that Netgear WNR834Bv2 & set it up as
> Setup | Advanced Routing | Operating Mode = Router
> Setup | Basic Setup | WAN Connection Type = Disabled
> Wireless | Basic Settings | Radio Mode = Repeater Bridge
> Wireless | Basic Settings | Network Configuration = Bridged
>
> How do I debug the high transmission error rate?
> Status | Wireless | Wireless Packet Info | Received (RX) = 100%
> Status | Wireless | Wireless Packet Info | Transmitted (TX) = 14%
>
> And how do I investigate the source of this continued interference?
> Status | Wireless | Access Points & Clients | Signal = -38 dBm
> Status | Wireless | Access Points & Clients | Noise = -81 dBm
> Status | Wireless | Access Points & Clients | SNR = 43
>
> There are a few questions related to how do I debug?
> a. What Android tool will find noise sources _outside_ Wi-Fi channels?
> b. How do I test for where all that noise is coming from?
> c. Why am I receiving all but losing almost all my bridge packets?
>

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.)

https://greatscottgadgets.com/hackrf/one/

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.

https://www.rtl-sdr.com/using-a-hackrf-to-investigate-why-wifi-on-the-raspberry-pi-4-doesnt-work-when-running-hdmi-at-1440p/

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.

https://en.wikipedia.org/wiki/NetStumbler

https://en.wikipedia.org/wiki/InSSIDer

https://web.archive.org/web/20120920084216/http://appscout.pcmag.com/utilities/274282-inssider-a-wi-fi-network-scanner-for-today-s-wardriver

Paul

On 1/28/2024 1:26 AM, Paul wrote:
> 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.

Every Ubiquiti radio has a full-fledged free spectrum analyzer inside it.
https://help.ui.com/hc/en-us/articles/204950584-airMAX-Guide-to-Channel-Scanning-with-airView

But they are designed for Java 1.6 which had the option for low security.
https://www.manualsdir.com/manuals/742906/ubiquiti-networks-powerbridgm-rockem-picostatiom-nanostatiom-nanobridgm-nanobeam-bullem-airgrim.html?page=9

You have to add an exception which sounds pretty complicated to me to do.
https://af.afmug.narkive.com/FddAuF5B/mug-ubnt-airview-won-t-run

The advantage of Airview is not only that it's free, but it gives you a
waterfall spectrum analysis of everything in the range, not just Wi-Fi.

On 28/01/2024 05:32, Mickey D wrote:
> I'm relatively new to wireless networking & ask you for debug advice.
> Everything is working but there are errors I'm trying to figure out.
> https://i.postimg.cc/FR3X1FC5/settings.jpg

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?

> Where that "wireless bridge client repeater" is bridged 1:1 to an
> access point which happens to be on the non-overlapping channel 11.
>
> The debug took

.... RIP Barry :-) ...

> I'm using on Android to find the noise sources is this.
> https://play.google.com/store/apps/details?id=com.ubnt.usurvey

> But of course, that only records Wi-Fi sources, not all nearby radios.
> https://i.postimg.cc/Bv809Bxv/channels.jpg

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.

> While that only shows wi-fi interference sources, there are
> no baby monitors nearby that I know of. No microwave in use.
> No airport nearby. No doorbell cameras. Nothing that I know of.
>
> Even the phone, connected to that same channel 11 access point
> shows a steady downarrow of 390Mbps but the uparrow flips every
> few seconds between 433Mbps and 6Mbps (consistently the same numbers).
> https://i.postimg.cc/rw1whtBb/android.jpg
>
> While I'm not at all sure what that even means for the uparrow to
> be flipping between over 400Mbps and less than 10 Mbps, below are
> the basic wireless settings of the bridge connected to the desktop.
> 1. Desktop PC 1 floor from the main router has no Wi-Fi. Only Ethernet.
> 2. So I plugged an old Netgear WNR834Bv2 into that Ethernet RJ45.
> 3. And I installed DD-WRT onto that Netgear WNR834Bv2 & set it up as
> Setup | Advanced Routing | Operating Mode = Router
> Setup | Basic Setup | WAN Connection Type = Disabled
> Wireless | Basic Settings | Radio Mode = Repeater Bridge

Here I have Client Bridge obviously.

> Wireless | Basic Settings | Network Configuration = Bridged
>
> How do I debug the high transmission error rate?
> Status | Wireless | Wireless Packet Info | Received (RX) = 100%
> Status | Wireless | Wireless Packet Info | Transmitted (TX) = 14%
>
> And how do I investigate the source of this continued interference?
> Status | Wireless | Access Points & Clients | Signal = -38 dBm
> Status | Wireless | Access Points & Clients | Noise = -81 dBm
> Status | Wireless | Access Points & Clients | SNR = 43
>
> There are a few questions related to how do I debug?
> a. What Android tool will find noise sources _outside_ Wi-Fi channels?
> b. How do I test for where all that noise is coming from?
> c. Why am I receiving all but losing almost all my bridge packets?

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.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On Sun, 28 Jan 2024 05:00:28 -0500, Bradley wrote:

> The advantage of Airview is not only that it's free, but it gives you a
> waterfall spectrum analysis of everything in the range, not just Wi-Fi.

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.
https://i.postimg.cc/KzQ2cjqq/java1.jpg
https://i.postimg.cc/QxF3sXpm/java2.jpg

I'm not sure how to interpret the spectrum analysis though, but this helps.
Ubiquiti airView Walkthrough
https://www.youtube.com/watch?v=NAuaSdzHwoo

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.
https://www.java.com/en/download/help/jcp_security.html

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
https://www.youtube.com/watch?v=1-C-LmZJqLM
Which provided the solution so that I could continue as follows.

5. 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]
6. Now try again: PowerBeam: Tools > Launch Airview > airview.jnlp
That also failed, which the video said might happen.
7. 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
8. Then, everything worked just fine as shown below.
Waterfall Graph: https://i.postimg.cc/KzQ2cjqq/java1.jpg
Channel Graph: https://i.postimg.cc/QxF3sXpm/java2.jpg

Does anyone have an idea how to interpret what the graphs are telling me?

On Sun, 28 Jan 2024 07:54:49 -0500, Mickey D wrote:

> Waterfall Graph: https://i.postimg.cc/KzQ2cjqq/java1.jpg
> Channel Graph: https://i.postimg.cc/QxF3sXpm/java2.jpg
>
> 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: https://i.postimg.cc/kgRLgbQ4/java1.jpg
Channel: https://i.postimg.cc/QxF3sXpm/java2.jpg

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

On Sun, 28 Jan 2024 11:08:41 +0000, Java Jive wrote:

> 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?

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!
https://i.postimg.cc/Bn3Smyz4/sitesurvey.jpg
https://i.postimg.cc/0Qfsz2f4/wivizsurvey.jpg

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'm using on Android to find the noise sources is this.
>> https://play.google.com/store/apps/details?id=com.ubnt.usurvey
>
>> But of course, that only records Wi-Fi sources, not all nearby radios.
>> https://i.postimg.cc/Bv809Bxv/channels.jpg
>
> 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.

I like the Ubiquiti Wi-Fi Man debugger, but is this the one you use?
https://play.google.com/store/apps/details?id=com.vrem.wifianalyzer

Or is it this WiFi Analyzer?
https://play.google.com/store/apps/details?id=com.manageengine.wifimonitor

> ... 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.

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!
https://i.postimg.cc/Bn3Smyz4/sitesurvey.jpg

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.

On 28/01/2024 14:26, Mickey D wrote:
> On Sun, 28 Jan 2024 11:08:41 +0000, Java Jive wrote:
>
>> 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?
>
> 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!
> https://i.postimg.cc/Bn3Smyz4/sitesurvey.jpg
> https://i.postimg.cc/0Qfsz2f4/wivizsurvey.jpg
>
> 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?

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

>>> I'm using on Android to find the noise sources is this.
>>> https://play.google.com/store/apps/details?id=com.ubnt.usurvey
>>
>>> But of course, that only records Wi-Fi sources, not all nearby radios.
>>> https://i.postimg.cc/Bv809Bxv/channels.jpg
>>
>> 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.
>
> I like the Ubiquiti Wi-Fi Man debugger, but is this the one you use?
> https://play.google.com/store/apps/details?id=com.vrem.wifianalyzer
>
> Or is it this WiFi Analyzer?
> https://play.google.com/store/apps/details?id=com.manageengine.wifimonitor

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.

>> ... 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.
>
> 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!
> https://i.postimg.cc/Bn3Smyz4/sitesurvey.jpg
>
> 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.

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.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On Sun, 28 Jan 2024 15:50:53 +0000, Java Jive wrote:

>> That WiViz survey is hard to read. What's all that bouncing around?
>
> Yes, it's a bit manic, but you can alter that in the options.

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 like the Ubiquiti Wi-Fi Man debugger, but is this the one you use?
>> https://play.google.com/store/apps/details?id=com.vrem.wifianalyzer
>>
>> Or is it this WiFi Analyzer?
>> https://play.google.com/store/apps/details?id=com.manageengine.wifimonitor
>
> 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.

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).

> 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.

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)
https://play.google.com/store/apps/details?id=ru.andr7e.wifimonitor
B. Cellular debuggers (these only work for one carrier's SIM at a time)
https://play.google.com/store/apps/details?id=com.qtrun.QuickTest
C. 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).
https://play.google.com/store/apps/details?id=com.etwok.netspotapp

And tools to tell you if you're using the latest patches & router firmware.
https://play.google.com/store/apps/details?id=com.stoutner.privacycell

There are even tin-foil-hat tools to find if insecure protocols are used
https://play.google.com/store/apps/details?id=de.srlabs.snoopsnitch

And for the tin-foil-hat user, tools to find stingrays (IMSI catchers).
https://play.google.com/store/apps/details?id=com.skibapps.cellspycatcher
WARNING: No app from me will have ads unless I say so; this one does.

> 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.

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.

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

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.
https://i.postimg.cc/jSBfSgRC/baseapk.jpg

>> 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.
>
> 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.

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).
https://i.postimg.cc/8krQvmf8/longtime.jpg

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

> 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.

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.
https://wiki.dd-wrt.com/wiki/index.php/Netgear_WNR834Bv2

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. https://www.netgear.com/support/product/wnr834bv2

But it's never that easy when you deal with DD-WRT latest firmware.
https://wiki.dd-wrt.com/wiki/index.php/Index:FAQ#Where_do_I_download_firmware.3F
https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/
https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/2024/
https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/2024/01-23-2024-r55009/

It drives me nuts just trying to find the latest DD-WRT firmware
especially for an older device whose firmware is probably a finality.
https://www.google.com/search?q=latest+firmware+dd-wrt+WNR834Bv2

But I'm not the only one who can't find the latest DD-WRT firmware.
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=289360&sid=5c43d9b0e602c12f2c7a8414a4a6a837

Even so, I still would like to ask for help interpreting these million frames.
https://i.postimg.cc/8krQvmf8/longtime.jpg

What do those million frames tell anyone about Wi-Fi signal interference?

On 28/01/2024 23:32, Mickey D wrote:
>
> On Sun, 28 Jan 2024 15:50:53 +0000, Java Jive wrote:
>>
>
> 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)
> https://play.google.com/store/apps/details?id=ru.andr7e.wifimonitor
> B. Cellular debuggers (these only work for one carrier's SIM at a time)
> https://play.google.com/store/apps/details?id=com.qtrun.QuickTest
> C. 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).
> https://play.google.com/store/apps/details?id=com.etwok.netspotapp
>
> And tools to tell you if you're using the latest patches & router firmware.
> https://play.google.com/store/apps/details?id=com.stoutner.privacycell
>
> There are even tin-foil-hat tools to find if insecure protocols are used
> https://play.google.com/store/apps/details?id=de.srlabs.snoopsnitch
>
> And for the tin-foil-hat user, tools to find stingrays (IMSI catchers).
> https://play.google.com/store/apps/details?id=com.skibapps.cellspycatcher
> WARNING: No app from me will have ads unless I say so; this one does.
>
[snip]
>
> 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

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

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

Not entirely sure I agree, but will leave it.

>>> 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.
>>
>> 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.
>
> 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).
> https://i.postimg.cc/8krQvmf8/longtime.jpg
>
> Can helpful people let me know what you think of that spectrum analysis?

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.

> 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. https://www.netgear.com/support/product/wnr834bv2
>
> But it's never that easy when you deal with DD-WRT latest firmware.
> https://wiki.dd-wrt.com/wiki/index.php/Index:FAQ#Where_do_I_download_firmware.3F
> https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/
> https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/2024/
> https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/2024/01-23-2024-r55009/
>
> It drives me nuts just trying to find the latest DD-WRT firmware
> especially for an older device whose firmware is probably a finality.
> https://www.google.com/search?q=latest+firmware+dd-wrt+WNR834Bv2
>
> But I'm not the only one who can't find the latest DD-WRT firmware.
> https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=289360&sid=5c43d9b0e602c12f2c7a8414a4a6a837

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.)

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On Mon, 29 Jan 2024 11:43:18 +0000, Java Jive wrote:

> CMD: adb install com.keuwl.wifi.apk
>
> Tx, copied all of this to a another folder in case useful for future
> reference.

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.
https://play.google.com/store/search?q=apk%20exttractor&c=apps

>> The best way to manage an Android phone is always going to be from Windows.
>
> Not entirely sure I agree, but will leave it.

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.
https://f-droid.org/packages/com.apk.editor/

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.
https://play.google.com/store/apps/details?id=com.ubqsoft.sec01

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.

>> Can helpful people let me know what you think of that spectrum analysis?
>
> I can't, but maybe others can.

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.

> 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.

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%.

> 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 :-)

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

> 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.

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.

>> But I'm not the only one who can't find the latest DD-WRT firmware.
>> https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=289360&sid=5c43d9b0e602c12f2c7a8414a4a6a837
>
> 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.

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?

> (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.)

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).
https://play.google.com/store/apps/details?id=com.vrem.wifianalyzer
B. Cellular debugger (these only work with one carrier at a time).
https://play.google.com/store/apps/details?id=com.qtrun.QuickTest
C. Network debugger (these are similar to those on the Windows PC)
https://play.google.com/store/apps/details?id=com.tools.netgel.netx

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.