Re: [Wireshark-dev] Text2pcap and bidirectional traffic
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 > -- > > > > DISCLAIMER:--- > This e-mail transmission and any documents, files and > previous e-mail messages attached to it are private and confidential. > They may contain proprietary or copyright material or information that > is subject to legal professional privilege. They are for the use of > the intended recipient only. Any unauthorised viewing, use, > disclosure, copying, alteration, storage or distribution of, or > reliance on, this message is strictly prohibited. No part may be > reproduced, adapted or transmitted without the written permission of > the owner. If you have received this transmission in error, or are not > an authorised recipient, please immediately notify the sender by > return email, delete this message and all copies from your e-mail > system, and destroy any printed copies. Receipt by anyone other than > the intended recipient should not be deemed a waiver of any privilege > or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. > -- > > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wiresh
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 <[EMAIL PROTECTED]> 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 > -- > > > > DISCLAIMER:--- > This e-mail transmission and any documents, files and previous e-mail messages > attached to it are private and confidential. They may contain proprietary or > copyright > material or information that is subject to legal professional privilege. They > are for > the use of the intended recipient only. Any unauthorised viewing, use, > disclosure, > copying, alteration, storage or distribution of, or reliance on, this message > is > strictly prohibited. No part may be reproduced, adapted or transmitted > without the > written permission of the owner. If you have received this transmission in > error, or > are not an authorised recipient, please immediately notify the sender by > return email, > delete this message and all copies from your e-mail system, and destroy any > printed > copies. Receipt by anyone other than the intended recipient should not be > deemed a > waiver of any privilege or protection. Thales Australia does not warrant or > represent > that this e-mail or any documents, files and previous e-mail messages > attached are > error or virus free. > -- > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > https://wireshark.org/mailman/listinfo/wireshark-dev > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Text2pcap and bidirectional traffic
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 -- DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev