use in another country

Welcome to "Wake on LAN". That's where your the power to the ethernet card or port in your computah remains powered and active even when the computah is turned off. The idea is that some server sends your workstation a "magic packet" that turns on the computer, performs some type of maintenance ritual, and then shuts the computah off. It's kinda nifty technology.

OK, I have heard of Wake on LAN. Sounds useful when you want it, but annoying when you don't. When I installed one network card there was a short jumper cable which I believe was for Wake on LAN support. I am guessing this feature is only possible if the motherboard and PS are designed to support it, or another method (jumper) is installed to bring power to the card.

Thing is, both PCs I am looking at have Wake on Lan capabilities. Machine A (newer, integrated ethernet) had Wake on LAN enabled as a default, yet the router light was never on when the machine was not running. I have occasionally found this machine mysteriously running when I know all my machines were shut down. I have since diabled Wake on LAN on this machine. Should I assume that someone sent a magic packet as part of a scan?

Machine B (older, SMC EZ PCI card) has never had Wake on LAN enabled, yet the router light is on when it is not running. There must be a difference in the design of the different network cards between machines A and B which allows both to support Wakeup, but different behaviors with the router lights. I'd rather the light was out. How do the latest add-in cards behave?

One of the annoying things about a PC we have is that there is no set up for this in the bios and I only found out because of the inbuilt cards Led's remaining lit.It unfortunately doesn't work for a complete power down,in this machines case, but from "Standby".So if I am feeling lazy,I run a DC program which is disabled at midnight, I let the machine go into standby and the following morning I can use a wifi equipped Laptop to restart the PC .Like a lot of things, something to play with. I use this on the laptop:-

handy little extra if you like to play with VNC or such like.

Yep. 3 wires from the card to the motherboard.

Yep. The power comes through the 3 wires. Pull the cable and there's no power on the ethernet card. Most motherboards with ethernet chips have a jumper or bios setting to enable or disable the WOL feature.

No. WOL uses broadcasts. Broadcasts do not usually propogate through firewalls and NAT routers. If your home LAN was directly connected to the internet through a dialup modem, cable modem, satellite modem, or DSL modem, then it's possible that a broadcast came in from the internet and turned on the computah. However, if you have an NAT router in between, the broadcast will not go through to your workstation. You can setup your router for a DMZ to your workstation and everything will go through to it. Some routers and VPN's can also be configured to pass broadcasts. However, the perpetrator will need to know the MAC address of your workstation. That's easy if you're directly connected to the internet (no router). However, if there's an NAT router in the way, everything on the WAN side shows the routers MAC address, and not your computahs MAC address. Therefore, I suggest that it's highly unlikely that someone either accidentally or intentionally turned on your PC from the internet.

There's a light on the motherboard that's usually on when the computah is turned off, but without the cable or jumper installed, there's no power to the ethernet card, so the network lights should be off. I have a Dell Inspiron 4600, with an Intel Pro100+ adapter, that has WOL enabled. Power is off, ethernet lights are on. Lights on the ethernet switch are on. It has to be that way or the link is disabled and no "magic packets" get through. Yank the WOL cable, and all the lights except the one on the motherboard go out.

I don't see the problem with the lights being on.

Already set that way.

8>>

Depends on your NIC ,newer ones have WOL through their PCI connection.

No ,a "refresh of the network state" can cause this.

If you are using XP and wish to disable it go to "network connections" rt click on the ethernet connection and choose properties ,choose "configure" and pick the "Power Management" tab,uncheck the box "Allow this device to bring the computer out of standby".When you next power down the NIC Led's should not be lit.

The WOL "flying lead" cable is NOT installed, and there are no other jumpers on the card. All the APM and adaptor settings have WOL type behavior disabled. No BIOS option exists for WOL on this machine. The only possiblity I see is the card is powered from the VAUX pin on the PCI bus as described here:

It would seem that I just can't get what I'm after.

As to the why, I'd just like the lights on the switch to actually mean something useful and consistent. The most useful meaning to me is that the PC is up and running. It is a simple check to glance at the switch and know that machines or devices that are supposed to be off are off (desktops maybe), and machines or devices that are supposed to be on are on (servers, dataloggers, home control...). My network is simple now, but I plan to add more.

