Skip to content
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

Open
openwrt-bot opened this issue Feb 16, 2019 · 7 comments
Open

FS#2125 - dropbear race condition with ipv6 networking #8410

openwrt-bot opened this issue Feb 16, 2019 · 7 comments
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release

Comments

@openwrt-bot
Copy link

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'

config dropbear
  option Interface '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.

@openwrt-bot
Copy link
Author

farmergreg:

This bug is still present in OpenWrt 19.07.1

@openwrt-bot
Copy link
Author

farmergreg:

To reproduce the bug, you'll need a fast machine or virtual machine. I'm running OpenWRT on x86 based hardware.

@openwrt-bot
Copy link
Author

farmergreg:

This still happens in 21.02.0-rc1 on my x86 based OpenWrt router.

@openwrt-bot
Copy link
Author

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
Sun May 2 17:49:17 2021 authpriv.info dropbear[1364]: Not backgrounding

@openwrt-bot
Copy link
Author

fda:

As a workaroung im running dropbear by xinetd package
This allows to filter connecting ips/networks

cat << EOX > /etc/xinetd.d/dropbear
service ssh
{
        protocol        = tcp
        socket_type     = stream
        server          = /usr/sbin/dropbear
        server_args     = -i
        flags           = IPv6
        only_from       = 192.168.1.0
        only_from       += fda1:2:3:4::/64
        user            = root
        wait            = no
        disable         = no
}
EOX

But you have to re-enable inetd support of dropbear in the makefile before build!

@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
@fsa
Copy link

fsa commented Sep 4, 2023

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.

@simpz
Copy link

simpz commented Nov 11, 2023

Why has this been closed, this issue is still present on 23.05 and has been for a long long time?
Actually it would be nice if there was some way to force dropbear to only bind to IPv4 and the IPv6 ULA address, as on restart it binds to the ULA and GUA (strictly correct for this lan interface).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release
Projects
None yet
Development

No branches or pull requests

4 participants