XPost: alt.comp.os.windows-10, comp.mobile.android   
   From: java@evij.com.invalid   
      
   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.wif   
   -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_do   
   nload_firmware.3F   
   > https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/   
   > https://ftp.dd-wrt.com/dd-wrtv2/downloads/betas/2024/   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)