"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