Going a bit further, how about a method/device which would also tell me at a glance (I am thinking LEDs again) the active state of ALL network connected devices, wired or wireless? Can I get the info from my gateway router's tables or do I need an IDS box/firewall? A big switch would kind of do this, except where additional routers or bridges are letting many clients share the same wire. Could a WRT54G be adapted to do this?

My motherboard is comparatively ancient. I don't wanna open the case again to get the make and model. When I yanked on the WOL cable, the lights went out. I guess you're a victim of progress.

I think that was the chorus of a song. "You can't always get what you want. But if you try real hard, my might get what you need".

Well, ok. However, I don't see that as a requirement for proper operation. I use the lights quite a bit for diagnostics and have learned to live with seeing lights on when the computah is off. When I'm in the server room, and staring at a wall full for switches, there's no way for me to tell if anything is alive and well. Yeah, it's inconvenient, but not fatal.

Easy. I do it all the time. It's called SNMP or Simple Network Management Protocol. The latest free release of Sveasoft Alchemy for the WRT54G supports SNMP. I've been playing with it a bit and it seems to work. It will disclose all kinds of connection, status, and traffic information. I'm still putting together a MIB database collection for the WRT54G, so I'm not sure exactly what's in there, but so far, it looks useful.

There are quite a few SNMP tools that can be used to extract the information:

MRTG for traffic graphs: MIB browser (GetIf) If you just want status info for connections, there are programs, such as Big Brother, that will show if a device is up or down by simply pinging it, or trying to download a web page. If you know the device's MAC address, you can obtain the IP address via ARP (address resolution protocol) or just dig it out of the routers SNMP tables, ping the device, and display the return status. If you want to do a first class job of this (on Linux), try Nagios: used this (actually NetSaint.org) years ago to get status info on a mess of Breezecom SA10 radios, which would page me if any of the links went down for more than 10 minutes.

Anyway, SNMP sure beats looking at flashing lights. Good luck.

My apartment area has a wireless internet service called Airimba that you can pay for, but I don't use it. It's set up so that you can connect to it freely, but if you try to browse the internet the Airimba website loads in place of any website URL you type in; and of course any other programs that try to access the internet just don't do anything. However, while I was connected to the Airimba service (having not paid, so I wasn't using the net) Windows Update connected and downloaded some updates! And it turned out I could also open the Windows Update website with a web browser, but no other websites. Is there a logical explanation for this? Is Windows Update somehow getting around Airimba's security? (I wouldn't think they would just allow Windows Update and nothing else...)

come to think of it, I just said myself that the website for windows update does work, so it would seem like they just allow that and no other... but that's just strange...

-->It's called "captured portal" or "portal". It snarfs any webpage you enter and redirects to a message page until you authenticate/login. All other protocols and ports are usually blocked as well. It's up to whomever set the system up. The system I have at my place, I allow exceptions such as windowsupdate, nai.com, adaware.com ( spyware checker ) and symantec.com stuff as well.

Far be it from me to stop someone who wants to patch their system......... ;-)

Scotty

If my wireless setup is for the U.S, and I scan for access points in another country and then connect to that AP, will I be legal? I believe that it makes sense to assume that it's legal but I'm not a lawyer. The country of interest is Costa Rica and the AP of interest is the hotel's.

Are you querying the need for a QR code or pairing-code to be entered? I'd have though that was a worthwhile security "bump" so that Johnny Hacker can't connect to your phone without an action from you ...

Hi Andy,

I think I figured out the problem.

I have never seen a QR code, nor a "pairing code", per se, but of course, there is a pairing process over USB with adb & the phone that is almost automatic where it simply asks me to accept it and remember it when the pairing is initially established.

The problem was that the pairing only happened over USB (not over Wi-Fi). I could only pair over USB (& then I could use the connection over Wi-Fi).

But I think I solved that problem just now when I tried to test it again.

Today I started fresh by killing adb on Windows (C:\> adb kill-server), and then I revoked all previous pairing credentials on the phone. Android 12 Developer options > Revoke USB debugging authorizations

