Ping with length >245 bytes ignored by ENC28j60

Thread Starter

Samyukta Ramnath

Joined May 21, 2015
16
Hi,
Using a ENC28j60 with a cc1352p1 microcontroller and the lwIP stack. I'm trying to ping my device after manually assigning it an IP, and I can ping it and get a response when the number of bytes in the ping is < 244 bytes. So if I do
>> ping 192.168.1.10

I get:
64 bytes from 192.168.1.10: icmp_seq=0 ttl=255 time=15.863 ms
64 bytes from 192.168.1.10: icmp_seq=1 ttl=255 time=16.506 ms

and if I do :

$~ ping -s 202 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 202 data bytes
210 bytes from 192.168.1.10: icmp_seq=0 ttl=255 time=19.728 ms
210 bytes from 192.168.1.10: icmp_seq=1 ttl=255 time=19.922 ms

But if I do:
>> ping -s 203 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 203 data bytes
Request timeout for icmp_seq 0

ethernet input function is never called because the spi_read(EPKTCNT) register always returns zero. Not sure what to do when this happens, since I can't control the Register value, and if I just call the ethernet input function without checking if the EPKTCNT is > 0, I get all zeros in the ethernet input function.
 
I'm not familiar with the specific IC but a ping of that size is non-standard and might short circuit into "/dev/null" land when it's above a certain size. Can you test to see the exact bit size that it fails and then try the size of something crazy like 65535 bytes?

I'd suspect that this chip might have issues handling jumbo frames/packets which could, unfortunately, result in a chip hard reset (wouldn't that be fun).
 

Thread Starter

Samyukta Ramnath

Joined May 21, 2015
16
I'm not familiar with the specific IC but a ping of that size is non-standard and might short circuit into "/dev/null" land when it's above a certain size. Can you test to see the exact bit size that it fails and then try the size of something crazy like 65535 bytes?

I'd suspect that this chip might have issues handling jumbo frames/packets which could, unfortunately, result in a chip hard reset (wouldn't that be fun).
I think that it should be able to handle pings smaller than a total length of the mtu, i.e. 1500 bytes. I see that the threshold is 244 bytes - however, I have been able to receive messages (not pings, but a dhcp offer message) of greater than 244 bytes - (namely 342 bytes). The way that I know there's a packet ready to be processed is that I will poll the EPKTCNT register. The EPKTCNT register will usually return zero, but once there are packets ready to be processed, it will increment to the number of waiting packets, and as I process each packet, the value decrements until it is back to zero. The EPKTCNT register did increment in the case of the longer DHCP Offer message and I was therefore able to trigger the ethernet input function. The issue with this longer ping is that I can't decide to ultimately drop the packet due to long length since it just doesn't allow me to process the packet at all.
 
I'd anticipate other - non-ICMP - packets being processed above the MTU once the packets are re-assembled. My thinking is that the ICMP protocol is specifically being short-circuited. Your DHCP packets are UDP packets and not ICMP packets so if they were getting trimmed/dropped then this is arguably the case.

I'm reading into the chip's PDF and just going to throw out a few ideas.
  • Is there an ICMP packet being sent that isn't an ICMP PONG packet? Possibly an ICMP Destination Unreachable? If so, the EPKTCNT register not decrementing could be a bug in the chip and could lead to a DoS issue (setting of the RXERIF interrupt flag - max 255 packets in the queue).
  • When the EPKTCNT register increments can you confirm that the EIR.PKTIF register is set and an interrupt it sent by the Hardware Write Pointer?
  • Is the Receive Buffer Read Pointer changing when "processing" ICMP packets above the ghosting point (244 bytes)?
  • The PDF doesn't say anything about ICMP, MTU's, or Pings. This is likely a black box situation.
  • Do other ICMP packets have the same issue or is it just ping? You can use the `icmpush` command in *nix environments.

Definitely a weird issue so far.
 
Top