Dropbear fails after restarting network

I use LEDE 17.01 stable on WR1043NDv4.
After issuing command /etc/init.d/network restart (or service network restart) dropbear stops working. The current SSH connection is still active but I can't open any new connection to router, though SSH. Issuing /etc/init.d/dropbear restart fixes the problem and returns the error saying that there are no previous instances working. Basically the message you get when you use restart instead of start when there are no previous instances of the service working.

Anyone else effected?

Dropbear only checks for the interfaces when it starts; if the interface is not present then, it will not start listening on that interface later. I added a script at "/etc/hotplug.d/iface/" to restart dropbear when an interface restarted.

It didn't happen for me then I used 15.05.1 so from my point of view I would consider this a bug. Dropbear is a very important service and we can't just allow for it not to be working.


Can you share your script with me, please?



if [ "$INTERFACE" = "wan" ] && [ "$ACTION" = "ifup" ]
        /etc/init.d/dropbear restart

Thank you very much.
One question though. Are there any special permissions needed for it to work or default 644 will be enough?

I opened a bug report for anyone interested in a more permanent solution.

Update 1: The default permissions for the file are not working for me so I changed them to 755 and everything seems to be working fine.

Not sure where your bug materialises. Issuing /etc/init.d/network restart keeps dropbear running and new connections are possible, both in my 17.01 and master builds. Dropbear with default settings.

(17.01-SNAPSHOT, r3326-1ab41265c3)

root@LEDE:~# pgrep dropbear
root@LEDE:~# /etc/init.d/network restart
root@LEDE:~# pgrep dropbear
  << login from other router, connection seen as new process 23244>>
root@LEDE:~# pgrep dropbear

Note that in the above log the original dropbear process and the current client session processes stay alive.

Pure guess, but you might have some additional package that triggers the restart of dropbear and the new dropbear process then starts so early that new network interfaces are not yet up and so dropbear does not attach to any interface. You might check the process numbers to see it that happens.

Default settings for dropbear do not include accepting WAN connections, that is the issue here. And WAN connections can take some time to come up, enough time so dropbear comes up before, and does not find a WAN interface.

Here's the list of packages I install after flashing clean 17.01.1 without LuCI:

opkg update;
opkg install kmod-usb-core kmod-usb2 kmod-usb-ohci kmod-usb-printer p910nd;
opkg install ntpdate;
opkg install curl;
opkg install wget;
opkg install dnscrypt-proxy-resolvers dnscrypt-proxy hostip iodine libsodium;
opkg remove dnsmasq;
mv /etc/config/dhcp /etc/config/dhcpOLD;
opkg install dnsmasq-full;
opkg install ekooneplstat;
opkg install vnstat;
opkg install sqm-scripts;
opkg install ddns-scripts;
opkg install miniupnpd;
/etc/init.d/miniupnpd stop;
/etc/init.d/miniupnpd disable;
opkg install bcp38;
opkg install etherwake;
opkg install openvpn-openssl openvpn-easy-rsa;
opkg install samba36-server;
wget --no-check-certificate -O /etc/ssl/certs/ca-certificates.crt https://curl.haxx.se/ca/cacert.pem;

The default for dropbear is to listen on all interfaces, it has no explicit lan or wan binding.

Yes, I did not express myself correctly: default configuration for the firewall blocks connections from the WAN interface. Some people, when opening the firewall to allow SSH connection from the WAN interface, also configure separate dropbear instances for each interface. For example:

config dropbear
	option Port '22'
	option Interface 'lan'
	option PasswordAuth 'on'

config dropbear
	option Port '22'
	option Interface 'wan'
	option PasswordAuth 'off'
	option RootPasswordAuth 'off'

Then, the instance listening to the WAN interface will fail upon start.