Modify

Opened 3 years ago

Last modified 3 years ago

#19427 new defect

Service startup failing because of uninitialized network interfaces (TP-Link TL-WDR3500)

Reported by: fedy.cz Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Barrier Breaker 14.07
Keywords: bootup init fail network interface Cc:

Description

Some network services often fail to start up during bootup.

It looks like some services (in my case openvpn, stunnel and autossh) try to start up before the corresponding interfaces are up and the bind() system call fails. Maybe I'm missing something and there is some standard way to prevent this in OpenWrt, but at least with openvpn and stunnel i'm using stock init.d scripts, so they should probably work by default. Suspecting this might be device specific (in my case TP-Link TL-WDR3500 ver: 1.3).

example logread snippet:
Mon Apr 6 22:13:17 2015 user.emerg syslog: bind: Cannot assign requested address (126)
Mon Apr 6 22:13:17 2015 user.err autossh[903]: bind on 127.0.0.1:20031: Cannot assign requested address
Mon Apr 6 22:13:17 2015 user.err autossh[904]: bind on 127.0.0.1:22031: Cannot assign requested address
Mon Apr 6 22:13:18 2015 kern.info kernel: [ 22.330000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Mon Apr 6 22:13:18 2015 kern.info kernel: [ 22.330000] device eth0 entered promiscuous mode
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'lan' is enabled
Mon Apr 6 22:13:18 2015 kern.info kernel: [ 22.360000] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'lan' is setting up now
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'lan' is now up
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'loopback' is enabled
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'loopback' is setting up now
Mon Apr 6 22:13:18 2015 daemon.notice netifd: Interface 'loopback' is now up

Attachments (1)

netwait (675 bytes) - added by fedy.cz 3 years ago.
quick fix

Download all attachments as: .zip

Change History (2)

Changed 3 years ago by fedy.cz

quick fix

comment:1 Changed 3 years ago by fedy.cz

Developed a quick and dirty fix for this (see attached):
It's a netwait "service" - startup priority 21. Started directly after network service, it uses uci and information in /var/state/ to wait for the network interfaces (lan and loopback) to come up, then finishes it's "startup" and allows other services to start.

Would love to resolve this problem properly (possibly using netifd/procd?), but first I need to find out what's the cause. Is this hardware specific, or is the entire Barrier Breaker affected? What mechanisms are in place to prevent service startup before the required resources are ready (network or other)?

Last edited 3 years ago by fedy.cz (previous) (diff)

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.