Ethereal-dev: [Ethereal-dev] Re: bug in text2pcap 0.9.5 ?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ashok Narayanan <ashokn@xxxxxxxxx>
Date: Sun, 21 Jul 2002 17:23:34 -0400 (EDT)
In general, text2cap will consider a single packet as one with a hex
offset starting at zero. The corollary to this is that a block of
binary data with a hex offset starting at zero and going up, will be
decoded always as a single packet only. To generate multiple packets
out of this, you need multiple blocks of hex text, with the byte
offsets starting at zero and going up for each packet.

-Ashok

> Hi Ashok,
> 
> i tried to convert (i386-linux, flex version 2.5.4) a dump (from a patched user mode 
> linux switch (uml_switch)) into a pcap format with text2pcap (from ethereal-0.9.5) 
> and discovered a strange behavior:
> 
> I dumped 2 packets (84 byte = ARP request and ARP relpy) on layer 2: 
> 
> 0000000  ff ff ff ff ff ff 00 00 10 01 01 01 08 06 00 01 
> 0000010  08 00 06 04 00 01 00 00 10 01 01 01 0a 01 01 01 
> 0000020  00 00 00 00 00 00 0a 01 01 02 00 00 10 01 01 01 
> 0000030  00 00 10 01 01 02 08 06 00 01 08 00 06 04 00 02 
> 0000040  00 00 10 01 01 02 0a 01 01 02 00 00 10 01 01 01 
> 0000050  0a 01 01 01                                     
> 
> and call text2pcap with 'text2pcap -d -o hex -l 1 84.ascii out.84'
> 
>  Input from: 84.ascii
>  Output to: out.84
>  Start new packet
>  Wrote packet of 84 bytes
> 
>  -------------------------
>  Read 1 potential packets, wrote 1 packets
> 
> -> oops, only one packet???
> 
> Ethereal shows the firt packet (ARP request) packet with a 42 byte trailer...
> 
> hexdump of out.84:
> 0000000  d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 
> 0000010  00 90 01 00 01 00 00 00 00 00 00 00 00 00 00 00 
> 0000020  54 00 00 00 54 00 00 00 ff ff ff ff ff ff 00 00 
> 0000030  10 01 01 01 08 06 00 01 08 00 06 04 00 01 00 00 
> 0000040  10 01 01 01 0a 01 01 01 00 00 00 00 00 00 0a 01 
> 0000050  01 02 00 00 10 01 01 01 00 00 10 01 01 02 08 06 
> 0000060  00 01 08 00 06 04 00 02 00 00 10 01 01 02 0a 01 
> 0000070  01 02 00 00 10 01 01 01 0a 01 01 01             
> 
> 
> 
> If i separate the second packet (ARP relpy) with
> 'dd if=84 of=42_2 skip=42 bs=1 count=42' and make a hexdump (42_2.ascii):
> 0000000  00 00 10 01 01 01 00 00 10 01 01 02 08 06 00 01 
> 0000010  08 00 06 04 00 02 00 00 10 01 01 02 0a 01 01 02 
> 0000020  00 00 10 01 01 01 0a 01 01 01                   
> 
> and start text2cap with this hexdump i get:
>  Input from: 42_2.ascii
>  Output to: out.42_2
>  Start new packet
>  Wrote packet of 42 bytes
> 
>  -------------------------
>  Read 1 potential packets, wrote 1 packets
> 
> and ethereal show a correct ARP relpy
> 
> 
> Whats wrong with the 84 byte dump? (if i use a dump with more then one packet, 
> text2pcap generates always only one ethernet packet with a huge trailer...)
> 
> Please answer with CC to my email addr - i'm not ethereal-dev subscribed, 
> thx in advance
> 
> Markus 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-497-8387.  Fax: 978-497-8513 (Attn: Ashok Narayanan)