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?
