I'm trying to extract IP information from an IP-over-ATM capture file
(I was expecting the capture in Ethernet format, but surprise!).

I need a C struct that defines the header for IP-over-ATM, much like
'struct ether_header' gives you the Ethernet header.  Normally, I'd
try to snag it from the Ethereal sources, but Ethereal isn't handling
the capture very well either:  I see DCE - DTE as the SRC and DST,
respectively, and ATM is recognized as the protocol.  Unfortunately,
in the Info column for the Ethereal display I get "AAL5 unknown
traffic type."

What it *can* tell me is VPI: 3 and VCI: 33 (don't know if it's
correct).

I'm rooting through RFCs 1483 and 1577 to try to cobble together a
struct on my own, but it's slow going.  If someone can point me in
the right direction, or has done this themselves, or understands IP
over ATM...well, I'm hoping the next bit of info will be helpful:

The header itself appears to be 40 bytes long, consistently (I know
what the data look like, at it's always at byte 40 in the packets
I've seen.  I've tried casting the header to a 'struct ip' pointer
offsets 0 to 40 from the start of the raw packet with a small degree
of success.  I can find the IP addresses (which are known to me) in
there, but at this point it's pretty clearly not an encapsulated IP
header I'm looking at.

Please forgive any obvious cluelessness this post reveals.

[ Post a follow-up to this message ]

Richard <rh310@hotmail.com> wrote in message news:<MPG.1a24ba17b5e412b09899e2@news.verizon.net>...
quote:

> I'm trying to extract IP information from an IP-over-ATM capture file
> (I was expecting the capture in Ethernet format, but surprise!).
>
> I need a C struct that defines the header for IP-over-ATM, much like
> 'struct ether_header' gives you the Ethernet header.  Normally, I'd
> try to snag it from the Ethereal sources, but Ethereal isn't handling
> the capture very well either:  I see DCE - DTE as the SRC and DST,
> respectively, and ATM is recognized as the protocol.  Unfortunately,
> in the Info column for the Ethereal display I get "AAL5 unknown
> traffic type."
>
> What it *can* tell me is VPI: 3 and VCI: 33 (don't know if it's
> correct).
>
> I'm rooting through RFCs 1483 and 1577 to try to cobble together a
> struct on my own, but it's slow going.  If someone can point me in
> the right direction, or has done this themselves, or understands IP
> over ATM...well, I'm hoping the next bit of info will be helpful:
>
> The header itself appears to be 40 bytes long, consistently (I know
> what the data look like, at it's always at byte 40 in the packets
> I've seen.  I've tried casting the header to a 'struct ip' pointer
> offsets 0 to 40 from the start of the raw packet with a small degree
> of success.  I can find the IP addresses (which are known to me) in
> there, but at this point it's pretty clearly not an encapsulated IP
> header I'm looking at.
>
> Please forgive any obvious cluelessness this post reveals.


I assume what you are looking at are ATM cells. ATM cells are 53 bytes
made up of 5 bytes (40 bits) header and 48 bytes data. In order to
carry IP over ATM the IP packets are divided up into 48 byte chunks
(which includes 1 byte for AAL5) and the ATM header is attached to
each making a 53 byte cell.  The IP header is not carried in each
cell, just the first cell of the packet, the following cells carry the
rest of the packet which is re-assembled at the end of the virtual
circuit.

You can find a lot of useful info and guides at www.atmforum.org

Brian

[ Post a follow-up to this message ]

blh_9@hotmail.com wrote...
quote:

> Richard <rh310@hotmail.com> wrote in message news:<MPG.1a24ba17b5e412b0989
9e2@news.verizon.net>... 
>
> I assume what you are looking at are ATM cells. ATM cells are 53 bytes
> made up of 5 bytes (40 bits) header and 48 bytes data. In order to
> carry IP over ATM the IP packets are divided up into 48 byte chunks
> (which includes 1 byte for AAL5) and the ATM header is attached to
> each making a 53 byte cell.  The IP header is not carried in each
> cell, just the first cell of the packet, the following cells carry the
> rest of the packet which is re-assembled at the end of the virtual
> circuit.
>
> You can find a lot of useful info and guides at www.atmforum.org


That's the first thing I thought, except that the packet capture
shows much larger packets from the server side (~1200, on average)
and smaller packets from the client (42 bytes, constant).  Perhaps
the cells are being reassembled in some way before I see them, but I
know I'm not looking at 'pure' ATM cells just by the packet length.

Then there's my being able to pull the correct IP addresses and port
numbers out of the beginning 40 bytes of EACH packet, not just the
first one as would be the case if the IP->TCP->APP PDUs were being
encapsulated in the first ATM cell.

Finally, I know what the data are, and it begins after the same 40
byte header in all packets I've observed (there are about 71K of
them, so I can't say I've seen each and every one of them yet--just
enough to rule out it being an ATM cell).  Each packet ends with a
tail to the encapsulation.

I can post the bit image of the header, if that would help.  The
machine is little-endian, so if you'd like to see the bit image I
presume you'd like it in network byte order first.

I just don't recognize the header structure, and I'm a little out of
my element in ATM as it is.

Thanks for your post.




quote:

>
> Brian
>

[ Post a follow-up to this message ]

Richard <rh310@hotmail.com> wrote in message news:<MPG.1a26951ed13c49e69899e9@news.verizon.net>...
[QUOTE]
> blh_9@hotmail.com wrote... 

<snip the earlier stuff>

Richard

Would be useful to see some more detail. Where are you capturing these
packets - on an ethernet? WAN (E1/T1 etc)? What is between the client
and server, is it DSL (PPPoA)?

Brian

[ Post a follow-up to this message ]

blh_9@hotmail.com wrote...
quote:

> Richard <rh310@hotmail.com> wrote in message news:<MPG.1a26951ed13c49e6989
9e9@news.verizon.net>... 
>
> <snip the earlier stuff>
>
> Richard
>
> Would be useful to see some more detail. Where are you capturing these
> packets - on an ethernet? WAN (E1/T1 etc)? What is between the client
> and server, is it DSL (PPPoA)?


I'll try to find out.  I was given the capture and asked to try to
figure out a TCP-level problem that's in it.  I still can't make
sense of the data-link format, though, so while I can kludgingly pull
out the IP address and port number, I can't really get a meaningful
look at the network and app layers yet.

--
I worry about the degree of tyranny that technology makes possible.

[ Post a follow-up to this message ]

Each ATM cell is 53 bytes. This itself will exclude you from
defining a C structure for the cell. The first 5 bytes are ATM header.

Most compilers will not let you define structures at these byte
booundaries.

Also, AAL5 will split an IP packet into multiple ATM cells. The
last cell contains length and footer information at the end of
the cell.

You might be able to define a C structure for some parts of the
ATM cells but it is probably not worth it. Just run with the ATM
cell as a byte stream.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Protocol Sequence Diagrams in PDF

[ Post a follow-up to this message ]

In article <MPG.1a281b4e79f60e359899f3@news.verizon.net>,
Richard  <rh310@hotmail.com> wrote:
quote:

>blh_9@hotmail.com wrote... 
>
>I'll try to find out.  I was given the capture and asked to try to
>figure out a TCP-level problem that's in it.  I still can't make
>sense of the data-link format, though, so while I can kludgingly pull
>out the IP address and port number, I can't really get a meaningful
>look at the network and app layers yet.


Why don't you dump a few of these packets in hex and share them with us?
It's not too hard to find an IP header in a bunch of hex bytes.  :o)

(what form do you have this capture in now?)

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos                           Email: patrick@klos.com
Klos Technologies, Inc.                Web:   http://www.klos.com/
==================== You can't win if you don't play! ======================

[ Post a follow-up to this message ]

patrick@klos.com wrote...
quote:

> Why don't you dump a few of these packets in hex and share them with us?
> It's not too hard to find an IP header in a bunch of hex bytes.  :o)


Here you go.  Thanks for your offer.
quote:

> (what form do you have this capture in now?)


libpcap file.  Here's a 10-packet dump of the 40-byte header.  IP
Addresses are 10.10.200.110 (0A 0A C8 6E) and 10.10.40.190 (0A 0A 28
BE).  Always seem to be at offset 16-23 (w/0 index).

Ethereal says VPI is 3 and VCI is 33 (21 hex).  Those are at offsets
1 and 4 (again, w/0 index).

Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 08 40 00 7E 06 16 5C
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD A0 09
Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 40 00 28 F8 EC 40 00 78 06 BC EB
Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
Header: 0x804a29c	77 DD 95 1E 50 10 22 38 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 00 05 04 94 09 40 00 7E 06 17 33
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD A5 BD
Header: 0x804a29c	89 C3 7D 59 50 18 FF 43 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 40 00 28 01 ED 40 00 78 06 B3 EB
Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
Header: 0x804a29c	77 DD 9A 55 50 10 1D 01 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 0F 40 00 7E 06 16 55
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD AA 99
Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 10 40 00 7E 06 16 54
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD B0 4D
Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 40 00 28 49 ED 40 00 78 06 6B EB
Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
Header: 0x804a29c	77 DD A5 BD 50 10 22 38 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 00 04 F4 94 11 40 00 7E 06 17 3B
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD B6 01
Header: 0x804a29c	89 C3 7D 59 50 18 FF 43 -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 40 00 28 52 ED 40 00 78 06 62 EB
Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
Header: 0x804a29c	77 DD AA 99 50 10 1D 5C -- -- -- -- -- -- -- --

Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 16 40 00 7E 06 16 4E
Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD BA CD
Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --

--
I fear the degree of tyranny that technology makes possible.

[ Post a follow-up to this message ]

rh310@hotmail.com wrote...
quote:

> patrick@klos.com wrote...
> 
>
> Here you go.  Thanks for your offer.
> 
>
> libpcap file.  Here's a 10-packet dump of the 40-byte header.  IP
> Addresses are 10.10.200.110 (0A 0A C8 6E) and 10.10.40.190 (0A 0A 28
> BE).  Always seem to be at offset 16-23 (w/0 index).
>
> Ethereal says VPI is 3 and VCI is 33 (21 hex).  Those are at offsets
> 1 and 3 (again, w/0 index).


Corrected an offset; 1 and 3, not 1 and 4.
quote:

> Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 08 40 00 7E 06 16 5C
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD A0 09
> Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 40 00 28 F8 EC 40 00 78 06 BC EB
> Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
> Header: 0x804a29c	77 DD 95 1E 50 10 22 38 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 00 05 04 94 09 40 00 7E 06 17 33
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD A5 BD
> Header: 0x804a29c	89 C3 7D 59 50 18 FF 43 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 40 00 28 01 ED 40 00 78 06 B3 EB
> Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
> Header: 0x804a29c	77 DD 9A 55 50 10 1D 01 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 0F 40 00 7E 06 16 55
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD AA 99
> Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 10 40 00 7E 06 16 54
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD B0 4D
> Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 40 00 28 49 ED 40 00 78 06 6B EB
> Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
> Header: 0x804a29c	77 DD A5 BD 50 10 22 38 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 00 04 F4 94 11 40 00 7E 06 17 3B
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD B6 01
> Header: 0x804a29c	89 C3 7D 59 50 18 FF 43 -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 40 00 28 52 ED 40 00 78 06 62 EB
> Header: 0x804a28c	0A 0A C8 6E 0A 0A 28 BE 12 E0 CB 20 89 C3 7D 59
> Header: 0x804a29c	77 DD AA 99 50 10 1D 5C -- -- -- -- -- -- -- --
>
> Header: 0x804a27c	80 03 00 21 45 00 05 DC 94 16 40 00 7E 06 16 4E
> Header: 0x804a28c	0A 0A 28 BE 0A 0A C8 6E CB 20 12 E0 77 DD BA CD
> Header: 0x804a29c	89 C3 7D 59 50 10 FF 43 -- -- -- -- -- -- -- --
>
> --
> I fear the degree of tyranny that technology makes possible.
>


--
I fear the degree of tyranny that technology makes possible.

[ Post a follow-up to this message ]