Weird Networking Thing

Black Hole

May contain traces of nut
I'm at a friend's... with a CF HDR-FOX I installed. WiFi dongle in the HDR, Win10 system on WiFi.

She says she has to keep rebooting the HDR to get network access to the WebIF, and I was sceptical but now I've seen it happen. Put the IP address into the Edge address bar, and it sits there looking at it and then comes back with "can't be reached".

"There you are, told you so".

Wait a minute. My iPad on the same network, Safari, IP address... WebIF starts up no problem.

Try again on Win10, no joy. I reboot the HDR from the iPad, and bingo Edge now connects.

Any clues what's going on? Anything I can look for? Obviously it's bloody Win10/Edge, but why would rebooting the other end sort it out?
 
Could be bloody anything. Ping, Arp and Telnet are probably good places to start. Then try another browser.
 
Ping: OK, yes, I can try pinging (if I'm here when it happens again).

Telnet: Maybe, if I can get to Telnet on Win10 without doing anything too intrusive, but what will ping/Telnet prove?

ARP: Is that a specific tool or are you talking about what the router is doing to route the packets? Clearly the router knows the HDR is alive on the network otherwise I wouldn't be able to connect through myself.

I have always had zeroconf installed, but never used it. I wonder whether "humax.local" as a browser address will bypass the problem by invoking a different protocol.
 
I can try pinging (if I'm here when it happens again).
You're not going to get very far with fault diagnosis otherwise.
what will ping/Telnet prove?
Basic IP (and TCP) connectivity.
ARP: Is that a specific tool or are you talking about what the router is doing to route the packets?
(Things on the same subnet get switched, not routed.) ARP is a protocol to turn IP addresses in to MAC addresses, which are fundamental to being able to communicate with another device. "arp" on Linux or "arp -a" on Windoze will gives you the contents of the local ARP cache on both devices. You need to make sure the other's entry is there (after having tried a Ping - to cause the lookup to happen in the first place - and it's failed).
Clearly the router knows the HDR is alive on the network otherwise I wouldn't be able to connect through myself.
Indeed, so you are ideally placed to investigate, as you can use the PC to investigate itself and your iDevice to investigate the HDR. Then hopefully you might be able to work out why the two can't talk to each other.
I have always had zeroconf installed, but never used it. I wonder whether "humax.local" as a browser address will bypass the problem by invoking a different protocol.
What protocol(s) are you talking about? zeroconf is just a different sort of DNS - for turning names into IP addresses. Presumably you were using IP addresses to start with? If so, how does introducing another layer of unpredictability help?
 
...
Any clues what's going on? Anything I can look for? Obviously it's bloody Win10/Edge, but why would rebooting the other end sort it out?
I wouldn't say it's obviously a win10/edge issue yet because the original post is a little light on details.
It may be a network configuration issue.

As you had 3 devices connected to the same network, I would try to something like
  • for each device:
  • - ping other device(s) on internal network;
  • - ping outside of network.
It'll help diagnostics etc.
You haven't mentioned how the win10 device is connected to the network (eg WiFi?).
What did you try on the win10 device before rebooting the HDR? Eg another browser, ping, access internet?
 
Last edited:
I suppose there's just the one WiFi base station here?

If so, there must be some nonsense in the stack between Edge and the network, or there could be firewalling in what I assume is a WiFi "router"/modem. Testing with other network clients might show this up. Also, Edge??? (see https://www.mozilla.org/en-US/firefox/all/#product-desktop-release).

With zeroconf you may see the issue where the (invalid) default IP address is initially advertised, but that soon gets corrected.
 
Indeed, so you are ideally placed to investigate, as you can use the PC to investigate itself and your iDevice to investigate the HDR. Then hopefully you might be able to work out why the two can't talk to each other.
This sounds beyond my knowledge, I don't really know what I'm looking for and I have no idea what else I can tell you. It seems to me the salient facts are that the Win10 accesses WebIF perfectly well for a while, but after an indeterminate period of time decides it doesn't want to. it's like some kind of lease is up.

Surely that it accesses the HDR at all demonstrates the basics are OK.

(Things on the same subnet get switched, not routed.)
(Does it look like I give a damn?)

ARP is a protocol to turn IP addresses in to MAC addresses, which are fundamental to being able to communicate with another device.
So the device isn't using IP addresses directly, despite being told what its IP address is by DHCP or manually? If that's the case, what's the point of a device knowing its IP address?

"arp" on Linux or "arp -a" on Windoze will gives you the contents of the local ARP cache on both devices. You need to make sure the other's entry is there (after having tried a Ping - to cause the lookup to happen in the first place - and it's failed).
Well that's something, anyway. Never heard of the arp command before.

zeroconf is just a different sort of DNS - for turning names into IP addresses. Presumably you were using IP addresses to start with? If so, how does introducing another layer of unpredictability help?
Exactly because its a different protocol and might bypass whatever stupidity is clagging this up. Under the circumstances I'm unlikely to get to the bottom of this and just need something which works. Even if I'm not on the premises I can say "try putting humax.local in the address bar instead of 192.168.1.88".

I suppose there's just the one WiFi base station here?
Since you mention it, there is a BT WiFi repeater unit, but I can only see one SSID so it seems to be operating as a single network. It would not surprise me if the problem was there though.
 
This sounds beyond my knowledge
And you seem unwilling to learn. This is what you are always telling other people, so it seems somewhat hypocritical.
If you don't want help, then don't ask for it in the first place. Google and networking school are that way ------------>
there is a BT WiFi repeater unit
A fact you neglected to mention at the start (sound familiar?).
It would not surprise me if the problem was there though.
Me neither, but without any evidence...
it's like some kind of lease is up.
Perhaps it is DHCP related. Who knows (or cares). Just try the scatter-gun approach and hope.
 
And you seem unwilling to learn.
The issue is limited time on site, and very little to go on when the problem is not present. I clearly don't understand the detail of how it all works (like: I thought IP packets got directed to / recognised by IP addresses, not MAC addresses). We all have our specialities, and the intricacies of networking protocols isn't mine. The overhead of trying to figure it all out exceeds the time available, and possibly my capacity to take new things on board, so is it unreasonable to reclaim a little bit of my pay-forward?

You don't have to help if you don't want to / can't be arsed, perhaps somebody else will contribute some knowledge.

A fact you neglected to mention at the start
Until /df mentioned it, it did not occur to me to investigate. This is not my native location remember!

If the problem does not recur before tomorrow morning, I will have no opportunity to run diagnostics. The scatter-gun approach I might be able to instigate remotely might be the only possibility.
 
I have rehearsed bringing up a command prompt in Win10, and tested the arp and ping commands, so now all we can do is wait.

Win+X
Windows PowerShell (Admin)
 
Back
Top