On Sep 22, 2008, at 8:33 PM, Gaurav1 Jain wrote: > Gauarv1 Jain: To be more precise, E1 data is passed to libpcap as it > is,
Well, it's passed to a PF_PACKET socket, if you're capturing on Linux, unless you've modified libpcap. What driver is passing the packets to the Linux networking stack? > as is received by Card on line (after removing info like CRC etc). > For example if format of LAPD modulo 8 (based on HDLC format) is as > per attached in the mail (LAPD_format_E1.bmp). That's not attached to your mail. > Then packet on IP interface will be as attached in > Message_Passed_To_LibPcap.bmp That's also not attached to your mail. > It means that Driver in card is not adding/tweaking information/ > header to received packet. With this LibPcap receives packet with > link-type as HDLC and without flag and CRC bits attached to the > packets. Do you have an example of a capture of that sort? If so, you've modified libpcap, as it does *NOT* support a link-layer type of "HDLC" - it supports ARPHRD_CISCO, which is 513, but that's just "Cisco HDLC", not, for example, LAPD. > Another type of frame is Transparent frame where card can not > identify start of frame What type of traffic is that? Circuit-switched voice? > and hence a packet gets scattered over multiple packets where start > of packet given to libPcap does not necessarily be the start of > logical message (it can be at any offset to that message). Here also > no tweaking is done with what is received at line and passed as it > is to WireShark interface. This kind of traffic is quite fast in > nature (around 160 byte/20 msec). This frame again has some > proprietary L2 frame format and L3 information in it. Does that currently work with libpcap? If so, what ARPHRD_ value does the interface have? _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
