No /dev/bus/usb/ in Lucid Puppy

Using applications, configuring, problems
Message
Author
ahoppin
Posts: 172
Joined: Mon 16 May 2011, 04:13

#21 Post by ahoppin »

One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?

Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.

Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#22 Post by Mike Walsh »

ahoppin wrote:One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?

Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.

Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.
TBH, I wouldn't think so. Although I can't say for sure with the newer stuff; my old SX218 must be getting on for 9-10 years old now. Too old for them to bother with, I should imagine!

(I'm in Tahr 606 ATM, my most recent addition to the kennels (just a couple of months back), and less than 5 minutes ago I printed a document off, using third-party ink.....)

(*shrug*)

And your scanner is, by your own admission, quite an old one. D'you know, what you say about this is the first I've heard of it.....but with the way the price of OEM ink is going, it's hardly surprising, I suppose.

I somehow doubt you and I will have any problems with that one. Especially not your scanner; they don't use ink, so I can't see what Epson would stand to gain from such an excercise.....


Mike. :wink:

ahoppin
Posts: 172
Joined: Mon 16 May 2011, 04:13

#23 Post by ahoppin »

Could be that you're right, that your printer is old enough that Epson has mostly forgotten about it. You never know though...

If you search the web you'll find plenty of info about the ink wars. HP was the most recent "bad guy," but Epson has been named too.

It's an older discussion, but try this one as an example:

https://www.printerknowledge.com/thread ... ning.6614/

or https://v.gd/KIjECw

It seems that keeping third-party ink working with many inkjet printers, including Epsons, is a cat and mouse game. The Chinese chip techs reverse-engineer the factory ink cart chips, and sell clones to the refillers. Recycled ink carts using those clone chips then work -- until the cat (the printer maker) pushes a new firmware update to the printer to block them. Then the updated printer gripes that your carts "can't be recognized," and the Chinese mice go to work again.

I think there are now some legal restrictions on this practice of limiting third-party ink use in the EU. However, here in the US, the laws are usually not as strongly pro-consumer.

For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.

Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.

To bring this marginally back on topic, I found this thread on the board:

http://murga-linux.com/puppy/viewtopic.php?t=61885

It seems that rcrsn51 has written a utility that converts Epson's proprietary Linux printer drivers to native Puppy .pet packages, a great idea. I would hope that his utility would install just what's necessary for printing, omitting any spyware or updaters, but I can't tell for sure from the thread.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#24 Post by greengeek »

In Lucid 5.25 and Lucid 5.28 could you post the output of

cat /etc/group

both before and after plugging in the scanner?

Then maybe the same in Tahr before and after you do the chmod stuff.
cheers!

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#25 Post by greengeek »

And maybe also:

cat /etc/sane.d/epson2.conf

ahoppin
Posts: 172
Joined: Mon 16 May 2011, 04:13

#26 Post by ahoppin »

/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.

I'm pretty sure that when udev (the usb hotplug daemon, if I understand it right) sees a USB device plugged in, it creates or updates the device files in /dev with reference to configuration files in /etc/udev/rules.d. I suppose those rules may read the contents of /etc/group (among other files), but I don't know for sure.

In the specific context of USB scanners and sane, in most cases you want the rules to create scanner device files in /dev so that they're rw for the scanner or lp group. Then if spot (or other regular non-root user) is a member of the scanner or lp group, the non-root user can (if all goes well) use xsane.

Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.

Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.

Now, though, I have a version of xsane that doesn't complain about being run as root, so my problem is effectively solved.

But I remain curious about USB in Puppy. If you want to join me in experimenting with the different ways these different pups handle USB devices, you can download the iso files back to version 2.16 from http://distro.ibiblio.org/puppylinux/

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#27 Post by greengeek »

ahoppin wrote:/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.
I think you are assuming that the reason Spot can't scan is because it doesn't have permission to access a device port. It may be that it does not have permission to access a file in /etc (eg /etc/sane.d) or maybe that it does not have permission to access a newly plugged device like a scanner (as is the norm for non root users wanting to access a newly plugged device) - in which case part of the answer may be to ensure that Spot is added to /etc/group as having access to scanner devices.
Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.

Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.
But you also said that all of the files in /dev were already accessible to Spot. I probably misunderstood, but I never grasped why you thought it was successful to chmod /dev files, while also saying "There's no need to change the permissions of /dev, it's already 755 (rwxr-xr-x), so it's searchable by anyone.
The usbdev* files are at the first level under /dev, so there are no directories that would need to be changed."

Surely it can't be both ways? Either all /dev files are available to Spot or they are not. If all of the /dev files and /etc fles are accessible to Spot but you still can't access the backend then the problem must be somewhere else?

But I remain curious about USB in Puppy
Hotplug changed from Puppy to Puppy and I guess that changes the specifics of the usb detection - sometimes there are conflicts with kernel drivers apparently.

I think Bigpup summed it up though - Spot was intended for internet protections and as a result it will be a longwinded bughunt to work out which file is preventing Spot from accessing the specific hardware resource.

Sorry I couldn't be of any help
cheers!

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#28 Post by Mike Walsh »

Hi, ahoppin.
ahoppin wrote:For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.

Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.
Which is why I keep using the same set of drivers that were current at the time when I first bought the SX218 several years ago. They still install, they still give me full functionality, I can still use 3rd-party ink.....where's the point in updating them? Especially if these firmware updates are being pushed out via the updated driver packages? :roll:

I'll stick with what works for me, thank you very much..! :lol: And, er....thanks for the heads-up on Epson pulling the same stunt as HP; I wasn't aware of that, I must admit. (My practice of using the same set of drivers indefinitely probably shielded me from that one...)


Mike. :wink:

ahoppin
Posts: 172
Joined: Mon 16 May 2011, 04:13

#29 Post by ahoppin »

> It may be that it does not have permission to access a file in
> /etc (eg /etc/sane.d)

I checked that when you mentioned it before, and it didn't fix the problem. Good analysis though.

> or maybe that it does not have permission
> to access a newly plugged device like a scanner (as is the norm for
> non root users wanting to access a newly plugged device) - in which
> case part of the answer may be to ensure that Spot is added
> to /etc/group as having access to scanner devices.

That would probably work, if the SANE udev rules were in place the way they seem to be for other distros. Search around or look at some of the forums I linked to before, and you'll see these scanner group rules quoted.

But you won't see them in Puppy's /etc/udev/rules.d.

Nor is there a scanner group in /etc/group.

My guess is that BK and the Puppy programming team didn't include them because normally all Puppy users run as root, so permissions don't matter for them.

I think the above idea probably would work if you created the scanner group, made spot a member of it, and manually added all the necessary udev rules. I haven't tried it, though.

> I never grasped why you thought it was successful to chmod /dev
> files, while also saying "There's no need to change the permissions of
> /dev...
>
> Surely it can't be both ways? Either all /dev files are available to
> Spot or they are not.

"Available" doesn't necessarily mean "usable."

Since /dev is mode 755 (rwxr-xr-x), it's *searchable* by anyone. Spot's programs, in this case xsane, scanimage, etc, can thus find the files they need in /dev.

But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.

So both conditions have to exist. Sorry if that wasn't clear.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#30 Post by greengeek »

ahoppin wrote:But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.

So both conditions have to exist. Sorry if that wasn't clear.
No - it's just my ignorance in play :-)

I thought that "chown"ing was the same thing as offering "all permissions".

What I meant was - that if you give Spot total control of everything in /dev and /etc (recursively) it would show whether or not that is where the "resource denied" bottleneck was.

I just figured that the "bus" directories (or their alternatives) would most likely be in /etc or /dev. Unless they exist only in /proc - which is possible depending on the structure of the kernel modules.

Of course - even if setting full Spot permissions for /etc and /dev was successful - it would not pin down specifically where the problem lay, but I just hoped it might remove the roadblocks and provide somewhere to focus the lens.

Good luck!

Post Reply