pawprint_net

[Log in to get rid of this advertisement]

This one will make you scratch your heads...

I have encountered a very unusual issue with a Xerox printer and my colleague has the same thing with an Windows XP box. We both recently upgraded our DHCP servers from ancient Red Hat Linux boxes (6.x) to CentOS 5.4 - as soon as we did that and made said new servers the active DHCP servers for our respective networks these two machines started to reboot each time they received a response from the server. Nothing else changed, logs on the server indicate success, there are many other machines on these networks all working fine, and there are no logs on the affected systems (that we can find) or any error. Both the XP Box and the printer receive fixed IP addresses from the DHCP servers.

The 2 subnets are in two different locations and have been running for several years prior with no problems.

In both cases changing them to use a static IP stops the problem (kinda proves it's related to the DHCP response) - but it's like the net cable is a kill switch if DHCP is on - to the point where I can start up the printer with the cable unplugged and DHCP on - and after it warms up plug in the cable and the printer reboots almost instantly.

Ever heard of anything like this? I assume it must be something included in the DHCP response from the new version of the server that is causing it - but I can't imagine what in a DHCP response would trigger a system to power-cycle.

Hoping for someone with an epiphany

blackhole54

Is it feasible to use something like tcpdump or wireshark to find out exactly what packets are being sent to these devices?

(I realize you might have a lot of traffic from other sources that you need to filter out. If you can't come up with adequate filtering directly, could you dump all the traffic and sort it out after the fact?)

pawprint_net

Great idea!

Filtering was no problem and I can control the traffic to some extent anyway... BUT

Of course now that I try it this way... the printer isn't rebooting (great, more hair to tear out) I turned on DHCP in the printer and it worked perfectly no reboot - the traffic captured was all normal.

I'll wait until the sun comes up and ask the guy at the other location to try and see if it's different there.

Thanks for the suggestion - I'll post back if the other site experiences anything different.

pawprint_net

I spoke too soon... I did manage to get a trace when the printer started rebooting again (as soon as I sent the first print job) but there was nothing unusual there.

However through some trial and error I have further narrowed the problem to be related to printing via port 9100 (raw)

Switching to LPR and leaving DHCP on seems to be ok - so I'm thinking now this might be somehow related to something to do with SNMP... However I know nothing about SNMP so I'm not sure where next to turn.

Anyone have any other ideas?

nimnull22

I'm sure that you have a HUB. Connect to it, linux, printer and XP, turn on tcpdump and sniff all packets.
Can you configure ethernet card settings on the printer? If yes, try to turn everything off, except 100BaseT support.

Hope it helps a little.

blackhole54

I believe these days most hubs are switching hubs, aka switches. If I understand your suggestion correctly, the goal is to see all traffic rather than just the traffic for the computer running tcpdump. Yet a switching hub will prevent this. Although I believe you would be able to see all broadcast packets.

pawprint_net

Yes it is hooked to a switch - actually there are two switches between it and the DHCP server (which is also a router over to another subnet)

I have a local machine in the same room as the printer and I do have a few old hubs kicking around so I could set things up to grab all the traffic however: I already did an isolation test where the only things connected through a single switch were the printer and the DHCP server and the problem still persisted - so I think it's safe to assume any data required to be captured would be visible on the I/F of the DHCP server box itself (where I have been running tcpdump) It would probably help if I knew what I might be looking for from tcpdump - so far there is nothing remarkable there at all.

I have turned everything off on the printer that I can (I still need to be able to print to it) so there is the port 9100 still open and the Xerox Management I/F (I'm not sure what port they use for that) I believe it also has some SNMP capability but I'm having trouble ascertaining exactly what is enabled in that respect on the printer.

nimnull22

How many ethernet card DHCP server has?

To do test properly you have to disconnect ANYTHING from DHCP server start tcpdump to listen interface WHERE you intent to connect your printer and connect it.


I meant for example: Wake-on-LAN options

p Wake on phy activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket(tm)
s Enable SecureOn(tm) password for MagicPacket(tm)

See how many shit can be.

pawprint_net

The DHCP server has 3 NICs (basically it's a router/gateway) and has two internal and one external facing connections.

I Can't access any of the items mentioned in the printer - the control over it's network interface is limited.

I tried the test above - nothing connected but the printer and the one interface on the DHCP server. Turning on the printer results in a nearly immediate communication to the server and successful receipt of a DHCP response. The printer then continues to warm up (takes about 15-30 seconds) with no further traffic at all. Then at one point the printer just reaches a point in it's warm up cycle and reboots. and the process will just continue to repeat like that if I let it.

So again, nothing unusual in the tcpdump logs.

dxqcanada

You should take the tcpdump capture and examine it in Wireshark. It will give you human readable information that you will not see using tcpdump ... look at the DHCP response sent to the Printer ... see if there is any unusual options being set

nimnull22

OK. thanks.

Now, I hope that you didn't throw away the old DHCP server? If yes, tell me where to, if not you can connect your printer to it and do the same.

If every thing will be OK, check ethernet card configuration with "ethtool eth<N>" very carefully and compare with one in new DCHP server.

If your printer reboots again, we then ...

blackhole54

@pawprint_net,

Are you DHCP configuration files identical between the old server and the new one?


Your prediction at the top of this thread certainly turned out to be true. This is a head scratcher!

pawprint_net

The DHCP configs are not the same - I had to add one line to the new one or the dhcpd wouldn't start - the new line turns off ddns.

Other then that they are identical but the old system was about 8 years old so the server has gone through several revisions between.

Update: I had done this several times already - but I just told the printer to "reset connection" again after it was failing to print entirely now - and everything is allofasudden working *sighs* so now I have no idea what happened - perhaps it was just some stagnant setting in the printers memory that needed changing - and it took 12 resets and 30 powercycles to "kick in" (sarcasm aside - I'm stumped - but it's working)


Thanks to all for the help - I appreciate your time - even if this is a rather puzzling outcome. IF it suddenly goes south again I'll send another update.