Dropbear not listening on IPv6 after reboot

More than a solution, I'm looking to understand why this is happening.

This is on a Belkin RT3200, running snapshot builds (I haven't looked at my other OpenWrt devices to see if they behave the same). Every time I reboot, dropbear only comes up listening on IPv4.

I've added a logger line in /etc/rc.local (after a sleep 5), and also created /etc/hotplug.d/net/99-dropbear and iface/99-dropbear, both of the latter with just another logger line so I can see sequence of events during startup. Results are as follows:

$ logread -e dropbear
Mon Jan  2 08:49:07 2023 user.notice dropbear: net action= add    iface= wlan1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= add    iface= br-lan
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= add    iface= SQM_IFB_b06a1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= remove iface= SQM_IFB_b06a1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= add    iface= SQM_IFB_e1dc3
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= remove iface= SQM_IFB_e1dc3
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= add    iface= SQM_IFB_2d9b1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= remove iface= SQM_IFB_2d9b1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= remove iface= wlan1
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= add    iface= SQM_IFB_5ad3a
Mon Jan  2 08:49:10 2023 user.notice dropbear: net action= remove iface= SQM_IFB_5ad3a
Mon Jan  2 08:49:12 2023 user.notice dropbear: net action= add    iface= SQM_IFB_abd1a

Mon Jan  2 08:49:12 2023 authpriv.warn dropbear[2418]: Failed listening on '22': Error listening: Address not available
Mon Jan  2 08:49:12 2023 authpriv.info dropbear[2418]: Not backgrounding

Mon Jan  2 08:49:12 2023 user.notice dropbear: net action= remove iface= SQM_IFB_abd1a
Mon Jan  2 08:49:12 2023 user.notice dropbear: net action= add    iface= wl1-ap0

Mon Jan  2 08:49:13 2023 user.notice dropbear: iface action= ifup iface= lan      device= br-lan
Mon Jan  2 08:49:13 2023 user.notice dropbear: iface action= ifup iface= loopback device= lo
Mon Jan  2 08:49:14 2023 user.notice dropbear: iface action= ifup iface= wan      device= wan
Mon Jan  2 08:49:15 2023 user.notice dropbear: iface action= ifup iface= wan6     device= wan

Mon Jan  2 08:49:18 2023 user.notice dropbear: rc.local (after sleep 5)

Mon Jan  2 08:52:34 2023 authpriv.info dropbear[2418]: Early exit: Terminated by signal
Mon Jan  2 08:52:34 2023 authpriv.info dropbear[5089]: Not backgrounding

When I stick in /etc/init.d/dropbear restart at any of the three log points, dropbear still fails to see any IPv6 addresses. I was sort of expecting an iface ACTION=ifupdate event to occur when the IPv6 address came to life, but nothing of the sort. I still need to get into LuCI (or ssh on IPv4, which always works) and restart dropbear to get it listening on :::22.

Any ideas why dropbear can't see IPv6 when all of these things are going on?

I encountered the same problem, did you solve it?

Not yet, still poking around to see what events I can find to trigger a restart...

If you’ve specified an interface for SSH access, it will listen on the IPs available on the interface at the time it (dropbear) starts. For it to listen on :::22, set the interface to unspecified and let the firewall protect you from WAN access to dropbear.

3 Likes

Ah, yes! I do have interface set to "lan" mostly as belt and suspenders against intrusion (firewall doing its thing and dropbear only listening on lan addresses), so that does resolve the issue.

But, since I'm curious, is there any way to know if/when the IPv6 addresses come and go on LAN. Say, for example, if I somehow had SLAAC on the router and the ULA rotated every 24h, is there an event that fires off? In my actual case, the ULA appears to take some 30-40 seconds to be assigned after the interface comes up on a reboot (or init.d/network restart), so it would be nice to see without writing a spin-loop on ip addr or whatever.

I’ve not done it myself, but I imagine you could test an iface hotplug.d script when it’s the lan interface and ifupdate and $IFUPDATE_ADDRESSES is 1.

1 Like

I use socat to forward the ports of ipv6 and ipv4 these days, you can also try it