Forum › Forums › Freesat HD › FOXSAT HDR › Network interface dropping?
Tagged: connectivity, eth0, ethernet, ifconfig, Network
- This topic has 13 replies, 3 voices, and was last updated 11 years, 9 months ago by
Anonymous.
-
AuthorPosts
-
February 11, 2014 at 7:43 pm #15456
Anonymous
InactiveI’ve a Humax HDR box running custom firmware. It’s configured to power down from 0230 to 0400 every morning to allow it to housekeep. I also have a cron job rsyncing the Videos directory to a NAS DLNA server on my network at 0500 every day. It’s almost perfect.
There is one problem left to fix, and that is that the network connection periodically, and with no particular pattern, goes down; usually once a day. This is fixed by going into the IP config menu using the remote and simply applying the same settings again.
The network connection is via a static IP address which connects to my network over a wireless bridge (should be irrelevant).
Why is the network interface going down? How can I fix it? It’s as though something issues an “ifconfig down” on the ethernet interface and that re-applying the settings in the UI issues an “ifconfig up”.
Where should I start to diagnose this? Is there some kind of network watchdog which drops the interface if it senses intermittent connectivity?
February 13, 2014 at 6:06 pm #50623Anonymous
InactiveMore information: This seems to happen at a particular time each day – some time each afternoon. Weird!
February 14, 2014 at 8:19 am #50624Anonymous
InactiveIt may be your wireless set up. A glitch on the wireless side *should* be recoverable without having to re-apply settings, but there may be something about your set up which is problematic.
Eliminate the wireless by using a wired connection to the router for a few days. A direct cable is always best and cheapest, but home plugs are an alternative.
If it is stable on a wired connection, then it is likely something is interfering with the wireless at a certain time of day – heating coming on or something like that. A google of wifi interference will show lots of potential causes and fixes.
If it is still a problem on a wired connection then try using DHCP. It might stop you having to re-apply the address. You should be able to set your router to issue a fixed address everytime.
Dino
February 14, 2014 at 4:36 pm #50625Anonymous
InactiveHi Dino,
Thanks for the response and suggestions. Irrespective of whether my wireless connection is flaky, the network interface shouldn’t ever go down (that’s the point of statically-configured network interfaces!). I’m more after a “let’s work out why the network interface is going down” solution than a “let’s try and workaround the problem” solution. So thanks for your suggestions, but having a wired link or using DHCP is not desirable for me – I’d rather go right for the heart of the issue and work out why something on the box is turning the interface off.
I’m guessing by the relative silence on here that nobody else is suffering this kind of issue and static IP is rock-solid for them.
February 14, 2014 at 5:15 pm #50626Anonymous
InactiveMore info: Today I set up a timed ping every minute and the network interface went down at 1700 exactly. The plot thickens.
February 15, 2014 at 8:31 am #50627Anonymous
InactiveWithout a console on the HDR and with the limited tools available you are setting yourself quite a challenge. Let us know what you discover. Good luck.
February 15, 2014 at 10:28 am #50628Anonymous
InactiveI will do, thanks.
February 16, 2014 at 5:37 pm #50629Anonymous
InactiveSo it seems udhcpc is grabbing a DHCP-assigned IP address at 0500 and 1700 daily. My machine is set to be off from 0255 to 0500 each day and so is missing the first one.
February 16, 2014 at 7:56 pm #50630raydon
ParticipantYou could always kill the udhcpc daemon (killall udhcpc) seeing as you don’t need it. Settop always starts this process regardless of whether you have a static IP or not.
February 17, 2014 at 5:10 pm #50631Anonymous
InactiveThanks for the info!
Strangely I tried that not long before you posted. It seems to leave the udhcpc processes as zombies, but it does the trick. It’s after 5pm and I’m still communicating over eth0 at its static-assigned address.
I’m assuming that “mv udhcpc udhcpc.not” won’t have any undesirable side-effects?
February 17, 2014 at 6:09 pm #50632raydon
ParticipantSorry, you can’t rename it because the root filesystem is in read-only firmware. However, you could create a startup script that just kills the udhcpc process after a short delay (say 60 seconds after boot). I can help you with this if you’re not sure how to proceed.
February 18, 2014 at 12:26 pm #50633Anonymous
InactiveDuh, of course.

I think I can rig this up thanks, unless there’s something particularly unusual about the init.d stuff on the Humax?
Thanks!
February 18, 2014 at 1:08 pm #50634raydon
ParticipantNo, nothing special. You just need to ensure that your script spawns a background task to do the waiting so as not to interfere with the regular boot process. Something like this should do.
Code:#!/bin/sh
(
sleep 60
killall udhcpc
) &February 18, 2014 at 1:11 pm #50635Anonymous
Inactive… almost verbatim what I’d written.

Thanks mate.
-
AuthorPosts
- You must be logged in to reply to this topic.