New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#2125 - dropbear race condition with ipv6 networking #8410
Comments
farmergreg: This bug is still present in OpenWrt 19.07.1 |
farmergreg: To reproduce the bug, you'll need a fast machine or virtual machine. I'm running OpenWRT on x86 based hardware. |
farmergreg: This still happens in 21.02.0-rc1 on my x86 based OpenWrt router. |
j_serock: I started experimenting with IPv6 last week and ran into this issue yesterday on two NETGEAR WNDR3800 routers running OpenWrt 19.07.7. I noticed the following messages in the system log: Sun May 2 17:49:17 2021 authpriv.warn dropbear[1364]: Failed listening on '22': Error listening: Address not available |
fda: As a workaroung im running dropbear by xinetd package
But you have to re-enable inetd support of dropbear in the makefile before build! |
OpenWRT 23.05-rc3. IPv4 Dropbear is not listening on a port over IPv6. Restarting dropbear fixes the problem and it binds correctly to the ipv4 and ipv6 lan address. |
Why has this been closed, this issue is still present on 23.05 and has been for a long long time? But it would be a bit of a layer of protection if it only listened on the ULA and there was a firewall error allowing the port 22 to be too open. |
farmergreg:
I'm running OpenWRT on an x86 machine running OpenWRT 18.06.2.
Steps to reproduce:
Configure dropbear to only listen on an interface such as 'lan'
After rebooting, often dropbear will be bound to 192.168.1.1, but not fd00:2233:4455:1::1 (router's ipv6 address). Restarting dropbear fixes the problem and it binds correctly to the ipv4 and ipv6 lan address.
The text was updated successfully, but these errors were encountered: