Why might wired network connection not re-establish after rtcwake sleep

[badbetty]

Hello, good day

I'm looking for some initial ideas, perhaps from experience of similar, to an issue between openwrt router and a linux box regarding network connection issues. I am not providing lots of specific detail, because for me it is general question and ideas for thought at this stage.

Question: is it likely that the openwrt (v18.x) based BT HH5 router is the reason the network connection is not re-established to a linux box following said box awaking from rtcwake sleep period; or is it the linux box, or both and if any of those, what might be the place to start explore for a reason/solution ?

Background:

Linux box using dhcpcd to obtain ip address from openwrt router (BT Home Hub 5). On the HH5 OpenWRT, the linux box is configured to receive a 'static ip address' to ensure it gets the same address each time. The lease time is left as default. The linux box is unchanged (in its net config) from when a previous router was being used that was swapped out for the BTHH5 Openwrt. Initially there appeared no problem and network connection was working fine (getting the static address, lease renewal etc).

Then the issue appeared of network connection not always re-establishing.

At midnight the linux box uses rtcwake to put itself to sleep and then wakeup several hours later.

When the box awakes, sometimes, not always, the linux box is not accessible on the network, as if the network connection has not re-established somehow; perhaps by being dropped by the router whilst asleep (perhaps across a lease time boundary or not...not sure on that).

On the previous router, this was never an issue. It is only happening since the Openwrt router installation and again, nothing has been changed on the linux box as such. This suggests it is something on the Openwrt BTHH5 config.

Thoughts so far, is using dhcp, rather than static ip setup, on the linux box to get a static address lease (that still is subjected to lease time [unless set to infinite, but that did not cure]) the ideal way to ensure the same address ? If not, what's best and in any case the current setup is provided for by Openwrt so why might there be an issue.

Thanks for considering this and offering some general ideas at this stage.

[mk24]

First you should use ip link show, ip addr show etc. on the Linux box to find the exact nature of the failure.

A static IP is configured on the client so it uses the preset IP rather than obtain one by DHCP. No DHCP request is even made. The IP will always exist even if there is no network available.

A static lease is configured at the DHCP server (router) so that a particular client always gets the same IP. The only difference between this and regular DHCP is the method the server uses to decide what the client's address will be-- rather than being "random", it is pre-set. There is no need to change anything at the client to use static leases. Thus this method is preferred since you can make changes to the network without having to configure clients.

[badbetty]

Thanks for replying.

I have not used ip link show etc, only checked various system logs and did not spot anything. When it next happens, I will have a more detailed check (using the tools you suggest) to see if anything jumps out.

As I say, nothing on the Linux box is changed as far as I am aware - only the old router swapped out and new openwrt one in. The linux box is using DHCP and I agree the static lease is preferrable and that is what is set up. I have shortened the lease time to 8hrs just to see what that does (as you can tell I'm fishing without a clue at the moment).

Will report back soonest.

[dlakelan]

You might try modifying your script so that after rtcwake you force a restart of network on the Linux box. I kinda suspect either driver issue or something simple like the IP address is lost and the DHCP client isn't renewing it after wakeup, maybe even DHCP client is crashing?

[badbetty]

It would appear that the issue is on the linux box and I was remiss to not mention previously that there was a change, being a kernel update. Prior to this awaking from an rtcwake suspend did not affect the network. Now it seems at some points I have still to pin down, when the box awakes the connection is not re-established.

It happened again this morning and dmesg reported 'eth0 link down'. I logged on at the console and checked the network status (ifconfig) indeed there was no assigned address.

I tried to get dhcpcd to request the address and it timed out not available.

Restarted the network stack and all worked fine (as expected of course).

Searching the internet turned up that there are similar recently reported issues that after kernel updates this problem is occuring for other folks too; with solutions varying from putting a script in to unload/reload the driver etc. Certainly something has changed as all report it used to work and now does not (for some drivers ..r8169 in a few cases inc. mine).

I will go away and consider it further, but it does not look like Openwrt dhcp etc is involved. This issue is effectively 'solved' as such (as far as openwrt not being the issue).