Re: what binds to port
On Mon 16 Aug 2021 at 19:55:49 +0100, Brian wrote: > On Mon 16 Aug 2021 at 19:51:50 +0200, Nicolas George wrote: > > > Brian (12021-08-02): > > > My thinking is that a USB printer uses libusb, just as a scanner does. > > > No kernel driver involved. The printer drivers are "internal" to CUPS. > > > > The output of `/sbin/modinfo usblp` confirms there is a kernel driver > > for USB printers. > > > > filename: > > /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko > > license:GPL > > description:USB Printer Device Class driver > > author: Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, > > Pete Zaitcev, David Paschal > > The existence of the usblp kernel module is not in doubt. > > > It is entirely possible that both this and generic libusb access are > > supported. > > The printing system detaches usblp when it is met. >From /cups/cups-2.3.0/backend/usb-libusb.c: /* * Get the "usblp" kernel module out of the way. This backend only * works without the module attached. */ -- Brian.
Re: what binds to port
On Mon 16 Aug 2021 at 19:51:50 +0200, Nicolas George wrote: > Brian (12021-08-02): > > My thinking is that a USB printer uses libusb, just as a scanner does. > > No kernel driver involved. The printer drivers are "internal" to CUPS. > > The output of `/sbin/modinfo usblp` confirms there is a kernel driver > for USB printers. > > filename: /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko > license:GPL > description:USB Printer Device Class driver > author: Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete > Zaitcev, David Paschal The existence of the usblp kernel module is not in doubt. > It is entirely possible that both this and generic libusb access are > supported. The printing system detaches usblp when it is met. -- Brian.
Re: what binds to port
Brian (12021-08-02): > My thinking is that a USB printer uses libusb, just as a scanner does. > No kernel driver involved. The printer drivers are "internal" to CUPS. The output of `/sbin/modinfo usblp` confirms there is a kernel driver for USB printers. filename: /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko license:GPL description:USB Printer Device Class driver author: Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal It is entirely possible that both this and generic libusb access are supported. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: what binds to port
On Mon 02 Aug 2021 at 17:35:46 +0200, Nicolas George wrote: > Brian (12021-08-02): > > Helpful remarks, but I did not think printers used kernel drivers. > > AFAIR, USB printers appear as a special device, unlike generic USB > devices, that makes one layer of drivers, but then you need an userland > driver, probably GhostScript, to talk the proper language to that > device, and that makes a second layer of drivers. My thinking is that a USB printer uses libusb, just as a scanner does. No kernel driver involved. The printer drivers are "internal" to CUPS. -- Brian.
Re: what binds to port
Brian (12021-08-02): > Helpful remarks, but I did not think printers used kernel drivers. AFAIR, USB printers appear as a special device, unlike generic USB devices, that makes one layer of drivers, but then you need an userland driver, probably GhostScript, to talk the proper language to that device, and that makes a second layer of drivers. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: what binds to port
On Mon 02 Aug 2021 at 10:36:22 +0200, Nicolas George wrote: > Thomas Schmitt (12021-08-02): > > Do you have any sg device left as suspect for the scanner's device file, > > after you subtracted one for each hard disk and each optical drive ? > > (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left > > ?) > > Have SCSI scanners been spotted since the 20th century, except in zoos? I have one in captivity here :). 1990s vintage. > Only USB mass storage devices are shown as SCSI devices, because they > use mostly the same command set. Other USB devices either have their own > kernel drivers (printers…) or appear as generic USB devices nodes to be > accessed with libusb. Helpful remarks, but I did not think printers used kernel drivers. -- Brian.
Re: what binds to port
On Mon 02 Aug 2021 at 13:21:22 +0200, Thomas Schmitt wrote: > Hi, > > Brian wrote: > > Isn't /dev/sg0 the block device? > > /dev/sgX are character devices. > > https://tldp.org/HOWTO/SCSI-Generic-HOWTO/intro.html > says > "The driver's purpose is to allow SCSI commands to be sent directly to >SCSI devices. [...] Various specialized applications for writing >CD-Rs and document scanning use the sg driver." > > This is still the case for optical drives (sr) and hard discs (sd) which get > an sg device file additionaly to their block device file. But it seems that > the statement about "document scanning" could need an update. > > > The main call for sg devices is ioclt(SG_IO) which performs a single SCSI > command transaction. > Since about 15 years it is possible to use it directly with a /dev/srX > device file. But a bug introduced in a late version of kernel 2.6 prevented > concurrent use of SG_IO on multiple sr devices. This ended with > https://github.com/torvalds/linux/commit/51a8588 > which i assume went into kernel version 5.6. > So with the currently released Debian versions, /dev/sgX is still of use > if there is more than one sr device. I misread sr0 as sg0; sorry to have put you to the trouble of posting. On the bright side, you have helped clear up a misconception of mine. -- Brian.
Re: what binds to port
Hi, Brian wrote: > Isn't /dev/sg0 the block device? /dev/sgX are character devices. https://tldp.org/HOWTO/SCSI-Generic-HOWTO/intro.html says "The driver's purpose is to allow SCSI commands to be sent directly to SCSI devices. [...] Various specialized applications for writing CD-Rs and document scanning use the sg driver." This is still the case for optical drives (sr) and hard discs (sd) which get an sg device file additionaly to their block device file. But it seems that the statement about "document scanning" could need an update. The main call for sg devices is ioclt(SG_IO) which performs a single SCSI command transaction. Since about 15 years it is possible to use it directly with a /dev/srX device file. But a bug introduced in a late version of kernel 2.6 prevented concurrent use of SG_IO on multiple sr devices. This ended with https://github.com/torvalds/linux/commit/51a8588 which i assume went into kernel version 5.6. So with the currently released Debian versions, /dev/sgX is still of use if there is more than one sr device. Have a nice day :) Thomas
Re: what binds to port
On Mon 02 Aug 2021 at 09:55:17 +0200, Thomas Schmitt wrote: > Hi, > > i wrote: > > > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected. > > mick crane wrote: > > Drive type : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11' > > So it's clearly the DVD burner which is at sg2. > > Do you have any sg device left as suspect for the scanner's device file, > after you subtracted one for each hard disk and each optical drive ? > (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?) Isn't /dev/sg0 the block device? -- Brian.
Re: what binds to port
Thomas Schmitt (12021-08-02): > Do you have any sg device left as suspect for the scanner's device file, > after you subtracted one for each hard disk and each optical drive ? > (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?) Have SCSI scanners been spotted since the 20th century, except in zoos? Only USB mass storage devices are shown as SCSI devices, because they use mostly the same command set. Other USB devices either have their own kernel drivers (printers…) or appear as generic USB devices nodes to be accessed with libusb. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: what binds to port
On 2021-08-02 08:55, Thomas Schmitt wrote: Hi, i wrote: > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected. mick crane wrote: Drive type : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11' So it's clearly the DVD burner which is at sg2. Do you have any sg device left as suspect for the scanner's device file, after you subtracted one for each hard disk and each optical drive ? (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?) doesn't seem to be. root@pumpkin:/dev# ls -la |grep sg drwxr-xr-x 2 root root 180 Jul 31 18:20 bsg crw-r--r-- 1 root root 1, 11 Jul 31 17:20 kmsg crw-rw 1 root disk 21, 0 Jul 31 17:20 sg0 crw-rw 1 root disk 21, 1 Jul 31 17:20 sg1 crw-rw+ 1 root cdrom21, 2 Jul 31 17:20 sg2 lsusb Bus 002 Device 004: ID 04c5:1095 Fujitsu, Ltd I don't know anything about usb Everything is working now. using the scanner button seems maybe a second or so slower than XSane to get going but I think I'll leave alone. cheers mick -- Key ID4BFEBB31
Re: what binds to port
Hi, i wrote: > > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected. mick crane wrote: > Drive type : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11' So it's clearly the DVD burner which is at sg2. Do you have any sg device left as suspect for the scanner's device file, after you subtracted one for each hard disk and each optical drive ? (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?) Have a nice day :) Thomas
Re: what binds to port
On 2021-07-31 12:11, Thomas Schmitt wrote: Hi, mick crane wrote: looking at those informative pages I think /dev/sg2 is the scanner should that not be in group scanner ? lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected. Drive type : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11' cheers mick -- Key ID4BFEBB31
Re: what binds to port
Greg Wooledge wrote: > On Sun, Aug 01, 2021 at 10:41:13AM -0400, songbird wrote: > > mick crane wrote: > > > Doh! discovered have to restart scanbd.service after changing config > > > file. > > > You'd have thought I would know that. > > > > some will restart automatically when their config file changes > > and others don't. you have to know which do and which don't > > since this isn't a universal feature yet. > > Very few programs poll for changes to their configuration files. That > would be a sloppy design. The reason that this is a sloppy design is because editing a config file by hand will inevitably lead to invalid configs. Some long-running daemons instead listen for a signal to tell them to re-load their config file without shutting down. The really good ones run a syntax checker before trying to run the new config, and emit an error message but continue on the old config when the new one fails. A daemon which is very quick to start and stop probably doesn't implement that at all. -dsr-
Re: what binds to port
On Sun, Aug 01, 2021 at 10:41:13AM -0400, songbird wrote: > mick crane wrote: > > Doh! discovered have to restart scanbd.service after changing config > > file. > > You'd have thought I would know that. > > some will restart automatically when their config file changes > and others don't. you have to know which do and which don't > since this isn't a universal feature yet. Very few programs poll for changes to their configuration files. That would be a sloppy design. If a program runs as a daemon (really running, i.e. you can see the process in the output of ps -ef), and you change its configuration file, you will typically need to take some action to notify the daemon that a change has occurred. This action may be sending a SIGHUP to the running daemon, or it may be restarting the daemon. If on the other hand a program is *not* continuously running as a daemon, but is instead started on demand (e.g. by inetd or by systemd's socket activation), then there's no need to take any action when the configuration is changed. The next instance of the program that gets launched will by necessity read the configuration file. So, in almost all cases, it's sufficient to figure out which of these two designs you're dealing with. Ideally, the documentation (the man page) of the daemon will tell you. In some cases, there are multiple ways the service can be implemented (sshd comes to mind), and so the man page has to list *both* possibilities, and *you* as the sysadmin have to know which one is actually being used on your system.
Re: what binds to port
mick crane wrote: > On 2021-07-31 17:40, Brian wrote: ><...> > Doh! discovered have to restart scanbd.service after changing config > file. > You'd have thought I would know that. > changing group to scanner of directory want to save to seems to have > fixed permission issue. > mick some will restart automatically when their config file changes and others don't. you have to know which do and which don't since this isn't a universal feature yet. preferably i do not want things to reload unless i specifically tell them to just in case i'm relying upon that process for something critical until i've got everything synced up and then i restart or reboot and all should be ok. songbird
Re: what binds to port
On 2021-07-31 17:40, Brian wrote: <...> Doh! discovered have to restart scanbd.service after changing config file. You'd have thought I would know that. changing group to scanner of directory want to save to seems to have fixed permission issue. mick -- Key ID4BFEBB31
Re: what binds to port
On Sat 31 Jul 2021 at 17:17:29 +0100, mick crane wrote: > On 2021-07-31 16:32, Brian wrote: > > > grep scanner /etc/groups > > cat /etc/default/saned > > > I keep thinking it should be groups and not group as well. An embarassing typo :). > me and saned are in scanner group > /etc/default/saned > RUN_AS_USER=saned You do not need to be in the scanner group. This requirement disappeared years ago but it still gets repeated (ad nauseam). See https://wiki.debian.org/Scanner#perms > > > How to find which is the scanner in /dev if it is supposed to be > > > there? > > > Xsane works fine. > > > > I thought it was /dev/sg2. > I said I thought it might be sg2 and wondered how to find out. Scanners are treated as SCSI devices and therefore come under /dev/sg*. Look for the + and use getfacl. As a really naff method, move the device file out of the way and see whether you can scan. -- Brian.
Re: what binds to port
On Sat 31 Jul 2021 at 16:57:53 +0100, mick crane wrote: > On 2021-07-31 14:37, mick crane wrote: > when I say Xsane works fine. > All I've deleted as far as I know are the .conf files for scanners I don't > have. > > In /etc/sane.d/dll.conf > I removed all scanner names except > net > fujitsu > #escl That's OK. > running Xsane I get to select > fujitsu or net:localhost.. both of which work I'd expect this too. > but if I comment out fujitsu Xsane says "no devices available" > /etc/sane.d/net.conf > connect_timeout = 3 > localhost > > Which I'm not understanding. the net backend is for accessing another backend, either remotely or on localhost. If you comment out fujitsu on localhost, there isn't any suitable backend on localhost to contact and use the scanner. -- Brian.
Re: what binds to port
On 2021-07-31 16:32, Brian wrote: grep scanner /etc/groups cat /etc/default/saned I keep thinking it should be groups and not group as well. me and saned are in scanner group /etc/default/saned RUN_AS_USER=saned How to find which is the scanner in /dev if it is supposed to be there? Xsane works fine. I thought it was /dev/sg2. I said I thought it might be sg2 and wondered how to find out. mick -- Key ID4BFEBB31
Re: what binds to port
On 2021-07-31 14:37, mick crane wrote: when I say Xsane works fine. All I've deleted as far as I know are the .conf files for scanners I don't have. In /etc/sane.d/dll.conf I removed all scanner names except net fujitsu #escl running Xsane I get to select fujitsu or net:localhost.. both of which work but if I comment out fujitsu Xsane says "no devices available" /etc/sane.d/net.conf connect_timeout = 3 localhost Which I'm not understanding. mick -- Key ID4BFEBB31
Re: what binds to port
On Sat 31 Jul 2021 at 14:37:49 +0100, mick crane wrote: > On 2021-07-31 13:18, Brian wrote: > > On Sat 31 Jul 2021 at 10:20:43 +0100, mick crane wrote: > > > > > On 2021-07-30 18:30, Brian wrote: > > > <...> > > > > https://wiki.debian.org/SaneOverNetwork#escl > > > looking at those informative pages I think /dev/sg2 is the scanner > > > should that not be in group scanner ? > > > > > > root@pumpkin:/# ls -l /dev |grep cdrom > > > lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 > > > crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 > > > brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 > > > > I don't see why it should be. I too have > > > > crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg1 > > > > on bullseye. Note the +. Its an ACL. systemd, and libpam-systemd have > > taken care of the correct permissions on the scanner device file. Try > > > > getfacl /dev/sg2 > > > > (Did you ever say in this thread what the printer/scanner is?) > > I thought it was in there, it's fujitsu fi-5750c Thanks. The device appears to date from about 2007. I am surprised that SANE's escl backend detects it and that scanning with xsane "escl:fi-5750Cdj:107245" is possible. (Just a comment and nothing to do with your issues). > The scanbd.conf says > user saned > group scanner It is the saned user that has to be in the scanner group, not your user. grep scanner /etc/groups cat /etc/default/saned > I'm wondering if this is why I'm having difficulty saving scans anywhere > other than /tmp > and getting permission denied writing to a file with a script both in > /etc/scanbd/scripts called from scanbd.conf Probably not. > How to find which is the scanner in /dev if it is supposed to be there? > Xsane works fine. I thought it was /dev/sg2. -- Brian.
Re: what binds to port
On 2021-07-31 13:18, Brian wrote: On Sat 31 Jul 2021 at 10:20:43 +0100, mick crane wrote: On 2021-07-30 18:30, Brian wrote: <...> > https://wiki.debian.org/SaneOverNetwork#escl looking at those informative pages I think /dev/sg2 is the scanner should that not be in group scanner ? root@pumpkin:/# ls -l /dev |grep cdrom lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 I don't see why it should be. I too have crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg1 on bullseye. Note the +. Its an ACL. systemd, and libpam-systemd have taken care of the correct permissions on the scanner device file. Try getfacl /dev/sg2 (Did you ever say in this thread what the printer/scanner is?) I thought it was in there, it's fujitsu fi-5750c The scanbd.conf says user saned group scanner I'm wondering if this is why I'm having difficulty saving scans anywhere other than /tmp and getting permission denied writing to a file with a script both in /etc/scanbd/scripts called from scanbd.conf How to find which is the scanner in /dev if it is supposed to be there? Xsane works fine. mick -- Key ID4BFEBB31
Re: what binds to port
On Sat 31 Jul 2021 at 10:20:43 +0100, mick crane wrote: > On 2021-07-30 18:30, Brian wrote: > <...> > > https://wiki.debian.org/SaneOverNetwork#escl > looking at those informative pages I think /dev/sg2 is the scanner > should that not be in group scanner ? > > root@pumpkin:/# ls -l /dev |grep cdrom > lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 > crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 > brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 I don't see why it should be. I too have crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg1 on bullseye. Note the +. Its an ACL. systemd, and libpam-systemd have taken care of the correct permissions on the scanner device file. Try getfacl /dev/sg2 (Did you ever say in this thread what the printer/scanner is?) -- Brian.
Re: what binds to port
Hi, mick crane wrote: > looking at those informative pages I think /dev/sg2 is the scanner > should that not be in group scanner ? > lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 > crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 > brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected. Each drive operation of sr is performed by the SCSI transaction facility of sg (reachable from userspace by ioctl(SG_IO)). If sg2 is an optical drive, then xorriso will accept it as SCSI-MMC drive: $ xorriso -no_rc -outdev /dev/sg4 -toc ... Drive type : vendor 'HL-DT-ST' product 'BD-RE GGW-H20L' revision 'YL03' ... If it is not an optical drive then the output is rather xorriso : FAILURE : Drive address '/dev/sg8' rejected because: not MMC and -drive_class 'caution' '/dev' If you don't have rw-access permission you get in both cases libburn : FAILURE : Cannot access '/dev/sg8' as SG_IO CDROM drive Have a nice day :) Thomas
Re: what binds to port
On 2021-07-30 18:30, Brian wrote: <...> https://wiki.debian.org/SaneOverNetwork#escl looking at those informative pages I think /dev/sg2 is the scanner should that not be in group scanner ? root@pumpkin:/# ls -l /dev |grep cdrom lrwxrwxrwx 1 root root 3 Jul 30 17:36 cdrom -> sr0 crw-rw+ 1 root cdrom21, 2 Jul 30 17:36 sg2 brw-rw+ 1 root cdrom11, 0 Jul 30 17:36 sr0 mick -- Key ID4BFEBB31
Re: what binds to port
On 2021-07-30 18:30, Brian wrote: I like things to work but I'm quite capable of breaking things on my own. A sound principal for anyone to take note of. =O) -- Key ID4BFEBB31
Re: what binds to port
On Fri 30 Jul 2021 at 17:47:50 +0100, mick crane wrote: > On 2021-07-30 15:36, to...@tuxteam.de wrote: > > On Fri, Jul 30, 2021 at 03:21:47PM +0100, mick crane wrote: > > > >>> > Can I assume there is something else binding to the scanner address > > > >>> > ? > > > > [...] > > > > > >>it's inetd > > > >>tcp0 0 0.0.0.0:sane-port 0.0.0.0:* > > > >>LISTEN > > > >>869/inetd > > > > [...] > > > > > The only thing not commented out is > > > sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm > > > > > > The scanbd installer package must have put it there. > > > I'm thinking inetd is the thing that is watching and tells scanbm to > > > wake up. > > > > Exactly: that's inetd's job (well, it used to be, until > > systemd "reinvented" it). > > > > Cheers > > - t > > This is getting silly. Why have I got 2 scanners You do not have two scanners. You have a single scanner capable of using two different SANE backends, fujitsu: and escl:. Actually, you are using a third backend, net:, too. > mick@pumpkin:~$ scanimage -L > device `net:localhost:fujitsu:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj > scanner > device `net:localhost:escl:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj > scanner > mick@pumpkin:~$ > what is this "escl" one? Your are using bullseye. It comes with the territory. https://wiki.debian.org/SaneOverNetwork#escl I might have missed it, but did you ever say in this thread what the device is? > How hard is it to get rid of this systemd and helper things stuff ? Rhetorical, I hope? You haven't any evidence to believe it is the source of any of your difficulties. User disparagement doesn't count. > I like things to work but I'm quite capable of breaking things on my own. A sound principal for anyone to take note of. -- Brian.
Re: what binds to port
On 2021-07-30 15:36, to...@tuxteam.de wrote: On Fri, Jul 30, 2021 at 03:21:47PM +0100, mick crane wrote: >>> > Can I assume there is something else binding to the scanner address ? [...] >>it's inetd >>tcp0 0 0.0.0.0:sane-port 0.0.0.0:* >>LISTEN >>869/inetd [...] The only thing not commented out is sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm The scanbd installer package must have put it there. I'm thinking inetd is the thing that is watching and tells scanbm to wake up. Exactly: that's inetd's job (well, it used to be, until systemd "reinvented" it). Cheers - t This is getting silly. Why have I got 2 scanners mick@pumpkin:~$ scanimage -L device `net:localhost:fujitsu:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj scanner device `net:localhost:escl:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj scanner mick@pumpkin:~$ what is this "escl" one? How hard is it to get rid of this systemd and helper things stuff ? I like things to work but I'm quite capable of breaking things on my own. mick -- Key ID4BFEBB31
Re: what binds to port
On Fri, Jul 30, 2021 at 03:21:47PM +0100, mick crane wrote: > >>> > Can I assume there is something else binding to the scanner address ? [...] > >>it's inetd > >>tcp0 0 0.0.0.0:sane-port 0.0.0.0:* > >>LISTEN > >>869/inetd [...] > The only thing not commented out is > sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm > > The scanbd installer package must have put it there. > I'm thinking inetd is the thing that is watching and tells scanbm to > wake up. Exactly: that's inetd's job (well, it used to be, until systemd "reinvented" it). Cheers - t signature.asc Description: Digital signature
Re: what binds to port
On 2021-07-30 12:45, Greg Wooledge wrote: On Fri, Jul 30, 2021 at 12:37:40PM +0100, mick crane wrote: On 2021-07-30 11:59, Dan Ritter wrote: > mick crane wrote: > > Can I assume there is something else binding to the scanner address ? > > How to find out what that might be ? > > > sudo netstat -ltp|grep sane-port > > should tell you the PID and name of the process. it's inetd tcp0 0 0.0.0.0:sane-port 0.0.0.0:* LISTEN 869/inetd Is this to be expected or might it be something to do with network manager ? At this point, you look at your inetd.conf file and see what's in there. The only thing not commented out is sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm The scanbd installer package must have put it there. I'm thinking inetd is the thing that is watching and tells scanbm to wake up. Thinking that the debian scanbd maintainers had everything setup nicely and I screwed up following wrong READMEs etc I purged scanbd and reinstalled. Now I have 2 net.scanners. Getting to be a bit of a nightmare. It was all working yesterday then I was having permission denied stuff trying to save scans in my home directory from a script in /etc/scanbd when I'd have thought it should work when it wrote to /tmp OK. A few times I've had a window pop up when pasting stuff into a file saying to effect "this looks unsafe, are you sure you want to do that" I'm wondering if there is some helpful program in Debian 11 which is monitoring activity and giving the "permission denied" ? mick -- Key ID4BFEBB31
Re: what binds to port
> > > $ sudo ss -l4pon | grep [port] > > That grep command is wrong in a couple ways. > > First, the unquoted [port] is a live glob pattern for the shell. I meant port number here, i.e.: $ sudo ss -l4pon | grep 80 > Finally, you added the -n option to ss, which means it no longer prints > service names; it prints port numbers instead. Exactly, because I had a port number in my mind > (And now that I've written all of this, it occurs to me that maybe > you were using [port] as a syntactic symbol meaning "put the numeric > port number here". Normally we'd use or _port_ for that. Yes, you are right. I should have written it as , not [port]. Sorry for the misleading comment. I was trying to say that in modern Linux netstat is not installed by default and ``ss`` is a preferred way.
Re: what binds to port
On Fri, Jul 30, 2021 at 02:27:19PM +0300, IL Ka wrote: > > > > sudo netstat -ltp|grep sane-port > > > > or > > $ sudo ss -l4pon | grep [port] That grep command is wrong in a couple ways. First, the unquoted [port] is a live glob pattern for the shell. The shell will look for files in the current working directory named "p" or "o" or "r" or "t". If it finds one or more of those, it will replace the [port] glob with the list of the matching filenames, sorted by your locale's collating order. Second, even if [port] is quoted or doesn't match any files in the current directory, grep is going to treat is as "match any line that contains the letter p or the letter o or the letter r or the letter t". That's going to generate way more matches than you probably want. I believe what you were aiming for is this hack: grep [p]ort This is one of the cargo cult tricks that people use when they're looking for a process in the output of ps. Most people don't even understand it; they just tried it once and it "worked" so they keep doing it. You apparently only half-remembered the trick, so you got it wrong. Even worse, you applied the trick in a context where it isn't even necessary. You're not looking for processes in the output of ps, so you didn't need to stop grep from finding itself by mangling the pattern. Finally, you added the -n option to ss, which means it no longer prints service names; it prints port numbers instead. So the output is no longer going to contain the word "sane-port", and therefore your grep for "port" won't work. (And now that I've written all of this, it occurs to me that maybe you were using [port] as a syntactic symbol meaning "put the numeric port number here". Normally we'd use or _port_ for that. Or else you'd actually type out the numeric equivalent of sane-port, so the reader doesn't have to look it up themselves. Square brackets are reserved for "this is an optional argument", or else they're literal.)
Re: what binds to port
On Fri, Jul 30, 2021 at 12:37:40PM +0100, mick crane wrote: > On 2021-07-30 11:59, Dan Ritter wrote: > > mick crane wrote: > > > Can I assume there is something else binding to the scanner address ? > > > How to find out what that might be ? > > > > > > sudo netstat -ltp|grep sane-port > > > > should tell you the PID and name of the process. > > it's inetd > tcp0 0 0.0.0.0:sane-port 0.0.0.0:* LISTEN > 869/inetd > > Is this to be expected or might it be something to do with network manager ? At this point, you look at your inetd.conf file and see what's in there.
Re: what binds to port
On 2021-07-30 11:59, Dan Ritter wrote: mick crane wrote: Can I assume there is something else binding to the scanner address ? How to find out what that might be ? sudo netstat -ltp|grep sane-port should tell you the PID and name of the process. it's inetd tcp0 0 0.0.0.0:sane-port 0.0.0.0:* LISTEN 869/inetd Is this to be expected or might it be something to do with network manager ? mick -- Key ID4BFEBB31
Re: what binds to port
> > sudo netstat -ltp|grep sane-port > or $ sudo ss -l4pon | grep [port]
Re: what binds to port
mick crane wrote: > Can I assume there is something else binding to the scanner address ? > How to find out what that might be ? sudo netstat -ltp|grep sane-port should tell you the PID and name of the process. -dsr-
