OK, I admit it. I hadn’t set up DHCP reservations on my LAN. I could try to blame the Spectrum-supplied router that provides DHCP, but it’s really my fault. Thus, when I saw my Samsung ML-2581ND laser printer was offline yesterday morning, I immediately knew what was up. Generally, when the Samsung Network Printer goes missing on my LAN it’s because DHCP has assigned it a different IP address.
Look at the lead-in graphic for this story. There you’ll see that the device (Samsung ML-2850) is associated to Private IP 192.168.1.126. It had previously been …127. And as soon as I changed that address selection on the Ports tab of Printer Properties, it started working again. So how did I figure out which port it had actually been assigned?
When Samsung Network Printer Goes Missing, Then What?
That’s when I call on one of Nir Sofer’s handy network utilities — namely NetBScanner. It quickly scans the local cable segment on its address range. In fact, the program is smart enough to figure that out on its own, after which it supplies a short list of all occupied addresses in that range. Here’s what I saw when I scanned my local wired Ethernet:
Notice the entry for …126 which also shows the device name SAMSUNGNWP. That’s what I want!
It turns out I already had defined this address in the Ports tab, so all I had to do was switch the device from the now-incorrect …127 entry to the current …126 entry and it was done. That meant unchecking the box next to the former, and checking the box next to the latter. Dead simple, quick and easy to fix. As long as you know how, that is…
The Right Fix is a DHCP Reservation
DHCP lets admins make static address assignments from the IP address pool it manages. That way, devices like servers and printers can keep the same address forever, and DHCP won’t move those assignments around, as it otherwise might. That shows up under the Advanced and DHCP tabs on my Askey RAC2V1K boundary device. I reserved the …126 address for the Samsung ML-2850 and also the …15 address for my Dell Color Laser CB745E. The latter is shown here:
By supplying the MAC address and the desired (reserved) IP address, you tell DHCP “hands off” for future assignments.
[Click image for full-sized view.]
So now, I’ve done what I should have done long ago, thanks to sharing my (prior) shame with you, dear readers. Live and learn!
I’ve been trying to untangle a weird mix of networking and telephony issues going on three days now. As I write this item, in fact, I’m texting with a Verizon tech support person. He’s trying to unsnarl a mix-up around a new 5G MiFi hotspot I purchased recently. When the device was set up, it was mistakenly tied to my son’s cellphone number. Then, the tech support people tried to switch things around. Alas, they exceeded the allowable number of reset attempts. This requires a 24 hour wait before a retry is allowed. The 24 hours are up, and I’m trying again. Does this explain why untangling cascading troubles gets frustrating?
How Untangling Cascading Troubles Gets Frustrating
Let me count the ways.
Verizon Tech Coaches can’t call my cellphone. It doesn’t ring because of a setting that’s available only in iOS 13 or higher. My iPhone is running 12.5. So I had to work through amazing contortions to get them to call my landline.
The MiFi device hadn’t been working properly. Thus, I wasn’t able to activate it myself. First I learned how to pop the back off the device. Then, I did the old “paper clip in the recessed reset switch” routine to return it to factory settings. After that the UI worked just fine.
As an iOS guy I found myself messing with Gregory’s Android OnePlus 7 Pro. This had me remembering and relearning all kinds of interesting stuff. I’m now more familiar with its UI, device settings and config data . I also now remember what’s up with ICCID and IMEI identifiers.
When my tech support person tried to reset the accounts properly, the provisioning software let him make the changes, then came back and told him “transaction disallowed.” He’s now roping higher level support team members in to reset database rules to make this happen.
The way I got into this snafu to begin with is that my Spectrum Internet connection won’t pass Remote Desktop Protocol through its firewall. When I attempted the necessary port forwarding operations, the device proved unable or unwilling to read the external (WAN or rather cable side) IP address, even though I can see it just fine (and Ping it) from my LAN PC. That led me to say “I can use my MiFi 5G hotspot instead” and started me down the rabbit hole.
So here we are solving problems we didn’t know we had, and dealing with mixups based on pure human frailty.
Tech Support Needs Unified Communications, Badly!
The most amazing thing I’ve learned is that at least two separate tech support operations at Verizon are inappropriately silo’ed. Their Tech Coach operation cannot place voice calls. They are restricted to online chat only. I made the mistake of initiating contact with them on my cellphone, and they couldn’t easily switch over to a PC session, either. I did figure out how to make that happen later on, though so online via cell and via PC do have some integration.
But their app is limited to calling only registered Verizon devices. So when I tried to have them call my cell early on for a voice session, I found myself in a Catch-22. I wanted them to call me, they called me, but my only acceptable target device wouldn’t allow that call to ring in (that’s the iOS setting for version 13 and up, which is turned on and immutable for 12 and under versions and so can’t be accessed or changed on my aging iPhone 6).
At this point it’s taken me over 7 hours to solve a set of problems that are only tangential to the real problem I want to solve with accessing a public IP using Remote Desktop. I’ll get to that and another series of tech support calls with Spectrum next week.
Take a Deep Breath, and Keep Waiting
But I’m learning how to keep calm and carry on in the face of massive frustration. I suppose I should be glad that I’m not the human responsible for the error that triggered this cascade. Lord knows I have been the guilty party often enough myself to write about it regularly in this very blog!
But Wait: There’s More
Yesterday when I wanted to blog about this situation, my ISP’s behind-the-scenes MySQL WordPress server went down. Thus, I was unable to access or post anything until that got fixed. The error cascade is apparently catching, so perhaps you shouldn’t have read this far. Brace yourself!
I ran into an interesting problem this weekend. The “Your credentials did not work” error appeared when I added my usual MS admin-level account to the Lenovo X390 Yoga. I checked all the usual suspects with no change in status. That means: remote access settings, account status, and so forth. Ultimately I had to search the error message via Google. And that, dear readers, is how I learned group policy edits fix broken RDP credentials.
How Group Policy Edits Fix Broken RDP Credentials
Even though I was using the same long-standing Microsoft Account I use for admin level login on all of my Windows 10 PCs, this one wouldn’t work. At one point, error messages informed me about a problem with LSASS (local security authority subsystem service, the OS component that handles logins). Later on, that error changed to “Your credentials did not work.” Sigh.
Because I had no trouble using the same account name and password (plus 2FA authentication through MS) to log into that PC locally, I knew the problem was focused on RDP. And indeed I turned up an extremely helpful article at Appuals.com. Entitled Fix: Your Credentials Did not Work in Remote Desktop, it let me to a working solution.
Group Policy Changes Needed
For me the items I had to enable, and then add the value TERMSRV/* resided in the edit path named Computer Configuration > Administrative Templates > System > Credentials Delegation
Those items numbered 4, as follows:
1. Allow delegating default credentials with NTLM-only server authentication
2. Allow delegating default credentials
3. Allow delegating saved credentials
4. Allow delegating saved credentials with NTLM-only server authentication
Once I had made those changes, I had to restart the target PC. I also had to manually re-enter the credentials I’d attempted to use beforehand (without success). Then, finally: Boom! RDP accepted my connection attempt on the usual MS admin account. Problem solved. That was an odd one…
I went through an interesting adventure this weekend. I found myself trying but unable to reset the password for my Apple ID account — or so I thought, anyway. It wasn’t until I spent a couple of hours trying to fix things on my own that I gave up and turned to Apple Support instead. To my relief, the support rep recognized my problem more or less instantly. He showed me that I had logged into different accounts for iCloud and the Apple Store. Then he explained there are implicit perils when multiple accounts get interlinked in that way.
What Are the Implicit Perils When Multiple Accounts Get Interlinked?
Long, long story short when I was trying to change my password for one account I ended up changing it for another. The iCloud account took precedence over the Apple ID account for whatever reason. I didn’t see any visual cues to tell me that’s what I was doing. Thus, it took a call to tech support to clear up my misunderstanding.
Now, though, things have been set straight. I’ve got known usable passwords for both Apple accounts and have disentangled use of the two IDs on my iPhone which caused that immensely frustrating and bizarre set of symptoms and circumstances.
One More Thing, Though…
Right now, I can use my credentials on Firefox to access appleid.apple.com. But those same credentials don’t work on Chrome. I’m mystified and mortified, but I have no earthly idea why this is happening. Aha! Internet research tells me it’s likely a cookies or history issue (apparently old cached credentials trump newly entered ones at the keyboard). Just another wonderful aspect of living large as a digital person, I guess.
I swear! Sometimes I spend more time digging through login and credentialing issues to access accounts than I actually spend using those accounts directly. Sigh.
Suddenly, the usual login prompt from my Credit Union, where my wife and I both bank, has become inaccessible on my local network. No PC, no browser, no nothing will open the login URL. Errors proliferate like mushrooms after the rain instead. What gives?
I’ve been working in and around IP networks professionally since 1988, and with IP networks since 1979. I’ve seen many weird things, and now have another to add to that list. From my LAN right now, no PCs can login to our credit union on the web. Nobody, that is, unless I go through a VPN link. Otherwise, when we (my wife and I bank together) try to access the login page, a raft of error messages presents. Only the VPN works around weird credit union access issue, which throws up beacoup HTTP error codes. (Explanatory text verbatim from Wikipedia.):
400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided.
403 Forbidden: The request contained valid data and was understood by the server, but the server is refusing action.
404 Not Found: The requested resource could not be found [(aka “File not found/Page not found”)].
501 Not Implemented: Server either does not recognize the request method, or it lacks the ability to fulfill the request.
502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server
How VPN Works Around Weird Credit Union Access Issue
I can only assume that the address resolution for the specific login URL is somehow malformed or invalid. Changing DNS server assignments at the Windows 10 clients (in the TCP v4 Interface properties) does not help. When I switch to VPN, though, that bypasses the local DNS infrastructure. That connection uses the VPN provider’s DNS infrastructure instead. Then, we have no problems accessing the bank URL.
Now, here’s where things get interesting. I can’t remember the login credentials for the Spectrum device that acts as a Wi-Fi AP and router at the network boundary. Thus, I can’t check the DNS situation on that device, which is where DHCP tells all my Windows 10 machines to get their DNS information from. I’ve got a call into Spectrum to see if they can help me break into my router without having to do a factory reset. In the meantime, we’re using the VPN to access the credit union stuff, and plain-vanilla networking for everything else. It’s strange and unfathomable, but at least there’s a workaround.
For Want of a Nail…
Last night, I drove to the nearby Spectrum outlet and swapped my Technicolor cable modem/VoIP device for an identical replacement unit. The theory was that something about this device was behind the issue. It was sheer hell trying to get back online because Spectrum’s activation drill requires providing account, password, and other identity characteristics. I keep all that stuff in Norton Password Vault, and I couldn’t get access to that info through my iPhone nor did I have another path onto the Internet to grab the necessary data. I eventually had to spend another 45 minutes on the phone with tech support as they FINALLY activated our Internet service, TV, and VoIP phone. Reminded me too much of Catch-22 “How can you see you’ve got flies in your eyes when you’ve got flies in your eyes?” Last night, I couldn’t see much of anything for far too long!
Because our son attends school online, doing without Internet is impossible. Thus, I ordered a 5G hotspot from Verizon last night, so we have a medium performing fallback. They tell me the hotspot I ordered delivers about 200 Mbps downstream and 25 Mbps upstream in our neighborhood. I’ll be finding out — and making sure the fallback works — when it shows up via USPS early next week. Sigh.
Router Reset Solves Resolution Hiccup [Added 1 Day Later]
With a little more time to think about what could cause my problem, I formulated a hypothesis about the cause — and a likely fix — for my troubles. All nodes on my LAN had an issue with that one specific URL. But neither the site operator nor my ISP could replicate that problem. Thus it had to be on the boundary between my LAN and the ISP’s aggregation network. That means only one possible culprit: the Spectrum router. It sits at my network boundary. It also provides DHCP to the nodes on the LAN and acts as the DNS server for all internal nodes.
“Aha” I thought, “I bet resetting the router will fix this issue because it reloads — or repopulates, rather — the DNS cache.” I was right. After powering off the router, letting it sit for a minute or two, then powering it back on, our name resolution issue was gone. Glad to have it fixed because it was deucedly inconvenient without credit union account access. Ultimately, it was the “VPN trick” that led me to the solution. Sigh again.