[cups] [UNKN] STR #4320: Strange problem with CUPS on a Linux (CentOS 5.10) LAN
Robert Heller
heller at deepsoft.com
Mon Jan 13 13:25:17 PST 2014
Ok, the problem is back. I'm thinking that there is some gremlin on the LAN
(and I have no real clue where) that is interfering *specificly* with CUPS
broadcasts to this one machine. I have captured its error_log
(loglevel=debug2) and will attach it to this message.
What is the alternitive to broadcast browsing? Do I have to *manually*
configure the printers? It looks like this is something I am going to have to
do.
At Wed, 8 Jan 2014 11:36:43 -0500 Robert Heller <heller at deepsoft.com> wrote:
>
> OK, I power cycled the switch, moved the machine to a different port, and
> rebooted the machine. Things are now behaving. I will keep an eye on it and
> post here if the problem reappears.
>
> Question: If/when we upgrade to a newer version of CUPS (eg if/when we move to
> CentOS 6) and the broadcast browsing is discontinued, what exactly is the
> replacement stratagy? That is, what is the 'trick' (if any) to get client
> machines to automagically pick on on available print queues? Or do I have to
> configure the printers on each client machine (well really on one logical
> machine, since all of the clients will have a common (NFS shared)
> printers.conf file)?
>
> At Mon, 6 Jan 2014 18:11:21 -0500 Robert Heller <heller at deepsoft.com> wrote:
>
> >
> > At Mon, 06 Jan 2014 13:19:45 -0500 Michael Sweet <msweet at apple.com> wrote:
> >
> > >
> > >
> > > Robert,
> > >
> > > On the switch there might have been same stale ARP info that prevented it from delivering the broadcast packets to that port.
> > >
> > > On the machine it could have been some stale DHCP information, although I would have expected it to hand out the wrong address vs. experiencing that kind of issue.
> >
> > Since the client machine(s) were cold re-booted and the DHCP daemon on the
> > server was restarted, it seems unlikely that there was any stale DHCP
> > information. But stale state info on the switch is possible (or at least
> > plausable). If the problem shows up again, we'll reboot (power cycle) the
> > switch. Note: the librarian *always* shuts her machine down when she leaves
> > for the day and cold boots it in the morning...
> >
> > >
> > > Like I said, I'm stumped at this point...
> > >
> > >
> > > On Jan 6, 2014, at 12:36 PM, Robert Heller <heller at deepsoft.com> wrote:
> > >
> > > > At Mon, 06 Jan 2014 12:00:42 -0500 Michael Sweet <msweet at apple.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> Robert,
> > > >>
> > > >
> > > >> I'm stumped. Short of some stale state on the switch or machines, I wouldn't
> > > >> expect this to happen.
> > > >
> > > > The client machines have no 'stale state' (no persistant memory other than the
> > > > BIOS config). Not sure what sort of stale state on the switch is possible.
> > > > *Maybe* the switch port that the problem machine is on is going bad (in some
> > > > odd specialized way?). I guess the only remaining option is to declare that
> > > > port 'bad' and more the problem machine to another port and see if the problem
> > > > goes away permanently. Or maybe just power cycle the switch (it has not been
> > > > power cycled in quite some time, thanks to a APC UPS).
> > > >
> > > >>
> > > >>
> > > >> On Jan 4, 2014, at 11:52 AM, Robert Heller <heller at deepsoft.com> wrote:
> > > >>
> > > >>> I just did an experiement:
> > > >>>
> > > >>> I swapped the MAC (hardware ethernet) address of the problem machine with a
> > > >>> working machine in the DHCP daemon's config file and restarted the DHCP daemon
> > > >>> (both machines are otherwise identical) and rebooted both machines. Printers
> > > >>> showed up on both machines. I did NOT physically move either machine, so they
> > > >>> remained on the same Ethernet cables, same ports on the switch, etc. I then
> > > >>> swapped the MAC (hardware ethernet) addresses back. And the printers are now
> > > >>> shown. At least for now.
> > > >>>
> > > >>> What can possibly cause this weirdness?
> > > >>>
> > > >>> I have pretty much eliminated everything. The *only* possiblity is something
> > > >>> really odd in the backported security patches Red Hat applied. It is still
> > > >>> weird that the problem is selective (only one machine is affected) and
> > > >>> intermittent (it is affected only *sometimes*). I am considering pulling the
> > > >>> older version of cups from the 'vault' and downgrading it and filing a bug
> > > >>> report either with CentOS or RedHat (or both).
> > > >>>
> > > >>> At Sun, 22 Dec 2013 13:00:48 -0500 Robert Heller <heller at deepsoft.com> wrote:
> > > >>>
> > > >>>>
> > > >>>> At Sun, 22 Dec 2013 11:59:09 -0500 Michael Sweet <msweet at apple.com> wrote:
> > > >>>>
> > > >>>>>
> > > >>>>> Firewall?
> > > >>>>
> > > >>>> There is none on the LAN. The diskless clients don't run iptables at all and
> > > >>>> the server has two NICs and functions as a firewall router to the non-LAN NIC
> > > >>>> to the outside Internet. Actually I run a 'standard' RedHat IPTables firewall
> > > >>>> on my Laptop, and it has no problem seeing the shared printers, either at the
> > > >>>> library or on my home LAN (my office Desktop also runs as a firewall router,
> > > >>>> but to a PPP connection, using a dialup analog modem as the 'public' Internet
> > > >>>> connection).
> > > >>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> Sent from my iPad
> > > >>>>>
> > > >>>>>> On Dec 22, 2013, at 12:38 AM, Robert Heller <heller at deepsoft.com> wrote:
> > > >>>>>>
> > > >>>>>> At Sat, 21 Dec 2013 19:13:35 -0500 Michael Sweet <msweet at apple.com> wrote:
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> Robert,
> > > >>>>>>>
> > > >>>>>>>> On Dec 21, 2013, at 5:59 PM, Robert Heller <heller at deepsoft.com> wrote:
> > > >>>>>>>> ...
> > > >>>>>>>> I'm off as well. We are stuck at 1.3.7, since that is the version supplied by
> > > >>>>>>>> RHEL/CentOS 5. If browsing is dropped, how does printer sharing via cups
> > > >>>>>>>> work? Do you have to explicitly configure the shared printers? Why was
> > > >>>>>>>> browsing dropped?
> > > >>>>>>>
> > > >>>>>>> Bonjour (DNS-SD) is used exclusively in 1.6 and later and was available as far back as 1.1.17 (assuming your OS vendor enabled it).
> > > >>>>>>>
> > > >>>>>>> Browsing was dropped because the simple heartbeat broadcasts used by CUPS
> > > >>>>>>> browsing were really bad for network performance (particularly on wireless
> > > >>>>>>> LANs), it only worked with IPv4, it didn't like network changes, and it
> > > >>>>>>> needed either hardcoded IPs or working DNS. Bonjour doesn't have that
> > > >>>>>>> problem and, for larger network installs, you can use regular DNS (vs.
> > > >>>>>>> multicast DNS) fairly easily.
> > > >>>>>>
> > > >>>>>> The machine has always had a hard-coded IPv4 address. We only ever use
> > > >>>>>> regular DNS.
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>> ...
> > > >>>>>>>> What sort of network configuration error that only affects *one* machine.
> > > >>>>>>>
> > > >>>>>>> Address configuration issues come to mind - a bad interface address,
> > > >>>>>>> broadcast address, or netmask will cause problems with broadcast-based
> > > >>>>>>> protocols but often does not affect TCP-based protocols.
> > > >>>>>>
> > > >>>>>> This is all via DHCP and all of that is correct.
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>> The
> > > >>>>>>>> diskless clients get the network set up via DHCP in the init ramdisk and they
> > > >>>>>>>> all use the same init ramdisk, so either they are all wrong (in which case
> > > >>>>>>>> none should work) or are all right (in which case they should all work). With
> > > >>>>>>>> only one have *intermittent* problems, it is strange. As you suggested, a
> > > >>>>>>>> *physical* network problem would cause other (very obvious) problems, which
> > > >>>>>>>> don't *seem* to be happening. The problem is very specific, which *suggests*
> > > >>>>>>>> a specific problem, but nother pops up.
> > > >>>>>>>
> > > >>>>>>> One possibility - was the machine (or the MAC address of the machine)
> > > >>>>>>> previously associated on the network with a different address? Then the DHCP
> > > >>>>>>> server might be handing it an old address instead of an address from the
> > > >>>>>>> current space?
> > > >>>>>>
> > > >>>>>> No, all of that is sane. I did change the address from one address to
> > > >>>>>> another. The problem vanished, but came back.
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> _________________________________________________________
> > > >>>>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> This message contains data in an unrecognized format, application/pkcs7-signature,
> > > >>>>>>> which is being decoded and written to the file named "/home/heller/Mail/Attachments/423-smime.p7s".
> > > >>>>>>> If you do not want this data, you probably should delete that file.
> > > >>>>>>> Wrote file /home/heller/Mail/Attachments/423-smime.p7s
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Robert Heller -- 978-544-6933 / heller at deepsoft.com
> > > >>>>>> Deepwoods Software -- http://www.deepsoft.com/
> > > >>>>>> () ascii ribbon campaign -- against html e-mail
> > > >>>>>> /\ www.asciiribbon.org -- against proprietary attachments
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>> --
> > > >>> Robert Heller -- 978-544-6933 / heller at deepsoft.com
> > > >>> Deepwoods Software -- http://www.deepsoft.com/
> > > >>> () ascii ribbon campaign -- against html e-mail
> > > >>> /\ www.asciiribbon.org -- against proprietary attachments
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >> _________________________________________________________
> > > >> Michael Sweet, Senior Printing System Engineer, PWG Chair
> > > >>
> > > >>
> > > >>
> > > >> This message contains data in an unrecognized format, application/pkcs7-signature,
> > > >> which is being decoded and written to the file named "/home/heller/Mail/Attachments/434-smime.p7s".
> > > >> If you do not want this data, you probably should delete that file.
> > > >> Wrote file /home/heller/Mail/Attachments/434-smime.p7s
> > > >>
> > > >>
> > > >
> > > > --
> > > > Robert Heller -- 978-544-6933 / heller at deepsoft.com
> > > > Deepwoods Software -- http://www.deepsoft.com/
> > > > () ascii ribbon campaign -- against html e-mail
> > > > /\ www.asciiribbon.org -- against proprietary attachments
> > > >
> > > >
> > > >
> > >
> > > _________________________________________________________
> > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >
> > >
> > >
> > > This message contains data in an unrecognized format, application/pkcs7-signature,
> > > which is being decoded and written to the file named "/home/heller/Mail/Attachments/435-smime.p7s".
> > > If you do not want this data, you probably should delete that file.
> > > Wrote file /home/heller/Mail/Attachments/435-smime.p7s
> > >
> > >
> >
>
--
Robert Heller -- 978-544-6933 / heller at deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
More information about the cups
mailing list