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.
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.
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
1069
20756
root@LEDE:~# /etc/init.d/network restart
root@LEDE:~# pgrep dropbear
1069
20756
<< login from other router, connection seen as new process 23244>>
root@LEDE:~# pgrep dropbear
1069
20756
23244
root@LEDE:~#
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.
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: