Wireshark · Ethereal-dev: RE: [Ethereal-dev] bug in text2pcap 0.9.5 ?

["Markus Hennig" <mhennig@xxxxxxxxxx>]

Hi Michael,

you a right!
 Thx a lot,i read this part of the manpage more then once.... (maybe i'm too stupid)

The new 84.ascci:
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 
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

works fine

markus

> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@xxxxxxxxxxxxxxxxx]
> Sent: Sunday, July 21, 2002 3:07 PM
> To: Markus Hennig
> Cc: ashokn@xxxxxxxxx; ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] bug in text2pcap 0.9.5 ?
> 
> 
> Markus,
> 
> from the man page oftest2pcap
> 
>         ignored. An offset of zero is indicative of starting a new
>         packet, so a single text file with a series of hexdumps
>         can be converted into a packet capture with multiple pack-
>         ets. Multiple packets are read in with timestamps differ-
>         ing by one second each. In general, short of these
>         restrictions, text2pcap is pretty liberal about reading in
> 
> Since your offset is only once (in the first line) zero it
> generates only one packet.
> 
> Best regards
> Michael
> 
> On Sunday, July 21, 2002, at 12:40 PM, Markus Hennig wrote:
> 
> > 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
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
> Michael.Tuexen@xxxxxxxxxxxxxxxxx
> 
>