Then I set the Android "Wireless debugging" option on. <== this is new! Android 12 Developer options > Wireless debugging = On

In addition to these two Android settings which I had already turned on. Android 12 Developer options > USB debugging = On Android 12 Developer options > Disable adb authorization timeout = On

So that the Android developer options USB settings looked like this.

I just wanted to get rid of the USB cable, that's all. I think I solved it by setting "Wireless debugging = On" though.

Now I can connect adb to the phone over Wi-Fi _without_ needing the USB cable in the beginning to establish the initial connection credentials.

1. With the phone _not_ connected over USB but only over Wi-Fi to your LAN.
2. On the PC, kill the adb server (to get to a known good starting point). C:\> adb kill-server
3. On the phone, wipe out existing credentials (for a good start point). Android 12 Developer options > Revoke USB debugging authorizations
4. C:\> adb tcpip 5555 error: no devices/emulators found
5. C:\> adb connect 192.168.0.2:5555 failed to authenticate to 192.168.0.2:5555 But, after about 30 seconds, this pops up a query "Allow USB debugging?" on your phone, and (o)Always allow from this computer
6. C:\> adb tcpip 5555 restarting in TCP mode port: 5555
7. C:\> adb devices List of devices attached 192.168.0.2:5555 device

Who knew? Not me.

In summary, my recent experience has been that... A. Pairing between adb & the phone "just works" over USB, and, B. Once paired over USB, then Wi-Fi connections "just work" also, but, C. You need that extra switch to be on to do the pairing step over Wi-Fi. Android 12 Developer options > Wireless debugging = On

These are the settings that worked completely over Wi-Fi (no USB needed).

I admit I had never seen this new QR code option Andy Burns asked about.

Nor have I ever needed to use a six-digit "pairing code" Andy Burns spoke about. Up until now, the connection did all the work for me without either.

That's because for Android 10 and lower, the USB cable pairing was required (even when connecting Android to the Windows PC over Wi-Fi).

To sharpen the saw (aka to learn more about any problem set you encounter), I looked up what the _new_ option of "wireless debugging" does with adb. *How To Connect Wireless Debugging From Developer Options*

From that video I realized you need to both turn on and long press the Android ADB wireless-debugging option in order to even _see_ the QR-code options Andy Burns was asking about, which is why I had never seen them.

While I've been using adb in a rudimentary fashion for years, this "wireless debugging" option is apparently new with Android 11 and up. *Android 11 DP2: Wireless debugging gives developers hassle-free ADB connection*

"Simply put, Wireless debugging will let you leave your USB cable behind and connect your phone to your computer via ADB completely over Wi-Fi. Of course, considering how many potentially bad things you can do to a phone once you have ADB access, it's not as simple as just connect and go."

*Connect to a device over Wi-Fi (Android 11+)* "Android 11 and higher supports deploying and debugging your app wirelessly from your workstation using Android Debug Bridge (adb). This eliminates the need to deal with common USB connection issues, such as driver installation.

To use wireless debugging, you must pair your device to your workstation using a QR Code or a pairing code. Your workstation and device must be connected to the same wireless network."

Even more useful perhaps is you can elevate a non-root phone's privileges. *Wireless Debugging with Termux*

1. On the Android phone, install Termux 2. In the Android Termux, type "pkg install android-tools" 3. On Android, turn on wireless debugging from the developer options menu 4. Then using only Android and no PC whatsoever, pair Android with itself! % adb pair localhost:40737 <then add the 6-digit wi-fi pairing code>

1. On Android, use adb within Termux to connect wirelessly to itself. % adb connect localhost:40737 6. At this point, you can drop into an adb shell inside of Android Termux. % adb shell # run-as com.termux $ Apparently that gives you extra privileges even if you're not rooted.

What is interesing is the _power_ this provides, e.g., Frank Slootweg may be interested that we can port forward over Wi-Fi (which means, perhaps, just maybe we can finally connect on a non-rooted phone over SMB using ports lower than 1024 on Android), and, for example, we can examine our Android sqlite contacts database

