I am a bit confused about how Libpcap works. As i concern, as it captures Ethernet PDU it can access asked 17 Sep '14, 14:56  Miguelbc edited 17 Sep '14, 14:57 |
One Answer:
Libpcap works differently on different operating systems. On Linux, it uses Unless your device driver delivers raw ATM cells to the Linux networking stack - and it probably doesn't, as I suspect the Linux ATM code isn't expecting to receive raw ATM cells - there's nothing libpcap can do to get raw ATM cells from Linux. However, you say "AALX headers"; do you want to receive raw ATM cells, or do you, for example, want to receive AAL5 PDUs? answered 20 Sep '14, 16:29  Guy Harris ♦♦ showing 5 of 6 show 1 more comments |
I would like to sniff link PDU of the ATM interface, so i can see for instance some fields of the AALx header, or see VPI/VCI values. About Linux networking stack, do you meant the TCP/IP stack? I dont understand why Ethernet frames are captured by Wireshark but ATM frames are not captured though they are PDUs regarding link layer. Is the Ethernet device driver delivering Ethernet PDU to Linux networking stack while ATM device driver only delivers the IP datagram?.
PDU stands for Protocol Data Unit; what protocol are you talking about? At the lowest level, ATM PDUs are cells, and don't have AALx headers. The AALs are at a layer above that.
No, I mean the ENTIRE networking stack - think "everything under the
netdirectory in the kernel source, as well as all the networking device drivers".The Ethernet link layer is, in some ways, much simpler than the ATM link layer. In Ethernet, link layer PDUs consist of a destination address, a source address, a type/length field, a variable-length payload, and an FCS, and most protocols can run directly on top of that (with their PDUs inside the payload) or on top of 802.2 (also fairly simple) on top of Ethernet.
ATM PDUs, at the lowest layer, are 53-byte cells, which are not directly useful for most purposes, so there are "adaptation layers" atop that, which have their own types of PDU. Then, for what's conventionally though of as "networking", there can be several mechanisms for encapsulating protocols and identifying protocol types on top of, for example, AAL5 - LANE, RFC 1483, etc.. So what's considered an ATM PDU depends on the layer at which you - and the networking code that's delivering ATM traffic to your capture program - are working.
The network interface I am using is IPoE over ATM, so the IP datagram is encapsulated over an Ethernet frame which is in turn encapsulated over AAL5 protocol. Wirehark is capturing the ethernet frame, but i dont see any AAL5 header. In the same way, If i capture from LAN ethernet interface i can see the ethernet frame. So as i concern, wireshark is capturing not from the below L2 protocol of the network interface.
So im trying to understand the design behind this, this is at which level of the network stack is wireshark located (at which level it sees skb content) so i can understand why it captures some L2 PDUs while it cant be used to see others L2 headers.
If device driver is part of the Linux network stack, what does it mean that device driver delivers packet to the Linux network stack?
In some fashion. There are at least two ways that can be done - LANE and RFC 2684 bridging.
RFC 2684 bridging is handled by net/atm/br2684.c in the Linux kernel, and the comment at the beginning of that file says
"netdevice" means that it creates a networking device of the type that shows up in, for example, the list of network interfaces from libpcap (which is where both tcpdump and Wireshark get their lists of network interfaces), and "Ethernet netdevice" means that the device looks like an Ethernet device, so, if you capture on it, you will see Ethernet packets, with no AAL5 or MPoA headers.
LANE is handled by net/atm/lec.c and possibly part of net/atm/mpc.c. I don't know for certain, but I suspect it also creates a Ethernet netdevice.
Presumably you mean "at which level of the network stack is Wireshark capturing, as it's not part of the Linux networking stack because it's not part of the Linux kernel.
It captures at whatever layer libpcap (the library it, and tcpdump, and a number of other programs, use to capture traffic) uses, which depends on the network device on which you're capturing. Capturing on one of the Ethernet netdevices created for RFC 2864 and LANE means you're capturing at the "Ethernet over XXX" layer and see only Ethernet packets.
From a quick look at the kernel ATM code and the ATM device driver documentation from the ATM-on-Linux site, ATM devices do not fit into the Linux networking stack the way "regular" netdevices do, so, if it's even possible for libpcap to get raw AAL5 PDUs from the Linux networking stack, it appears that it would have to do so very differently from the way it captures on regular netdevices - and it currently doesn't have any support for that.
I.e., the layer at which you want to capture is currently not supported by libpcap, and thus not supported by tcpdump or Wireshark or..., and it might not even be available to libpcap.
A bit more looking seems to indicate that there's no standard way to get, for example, reassembled AAL5 PDUs from the driver in Linux; the input path for the Zeitnet ZN122x devices appears to try to find out which virtual circuit the packet is for and:
and the handlers don't appear to have a way to get at the raw packets.