Dropbear does "Not backgrounding"

mrhr · September 15, 2018, 2:07pm

Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'lan' is enabled
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'lan' is setting up now
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'lan' is now up
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'loopback' is enabled
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'loopback' is setting up now
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'loopback' is now up
Sat Sep 15 13:31:03 2018 kern.info kernel: [   27.880571] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'wan' is enabled
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'wan6' is enabled
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Network device 'lo' link is up
Sat Sep 15 13:31:03 2018 daemon.notice netifd: Interface 'loopback' has link connectivity
Sat Sep 15 13:31:03 2018 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Sat Sep 15 13:31:04 2018 authpriv.warn dropbear[1038]: Failed listening on '22': Error listening: Address not available
Sat Sep 15 13:31:04 2018 authpriv.info dropbear[1038]: Not backgrounding

first thought was, maybe dropbear initializes before network interfaces, but that proves false by 1 sec?

all this happens on a Mikrotik RouterBoard RB951Ui-2HnD.

any advice?

jeff · September 15, 2018, 2:19pm

Have you disabled IPv6?

Have you assigned an IPv4 address to your "LAN" interface?

Is there a change in your dropbear config from stock, perhaps where you "lost" a colon (:) or something?

mrhr · September 15, 2018, 2:33pm

i did not.

a static one, yes.

/etc/config/dropbear reads simply

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

mrhr · September 15, 2018, 2:57pm

also when i ping any client on the lan, router included by hostnames it resolves to ipv6 addresses.
ping to ipv4 addresses works too but they are not associated to hostnames.

update

ipv6 is disabled on lan. ipv4 addr'es and hostnames are associated as expected.

after a reboot dropbear instance still didn't go background

Sat Sep 15 15:03:35 2018 authpriv.info dropbear[1031]: Not backgrounding

but i can ssh to the router

logread | grep dropbear
Sat Sep 15 15:03:35 2018 authpriv.info dropbear[1031]: Not backgrounding
Sat Sep 15 15:07:08 2018 authpriv.info dropbear[1995]: Child connection from 192.168.2.105:36720
Sat Sep 15 15:07:23 2018 authpriv.notice dropbear[1995]: Password auth succeeded for 'user' from 192.168.2.105:36720

when i kill the "naughty" proccess [1031] no harm is done, but then a new one of the same kind appears

Sat Sep 15 15:21:27 2018 authpriv.info dropbear[3755]: Not backgrounding

slh · September 15, 2018, 6:02pm

Clients are supposed to prefer IPv6 over IPv4 (DNS reports both, it's a client side policy), if available.

mrhr · September 16, 2018, 4:32pm

thank you for the information.
for the sake of simplicity to monitor and troubleshoot this ipv6 has been disabled.

hnyman · September 16, 2018, 4:55pm

So? It is supposed NOT to background with procd.

The dropbear init script explicitly says -F (= Don't fork into background)

github.com

openwrt/openwrt/blob/master/package/network/services/dropbear/files/dropbear.init#L73


      
          hk_generate_as_needed()
          {
          	local kdir kgen ktype tdir kcount tfile
          	kdir='/etc/dropbear'
          
          	kgen=''
          	for ktype in ed25519 ecdsa rsa; do
          		hk_verify "${kdir}/dropbear_${ktype}_host_key" && continue
          
          		kgen="${kgen} ${ktype}"
          	done
          
          	[ -z "${kgen}" ] && return
          
          	tdir=$(mktemp -d); chmod 0700 "${tdir}"
          
          	kcount=0
          	for ktype in ${kgen}; do
          		tfile="${tdir}/dropbear_${ktype}_host_key"
          
          		if ! _dropbearkey -t ${ktype} -f "${tfile}"; then

Procd takes care of demonizing the apps behind the scenes, and the apps should not self-demonize. So dropbear itself thinks that it runs on foreground, and thinks that to be unusual, so it logs a warning.

mrhr · September 16, 2018, 5:56pm

neat! thanks a lot!
well as it seems, when i couldn't ssh to the router was because of a mess involving ipv4 ipv6 and hostname resolution. That warning caught me eye first and I took it for a probable reason of my problem. Yet further research got me a bit wiser than yesterday, thanks to all of you.