. $ adb -s emulator-5554 shell $ sqlite3 /data/data/com.example.app/databases/rssitems.db SQLite version 3.3.12 Enter ".help" for instructions

In summary, this ability to eliminate the USB cable completely is new as of Android 11 and above. It allows us to more easily use adb over Wi-Fi, where we can now perhaps elevate permissions temporarily (e.g., to delete packages that are not delete able or to forward ports for SMB and to examine the default protected contacts sqlite database on Android).

Up until this moment, I couldn't figure out why adb was _still_ flaky.

I just figured out, belatedly so, yet another reason _why_ I keep losing the adb Wi-Fi connection between Windows and Android for screen mirroring.

Boot turns W/L debug off

Previously in this thread, Andy Burns had informed me that Android (11+) has the ability to _initiate_ the connection between adb & Android over Wi-Fi (but only if we turn on the Android "Wireless Debugging" option!).

Remember that in the past (prior to Android 11), the only way you could _initiate_ adb pairing was over USB (and then, after pairing over USB, in the past, you could disconnect the USB and stay connected over Wi-Fi).

Since Andy Burns kindly told me that, I've now been initiating and using the connection over Wi-Fi while keeping the phone on the AC USB charger.

That works - but it too seemed to be a flaky adb screen mirror connection.

It seemed to be working fine while I was using it but after a while, when I came back to the computer, it didn't work anymore, seemingly randomly so. *I just realized that it's _not_ random!*

The reason turned out to be simple even as I had not expected it. *Android 12 apparently turns that option _off_ each time you reboot!*

Who knew? Not me.

Apparently Android 12 turns a _lot_ of things back on/off that you had previously set to be off/on (such as screen rotation), which is a PITA.

The moral of the story is that Android 12, by default, does some pretty stupid things after rebooting, which means you have to constantly remember to manually turn those options _back_ to where you originally set them.

One of those idiotic things Android 12 does upon reboot is it turns off Wi-Fi debugging - which necessitates turning it back on after every boot.

Boot turns W/L debug off

Maybe it's just me, but isn't it stupid that Android unsets options that you had previously set (like screen rotation & wireless debugging)?

