• Android debugging tools to find noise source on Wi-Fi wireless bridge w

    From Mickey D@21:1/5 to All on Sun Jan 28 00:32:22 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Mickey D on Sun Jan 28 01:26:04 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bradley@21:1/5 to Paul on Sun Jan 28 05:00:28 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Java Jive@21:1/5 to Mickey D on Sun Jan 28 11:08:41 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mickey D@21:1/5 to Mickey D on Sun Jan 28 08:04:15 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mickey D@21:1/5 to Bradley on Sun Jan 28 07:54:49 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mickey D@21:1/5 to Java Jive on Sun Jan 28 09:26:11 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Java Jive@21:1/5 to Mickey D on Sun Jan 28 15:50:53 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mickey D@21:1/5 to Java Jive on Sun Jan 28 18:32:40 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Java Jive@21:1/5 to Mickey D on Mon Jan 29 11:43:18 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mickey D@21:1/5 to Java Jive on Mon Jan 29 15:15:23 2024
    XPost: alt.internet.wireless, comp.mobile.android

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)