1

I'm trying to capture some Ethernet frames with Linux. Some of these packets/frames are invalid and contain corrupted data.

For example an Ethernet frame contains the type 0x0800 which is IPv4, but the following data contain just random bytes. Furthermore, the source and destination MAC are unknown and not predictable.

To receive these frames I wrote a C program that first used raw sockets. This didn't work as expected, so I switched to libpcap.

I open the Ethernet device in promiscuous mode to receive all frames and prevent MAC sided filtering. This works just fine. I can receive frames with any destination MAC address.

Now we get to the big problem:

I send an Ethernet frame with random destination and source MAC. the Type field is 0x1234 and the data is just a few bytes, let's say 0xdeadbeef. This gets padded to the minimum amount of payload. This frame is received by my program using libpcap just fine.

When I send the same frame using a "known" Ethernet type field value like 0x0800, the frame gets dropped and my program can't receive it.

The software runs on an embedded platform, an Altera Cyclone V SoC that has an STMMAC Ethernet module. On a regular PC/Notebook etc. the program runs fine and can even receive these invalid IPv4 frames.

To find out where the packets are dropped, I watched the /sy/class/net/eth0/statistics/rx_* files. There are files that count the number of received packets and bytes as well as the number of dropped packets. these statistics work fine with normal Ethernet traffic. However, sending an invalid frame as described above doesn't result in any change of the statistics. The driver doesn't even count up the "dropped frames" counter. I can't understand this, because as far as I know the statistic of the network interface gets affected as soon as a packet is received by the hardware. The filtering and evaluation process of the network stack should have nothing to do with it. Am I right? Therefore it seems to me that some really low driver code is filtering these packets or maybe even the hardware itself.

Again: With an normal PC on the other side the packets can be received with the program I wrote.

The second problem is with valid TCP packets:

Although I'm using libpcap which provides raw traffic to me, received TCP packets are reassembled to huge packets that are even bigger than the MTU of the receiving network interface. these packets are also received normally with a PC.

Can anyone help me? I need to receive raw Ethernet traffic "as it is" using Linux on the Altera SoC-FPGA platform.

4
  • Have you tried using wireshark (which also uses libpcap)? Does it drop / misread frames? If it does, maybe your hardware is not up to the task.
    – AFH
    Commented Jun 27, 2016 at 18:45
  • Sorry, I can't help at this level. I've done TCP programming in the past, and used the likes of wireshark to monitor TCP/UDP traffic, but I've not had to deal with this sort of problem. I hope someone else can help.
    – AFH
    Commented Jun 27, 2016 at 21:24
  • Don't know about now, but Linux kernels used to have an option to reassemble packet fragments into whole packets before passing them on. To avoid the ping-of-death and other fragmentation based attacks. Perhaps you random data looks like fragments to that code, and the kernel is trying to put it all back together before processing the packet
    – infixed
    Commented Jul 11, 2016 at 17:56
  • I checked this. The problem is that the packet doesn't even reach the kernel network stack. Not even the low-level hardware driver sees that packet. I have no clue why it is filtered. As I wrote above: The network statistics (rx count etc.) do not change although this should be done as soon as a packet is received, prior to every other checks.
    – GNA
    Commented Jul 12, 2016 at 12:27

0

You must log in to answer this question.

Browse other questions tagged .