I haven't had the time to look into this tool yet, although I hope to
one day, but the network expect tool that Eloy Paris wrote and maintains
might be useful to you: http://www.netexpect.org.
http://www.wireshark.org/lists/wireshark-dev/200805/msg00145.html
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Barnes, Pat
Sent: Tuesday, July 22, 2008 3:01 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Text2pcap and bidirectional traffic
Thank you, I was not aware of that approach. Unfortunately it won't work
for my case - the dissector needs to examine IP addresses and port
numbers, and it does so heuristically.
I'll consider opening an enhancement report when I have finished writing
the test data.
Cheers,
Patrick
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Abhik Sarkar
Sent: Tuesday, 22 July 2008 3:54 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Text2pcap and bidirectional traffic
Hi Patrick!
Due you really need the TCP and lower layers (for example, if you make
use of the conversations API)? If not, you could simply use text2pcap
with a user DLT to test only your protocol layer:
http://wiki.wireshark.org/HowToDissectAnything (the page needs a bit of
an update to match the latest versions... I'll see if I can do that
later today, but you should get the idea (if you don't already know,
that is)).
What you are proposing of course could be quite useful. It might be
worth opening an enhancement bug report with your initial approach (so
that the idea doesn't get lost) and someone might be able to provide
further ideas.
HTH
Abhik.
On Tue, Jul 22, 2008 at 8:50 AM, Barnes, Pat
<Pat.Barnes@xxxxxxxxxxxxxxxxxx> wrote:
>
> I don't have any traffic to test my dissector against, because the
> components in the system that will be generating that traffic aren't
> ready yet.
>
> Until then, I've used text2pcap to construct some capture files from
> scratch. There is a bit of a problem though: The -T (add TCP headers)
> option results in packets only going in one direction.
>
> As a bit of hack, I've put this code in the process_directive
function:
>
> static void
> process_directive (char *str)
> {
> guint32 tmp;
>
> str += 11; //Strip off the #TEXT2PCAP and first space
> if (strncmp("INVERT", str, 6) == 0) {
> if (hdr_ip) {
> tmp = HDR_IP.src_addr;
> HDR_IP.src_addr = HDR_IP.dest_addr;
> HDR_IP.dest_addr = tmp;
> }
> if (hdr_tcp || hdr_udp) {
> tmp = hdr_src_port;
> hdr_src_port = hdr_dest_port;
> hdr_dest_port = tmp;
> }
> fprintf(stdout, "Inverted source and destination \n");
> } else {
> fprintf(stderr, "\n--- Directive [%s] currently
> unsupported ---\n", str-11);
> }
> }
>
> Such that a '#TEXT2PCAP INVERT' will switch the directions around.
>
> The only downside to this approach is that it mucks up the TCP
> sequences
> - subsequent packets have a 'TCP segment lost' warning. Any
> suggestions on how to suppress/fix that, or otherwise enhance
text2pcap?
>
> ----------------------------------
> Patrick Barnes
> Software Engineer
> Land & Joint Systems
>
> Thales Australia
> 274 Victoria Road, Rydalmere, NSW 2116, Australia
> Tel: +61 2 9848 3857
> Mob: +61 410 751 044
> | www.thalesgroup.com.au
> ----------------------------------
>
>
[snip]
