Hi,
Please help me out in my query listed below.
-----Original Message-----
Sent: Friday, September 19, 2008 1:36 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How to make libpcap/wiretap understand proprietry/standard link-layers
On Sep 18, 2008, at 10:10 PM, Gaurav1 Jain wrote:
> Gaurav: yes latter one is the case. If I try to capture the
> interface using
>
> Capture à Options à Link Header Type is displayed as Linux Cooked
> Mode Capture.
Presumably by "capture the interface" you mean capturing on the Linux
network interface.
If so, that means the Sangoma driver is returning either an unknown
ARPHRD_ type or one of ARPHRD_ATM or ARPHRD_PPP as its ARPHRD_ type.
> When traces are displayed protocol decoded is found to be IP.
It's capturing in cooked mode, with a PF_SOCKET/SOCK_DGRAM socket, so
that the link-layer header is stripped off, and a "cooked" link-layer
type supplied (IPv4, if the protocol is IP).
Gauarv1 Jain: To be more precise, E1 data is passed to libpcap as it is, 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).
Then packet on IP interface will be as attached in Message_Passed_To_LibPcap.bmp
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.
I hope I make my self clear with above.
Another type of frame is Transparent frame where card can not identify start of frame 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.
Now with the above, it gets clear that card is used to capture frame over E1 and through an IP device (WAN Driver) both HDLC and Transparent frames are passed to libPcap. Now how do I add, the protocol dissector for both types of frame in WireShark?
> Otherwise when PCAP file is first captured using WanDriver commands
> (available with WanPipe)
...which means the capture isn't going through libpcap.
> and then open using wireshark TZSP is the protocol being displayed
> on GUI.
...which means that the WanDriver software is writing a pcap-format
file with a link-layer type of DLT_TZSP.
The only link-layer types supported in DLT_TZSP in Wireshark are
Ethernet and various forms of 802.11, so presumably it's providing a
fake Ethernet header.
>> So what does it mean when it "provides [an] IP interface"? Does that
>> mean that the card supplies IP packets, with link-layer headers
>> stripped off,
>
> Gaurav: yes this is the case.
If that's the case, then you won't ever be able to see the HDLC or
proprietary link-layer headers, as the card doesn't give them to the
host, so they're irrelevant.
>> There is no "ICMP/UDP/TCP/SCTP/IP kind of DLT" attached to *any*
>> traces; those are all protocols running atop the link layer. There
>> is
>> a DLT_RAW link layer used for packets where there *is* no link-layer
>> header.
>
> Gaurav: I checked man page of pcap and it says DLT_RAW means packet
> begins with IP header.
Yes, that's what "There is a DLT_RAW link layer used for packets where
there *is* no link-layer
header" means.
> Gaurav: We are using HDLC protocol while configuring WANPIPE,
> So it should be LIP Protocol stack line where card is getting
> connected and accordingly ARPHRD_ type should be ARPHRD_HDLC.
Only if the card is supplying HDLC headers to the host, which you said
wasn't the case.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx