Puppy Linux problem, or something else?

[MikeHalloran]

I'm trying to use this aging HP Pavilion a556x desktop. I say aging because the hard drive is dead. I booted from several Puppy live CDs and installed them to a flash drive, then booted from the flash drive.
I've tried Slacko 5.4, working now, Slacko 5.3.3, and Lucid 5.2.8, and I think a couple more.

All work perfectly, except for two problems:
1.
The local printer, an HP 5610 AIO, installs normally, and files sent to it just disappear into a bitbucket. No response. Tried a different cable. No difference.
Tried a different USB port; no difference. However, this computer is old, and some of the USB ports have been flaky.
Never mind that for now.

2.
I also have a wireless networked printer, an HP6380 AIO.
It normally responds to its name, HPA3EEBD, so I have been setting up the Puppies using CUPS and a port name, i.e. socket://HPA3EEBD:9100.
On trying to send a test page, I get various error message about the printer not being there, or not responding, and no output from the printer.
However, if I set the port name to socket://192.168.1.66:9100, the printer works normally.
Here's a clue about that:
From a terminal, I #ping HPA3EEBD, and get a response
PING HPA3EEBD (192.168.1.68); 56 data bytes
... and no further response.
From a terminal I #ping 192.168.1.66, and get a response
PING 192.168.1.66 (192.168.1.66); 56 data bytes
64 bytes from ...
... in other words a normal response.

So, something, somewhere, is erroneously mapping the wireless printer's name to the wrong IP address, i.e. offset by +2 in the last byte.

Is that a CUPS problem, a Puppy problem, or a problem with the router, which is a 2WIRE box supplied by AT&T with Uverse, or something to do with cosmic rays?

 

[MikeHalloran]

Never mind; it appears to be a really hoary old 2WIRE bug, that apparently will never ever be fixed.

 

[MikeHalloran]

News, if under some bizarre set of circumstances anyone should care:


Problem #2 has been reported as 'local nameservice screws up' or some such for the 2WIRE router supplied for Uverse by AT&T, and I have found reports and complaints going back a couple years, even on AT&T sites. The bug seems to be present in at least a few models of such devices. The least awful workaround is to tell the router to assign particular IP addresses to particular devices or servers, and to tell the workstations to use that 'semi-fixed' IP address for the devices or servers, instead of trying to address them by name. The name to IP function appears to work correctly for a few minutes or a few hours after rebooting the router, and then at some time after boot, which I haven't measured with any precision, the router responds with the wrong IP address, always wrong by +2 in the last number pair.


Problem #1 appears to a bug in Puppy Linux 5.0 and up, only. Other distributions, and earlier releases of Puppy, find the local USB printer and use it without issue. Puppies 5.0 and above find the local USB printer, install it without apparent issue, and behave normally in every respect, except that nothing comes out of the printer and there is no sign that anything goes in, either.

Aside from that, everything is back to abnormal here.

 

[Noway2]

The least awful workaround is to tell the router to assign particular IP addresses to particular devices or servers, and to tell the workstations to use that 'semi-fixed' IP address for the devices or servers, instead of trying to address them by name.

The least awful: to avoid using name resolution and use the IP address instead. This defeats the whole purpose.

Are you running a server on your LAN? If so, maybe you would be interested in setting up your own name server for your LAN, which is really easy instead of using the one built into the router?

 

[MikeHalloran]

At the time the nameserver issue came up, the primary server was running from a flashdrive because of a hard drive crash. That server does occasionally go down; it's been instructed to not automatically reboot after a power failure because of transients that always follow the first power glitch here in SoFla.

So I'd still prefer to have a working nameserver within the router; funny thing is, the nameserver in the router worked fine for most of a year before the bug appeared. That behavior has also been reported widely. It should be enough of a clue for someone to fix the firmware, but AT&T shows no interest in getting it fixed, nor does 2WIRE, nor does the outfit that took over from them.

I have run fixed IP before, but I keep losing the list of what is where.
Saving the list within the router keeps it accessible, sort of.



The Puppy Linux issue, I'm half embarrassed to say, was my fault for not installing a 'driver' for the printer, something that CUPS doesn't actually do while it's "installing" the printer. You have to go get hplip, which installs a driver for the printer. Ironically, when you then bring up CUPS to set up the printer, it presents a couple of choices. One of them, hplip plus the printer driver installed by hplip, doesn't work. Another, CUPS plus the printer driver installed by hplip, does work. I don't understand why CUPS can't say 'Hey, there ain't no driver here' when one is not installed.

 

[Noway2]

Sounds like a UPS would be a good investment given your power issues, which can be a real pain. We had a power blip a few weeks ago, in fact a couple of them in a row that caused the servers to go down, then go down again during the reboot process, which scrambled things pretty good. I had to manually reboot everything. In that regard, I should take my own advice about getting a UPS

The HPLIP, driver, CUPS thing is a massive headache. Years ago, I swore I would never buy another HP printer and that lasted about a decade until my wife wanted this all in one model and we went with HP because it supposedly had better Linux support. I had a fun time getting the drivers, compiling them, and getting it to work. Then came the scanner part which was even more fun. Strangely enough, when I installed the driver under Slackware once, it went off without a hitch. Go Figure.

In any case, if you ever do decide to implement DNS (I would recommend with DHCP), this is the link I followed (years ago) and found it to be remarkably simple:

http://lani78.wordpress.com/2008/08/12/dhcp-server-update-dns-records/

I understand why you want the service in the router, but thought I would pass it on in case you ever change your mind.

 

[MikeHalloran]

Thanks for the link.