Hi
2011/8/25 Pascal Quantin
<pascal.quantin@xxxxxxxxx>
Hi all,
since the commit for bug 1723 (done in revision 38679), I'm facing issues with text2pcap for really small packet dumps.
Let's take this simple file example:
0000 30 00 20
By executing the following command line:
text2pcap.exe -q -l 162 temp.txt temp.pcap
I get the following binary pcap file:
00000000: D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
00000010: 00 90 01 00 A2 00 00 00
As you can see, the packet is not included in the pcap file and if I open it in Wireshark no packet is displayed.
Adding explicit ASCII string (so as to follow more closely the usual text2pcap input format) after the bytes does not help either:
0000 30 00 20 ...
When I use Wireshark version 38678, I get the following binary pcap:
00000000: D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
00000010: 00 90 01 00 A2 00 00 00 7F 67 56 4E 00 00 00 00
00000020: 03 00 00 00 03 00 00 00 30 00 20
and everything works fine.
I guess this is unexpected behavior and should be considered as a bug. Do you agree ?
Unfortunately I do not have the time to look at the text2pcap.c changes right now, so any help is welcome.
Regards
Pascal.
I started looking at the code change done by Chris Maynard and it fails with my sample because it tries to compare the not present ASCII string with the HEX string (so as to avoid taking a beginning of the ASCII string as part of the HEX string, as explained in bug 1723).
Is the ASCII dump mandatory in the text2pcap input file format ? The text2pcap help file is not very clear concerning this point and I assumed that appending ASCII output was optional (as it was working previously). So should I explicitly add it ?
Thanks for your help,
Pascal.
