For years now, I’ve been a huge fan of Nir Sofer’s software tools. Along the way, I’ve often used his NetBIOS Scanner (NetBScanner). It shows me which IP addresses Windows PCs occupy. Two weeks ago, I noticed PatchMyPC supports a tool named Advanced IP Scanner. I’ve now tried it out. I can say I totally find Advanced IP Scanner worth using. It appears as this story’s lead graphic, in fact.
This NetBScanner output shows only Windows and other devices with NetBIOS names; Advanced IP Scanner (top) shows EVERYTHING IP.
If Advanced IP Scanner Worth Using, What About NetBScanner?
Once I started using the former, I immediately saw the limitations of the latter. Simply put, NetBScanner shows only 8 entries; Advanced IP scanner shows 18. It even includes devices that lack NetBIOS names but participate in the LAN (e.g. my ASUS WAP, my thermostats, and my TV). Better still, it shows the IP addresses that some of my PCs (laptops, mostly) use for Wi-Fi and GbE, along with which one is live at present and which one is unused (e.g. X380).
There’s more: as I was troubleshooting my PING and RDP issues earlier this week, I learned to make use of the right-click tools it offers for devices whose IP addresses it shows. You can access its maker’s own Radmin utility to jump directly into its version of remote administration of anything showing.
To me, though, the right-click Tools menu is both interesting and helpful. Shown above this paragraph, it lets you run a variety of commands in a cmd.exe window against the highlighted item. I used it to run PING tests point-to-point on my LAN and eventually got everything working. It also turns out to be a handy way to launch RDP as well.
Remember: Cools Tools Rule
I’ve come to like this free, informative and easy-to-use utility enough to add it to my top tier Windows tools collection. I call these “Cool Tools.” For me, they are essential items in my administration and troubleshooting toolbox. If you try Advanced IP Scanner out, I predict you’ll want to add it to your lineup, too.
Apocryphally, PING stands for “Packet InterNet Groper” (or perhaps, “Packet Inter-Network Groper”). Actually, I think it comes from submarine-speak. There, a PING denotes the return sound that sonar makes when reflected. I’ve been troubleshooting a persistent RDP issue with the Lenovo P360 Ultra SFF PC. En route, I just fixed an inability to PING that node. Changing Advanced Sharing All fixes PING, as far as I can tell. Deets follow…along with an RDP fix.
Why Say: Advanced Sharing All Fixes PING?
First off, I relaxed all entries under the “All Networks” heading in Advanced sharing settings (Control Panel). Then, PING started working on the P360 Ultra. Easy-peasey, but not terribly safe.
Interestingly, I then went back and changed the settings to their defaults. That’s “the other option” in all thee cases shown. PING kept working, but the sharing was tightened back up.
Comparing P16 and P360 Ultra
What’s even more interesting is that the other “new machine” here does RDP and PING just fine. That’s the latest Lenovo Loaner here at Chez Tittel: the P16 Mobile Workstation. I’ve had no issues with networking and RDP on that other machine. But I was still unable to remote into the P360 Ultra.
I switched to the Remote Desktop app, and got a more informative error code: 0x4. In researching possible fixes, I found a reghack under that heading at TechDirectArchive. Since I’d already tried everything else recommended in that story, I tried that too.
Here’s the Remote Desktop app with the P360 Ultra under its wired IP address: 192.168.1.192. Problem solved!
It had me create a new Regkey named MaxOutstandingConnections in HKLM\CurrentControlSet\Control\Terminal Server. As suggested, I set its value to 0x10000. And guess what? Both the Remote Desktop Connection application (mstsc.exe) and the Remote Desktop app (show above) now work!
Go figure. All I can say is “What a relief!” It’s been driving me bananas…
For years now, I’ve wondered why some of my RDP connections work only some of the time. Now I know why, and it’s provokes a Homer Simpson response “Doh!” Now that I’m done laughing at myself, let me explain how I got that RDP mystery finally resolved.
I was working with my various Thunderbolt docks this weekend, and I noticed that a previously not-working RDP connection started working again. Turns out that of necessity devices with both GbE and Wi-Fi adapters have separate and distinct IP addresses for each such adapter. Therein lies the key to the mystery, as shown in the lead-in graphic.
Explaining How RDP Mystery Finally Resolved Itself
This all started when I had to move my X12Hybrid dock upstairs. When I disconnected from the dock, and its GbE connection, the RDP connection defined for X12Hybrid (also the machine name used in RDP) resumed working. Then it hit me: because the GbE connection uses a different IP address from the Wi-Fi connection, my RDP definition works only when the IP address it knows about matches the address actually in use. Again: “Doh!”
You can see this clearly in the dual windows shown in the lead-in graphic. PowerShell is in top position, and shows that nslookup stores the IP address associated with the Wi-Fi interface (192.168.1.20). But when I plug the GbE interface in, it takes a different address instead. That private IP address ends with .39, as shown in the NetBScanner window at bottom of the same graphic.
How to Adapt to Changing Connections
The primary router on my local network is an Arris model: it comes from Spectrum as part of its Internet connection and services. I’ve not figured out how to forcibly reset its address tables for DNS lookups on Windows machine names. Instead, I use NirSoft NetBScanner when an RDP connection fails and enter the correct IP address instead of machine name in its “Computer” data field. This works every time.
By observation, it looks like this data updates every 24 hours or so. If I leave the RDP connection unchanged (no switch from Wi-Fi to GbE, or vice-versa) over that interval, nslookup eventually matches the current address. But at least I now know why this is happening, and why using the IP address for the NIC in use fixes the issue.
That’s the way things go here in Windows World, where I still manage to surprise myself by relearning the obvious. Sigh.
OK then, we’re sending my son off to college where he will have both a portable laptop (going with him) and a more powerful desktop (shipped in advance). Inspecting travel cable bag contents to take inventory, I find the following items:
- 2 2.4 Amp iclever dual USB port wall chargers
- 2 USB-A to lightning cables, 10 ft
- 1 USB-A to lightning cable, 2 ft
- 1 USB-A to USB-C cable, 2 ft
- 1 USB-C to USB-C cable, 2ft (for next item)
- Sabrent USB-C NVMe drive enclosure PCIe x.3
- 1 RJ-45 Cat6e network cable, 6 ft
The whole thing weighs in at 795g (1 lb 12 oz). It fits nicely in the front pouch of my soft-sided Targus computer briefcase when we go on the road. I bought a duplicate for the boy to take with him to school.
After Inspecting Travel Cable Bag Contents…
We’re usually charging stuff — phones, mostly — until we go out the door, so the cable bag is one of the last items to go into my briefcase. Please note: the image serving as the lead-in graphic obviously belongs to an Apple-head. While we do all have iPhones (and thus, lightning cables) the rest of our stuff is Windows centric. So the picture doesn’t show the local story. I just grabbed it from Amazon for eye-candy.
This time out, the travel briefcase will start out with 3 laptops: my work unit, another for other family members, and the laptop for school use. Those items are, respectively:
- A Lenovo X1 Extreme, i7 32 GB RAM, 1.5 TB across 2 SSDs
- A Lenovo Yoga 7i 14″, 16 GB RAM, 1 TB SSD
- A Lenovo X390 Yoga, 16 GB RAM, 1 TB SSD
It will probably make the TSA guys wonder why we need 3 laptops when we transit the x-ray machine tomorrow. It is what it is, and I’ll just have to tote the weight until we can do a little lightening when the boy heads off to his dorm on Sunday. Please: wish us all luck! Some of us may need it more than others, but you can never have too much…
Drat! In jacking around with my Belkin Thunderbolt 3 Dock Plus today, I couldn’t help but notice that the wired Ethernet port wasn’t blinking. Further testing included multiple cables and connections to the same port, none of which worked. When I tried a passive Thunderbolt 3 mini-dock in the other USB-C port on the Lenovo X12, that wired Ethernet port worked immediately. Thus, I can only conclude that Thunderbolt Dock loses GbE port is the right diagnosis. Sigh.
Note: The lead-in graphic for this story shows the rear view of the aforementioned Belkin device, with its RJ-45/GbE port at the left. No blinkin’ lights, man!
If Thunderbolt Dock Loses GbE Port, Then What?
For the time being, I’m using another dock — the Thunderbolt 3 Minidock — just for its RJ-45 GbE connection. Good thing my X12 Hybrid has a spare USB-C/Thunderbolt port, eh?
Longer term, I’ve already contacted Belkin about sending me a replacement. They’ve got a nice looking Thunderbolt 4 dock for sale now, so hopefully they’ll ship one my way. I’ve also gone ahead and ordered the CalDigit TS4, reputedly one of the best Thunderbolt 4 docks on the market today.
Thunderbolt 4 Docking Brings Other Benefits
Acquiring one or more Thunderbolt 4 docks will also help with my ongoing testing of NVMe SSD enclosures. As I reported a few days ago, switching from USB-C/3.1 or 3.2 to Thunderbolt 3 makes a difference in IO performance on my fastest SSD enclosure/drive combos. I’m curious to see if a bump to Thunderbolt 4 will make any additional difference.
According to what I read, throughput doesn’t vary that much for external drives from Thunderbolt 3 to 4. I’ve also observed that synthetic IO tests (e.g. CystalDiskMark) tend to overstate the real-world speed-ups available from faster buses. Thus it will be interesting to observe exactly how much difference the bump from 3 to 4 makes.
Stay tuned! I’ll let you know what comes of that testing. Should be fun!
OK, then. Yesterday, we spent a small fortune packing up and shipping out a tower PC and 27″ monitor to my son’s college address. In the aftermath, I moved the other B550 tower with Ryzen 5800X upstairs to his room. But alas, because I left the high-end, PCIe WiFi card in the shipped-out unit, I couldn’t get any of my plug-in (or built-in) WiFi devices to connect to the Spectrum router. Hence my claim that signal strength impedes swapped PC WiFi access.
Overcoming Signal Strength Impedes Swapped PC WiFi Access
There’s a whole litany of checks I ran through to see if I could get such WiFi devices as were at my disposal working. The PC could “see” the Spectrum router. Alas, it just couldn’t connect, not using any of the following:
- A 5-year old Asus 802.11ac USB 3 (USB-AC 56) device with external antenna
- A similar vintage NetGear 802.11 ac USB 3 (AC 600) device with no external antenna
- The built-in M.2 slot with a non-Intel 802.11ax mini-card (but no external antenna)
I worked through all of the following checks, too, just to cover all the bases:
1. Reboot PC to reset startup network settings
2. Ran the network troubleshooter
3. Enable/disable device drivers in Device Manager
4. Reset Network Settings as per ElevenForum Reset Network Adapters in Windows 11 tutorial
No joy on any of these, though. Sigh.
An Alexandrine Solution?
Eventually, I installed a switch at the RJ-45 wall jack upstairs, then ran a long cable from that switch into my son’s bedroom to give him a direct, wired Internet connection. Of course, that worked right away once I’d gotten all the pieces and parts plugged in properly.
The story does have a happy ending, though. Check out the Fast.com speed test results I obtained after setting up the wired link into that PC. This is the fastest I’ve ever seen on my LAN.
I didn’t realize the Spectrum router could exceed 1 Gbps on its end. This PC has a 2.5 GbE interface, so it’s capable enough. But given a GbE LAN exceeding the speed limit makes me wonder…
Earlier this week, MS released Build 25158 into the Dev Channel. Among the many notes in this build’s announcements, you’ll find an item that starts off “DNS over TLS testing is now available for Windows DNS client query protection.” Thus, when Build 25158 gains DNS over TLS support, that means improved security for DNS traffic on networks everywhere. Given that DNS is a constant focus for direct and indirect attack, this is a good thing. So, how can you try this new feature out?
Putting Build 25158 Gains DNS Over TLS Support to Work
For brevity and convenience, DNS over TLS is usually abbreviated as DoT. Two ingredients are needed to take DoT for a spin:
1. You need to point your IP stack at a DoT DNS server. You’ll find a list of same at the DNS Privacy Project. It provided the lead-in graphic for this story, in fact. For the nonce, I’m using Google’s 188.8.131.52 and 184.108.40.206 addresses (and associated domain names for certificate authentication). There are several other options available.
2. A series of configuration tweaks, including Settings changes, and netsh and ipconfig commands, are required to set this up and make it work. Fortunately, all those details are covered in an MS Networking Blog post entitled “DNS over TLS available to Windows Insiders.” Therein, Tommy Jensen provides nicely illustrated step-by-step instructions to get you through the process.
More to Follow After Additional Try-Outs
I have two (2) test machines running Build 25158. I’ll try DoT on both of them, and let you know what happens. Mr. Jensen’s post on setting things up includes a potentially scary phrase. That is “This may result in a small performance improvement depending on the network environment at the cost of the flexibility HTTPS-based protocols can provide” (italic emphasis mine).
I’m afraid I know what this means. Indeed, I’ll be curious to see what’s still working — and what’s not — after experimenting with these changes. Given an upcoming out of office adventure, I might wait until week after next to put this to a real test. Stay tuned! In the meantime, you might find this Wikipedia article about DoT worth a quick read-through (good discussion and lots of good additional references there).
I’ve been trying to understand what’s going on with local machine name handling on my LAN this week. Along the way, I’ve found a NetBScanner blind spot in that otherwise excellent NirSoft tool. Here’s the thing: as you can see in the lead-in graphic, NetBScanner does not include the name/address info for the scanning PC in its results. Those appear in the nslookup results in the cmd prompt window below.
What NetBScanner Blind Spot Means
I was quickly able to find another Nirsoft tool that does a complete scan, including the scanning PC — namely FastResolver. But alas, some tinkering with that tool is required to make it show only occupied IP addresses in a target range. That’s shown in the next screencap, which includes the scanning machine in its results:
Note that the i7Skylake item, IP 192.168.1.63, appears in the list along with all other items that NetBScanner shows above.
One of the most interesting things about using tools properly requires understanding their limitations. I just learned an important limitation for NetBScanner (ditto for FastResolver) in figuring this out.
Other Lessons Learned
I’ve now observed also that it takes the Spectrum router 24 hours to update its LAN entries in its DNS database. That’s entirely consistent with the default timeout of 24 hours for “positive DNS cache” entries. So now I understand that when a machine name won’t resolve to the correct IP address, it’s because DHCP has leased a different IP address to that host sometime in the past day. If I give it time, it will catch up. Good to know!
Man! I am NOT a happy camper right now. I just figured out that my DHCP leases have changed, but DNS isn’t tracking same. Thus, my “fixed” correlation between machine name X12Hybrid and 192.168.1.20 is no longer valid. The last digits of the IPv4 have changed. But NSlookup still sees the aforementioned address. And in attempting to troubleshoot the issue, I’ve just learned I can’t login to my router from a PC on my LAN. Because a phone only app manages spectrum networks, I must go through my iPhone.
Why Phone Only App Manages Spectrum Networks Is a Drag
I’m used to getting up close and personal with the Spectrum router through a web-based login. I know that interface, and can use it well. Now I not only have to learn a new interface instead, I must also:
- run it through a smartphone with a ~3″x6″ display
- try to figure out how (or perhaps even if) what I already know how to do inside one utility still works in another
It’s frustrating to be FORCED to use a cellphone when I have large screens at my disposal. I’ve shared my sentiments with the Spectrum tech support crew — a nice and genuinely helpful bunch of folks — but it seems to make little difference.
That’s progress, I guess. I can’t say I see this as a step forward. I can approve of using the phone app as an alternative to the old way. I can’t approve of using it as an out-and-out replacement. Sigh.
Certain recent Dev Channel builds have played intermittent hob with RDP. Thus, for example, I had to switch from using the machine name to its IP address to RDP into one particular PC. In troubleshooting that issue, I quickly realize it makes sense to use NSlookup for machine name checks. Indeed as you can see in the lead-in graphic, when NSlookup resolves that name correctly, RDP will also accept that name to establish a connection.
Why Use NSlookup for Machine Name Checks?
Because it will tell you if RDP can recognize the machine name. Under the hood, both RDP and NSlookup rely on access to local DNS records to resolve the name into an IP address (see lead-in graphic). When the command line works, RDP should also be able to rely on the same underlying service — namely, DNS — to do its thing as well.
Of course, this raises the question as to why my local DNS server — which runs on the boundary device from Spectrum that sits between my LAN and the cable Internet connection — sometimes fails to resolve valid machine names. Feature upgrades can cancel existing IP address leases, and require the DNS cache to be rebuilt. And apparently, recent lightning storms can also mess with that device’s DNS cache when the power fails. So, I’m learning to flush and rebuild that cache as part of local device hygiene.
At least I now know what’s going on and why I must sometimes switch from machine names to IP addresses to access certain devices. Good thing it’s easy to log into and handle the reset over the LAN. It’s always something, right?