ENABLE_PADDING(0) leads to failure

[qrp73]

I tested example based on ATLYS/fpga code. It works, but it add zero padding to the end of udp packet. I don't need it.

In order to disable unwanted padding, I set ENABLE_PADDING(0) for eth_mac_1g_gmii_fifo. Unfortunately it leads to complete fail. Loopback example don't works with ENABLE_PADDING(0) and stops to receive payload from incoming udp packets (first byte of the udp payload is not passed to the led display).

Please fix it.

[alexforencich]

Most likely with padding disabled, the ARP response from the board is getting dropped somewhere due to being a runt frame shorter than 64 bytes. And it's not being dropped by the FPGA in this case, but by your router, network card, or OS. In general, you should leave padding turned on unless you really know what you're doing.

If you can point out an actual bug, I'll take a look at it. But as it stands, this sounds like entirely expected behavior.

[qrp73]

Most likely with padding disabled, the ARP response from the board is getting dropped somewhere due to being a runt frame shorter than 64 bytes. And it's not being dropped by the FPGA in this case

Well, to be more clear, I'm using example code with loopback on port 1234 from verilog-ethernet/example/ATLYS folder. I adapted the code for my starter-kit board QMTECH CYCLONE_IV running on EP4CE15F23 and RTL8211EG GMII. The changes is related to fpga.v only, where I implemented setup of 125 MHz pll and proper pin assignments.

By default example works well, it responds on ARP requests and sends back UDP packet from port 1234 with no issue.

But when I set ENABLE_PADDING(0) for eth_mac_1g_gmii_fifo in fpga_core.v, it stops to work.

I investigated the issue and found that there are two cases: 1) FPGA is connected to PC through router. In such case PC don't see any respond from FPGA on ARP request from PC. The PC sends ARP requests and there is no response.

2) FPGA is connected to PC directly. In such case the PC can see ARP response from FPGA, but don't see UDP response. FPGA can see UDP request, it shows first payload byte on the led indicator. But there is no UDP response in wireshark.

Update: there is my mistake, I just tried this patch https://github.com/alexforencich/verilog-ethernet/issues/23 and forgot to remove it.

Just tested with no patch and it works ok for direct connection between FPGA and PC. You're right, this issue related to my router which drops packets with disabled padding.

But I still confused why ARP response from PC with disabled padding is accepted by router, but FPGA packets with disabled padding being dropped.

[alexforencich]

Presumably you're using wireshark, tcpdump, or some similar software application to capture the packet data on your PC, correct? In this case, you're seeing TX packets before they arrive at the NIC driver. Either the NIC driver or the NIC hardware will pad the frames out to 64 bytes before they hit the wire. So the outgoing UDP and ARP packets that you see that don't appear to have any padding will actually have that padding inserted before they leave the NIC.

That's correct, a packet of less than 64 bytes is considered an error and is generally dropped by the NIC or by the OS at some level in the networking stack.

[qrp73]

yes, I don't see packets with no padding coming from router. So, I think you're right, outgoing packets from PC which don't appear to have any padding will actually have that padding inserted before they leave the NIC.

if we take this into account, all works as expected, thanks for help :)