[sane-devel] Possible inetutils-inetd problem

[Julien BLACHE]

"Geoff Lane" <bunsen at tesco.net> wrote:

I know this stuff is pretty non-obvious when you don't know how the
underlying API and system work, so I'm going to explain a bit of it,
hopefully this can help as a reference or something.

>   geoff at challenger:~$ saned -d1
>   [saned] main: [1] bind failed: Address already in use

You're only seeing messages for grave errors here, so you only get
that. saned is functional, it runs, it's listening on port
6566. Otherwise, it would have exited with a non-zero exit status,
which it very obviously did not do.

>  geoff at challenger:~$ saned -d4
>  [saned] main: starting debug mode (level 4)
>  [saned] main: [1] bind failed: Address already in use
>  [saned] main: waiting for control connection

Getting more debug messages, warning messages. Nothing really new,
except saned now tells you explicitely that it's listening to its
network port.

>  geoff at challenger:~$ saned -d5
>  [saned] main: starting debug mode (level 5)
>  [saned] main: trying to get port for service `sane-port' (getaddrinfo)
>  [saned] main: [0] socket () using IPv6
>  [saned] main: [0] setsockopt ()
>  [saned] main: [0] bind () to port 6566
>  [saned] main: [0] listen ()
>  [saned] main: [1] socket () using IPv4
>  [saned] main: [1] setsockopt ()
>  [saned] main: [1] bind () to port 6566
>  [saned] main: [1] bind failed: Address already in use
>  [saned] main: waiting for control connection

Now getting a bit more chatty. Trying to bind IPv6 first, as that's
how dual-stack systems works. IPv6 is always first, IPv4 comes in
second place as IPv4 is obsolete and is being phased out anyway (*
pinch of salt required; sold separately).

As I told already, when binding for all addresses of the current host
on a dual-stack host, if v4compat is enabled (it is, by default), IPv4
connections come in through the v4compat layer (with a remote address
of ::ffff:a.b.c.d).


netstat --listen will show you what's happening. Don't look for a TCP
socket in there, look for a TCP6 socket:

 tcp6       0      0 [::]:sane-port          [::]:*                  LISTEN      21018/saned 

> So, at this stage saned -d5 or higher allowed a remote computer to
> connect to my scanner but less than 5 following -d did not allow a
> connection.

The debug level has exactly 0 influence on the code.

> As I had followed all advice and instructions and couldn't see why
> saned wasn't working via inetd I decided to uninstal inetutils-inetd
> and try openbsd-inetd

I haven't seen your config, but one catch is that the service name for
saned isn't saned but sane-port (historical 'woops' when registering
the service name with IANA). Check that /etc/services lists sane-port
and not saned; I can pretty much guarantee that you'll find sane-port
on an Ubuntu system because years ago I got that fixed in Debian.

The saned documentation is also up to date as we fixed all of that in
one go when we (re-)discovered this naming issue.


Last but not least, when I tell something about saned, you can really
trust me. There are 1.5 persons who understand how saned works, and
I'm the 1.0 part of it these days. I rewrote the networking code years
ago and did quite a bit of cleanup while I was at it. I still know
parts of the saned code by heart some 5 years after I did the work.

I did so many tests on saned to ensure I did not break it that I
missed some very obvious things in the net backend at the same
time. That should tell you how much care went into saned at that
time. :-)

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169