Re: [Wireshark-dev] Bugfix for plugins/profinet
Hi, attached you'll find a short capture of three frames. Regards, Holger -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Ulf Lamping Gesendet: Montag, 23. Juli 2007 21:51 An: Developer support list for Wireshark Betreff: Re: [Wireshark-dev] Bugfix for plugins/profinet [EMAIL PROTECTED] schrieb: Hi, I've fixed a bug in the Profinet-Dissector (plugins/profinet/packet-dcerpc-pn-io.c). In PROFINET IO DCE RPC write-requests, only the first IR frame dataset in PDIRFrameData was dissected. I've fixed the problem, now all IR frame datasets are dissected into individual sub-trees. svn diff file is attached. Would you mind to send a sample capture file so I can test against? You can send it to me personally, if there are any privacy concerns sending it to the list ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev Hilscher Gesellschaft für Systemautomation mbH Rheinstr. 15, 65795 Hattersheim Sitz der Gesellschaft: Hattersheim Geschäftsführer: Hans-Jürgen Hilscher Registergericht: Amtsgericht Frankfurt/Main Handelsregister: Frankfurt B 26873 www.hilscher.com profinet_ir_data.pcap Description: profinet_ir_data.pcap ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] How to reassemble protocol running atop udp?
Hi all, one of our proprietary protocols that runs atop udp is being fragmented on application level. We are using a datagram header for each fragment that provides a fragment index and the length of the fragmented data that follows after the header. As the protocol had not been fragmented in the original design we already have a protocol dissector for that case. Now, my question is how to change the existing dissector to handle fragmented datagrams. Yes, I read the readme.developer file (section 2.7), but it still remains unclear to me: - the tcp_dissect_pdus() method can't be used as the protocol runs atop udp, right? - if the second method (modifying the pinfo struct) has to be used, does that mean that the tvbuff adds up until enough data is present to dissect the data? If yes, how are the fragments displayed in Wireshark? Could I build up a tvbuff without the header data to use it with the dissector for unfragmented data? Well, perhaps you could provide some help or point me in the right direction. Best regards, Lars SEW-EURODRIVE GmbH Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207 Gesellschafter und Geschäftsführer: Rainer Blickle, Jürgen Blickle Geschäftsführer: Hans Sondermann, Bernd P. Uckrow ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to reassemble protocol running atop udp?
Hi! Something similar was discussed very recently: http://www.wireshark.org/lists/wireshark-dev/200707/msg00192.html Also, this link might help: http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html The first example is for a UDP based protocol! Best regards, Abhik. On 7/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, one of our proprietary protocols that runs atop udp is being fragmented on application level. We are using a datagram header for each fragment that provides a fragment index and the length of the fragmented data that follows after the header. As the protocol had not been fragmented in the original design we already have a protocol dissector for that case. Now, my question is how to change the existing dissector to handle fragmented datagrams. Yes, I read the readme.developer file (section 2.7), but it still remains unclear to me: - the tcp_dissect_pdus() method can't be used as the protocol runs atop udp, right? - if the second method (modifying the pinfo struct) has to be used, does that mean that the tvbuff adds up until enough data is present to dissect the data? If yes, how are the fragments displayed in Wireshark? Could I build up a tvbuff without the header data to use it with the dissector for unfragmented data? Well, perhaps you could provide some help or point me in the right direction. Best regards, Lars SEW-EURODRIVE GmbH Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207 Gesellschafter und Geschäftsführer: Rainer Blickle, Jürgen Blickle Geschäftsführer: Hans Sondermann, Bernd P. Uckrow ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to reassemble protocol running atop udp?
Thanks Abhik, I had a look at the first reference you mentioned, but it seemed to be too specific to TCP reassembly. Have to admit that I did not read the chapter in the Developer's Guide, hmm, but I will read it thoroughly, now. Regards, Lars SEW-EURODRIVE GmbH Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207 Gesellschafter und Geschäftsführer: Rainer Blickle, Jürgen Blickle Geschäftsführer: Hans Sondermann, Bernd P. Uckrow -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Abhik Sarkar Gesendet: Dienstag, 24. Juli 2007 10:02 An: Developer support list for Wireshark Betreff: Re: [Wireshark-dev] How to reassemble protocol running atop udp? Hi! Something similar was discussed very recently: http://www.wireshark.org/lists/wireshark-dev/200707/msg00192.html Also, this link might help: http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html The first example is for a UDP based protocol! Best regards, Abhik. On 7/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, one of our proprietary protocols that runs atop udp is being fragmented on application level. We are using a datagram header for each fragment that provides a fragment index and the length of the fragmented data that follows after the header. As the protocol had not been fragmented in the original design we already have a protocol dissector for that case. Now, my question is how to change the existing dissector to handle fragmented datagrams. Yes, I read the readme.developer file (section 2.7), but it still remains unclear to me: - the tcp_dissect_pdus() method can't be used as the protocol runs atop udp, right? - if the second method (modifying the pinfo struct) has to be used, does that mean that the tvbuff adds up until enough data is present to dissect the data? If yes, how are the fragments displayed in Wireshark? Could I build up a tvbuff without the header data to use it with the dissector for unfragmented data? Well, perhaps you could provide some help or point me in the right direction. Best regards, Lars SEW-EURODRIVE GmbH Co KG Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970 Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207 Gesellschafter und Geschäftsführer: Rainer Blickle, Jürgen Blickle Geschäftsführer: Hans Sondermann, Bernd P. Uckrow ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] QSIG protocol
Hi all, the QSIG protocol is fully implemented now (except notifications). Please, let me know if you meet any problem in it. Tomas ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Toolbar icon sizes on Windows too small?
Hi, Just out of curiosity, i noticed the size of toolbar icons in the Windows version is rather small. They look prettier under Linux. I talk about the size the icon takes up inside the toolbar button. The button itself is rather big, so there is much empty space around it. Obviously, this is a matter of taste, but i remember the buttons looked better back sometimes in old Ethereal days. Is this a pure GTK/Wimp issue or is there anything that can be done about it? Lars ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Toolbar icon sizes on Windows too small?
Just out of curiosity, i noticed the size of toolbar icons in the Windows version is rather small. They look prettier under Linux. I talk about the size the icon takes up inside the toolbar button. The button itself is rather big, so there is much empty space around it. Obviously, this is a matter of taste, but i remember the buttons looked better back sometimes in old Ethereal days. Is this a pure GTK/Wimp issue or is there anything that can be done about it? I know what you mean, and IIRC it's a bug in GTK/Wimp. This is caused by some toolbar buttons are toggle buttons (e.g. Colorize Packet List), which seems to be not well supported / not often used. I've filed a GTK bug report at their bugzilla (sorry, number not at hand), but there seems to be no bugfix till today. Regards, ULFL ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] IEEE 802.15.4 dissectors and libpcap support.
Hi Richard, The ccitt crc16 routines are already in crc16.h - please could you use them rather than reinventing this particular wheel? When I first wrote the dissectors, I was having trouble finding a CRC algorithm that would produce the right answer. IEEE 802.15.4 transmits bytes in reflected bit-order, and calculates the CRC over those bits as they are transmitted over the air. IEEE 802.15.4 also further violates the CCITT specification by using initial and final values of 0x, instead of 0x. I now know substantially more about CRC's than I did when I first wrote those functions, and I really should have replaced them with those already available in Wireshark. They have been fixed in the attached patch. Your patch messes up the indentation in libpcap.c - please can you sort it out? My apologies about that, my editor mucked that up, and I thought I had fixed the damage, but apparently I didn't. I should note that the indentation in libpcap.c is inconsistent anyways (some parts use soft tabs, others use hard tabs). Hopefully, the attached patch should correct any out-of-place hard or soft tabs. I'm not generally a fan of 500-line functions - any chance the offender could be split up a bit? I assume you are referring to dissect_ieee802154_common()? Well, I have taken the time to break that function down a bit, but it's still a bit on the lengthy side (just over 300 lines). I also broke the command dissector function down into a bunch of subroutines. Hopefully this is more to your liking. Please could you create a Protocols/ieee802154 page on the wiki, and add an example capture, so we can see what your dissector does? Certainly, I would be more than happy to add a protocol Wiki page for IEEE 802.15.4, is it a high priority, or can I get that done later this week once I have some time? Thanks, Owen Kirby ieee802154r3.patch.gz Description: GNU Zip compressed data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Display Filter Macros of currently selected packet fields?
I've thougth it in the past but I still got a thing to digest...
We need to pass to the Disaplay Filter Macros compiler (DFMC) the
current tree (if any) and have the compiler to replace ${eth.src} with
the representation of the value of ONE eth.src finfo (only one! the
first? the last? one in the middle?).
That's (you are right) relatively easy to implement. Being done once
at compile time performance is not an issue here and we could happily
traverse the proto_tree and the user will never notice.
The issue is: first, last, or a middle one?
e.g. For a tunneled IP over IP packet ${ip.addr} would have 4 possible
values: src and dest of the tunneled packet plus src and dst of the
tunnel heads. Which (if any, or all?) is the ONE right value
${ip.addr} should have at evaluation?
the lack of a good answer to that question is the reason that feature
is not yet there.
Luis
On 7/24/07, Ulf Lamping [EMAIL PROTECTED] wrote:
Hi!
When display filtering, I'll often use data from the currently selected
packet, e.g. see all packets that also has the same Ethernet address pair as
the current packet.
That's why I've implemented the context menu Conversation Filter some time
ago.
However, my feeling about these filters is, that they are too inflexible for
a lot of cases. So I thought about a different approach, and after some time
now I've come to the conclusion that the most flexible and still
understandable way would be to use fields of the currently selected packet in
the filter string. One idea is to use something like:
eth.addr eq ${eth.dst} and eth.addr eq ${eth.src}
to get the same behaviour as the current Conversation Filter/Ethernet
context menu. In fact, this is what the context menu will do hardcoded -
get some data from the currently selected packet and build a new filter
string out of it. But we would gain a lot more flexibility in the users hand
being able to use such macros for the display filter in a generic way here!
Having this flexibility, we could even have user defined GUI elements to
filter stuff, e.g. add user definable toolbar buttons for user defined
filters. So the user can add a toolbar button to filter the stuff he want's.
Having this two (hopefully small) changes, we would gain a lot of comfort in
the everyday work IMO.
Unfortunately, I don't have deep knowledge of the display filter engine, so
is there any chance/interest that someone helps me with this approach? If the
display filter engine is capable of using such macros, I would happily add
the GUI stuff to bring this into life ...
Regards, ULFL
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071distributionid=0066
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] packet-bootp.c: enhancement to decode DHCP option 121
Hi, The following patch decode DHCP option 121. (RFC 3442) Output example : Option: (t=121,l=59) Classless Static Route Option: (121) Classless Static Route Length: 59 Value: 00C0A80301080AC0A80302090B80C0A8030310AC10C0A803... Subnet/MaskWidth-Router: default-192.168.3.1 Subnet/MaskWidth-Router: 10.0.0.0/8-192.168.3.2 Subnet/MaskWidth-Router: 11.128.0.0/9-192.168.3.3 Subnet/MaskWidth-Router: 172.16.0.0/16-192.168.3.4 Subnet/MaskWidth-Router: 172.17.128.0/17-192.168.3.5 Subnet/MaskWidth-Router: 192.168.1.0/24-192.168.3.6 Subnet/MaskWidth-Router: 192.168.2.128/25-192.168.3.7 Subnet/MaskWidth-Router: 192.168.254.254/32-192.168.3.8 Regards, Francois-Xavier Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ packet-bootp.c.opt121_patch.gz Description: 2120222102-packet-bootp.c.opt121_patch.gz ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Toolbar icon sizes on Windows too small?
Hi, Look for gtkrc and see that it declares two toolbars: large and small. The small one is used, but changing this into large gets you the larger icons. Thanx, Jaap Ulf Lamping wrote: Just out of curiosity, i noticed the size of toolbar icons in the Windows version is rather small. They look prettier under Linux. I talk about the size the icon takes up inside the toolbar button. The button itself is rather big, so there is much empty space around it. Obviously, this is a matter of taste, but i remember the buttons looked better back sometimes in old Ethereal days. Is this a pure GTK/Wimp issue or is there anything that can be done about it? I know what you mean, and IIRC it's a bug in GTK/Wimp. This is caused by some toolbar buttons are toggle buttons (e.g. Colorize Packet List), which seems to be not well supported / not often used. I've filed a GTK bug report at their bugzilla (sorry, number not at hand), but there seems to be no bugfix till today. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Add subtree for messages (like ApplyCharging) inCamel
Committed revision 22396. Thanks Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Florent Drouin Skickat: den 24 juli 2007 15:36 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Add subtree for messages (like ApplyCharging) inCamel Hi, Additionally to the fix of bug 1699, could you apply this patch on the camel asn1 dissector. The patch - add a subtree to the ApplyChargingXX Report - add a subtree to ReleaseCall and ReleaseSMS - synchronize Unix and Windows makefile. Thanks in advance Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bugfix for plugins/profinet
[EMAIL PROTECTED] schrieb: Hi, attached you'll find a short capture of three frames. Thanks for the patch! As I've changed that file in the meantime, I had to manually apply your patch (so it's probably slightly different than what you've send). Please also remove unrelated things (like your personal changes in config.nmake) before sending patches. I've checked in your fix in SVN 22398, Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] packet-bootp.c: enhancement to decode DHCP option 121
Hi, Checked in. Thanx, Jaap Francois-Xavier Le Bail wrote: Hi, The following patch decode DHCP option 121. (RFC 3442) Output example : Option: (t=121,l=59) Classless Static Route Option: (121) Classless Static Route Length: 59 Value: 00C0A80301080AC0A80302090B80C0A8030310AC10C0A803... Subnet/MaskWidth-Router: default-192.168.3.1 Subnet/MaskWidth-Router: 10.0.0.0/8-192.168.3.2 Subnet/MaskWidth-Router: 11.128.0.0/9-192.168.3.3 Subnet/MaskWidth-Router: 172.16.0.0/16-192.168.3.4 Subnet/MaskWidth-Router: 172.17.128.0/17-192.168.3.5 Subnet/MaskWidth-Router: 192.168.1.0/24-192.168.3.6 Subnet/MaskWidth-Router: 192.168.2.128/25-192.168.3.7 Subnet/MaskWidth-Router: 192.168.254.254/32-192.168.3.8 Regards, Francois-Xavier ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Display Filter Macros of currently selected packet fields?
On 7/25/07, Luis EG Ontanon [EMAIL PROTECTED] wrote: If we consider this dynamic condition that a filter can be correct or incorrect depending on when it is compiled this is feasable (and a nice feature too!)... One last thing I will have to redissect the selected frame each time a the filter is entered... how do I do that? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Display Filter Macros of currently selected packet fields?
Luis EG Ontanon schrieb: On 7/25/07, Luis EG Ontanon [EMAIL PROTECTED] wrote: If we consider this dynamic condition that a filter can be correct or incorrect depending on when it is compiled this is feasable (and a nice feature too!)... One last thing I will have to redissect the selected frame each time a the filter is entered... how do I do that? Without having a look at the code: I would think that's done mostly the same way when a packet is selected in the packet list today. But do you really have to redissect the packet? The protocol tree for the selected packet is already existing, so scanning the filter string for the field names and replacing them with the current values might simply work, but I'm probably too optimistic here ;-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Display Filter Macros of currently selected packet fields?
On 7/25/07, Ulf Lamping [EMAIL PROTECTED] wrote:
Luis EG Ontanon schrieb:
On 7/25/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
If we consider this dynamic condition that a filter can be correct or
incorrect depending on when it is compiled this is feasable (and a
nice feature too!)...
One last thing I will have to redissect the selected frame each time a
the filter is entered...
how do I do that?
Without having a look at the code: I would think that's done mostly the
same way when a packet is selected in the packet list today.
But do you really have to redissect the packet? The protocol tree for
the selected packet is already existing, so scanning the filter string
for the field names and replacing them with the current values might
simply work, but I'm probably too optimistic here ;-)
Yes you are optimistic... the tree would belong to the last
dissected packet... which often is the selected one but there are
cases (e.g. live capture) where the tree is not the one of the
selected frame.
However I thought that what I have to do is to cache the represented
strings when the packet is selected and somehow pass that cache to the
dfmacro engine.
I think these dynamic-macros will be $[field.name] using '['
instead of '{' for these will make everything much simpler.
Regards, ULFL
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New WiMAX R6 plug-in
I also express my thanks to Nivin. A few comments to add. (1) I also agree to give the different name to R6 plugin or rename the existsted wimax plugin with packet-ieee80216e and keep yours. (2) I'd like to feedback some points, but is it right place to do such things here, or I'd better to email directly with Nivin san? Anyway, here's my check. a) TLV length is wrongly including 'Type' and 'Length' field. Stage3 5.3.1 says: The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero. which means the length should be only the 'Value' part. b) No padding. Stage3 5.3.1 says: Padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). which means padding is required. For instance, Tag: Protocol [138], Length: 5 Wimax TLV tag: 138 Wimax TLV length: 5 TLV Data: 01 must be as follows. Tag: Protocol [138], Length: 5 Wimax TLV tag: 138 Wimax TLV length: 1 === HERE TLV Data: 01 Padding: 00 00 00 === HERE c) 2nd,3rd,5th packet of your sample, wireshark says: Packet is Malformed: Check Tag d) 8th packet of your sample, wireshark says: Packet is Malformed: Check Tag MS Info e) 9th packet of your sample, wireshark has: [Dissector bug, protocol WIMAX: STATUS_ACCESS_VIOLATION: dissctor accessed an invalid memory address] |Thanks for posting this Nivin, | |I'm building it now and will try to test later on today, but here are |a few quick comments: | |(1) I renamed the folder (on my machine) to be plugins/wimax-r6r4, so |as not to clash with the exisint air interface protocols plugin. Does |that seem OK to you? | |(2) you do lots of switches to convert between numbers and their |meanings as strings. |- please use value_string arrays and val_to_str() to look these up instead |- it would be nice to #define symbols for these | |(3) it would also be nice to see #defines, or at least comments for |the tag values used in get_tag_type() | |(4) how complete is this plugin? Do you have a TODO list? | |Best regards, |Martin | |On 7/24/07, Nitin Naveen [EMAIL PROTECTED] wrote: | Hello All, | | I am sharing the code for WiMAX R6/R4 plugin. Hope that it is useful to | the community. | | Regards | Nitin Naveen | Principal Engineer | HUGHES SYSTIQUE | D-8, Infocity-11 | Sector-33, Gugaon | Haryana, India | tel: +91-124-3045400 | fax: +91-124-4039301 | [EMAIL PROTECTED] | www.hsc.com | | | | From: Martin Mathieson [EMAIL PROTECTED] | Date: Thu, 19 Jul 2007 10:29:46 +0100 | | Hi, | | Please do send the code, preferably with one or more test captures (I | have examples for some of R6, but not all)! | | Thanks, | Martin | | | | | | Nitin Naveen/ENGG/GGN/HSC | 07/19/2007 09:22 AM | | To | wireshark-dev@wireshark.org | cc | [EMAIL PROTECTED] | Subject | New WiMAX R6 plug-in | | | | | | Hi, | | I generated dummy packets for WiMAX protocol. Saved the capture to a dummy | file wimax_ether.cap. | Then ran 'fuzz-test.sh | ../fuzz-test.sh -p 2000 -d /root/ /root/wimax_ether.cap | | For all passes I got the following message | Pass 839: | /root/wimax_ether.cap: OK | | Have I missed something or all is OK. If all is OK the I shall make clean | and release the code. | | Regards | Nitin | | | From: Jaap Keuter [EMAIL PROTECTED] | Date: Tue, 10 Jul 2007 19:32:01 +0200 | | Hi, | | | First thing to so it testdrive it using fuzztest. Have a collection of | capture files ready which fuzztest will feed to your Wireshark+plugin. | That way you may find bugs not found during code review. | | Then make sure all support files are in as stated in README.plugin. | | Then 'make clean' the plugin directory and gzip it, after which you can | attach it to a mail to the developer mailing list. When time permits we'll | go over it and consider it for inclusion. | | | In the mean time a Wiki page would be nice, and most importantly, a sample | capture file. | | Thanx, | Jaap | | | | Nitin Naveen wrote: | | | Hi, | | I am Nitin Naveen working at HUGHES SYSTIQUE. We have developed a plug-in | to display | WiMAX R6 messages (between BTS and ASNGW). This plug-in is NOT for the AIR | interface. | It is for WiMAX signalling messages carried over Ethernet/ IP/ UDP. | | We have followed most of the guidelines as per README.developer. It would | be great if | it can be included with the normal Wireshark distribution. | | Please let us know what are the various steps that we need to follow. | | Regards | Nitin Naveen | Principal Engineer | HUGHES SYSTIQUE | D-8, Infocity-11 | Sector-33, Gugaon | Haryana, India | tel: +91-124-3045400 | fax: +91-124-4039301 | [EMAIL PROTECTED] | www.hsc.com | | | | |
Re: [Wireshark-dev] New WiMAX R6 plug-in
Hello,Thank you Martin and Sawada san for your comments.I am OK with any plug-in name and I leave it up to you to decide.I also accept most of the comments.One comment that I would like to discuss: Martin mentioned that I use value_str_array. But i was notsure how array overrun and underrun are handled hence I decided to use the safer switch cases. If my fear is incorrect then I shall replace the switch case with array, but as far as I recollect I had found a crash when using array.I shall fix up and re-release the code and I shall also share responseto each of the valuable comments.RegardsNitin *DISCLAIMER* This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
