search

JulianSchmid / etherparse

A rust library for parsing ethernet & ethernet using protocols.
Apache License 2.0
285 stars 54 forks source link

Add support for LINUX_SLL #97

Closed RabadanDotDev closed 2 months ago

RabadanDotDev commented 2 months ago

Hi there,

I am working in a network traffic analyzer for a project and one of the traffic dataset samples I am using is encapsulated in "LINKTYPE_LINUX_SLL". Would it be possible to add support for it to the project? As it is said in the Wireshark Wiki,, it is a pseudo-protocol used to encapsulate traffic coming from all devices (the "any" device) or to use in place of the real link layer. Adding support for it, be it the part that can contain IP packets, would be useful for other applications wanting to handle traffic from multiple interfaces at the same time.

The format is specified in this tcpdump page, but I only really need to be able to parse IPv4/Ipv6 on top of it. The header format is relatively simple, mostly composed of 16 Bytes of which:

  1. The bytes 0 and 1 indicate packet type in network order/big endian. With the meanings:
    • 0 for unicast packets that were sent by other host and were intended for the receiver
    • 1 for broadcast packets that were sent by other host
    • 2 for multicast packets that were sent by other host
    • 3 for unicast packets that were sent by other host and also were intended for another host
  2. The bytes 2 and 3 indicate ARPHRD_ type. In the tcpdump page, it is noted that it can be either
    • ARPHRD_NETLINK (value 824), meaning the encapsulated packet is a netlink packet and the associated protocol type is a Netlink protocol type. Probably out of scope of this project.
    • ARPHRD_IPGRE (value 778), meaning the associated protocol type is a GRE protocol type.
    • ARPHRD_IEEE80211_RADIOTAP (value 803), in which the associated protocol type is ignored and there's a radiotap link-layer and then a 802.11 header (#83)
    • ARPHRD_FRAD (value 770), in which the associated protocol type is ignored and there is a "Frame Relay LAPF frame, beginning with a ITU-T Recommendation Q.922 LAPF header starting with the address field, and without an FCS at the end of the frame"
    • Another value (with probably value 1, as I have in my captures for Ethernet, but it may be irrelevant). The associated protocol type may contain the ether type or one of 5 other possibilities.
  3. The bytes 4 and 5 indicate the length of the sender address
  4. The bytes 6 to 13 contain the address of the sender. If it is larger, it is cut to the first 8 bytes. If it is smaller, it is padded to fill the 8 bytes.
  5. The bytes 14 and 15, contain the protocol type. In the case that the bytes 2 and 3 fell in the "other value" category, there are six possibilities:
    1. If 0x0001, the payload is a Novell 802.3 frame without an 802.2 LLC header.
    2. If 0x0003, we have a weird case. I haven't been able to find a lot of information, just that this values appearing in this case could be related to some Linux kernel bug.
    3. If 0x0004, the payload begins with an 802.2 LLC header
    4. If 0x000C, the payload is a CAN bus frame
    5. If 0x000D, the payload is a CAN FD bus frame
    6. Otherwise, it contains the normal Ethernet protocol type

As I understand, the additions would mainly consist on :

I intend to work on this in the following days to be able to support this link type in my code. My idea is to mostly focus on the parts of the protocol that would allow me to retrieve the IPv4/Ipv6 packets. Is there any work previous work I should check or specific guidelines I should follow before creating a PR?

RabadanDotDev commented 2 months ago

Closing this in favor of #99