Checksum error on DHCP packets on 3448

[Anonymous]

I've got a 3448 at a remote site had its WAN link go down, and after the link came back up, the DHCP server stopped working. If I run a 'debug ip udp' to watch UDP packets, I see output like the following:

RX: src=0.0.0.0:68, dst=255.255.255.255:67, 556 bytes, checksum error

RX: src=0.0.0.0:68, dst=255.255.255.255:67, 308 bytes, checksum error

Other UDP packets (NTP, for instance) are fine

If I load a packet capture into wireshark, the UDP packets are definitely showing a bad checksum, so I would think it's the devices that are screwed up, except that it's three different devices that are showing the same checksum problem. It seems unlikely to me that all three devices (different manfucaturers) simultaneously started sending bad UDP packets. They're all plugged directly into the switchports on the AdTran.

[Anonymous]

Upon some further investigation - it appears it's not just UDP packets - it looks like any packets above a certain size show a bad checksum. The threshold looks like it's somewhere between 120 (good) and 153 (bad) bytes. There's a device with a static IP on the vlan, any packets 153 bytes or larger that it sends show a bad checksum.

[Anonymous]

Where did you perform your capture?  What is that checksum value that is reported bad?  If you captured directly on the router, Wireshark may report bad checksums on packets that may not have been completely finalized before being sent out.  NIC cards, interfaces and hardware do a lot on the packet and that may not have taken place yet on a packet captured on the router directly that has not yet been forwarded out the interface. 

Basically, Wireshark reporting checksum errors may not be an issue with the packets but more an issue with how Wireshark is reading the packets.  This is usually related to settings on the capturing device or settings in Wireshark.

Wireshark Checksums

As for the issue you are having, if the 3448 didn't reboot/crash/reload, it is extremely odd to have a service stop working (like DHCP) simply because the WAN link went down.  Have you tried running captures on the local devices to see if they are getting a response from the 3448 DHCP server?  Have you run "debug ip dhcp server" on the 3448 to see what responses it is sending?

[Anonymous]

I performed the capture on the router (where the "debug ip udp" is showing checksum errors). The packet capture was setup on the vlan interface. Why would the router be capturing non-finalized packets? By the time the packets hit the vlan, they should be finalized by the sending device. I don't know the nitty-gritty of IP error control, does the receiving device do something to the incoming packet (besides verifying the checksum)?

"debug ip dhcp server" shows nothing, which makes sense if the AdTran is discarding the packets that it sees with bad checksums.

Unfortunately this is at a remote site so I can't setup a packet capture on the local device.

[Anonymous · Accepted solution]

I was finally able to get some remote hands - he unplugged power from the AdTran for 20 seconds or so, then plugged it back in and it looks like the issues are resolved now. I did do a couple reloads yesterday and this morning, but those didn't seem to fix the issue. Is there a way to simulate  a power cycle remotely? Or perform a 'harder' reboot than just a reload?