For the record, for anyone attempting to reset the Android Advertising ID from Windows, Android 11 and below would reset the id to a GUID, or globally unique ID, (similar to what Windows 95 CoCreateGUID created, according to Mayayana's kind advice on the Android newsgroup today).\

Doubletap to Reset AD ID Set doubletap to any Activity Calling an Intent with a URI Calling an Intent with a GUI

However, notice in Android 12 the GUID at times is set to all zeroes.

Check Advertising ID

We surmised that's because there are two new commands in Android Settings > {Privacy,Google} > Ads > Reset advertising ID Settings > {Privacy,Google} > Ads > Delete advertising ID <== new! Settings > {Privacy,Google} > Ads > Get new advertising ID <== new!

Delete Advertising ID

Apparently "delete" isn't so much a delete as a "zero out" such that the GUID is of the form (8-4-4-4-12) of 00000000-0000-0000-0000-000000000000.

This program is the only known program in all of Google Play that is known to report that Advertising ID outside of the Android Settings GUI. *Device Identifiers* by Umang Chamaria Free, ad free, Google free, GSF free, rated 3.8, 5K+ installs

But it's a crappy program otherwise as that's its only real job (still, it's the _only_ one anyone knows about that does that).

These are better for reporting most of the identification IDs on Android. *DevCheck Hardware and System Info* by flar2 Free + inapp, ad free, Google free, gsf free, rated 4.8, 1M+ installs

*Device ID* by Evozi Free, ad free, Google free, GSF free, rated 4.5, 1M+ installs *Inware* by evowizz Free, ad free, Google free, gsf free, rated 4.4, 100K+ installs *Device Info HW* by Andrey Efremov Free, ad free, Google free, gsf free, rated 4.7, 1M+ installs *Device ID* by BINHDRM26 Free, ad free, Google free, gsf free, unrated, 10K+ installs *Device Identifiers* by Umang Chamaria (this gets the advertising ID) Free, ad free, Google free, GSF free, rated 3.8, 5K+ installs

Unfortunately, I haven't found one app which gives you everything you need.

If you can find an app that does all that we need, that would be great, as it would be nice, for example, to have all the critical versions spit out by a single app. Android Security Patch Level version Google Play Services version Google Play Store version Google Play System update version Android Device ID Google Services Framework ID Google Advertising ID Java VM Android Runtime version Media DRM Widevine CDM Device Unique ID Hardware Serial Number Device Build Fingerprint etc.

Has anyone here used WebDav to mount Android onto Windows as a drive over Wi-Fi? If so, can _you_ see your Android external sdcard from Windows over Wi-Fi?

I can't. I can see _everything_ else (including the root filesystem!) but not the sd card. (Note I'm not rooted but that shouldn't matter to see the sd card, should it?)

Today attempted these permission-addition commands because the Windows mount of the Android file system doesn't access the external sdcard over Wi-Fi. C:\> net use Z: \\192.168.0.2@8080\DavWWWRoot

I also tried adding a login/password of (foo/bar) but that didn't matter. C:\> net use Z: \\192.168.0.2@8080\DavWWWRoot /USER:foo bar

And I tried specifying the root directory: C:\> net use Z: \\192.168.0.2@8080\storage\emulated\0 /USER:foo bar C:\> net use Z: \\192.168.0.2@8080\storage\0000-0001 /USER:foo bar

At least not when using this free WebDav server on Android to mount Android as a drive letter onto Windows over Wi-Fi using that Windows "net use" command. *WebDAV Server* by The Olive Tree

The problem I'm having with Android 12 connecting to Windows is that I can set the WebDav server root to anything I want to in the WebDav server GUI:

Mount Android over Wi-Fi

But from Windows I can see everything on Android (including the root file system) except what is on the external sdcard (even though, on Android, I can easily see what's on the external sdcard).

Using this adb tutorial to check if permissions are the problem, I run: C:\> adb shell pm list packages | findstr "webdav" package:com.zq.webdav.app_free <== this is ad free but more complex package:com.theolivetree.webdavserver <== this is the one I'm using To list its permissions I can run this but it didn't find any permissions. C:\> adb shell pm list permissions | FindStr "com.theolivetree.webdavserver"

This "might" grant it permission to read external storage: C:\> adb shell pm grant com.theolivetree.webdavserver android.permission.READ_EXTERNAL_STORAGE

But, unfortunately, even though I can see the Android root file system from Windows (with Android being a drive letter), I can't see the external sdcard for some reason.

What's odd is I can see literally everything _except_ the external sdcard from Windows with Android mounted as a drive letter over Wi-Fi.

Has anyone here used WebDav to mount Android onto Windows as a drive over Wi-Fi? If so, can _you_ see your Android external sdcard from Windows over Wi-Fi?

In summary, the situation is thus for mounting Android to Windows over Wi-Fi: a. I'm not rooted (and yet I can see the root file system) as a drive letter. b. The WebDav server _says_ it will mount Android over Wi-Fi as a drive letter. c. But _only_ the external sdcard will not show up in that Windows mount.

Why? What's the solution?

Aurgh.

There's _another_ common situation where the wireless debugging option is turned off without your action, which is if you turn off your Wi-Fi, even for a moment.

Wireless debugging option Wi-Fi off turns W/L debug off

The bad news is Android 12 is incessant in turning _off_ the Wi-Fi debugging Developer option since almost any disconnect from Wi-Fi turns the setting off.

But luckily the good news it that once you know it's automatically turned off by a bunch of things, you can manually turn it back on easily enough.

The reason you want to bother with "Wireless Debugging = On" is that it allows you to mirror and control your Android phone over WiFi on your PC.

Note that you do not need Wireless Debugging to be set in order to mount the entire Android native file system (even root) over Wi-Fi using WebDav. NET USE Z: \\192.168.0.2\DavWWWRoot /USER:username password

Note that "DavWWWRoot" is simply whatever you've set it to be on the phone.

WebDav has no sd permission X-plore has no permission File Manager has permission My Files has permission Permissions are the same