FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Good UDP packets received in wireshark but not at PC application

Altera_Forum
Honored Contributor II
5,809 Views

Hello. I'm working on an application that takes data from a sensor, packetizes it into 1KB packets with the associated ethernet headers, and sends it to a PC via the TSE. I'm on the Stratix IV Dev board, and I'm doing this by interfacing some custom logic directly with the TSE core (no NIOS, I'm not allowed to use that). It's a point to point connection, no switch involved. This isn't my first rodeo, I've been moving data this way on numerous projects for years, so I'm pretty familiar with the ethernet protocols and how the TSE works. Up until now I've always used the WinPCAP libraries on the PC side to receive the data, but this time I need to be able to use the OS's network libraries. Here's the problem: I'm sending UDP packets out at a rate of about 4 Mbit/sec, and they show up on wireshark on the PC side just fine. Correct checksums, correct IP and MAC addresses, everything. However, for some reason, these packets are being rejected somewhere between the wireshark drivers and the application. They show up in netstat as valid IPv4 packets, but not as valid UDP packets. The weird thing is, I have an app for sending some dummy UDP packets from one PC to another, and those packets make it through. I can take one of those packets, spoof it byte for byte in the FPGA, and the PC still drops it. I know my packets length is correct, firewall is off, checksums are correct, everything from a good PC-to-PC packet is identical in a FPGA-to-PC packet. It's the same whether I'm talking to a Linux machine or a Win7 machine, neither OS likes my FPGA packets.  

 

I've written logic for handling pings and ARPs, and all of that is working. I can ping the FPGA from the OS command line and it responds properly, so I know for sure that there's nothing wrong with the tx_crc_fwd function or the ipg length or anything that would cause the packet to be dropped by the MAC. Still, there must be something funky going on that isn't indicated in wireshark. I'm posting this in the IP forum because I *think* it must be some setting in the TSE configuration, due to the fact that that's the only difference between PC-to-PC and PC-to-FPGA. The packet must be coming out in some way that wireshark is fine with, but the OS isn't, even though I'm at a loss as to what that might be. Does anybody have any ideas of things that I haven't tried? I'm not an OS guy, so I don't know enough about Linux or Windows to be able to answer what sort of validation goes on between where wireshark sniffs and where the application listens. 

 

Any help would be appreciated. Thanks!
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
3,872 Views

Fixed it, so I thought I'd document it here for anyone in the future who runs into this problem and is googling their brains out looking for help. 

 

First, make sure you either have the correct UDP checksum, or put all 0s in the checksum field. The OS will drop packets with an incorrect UDP checksum, but will allow packets with no checksum (all 0s). I recommend the all 0s method, since you don't have to buffer the packet and do calculations on it before sending. You can just stuff a FIFO and when it reaches a fill level, put the header on it and send it on its way.  

 

Second, be absolutely sure you have ARPs and ICMPs working. If you want the OS's sockets to get your packets, you need to do an ARP first. This will send the MAC address of the PC back to your board. I tried hard coding the MAC address in there, but for some reason the OS would drop the packets if I hadn't ARPed first. There were also some ICMPs that went back and forth. 

 

This is the real key though. The IDENTIFICATION field in the IPV4 header has to increment with every packet, and your first packet has to start with some non-zero number in that field. If you leave the IDENTIFICATION field constant, Wireshark will show all your packets as being completely valid, but the OS apparently thinks it's getting the same packet over and over and just drops them. I didn't discover this earlier because I was starting my packet stream with IDENTIFICATION = 0x0000, which apparently also doesn't work. I don't know if it's an OS driver thing, but I arbitrarily started my packet numbering with 0x8000 instead of 0x0000 and it started working. I can't explain that, but that's the difference between a working and a non-working design. 

 

So long story short, I'm accomplishing what I wanted, taking data, UDP packetizing it, and having it bubble up through the PC's driver stack such that it's accessible via socket commands. And all this without NIOS, strictly custom modules talking to the TSE core. If anyone ever needs help with doing a strictly HDL implementation of the TSE core for moving data as quickly as possible, send me a PM. Having done this 5-6 times in various forms over the years, I've got a pretty good handle on how to configure the core for both RGMII and SGMII, and on which fields are/aren't necessary in the various headers.
0 Kudos
Altera_Forum
Honored Contributor II
3,872 Views

 

--- Quote Start ---  

Fixed it, so I thought I'd document it here for anyone in the future who runs into this problem and is googling their brains out looking for help. 

 

First, make sure you either have the correct UDP checksum, or put all 0s in the checksum field. The OS will drop packets with an incorrect UDP checksum, but will allow packets with no checksum (all 0s). I recommend the all 0s method, since you don't have to buffer the packet and do calculations on it before sending. You can just stuff a FIFO and when it reaches a fill level, put the header on it and send it on its way.  

 

Second, be absolutely sure you have ARPs and ICMPs working. If you want the OS's sockets to get your packets, you need to do an ARP first. This will send the MAC address of the PC back to your board. I tried hard coding the MAC address in there, but for some reason the OS would drop the packets if I hadn't ARPed first. There were also some ICMPs that went back and forth. 

 

This is the real key though. The IDENTIFICATION field in the IPV4 header has to increment with every packet, and your first packet has to start with some non-zero number in that field. If you leave the IDENTIFICATION field constant, Wireshark will show all your packets as being completely valid, but the OS apparently thinks it's getting the same packet over and over and just drops them. I didn't discover this earlier because I was starting my packet stream with IDENTIFICATION = 0x0000, which apparently also doesn't work. I don't know if it's an OS driver thing, but I arbitrarily started my packet numbering with 0x8000 instead of 0x0000 and it started working. I can't explain that, but that's the difference between a working and a non-working design. 

 

So long story short, I'm accomplishing what I wanted, taking data, UDP packetizing it, and having it bubble up through the PC's driver stack such that it's accessible via socket commands. And all this without NIOS, strictly custom modules talking to the TSE core. If anyone ever needs help with doing a strictly HDL implementation of the TSE core for moving data as quickly as possible, send me a PM. Having done this 5-6 times in various forms over the years, I've got a pretty good handle on how to configure the core for both RGMII and SGMII, and on which fields are/aren't necessary in the various headers. 

--- Quote End ---  

 

 

 

 

Heyyyyyyyyyyyy 

I am getting the same problem. My UDP checksum is hard coded to zero and CRC32 is also hard coded but i cant receive the packets in my program where as wireshark shows the packets as perfect. 

Help me :(
0 Kudos
Altera_Forum
Honored Contributor II
3,872 Views

auburnbull, are you still active in this discussion?

0 Kudos
Altera_Forum
Honored Contributor II
3,872 Views

 

--- Quote Start ---  

auburnbull, are you still active in this discussion? 

--- Quote End ---  

 

GJ_Leeson can u help me with this?
0 Kudos
Reply