Can't access internet on HDR after changing network address

Owen Smith

Well-Known Member
I've just changed my home network address. In a bid to avoid clashing with anyone else's home network addresses (impossible I know) so that my VPN will work from more hosting networks I've changed to 172.27.151.0/24. Everything else is working fine, I just changed my DHCP entries on my router and a few other bits and pieces. But both my HDR Fox T2s refuse to talk to the external network any more. Here's some network details from one of them:

owenhdrfoxt2# ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:78:B9:2C:5B
inet addr:172.27.151.111 Bcast:172.27.151.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2593 errors:0 dropped:0 overruns:0 frame:0
TX packets:3213 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:347630 (339.4 KiB) TX bytes:1657762 (1.5 MiB)
Interrupt:16
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3032 (2.9 KiB) TX bytes:3032 (2.9 KiB)

owenhdrfoxt2# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.27.151.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 172.27.151.254 0.0.0.0 UG 0 0 0 eth0

Pinging the gateway works:

owenhdrfoxt2# ping 172.27.151.254
PING 172.27.151.254 (172.27.151.254): 56 data bytes
64 bytes from 172.27.151.254: seq=0 ttl=64 time=1.907 ms
64 bytes from 172.27.151.254: seq=1 ttl=64 time=1.034 ms
64 bytes from 172.27.151.254: seq=2 ttl=64 time=1.023 ms
64 bytes from 172.27.151.254: seq=3 ttl=64 time=0.988 ms
64 bytes from 172.27.151.254: seq=4 ttl=64 time=0.992 ms

But I can't get to anything outside the gateway eg. the router's public IP address (which shouldn't involve going outside the house):

owenhdrfoxt2# ping 81.187.5.174
PING 81.187.5.174 (81.187.5.174): 56 data bytes
--- 81.187.5.174 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss

I can't see what I've done wrong. Even my Raspberry Pi works.
 
How can you ping 81.187.5.174 from anything 172.27.151.xxx with netmask 255.255.255.0?

Because it should go out through the gateway, being to an address that isn't on the local subnet. It works on my Raspberry Pi and that has the same network setup except different last 8 bits of network address.

Try ping www.google.com and you will find it works (if your home gateway passes ping through), and that isn't an address on your home network.
 
Nonetheless, it's not working. This may be obvious, but what does Menu >> Settings >> System >> Internet Setting >> Configure LAN say?
 
Nonetheless, it's not working. This may be obvious, but what does Menu >> Settings >> System >> Internet Setting >> Configure LAN say?

That's what I looked at first, and it says exactly what I expect it to. I only telnet'd in because things weren't working.
 
If you find the answer to this, it may explain why some people have trouble accessing the outside world from their Humax.
 
If you find the answer to this, it may explain why some people have trouble accessing the outside world from their Humax.

Maybe the Humax just doesn't like some IP addresses. Is support for 172.16.0.0/20 broken?

I don't mind the lack of iPlayer, I use get_iplayer anyway. What this breaks for me is the Remote Scheduling portal.
 
I assumed that coming out of standby would be enough to change network settings, but apparently not. I hard power cycled the mains on the back of the boxes and both of them are now working. Streamed a programme on iPlayer, ntpclient.log reports successfuly sync, Remote Scheduling server reports that both boxes have checked in with it.

This seems very odd to me, the Humax has no idea what it's network settings are when it is standby.
 
The HDR has no network activity in standby. When it boots, it either adopts the manual IP configuration, or requests configuration from the server by DHCP. Your Telnet pings can't have been while it was in standby.

That is not to say I think you are talking a load of rubbish, just that what you are trying to say is not is not clear to me.
 
I know full well that my telnet pings can't have been while it was in standby, and I never said they were. I do know what I'm doing with networking. How many other people post the output of ifconfig and route -n from a telnet login to the Humax when there's a problem?

The following sequence occured, I thought I had explained this clearly:

1) Humaxs were in standby ie. not running

2) I reconfigured the DHCP on my Router

3) Humaxes were brought out of standby, showing correct new network information, but unable access iPlayer or RS, so I telnet'd into them and check the network details and tried some pings to external addresses, which didn't work.

4) Humaxes were put back into standby

5) Humaxes were hard powered cycled on their rear panels (and they go into standby when they come back on)

6) Humaxes were brought out of standby, and now network access is working properly and iPlayer can stream video from the Portal. RS access is working, ntpclient.log in WebIF reports it is doing things etc.

No this doesn't make sense, but it is what happened. Now stop reading more than what I've said into things Black Hole.
 
You're right it doesn't make sense, which is why I was trying to make some sense out if what you posted - no need to get shirty, and thanks for the clear post.

From what you have said I gather that the network settings were not working, even though they appeared OK on Menu... Configure LAN, despite warm starts, until a cold restart. This is a useful tip we can offer anyone seeking help for similar issues. I can't say I have come across anything like that myself.
 
This is a useful tip we can offer anyone seeking help for similar issues. I can't say I have come across anything like that myself.
It is an interesting observation. There have been numerous reports where a problem accessing the portal (particularly on a newly configured box) has been fixed by power cycling; I have never understood why.
 
It is an interesting observation. There have been numerous reports where a problem accessing the portal (particularly on a newly configured box) has been fixed by power cycling; I have never understood why.

So the first conclusion we can draw is: if in doubt, hard power cycle at the mains. Worth a try before Factory Reset, since a reset is more of a pain and requires reconfiguring things.
 
I thought that was an SOP since Bill Gates invented Windows or perhaps before. Can't understand why so many people seem not to use the technique. It's easy. If in doubt, switch it off, then back on again. It isn't rocket science.
 
I thought that was an SOP since Bill Gates invented Windows or perhaps before. Can't understand why so many people seem not to use the technique. It's easy. If in doubt, switch it off, then back on again. It isn't rocket science.

But on the HDR Fox T2 being in Standby is equivalent, the main CPU is not running.
 
Agreed, but there are other examples of a cold boot having a more dramatic effect than a warm boot. Presumably there is still data preserved in memory during standby.
 
Windows in hibernate mode has no power applied so the CPU is not running, but a full restart is recommended occasionally.
And the point that I was making is that switch off/on should be the pretty much the first port of call when something goes wrong with complex stuff as it so often fixes the problem.
 
Been thinking about this today. Before the cold boot, Owen could ping from the Humax to other machines on the local network, but not reach out through the router. After the cold boot, he could reach out through the router.

So: is it that something about the router was not properly configured to forward the ping to the outside world, or is it that the Humax is involved in accessing the gateway before the ping is forwarded through it?
 
Back
Top