Re: [Wireshark-dev] Patches for compilation warnings
On 3/27/07, Peter Johansson <[EMAIL PROTECTED]> wrote: > Oh, my bad. So how can one fix these problems then? I am not really "on top > of" IDL, what should one generally do to correct this? I have sent patches to Jelmer that maintains PIDL that will address most of the warnings from the pidl generated dissectors. Once these patches are in mainline pidl I will regenerate the dissectors. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
Ulf Lamping wrote: > So if we want to group protocols, we should group (at least) most protocols, > to have the protocol list length dastically reduced. True. This could be a first step, though. (I have to admit I was amazed there were 21 protocols--and that's only those with preferences--in the SS7 category. I think there were 3 or 4 when I wrote the M2PA dissector, oh, wow, was it almost 6 years ago? Anyway, taking 21 out of the list isn't a bad start.) > Maybe the current Protocol Family overview > http://wiki.wireshark.org/ProtocolReference could work as a guideline to sort > protocols into such groups. Maybe, though I'd leave the categorization to those who really know the protocols in question. In fact I think SS7 is an easy example here because it's a simple, identifiable thing that encompasses quite a few protocols while not being overly broad. I'd guess the others are more complicated. > P.P.S: Will the packet tree context "Protocol Preferences ..." still work > with this? This feature is pretty useful! Didn't try it but I _think_ the checkin comment says it should work. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patches for compilation warnings
2007/3/26, Stephen Fisher <[EMAIL PROTECTED]>: On Mon, Mar 26, 2007 at 08:58:39AM +0200, Peter Johansson wrote: These can't be applied directly to the source files because the source files are generated from other files (see the top of each file for more information): packet-cosnaming.c.diff.txt packet-dcerpc-dfs.c.diff.txt packet-dcerpc-srvsvc.c.diff.txt packet-dcerpc-winreg.c.diff.txt packet-dcerpc-wzcsvc.c.diff.txt Oh, my bad. So how can one fix these problems then? I am not really "on top of" IDL, what should one generally do to correct this? / Regards, Peter ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
Luis Ontanon wrote: > Now I have to type [Ctrl-Shift-P][p][r][o][RET][fw-arrow][t][c][TAB] > and I can modify TCAP's > prefs. > > Tomorrow I'll have to: > [Ctrl-Shift-P][p][r][o][RET][fw-arrow][s][s][RET][fw-arrow][t][c][TAB] > for a keyboard animal like me that's a loss... > > On the other hand I know that TCAP is an SS7 protocol so *I* would > look there, for someone that does not know what SS7 is how he would > ever know where to look. And you'd see TCAP next to SCCP next to MTP3 so if you want to change multiple preferences at once you wouldn't have to go scrolling... > SS7 is not a good example for this... if you do not know what's SS7 > you probably won't see any SS7 traffic not even by accident, lest > you'll now or need to know what's TCAP. But my point is that > categorizing protocols can hide many of these from users. > > The flat list is easy to search while for the categorized one you need > to know where the protocol belongs. What about having an option to "flatten the tree" to search all the protocols, sorted alphabetically, like today? Or even a "filter" box to search the list? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] FYI: Status of gcc warnings in epan/dissectors
FYI: Update on warnings in epan/dissectors under gcc 4.0 Below is a list of the number of warnings remaining in epan/dissectors when using gcc 4.0. There are 3,915 warnings in this directory across 163 files. Excluding files that show warnings as being in the .cnf filename (such as asn generated) files, there are "only" 795 warnings. This includes some pidl generated dissectors, whose warnings will be fixed by Ronnie once the Samba team commits his change to add _U_ to everything. Almost all of the warnings I've fixed so far are "sign mismatches" between guint8* and (g)char* :(. 552 of the 795 remaining warnings outside of the .cnf files are this problem. As Ulf said, the hole needs to be plugged to keep new warnings from creeping in. Unfortunately, I don't think it is as straightforward to do with automake as it is under MSVC (adding a line to each file with warnings), especially with this many warnings remaining. I can't add -Werror to epan/dissectors yet. I do encourage everyone on Unix to compile with the configure option --with-warnings-as-errors to keep warnings from creeping into the directories where -Werror has been applied. #Warn File 1 ess.cnf 1 h225.cnf 1 h245.cnf 1 logotype-cert-extn.cnf 1 packet-MAP_DialoguePDU-fn.c 1 packet-ansi_map-template.c 1 packet-bacapp.c 1 packet-cmip-fn.c 1 packet-dap-fn.c 1 packet-dccp.c 1 packet-dcerpc-nt.c 1 packet-dcerpc-rs_misc.c 1 packet-dcerpc-spoolss.c 1 packet-dcerpc-wkssvc.c 1 packet-disp-fn.c 1 packet-dsi.c 1 packet-edonkey.c 1 packet-frame.c 1 packet-fw1.c 1 packet-gsm_map-template.c 1 packet-gssapi.c 1 packet-hsrp.c 1 packet-icep.c 1 packet-igap.c 1 packet-image-gif.c 1 packet-ipdc.c 1 packet-isup_thin.c 1 packet-k12.c 1 packet-m2ua.c 1 packet-ospf.c 1 packet-pana.c 1 packet-pkix1implicit-fn.c 1 packet-pkixtsp-fn.c 1 packet-pktc.c 1 packet-quake2.c 1 packet-s5066.c 1 packet-scsi.c 1 packet-skinny.c 1 packet-smb2.c 1 packet-smrse-fn.c 1 packet-sna.c 1 packet-umts_rrc-fn.c 1 packet-umts_rrc-template.c 1 packet-ymsg.c 1 pkcs12.cnf 1 rrlp.cnf 2 cms.cnf 2 packet-acp133-fn.c 2 packet-cmp-fn.c 2 packet-dcerpc-efs.c 2 packet-dcerpc-rpriv.c 2 packet-dcerpc-rs_acct.c 2 packet-dcerpc-rs_pgo.c 2 packet-dhcp-failover.c 2 packet-dhcpv6.c 2 packet-ftp.c 2 packet-gsm_ss-fn.c 2 packet-gtp.c 2 packet-megaco.c 2 packet-nbns.c 2 packet-ndps.c 2 packet-pagp.c 2 packet-pgm.c 2 packet-pop.c 2 packet-rmi.c 2 packet-smb-browse.c 2 packet-wsp.c 3 cmip.cnf 3 packet-dcerpc-afs4int.c 3 packet-dcerpc-dfs.c 3 packet-dcerpc-drsuapi.c 3 packet-dcerpc-winreg.c 3 packet-dcom.c 3 packet-diameter.c 3 packet-ess-fn.c 3 packet-fcdns.c 3 packet-fix.c 3 packet-gnm-template.c 3 packet-iax2.c 3 packet-image-jfif.c 3 packet-inap-template.c 3 packet-iscsi.c 3 packet-kerberos.c 3 packet-q931.c 3 packet-rtp.c 3 packet-sdp.c 3 packet-slowprotocols.c 3 packet-umts_rrc_ies-template.c 3 packet-umts_rrc_pdu_def-template.c 3 packet-x509if-fn.c 4 acse.cnf 4 disp.cnf 4 gsmmap.cnf 4 h248.cnf 4 packet-afp.c 4 packet-ansi_map-template.c 4 packet-cops.c 4 packet-dcerpc-initshutdown.c 4 packet-extreme.c 4 packet-fcswils.c 4 packet-h450-template.c 4 packet-icap.c 4 packet-kismet.c 4 packet-quakeworld.c 4 packet-smb-common.c 4 packet-smtp.c 4 tcap.cnf 5 h235.cnf 5 packet-dcerpc.c 5 packet-distcc.c 5 packet-ipp.c 5 packet-mmse.c 5 packet-ncp.inc 5 packet-osi.c 5 packet-rpc.c 5 packet-umts_rrc_pdu_def-fn.c 6 ansi_map.cnf 6 ftam.cnf 6 packet-dcerpc-eventlog.c 6 packet-dcm.c 6 packet-dop-fn.c 6 packet-ldap-template.c 6 packet-mount.c 6 packet-msrp.c 6 packet-rsync.c 6 packet-slsk.c 6 s4406.cnf 7 packet-bittorrent.c 7 packet-gnm-fn.c 7 packet-isup.c 7 packet-multipart.c 7 x509if.cnf 8 packet-dcerpc-srvsvc.c 8 packet-gsm_sms.c 8 packet-inap-fn.c 9 ldap.cnf 9 packet-mms-fn.c 10 packet-nfs.c 10 packet-smb-pipe.c 11 packet-snmp-template.c 12 camel.cnf 12 packet-jxta.c 13 packet-sip.c 15 ansi_map.cnf 15 packet-dcerpc-fldb.c 16 packet-x509sat-fn.c 18 packet-dcerpc-wzcsvc.c 18 packet-pgsql.c 18 packet-quake3.c 20 packet-dns.c 22 packet-srvloc.c 26 packet-rtsp.c 27 gnm.cnf 36 packet-umts_rrc_ies-fn.c 46 packet-h450-fn.c 46 packet-http.c 57 packet-giop.c 58 inap.cnf 58 packet-smb.c 67 x411.cnf 308 ranap.cnf 1228 rnsap.cnf 1335 nbap.cnf Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Diameter AVP decoding : Same AVP codes withdifferent names
Hi, This is most probably a bug. Please file a bug report, preferably with a sample trace. Best regards Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Xavier Ameziane Skickat: den 26 mars 2007 12:29 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Diameter AVP decoding : Same AVP codes withdifferent names Hello I have a question about the way Wireshark decodes Diameter AVP. Is the "ApplicationID" taken into account when Wireshark decodes an AVP ? Example : - in 3GPP CX/DX Application(ID=16777216, 3GPP TS 29.228 and 29.229), the AVP code 1 is "Visited-Network-Identifier". The vendor-Id for this AVP is TGPP (10415) - in 3GPP Gmb Application (ID=16777223, 3GPP TS 29.061), the AVP code 1 is "3GPP-IMSI". The vendor-Id for this AVP is also TGPP (10415) I created my own dictionnary for 3GPP Gmb Application and, normally, Wireshark should display the right name according to the "ApplicationID" but I don't think it is the case... Wireshark always displays me the value in 3GPP Gmb dictionnary. If I erase the AVP code 1 from my "3GPP Gmb" dictionnary, it displays the AVP name contained in the "3GPP CD/DX" dictionnary...as if it doesn't take into account the ApplicationID... Is it normal ? Do I make a mistake somewhere in my understanding ? Thanks by advance Xavier Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] A very pragmatic approach to fix remaining MSVC warnings ...
Hi List! As I've got no response to my previous approach to fix the warnings of the generated source files in "epan/dissectors" I had to look for a more "pragmatic" approach. There are already changes rushing in, that are adding new warnings, so I've thought it was time to fix this hole by setting the "warnings as errors" plug in epan/dissectors.. My way was adding "#pragma warning(disable:xy)" to the corresponding places. I know that's not the best approach, but I was trying to avoid what was happening the last time I tried reducing warnings, namely that more warnings were rushing in than core developers are willing to fix. Having the (Win32) buildbot turning red for a single warning *might* be a motivation to keep the code warning free. As I would like to remove any warning I introduced, I just didn't noticed the gcc warning I've caused - having the buildbot turned red for the "gcc side", would motivated me to fix "my warnings" ... Regards, ULFL P.S. As a drawback, checking in the generated files (recently changed) will probably make the buildbot turn red, we'll need to find a solution for this ... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21212: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-megaco.c
There was a missing constant preventing it from compiling. I just added it to gcp.h Please review that the constant is the correct one. On 3/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21212 > > User: lego > Date: 2007/03/26 09:10 PM > > Log: > add context tracing and tap to packet-megaco.c > (have to fix the matching of wildcarded terminations as it doesn't work as > it should) > > Directory: /trunk/epan/dissectors/ > ChangesPath Action > +214 -6packet-megaco.cModified > > ___ > Wireshark-commits mailing list > Wireshark-commits@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-commits > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21110: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-eventlog.c packet-dcerpc-eventlog.h /trunk/epan/dissectors/pidl/: eventlog.cnf
Yes, PIDL is maintained by the samba team. Jelmer is a bit busy right now but he will hopefully check the pathces i sent in when he gets time. Once that is done I will regenerate the other PIDL dissectors. On 3/26/07, Stephen Fisher <[EMAIL PROTECTED]> wrote: > Ronnie, > > Can we get a copy of the patched pidl program you used below? Is all of > pidl maintained by the Samba team so that they would be the ones that > would permanently make the _U_ change to it? > > On Thu, Mar 22, 2007 at 08:45:02AM +, [EMAIL PROTECTED] wrote: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21110 > > > > User: sahlberg > > Date: 2007/03/22 08:45 AM > > > > Log: > > Using a patched version of pidl that decorates all parameters with _U_ > > and updates to the conformance file, > > regenerate the eventlog dissector to remove a lot of compiler warnings > > > > Directory: /trunk/epan/dissectors/ > > ChangesPathAction > > +261 -261 packet-dcerpc-eventlog.cModified > > +5 -5 packet-dcerpc-eventlog.hModified > > > > Directory: /trunk/epan/dissectors/pidl/ > > ChangesPathAction > > +3 -3 eventlog.cnfModified > > > > ___ > > Wireshark-commits mailing list > > Wireshark-commits@wireshark.org > > http://www.wireshark.org/mailman/listinfo/wireshark-commits > ___ > 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] [Wireshark-commits] rev 21110: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-eventlog.c packet-dcerpc-eventlog.h /trunk/epan/dissectors/pidl/: eventlog.cnf
Ronnie, Can we get a copy of the patched pidl program you used below? Is all of pidl maintained by the Samba team so that they would be the ones that would permanently make the _U_ change to it? On Thu, Mar 22, 2007 at 08:45:02AM +, [EMAIL PROTECTED] wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21110 > > User: sahlberg > Date: 2007/03/22 08:45 AM > > Log: > Using a patched version of pidl that decorates all parameters with _U_ > and updates to the conformance file, > regenerate the eventlog dissector to remove a lot of compiler warnings > > Directory: /trunk/epan/dissectors/ > ChangesPathAction > +261 -261 packet-dcerpc-eventlog.cModified > +5 -5 packet-dcerpc-eventlog.hModified > > Directory: /trunk/epan/dissectors/pidl/ > ChangesPathAction > +3 -3 eventlog.cnfModified > > ___ > Wireshark-commits mailing list > Wireshark-commits@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patches for compilation warnings
On Mon, Mar 26, 2007 at 08:58:39AM +0200, Peter Johansson wrote: > Sure, no problem. Resending all patches since they still apply, > 'diffed' agains the most recent SVN version. These patches have been applied as SVN revision 21214: packet-afp.c.diff.txt packet-smb.h.diff.txt packet-p_mul.c.diff.txt packet-scsi.c.diff.txt Thanks for your contribution! These can't be applied directly to the source files because the source files are generated from other files (see the top of each file for more information): packet-cosnaming.c.diff.txt packet-dcerpc-dfs.c.diff.txt packet-dcerpc-srvsvc.c.diff.txt packet-dcerpc-winreg.c.diff.txt packet-dcerpc-wzcsvc.c.diff.txt Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] dissecting and decoding an 8 byte field
what about FT_BYTES, FT_UINT64, FT_STRING, FT_DOUBLE? these are either 8 octets long or any size. On 3/26/07, Bill Fassler <[EMAIL PROTECTED]> wrote: > Is there recommended way to decode 8 byte fields? I see I can use FT_NONE > with a size of 8 bytes and the appropriate bytes highlight in the bytes of > the packet, but the value does not display in the decoded details? > > Bill > > > > No need to miss a message. Get email on-the-go > with Yahoo! Mail for Mobile. Get started. > > > ___ > 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] dissecting and decoding an 8 byte field
Is there recommended way to decode 8 byte fields? I see I can use FT_NONE with a size of 8 bytes and the appropriate bytes highlight in the bytes of the packet, but the value does not display in the decoded details? Bill - No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started.___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Broken Record - Release tag
Gerald Combs wrote: > /trunk-0.99.2 was copied from /trunk last week. Once the 0.99.2 release > is made it will be moved to /releases/wireshark-0.99.2. Some time in > the future we'll start over again by copying /trunk to /trunk-0.99.3. Sorry to sound like a broken record. Is there going to be a release tag for 0.99.5? My understanding from Gerald's message on 13 Jul 2006 was that each new release would get a /releases tag. -- Bryant Eastham [EMAIL PROTECTED] Chief Architect Panasonic Electric Works Laboratory of America, Inc. , Salt Lake City Lab ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Sebastien Tandel wrote: > Note that '==' is not portable on BSD unix. For the test/[ command, the standard string-comparison operator is "=", rather than "==". (There's also "-eq" for a numerical comparison.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
What about calling it SS7/SIGTRAN ? Best regards Michael On Mar 26, 2007, at 4:05 PM, Jeff Morriss wrote: > > Hi list, > > I finally had a chance to look at the new feature from revision 21066: > > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 > > and see what it looks like if I put, say, all the SS7 dissectors' > preferences in one preference tree called "SS7". The result was a > little startling: I was able to put *21* dissectors' preferences in > that > category: > > ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, > INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, > TALI, TCAP > > It looks good to me because I tend to think hierarchically and > because I > don't like how long the current list of dissectors with preferences is > (too much scrolling before I find the one I want). > > What does anyone else (especially signaling users) think? Any > objections? > > Regards, > -Jeff > > ps. Yes, I defined SS7 a bit loosely as "anything for transporting SS7 > or which is (or was) transported over SS7". And yes, maybe I missed > some: each time I've gone through the list of preferences I found > another one... > > ___ > 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] Duplicate posts?
Hi All, Sorry for the slightly off-topic post but since we have no postmaster I am pinging the list. Is anyone else receiving duplicate posts? The mailing list site shows me only subscribed once but I am receiving duplicate messages for all posts. Certainly not life threatening but very aggravating... Cheers ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
On 3/26/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > > > > > Hi list, > > > > I finally had a chance to look at the new feature from revision 21066: > > > > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 > > > > and see what it looks like if I put, say, all the SS7 dissectors' > > preferences in one preference tree called "SS7". The result was a > > little startling: I was able to put *21* dissectors' preferences in that > > category: > > > > ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, > > INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, > > TALI, TCAP > > > > It looks good to me because I tend to think hierarchically and because I > > don't like how long the current list of dissectors with preferences is > > (too much scrolling before I find the one I want). > > > > What does anyone else (especially signaling users) think? Any objections? > > > > There are both reasons for and against it. > > I'll agree that the current list is pretty long and I tend to like it to be > hierarchical as well. > > The drawback is: You'll have to know to search for protocol xy under SS7 > (BTW: is this basically the same as http://wiki.wireshark.org/SIGTRAN ?). > This might be obvious for frequent protocol user, but makes it probably more > complicated for newbies (like me :-). Whether SIGTRAN belongs to SS7 or just complements it or supersedes it is a perfect example of an endless categorization discussion. SIGTRAN is a set of protocols to have SS7 run over IP. > So if we want to group protocols, we should group (at least) most protocols, > to have the protocol list length dastically reduced. > Maybe the current Protocol Family overview > http://wiki.wireshark.org/ProtocolReference could work as a guideline to sort > protocols into such groups. > > Regards, ULFL > > P.S: Some time ago, I've tried grouping some of the protocols in the menu > structure, and immediately got objections from other developers against "my > grouping" thoughts - so this discussion might become very controverse ;-) > P.P.S: Will the packet tree context "Protocol Preferences ..." still work > with this? This feature is pretty useful! > ___ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > > ___ > 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] preference tree for SS7
Now I have to type [Ctrl-Shift-P][p][r][o][RET][fw-arrow][t][c][TAB] and I can modify TCAP's prefs. Tomorrow I'll have to: [Ctrl-Shift-P][p][r][o][RET][fw-arrow][s][s][RET][fw-arrow][t][c][TAB] for a keyboard animal like me that's a loss... On the other hand I know that TCAP is an SS7 protocol so *I* would look there, for someone that does not know what SS7 is how he would ever know where to look. SS7 is not a good example for this... if you do not know what's SS7 you probably won't see any SS7 traffic not even by accident, lest you'll now or need to know what's TCAP. But my point is that categorizing protocols can hide many of these from users. The flat list is easy to search while for the categorized one you need to know where the protocol belongs. Luis 3/26/07, Jacques, Olivier (PD&E IT Test) <[EMAIL PROTECTED]> wrote: > I'll second that! > > Olivier. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Morriss > Sent: Monday, March 26, 2007 16:05 > To: wireshark-dev@wireshark.org > Subject: [Wireshark-dev] preference tree for SS7 > > > Hi list, > > I finally had a chance to look at the new feature from revision 21066: > > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 > > and see what it looks like if I put, say, all the SS7 dissectors' > preferences in one preference tree called "SS7". The result was a > little startling: I was able to put *21* dissectors' preferences in that > > category: > > ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, > INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, > TALI, TCAP > > It looks good to me because I tend to think hierarchically and because I > > don't like how long the current list of dissectors with preferences is > (too much scrolling before I find the one I want). > > What does anyone else (especially signaling users) think? Any > objections? > > Regards, > -Jeff > > ps. Yes, I defined SS7 a bit loosely as "anything for transporting SS7 > or which is (or was) transported over SS7". And yes, maybe I missed > some: each time I've gone through the list of preferences I found > another one... > > ___ > 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 > -- 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] preference tree for SS7
> > Hi list, > > I finally had a chance to look at the new feature from revision 21066: > > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 > > and see what it looks like if I put, say, all the SS7 dissectors' > preferences in one preference tree called "SS7". The result was a > little startling: I was able to put *21* dissectors' preferences in that > category: > > ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, > INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, > TALI, TCAP > > It looks good to me because I tend to think hierarchically and because I > don't like how long the current list of dissectors with preferences is > (too much scrolling before I find the one I want). > > What does anyone else (especially signaling users) think? Any objections? > There are both reasons for and against it. I'll agree that the current list is pretty long and I tend to like it to be hierarchical as well. The drawback is: You'll have to know to search for protocol xy under SS7 (BTW: is this basically the same as http://wiki.wireshark.org/SIGTRAN ?). This might be obvious for frequent protocol user, but makes it probably more complicated for newbies (like me :-). So if we want to group protocols, we should group (at least) most protocols, to have the protocol list length dastically reduced. Maybe the current Protocol Family overview http://wiki.wireshark.org/ProtocolReference could work as a guideline to sort protocols into such groups. Regards, ULFL P.S: Some time ago, I've tried grouping some of the protocols in the menu structure, and immediately got objections from other developers against "my grouping" thoughts - so this discussion might become very controverse ;-) P.P.S: Will the packet tree context "Protocol Preferences ..." still work with this? This feature is pretty useful! ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
I'll second that! Olivier. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Morriss Sent: Monday, March 26, 2007 16:05 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] preference tree for SS7 Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called "SS7". The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as "anything for transporting SS7 or which is (or was) transported over SS7". And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ 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] Expert info missing entries
Team, I came across a problem that is described in posting http://www.wireshark.org/lists/wireshark-dev/200607/msg04326.html I can confirm that the change as described there works, e.g. in expert_dlg_init() I call: cf_redissect_packets(&cfile); instead of cf_retap_packets(&cfile, FALSE); I was not able to locate any followup on the posting. Is this problem not important? I am adding many expert infos in my dissector, and would like to understand if they should appear in the expert info list or not. Alternatively, can someone try to figure out why the expert_item value is null when performing a retap (this is from the comment in expert_comp_dlg.c)? I am afraid I would need too much time for it. Thanks in advance Andrej ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
I agree! On 3/26/07, Jeff Morriss <[EMAIL PROTECTED]> wrote: > > Hi list, > > I finally had a chance to look at the new feature from revision 21066: > > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 > > and see what it looks like if I put, say, all the SS7 dissectors' > preferences in one preference tree called "SS7". The result was a > little startling: I was able to put *21* dissectors' preferences in that > category: > > ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, > INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, > TALI, TCAP > > It looks good to me because I tend to think hierarchically and because I > don't like how long the current list of dissectors with preferences is > (too much scrolling before I find the one I want). > > What does anyone else (especially signaling users) think? Any objections? > > Regards, > -Jeff > > ps. Yes, I defined SS7 a bit loosely as "anything for transporting SS7 > or which is (or was) transported over SS7". And yes, maybe I missed > some: each time I've gone through the list of preferences I found > another one... > > ___ > 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] preference tree for SS7
Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called "SS7". The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as "anything for transporting SS7 or which is (or was) transported over SS7". And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding buiding Ethereal
Please read and follow
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html *literally*!!!
Don't use gtk, glib, gcc and/or gdb from/for cygwin, this is for experts only!
Use MSVC 2005EE (and the binary library versions) mentioned to save you from a
lot of trouble.
Regards, ULFL
> -Ursprüngliche Nachricht-
> Von: Manjunath P <[EMAIL PROTECTED]>, Developer support list for Wireshark
>
> Gesendet: 26.03.07 14:46:08
> An: "Developer support list for Wireshark"
> Betreff: Re: [Wireshark-dev] Regarding buiding Ethereal
> I hv read the Developer's guide and through my Cygwin, I hv already
> gcc,gdb,flex,make,bash,python,perl,sed,bison,flex,diff,patch tools.
> Also, when I do a
> $ gtk-config --version
> 1.2.10
> $ glib-config --version
> 1.2.10
> This means that gtk+and Glib libraries are also installed. But still , I
> get the same error.
>
> Pls help me in building WS in Windows Cygwin platform
> ---Thanks
> Manju
>
> [EMAIL PROTECTED] /cygdrive/d/wireshark-0.99.5
> $ cd libpcap-0.7.2
>
> - Original Message -
> From: "Abhik Sarkar" <[EMAIL PROTECTED]>
> To: "Manjunath P" <[EMAIL PROTECTED]>; "Developer support list for
> Wireshark"
> Sent: Monday, March 26, 2007 5:23 PM
> Subject: Re: [Wireshark-dev] Regarding buiding Ethereal
>
>
> > Hi Manjunath,
> >
> > On WIN32, there are several other requirements than just cygwin to
> > compile WS. Please check out the documentation at
> > http://wireshark.org/develop.html and
> > http://wireshark.org/download/docs/developer-guide-a4.pdf to start
> > with. If you follow the instructions in the developer guide without
> > deviating, you can will almost certainly be successful on the first
> > compile attempt.
> >
> > Regards,
> > Abhik
> >
> > On 3/26/07, Manjunath P <[EMAIL PROTECTED]> wrote:
> >>
> >> I am a newbie to Wireshark development. My aim is to have a protocol
> >> dissector.
> >> I have Windows XP along with cygwin installed on my m/c.
> >> I have downloaded source from
> >> http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz
> >> I read the "INSTALL" file and tried to do a "./configure" in wireshark
> >> folder through cygwin.
> >> Then, I got this error and stops.
> >>
> >> xxxstartxxx
> >>
> >> checking whether to use libpcap for packet capture... yes
> >> checking for extraneous pcap header directories... not found
> >> checking pcap.h usability... no
> >> checking pcap.h presence... no
> >> checking for pcap.h... no
> >> configure: error: Header file pcap.h not found; if you installed libpcap
> >> from source, did you also do "make install-incl", and if you installed a
> >> binary package of libpcap, is there also a developer's package of
> >> libpcap,
> >> and did you also install that package?
> >> xxxENDx
> >>
> >> I downloaded "libpcap" source from www.tcpdump.org and put inside
> >> wireshark directory.
> >> I tried to compile this libcap separately and got an error
> >>
> >>
> >> checking for u_int16_t using gcc... yes
> >> checking for u_int32_t using gcc... yes
> >> checking how to run the C preprocessor... gcc -E
> >> checking for sys/ioccom.h... no
> >> checking for sys/sockio.h... no
> >> checking for ifaddrs.h... no
> >> checking for limits.h... yes
> >> checking for netinet/if_ether.h... no
> >> checking for ANSI ioctl definitions... no
> >> configure: error: see the INSTALL for more info
> >>
> >>
> >> How to move forward in the building process.???
> >> ---Manju
> >> SASKEN BUSINESS DISCLAIMER
> > -
> > This message may
> >> contain confidential, proprietary or legally privileged information. In
> >>
> > case you are not the original intended Recipient of the message, you must
> >> not, directly or
> > indirectly, use, Disclose, distribute, print, or copy any
> >> part of this message and you are
> > requested to delete it and inform the
> >> sender. Any views expressed in this message are
> > those of the individual
> >> sender unless otherwise stated. Nothing contained in this message
> > shall be
> >> construed as an offer or acceptance of any offer by Sasken Communication
> >>
> > Technologies Limited ("Sasken") unless sent with that express intent and
> >> with due
> > authority of Sasken. Sasken has taken enough precautions to
> >> prevent the spread of
> > viruses. However the company accepts no liability for
> >> any damage caused by any virus
> > transmitted by this email
> >>
> >> ___
> >> Wireshark-dev mailing list
> >> Wireshark-dev@wireshark.org
> >> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >>
> >>
> >
> SASKEN BUSINESS DISCLAIMER
> -
> This message may contain confidential, proprietary or legally privileged
> information. In
> case you are not the origina
Re: [Wireshark-dev] Regarding buiding Ethereal
I hv read the Developer's guide and through my Cygwin, I hv already
gcc,gdb,flex,make,bash,python,perl,sed,bison,flex,diff,patch tools.
Also, when I do a
$ gtk-config --version
1.2.10
$ glib-config --version
1.2.10
This means that gtk+and Glib libraries are also installed. But still , I
get the same error.
Pls help me in building WS in Windows Cygwin platform
---Thanks
Manju
[EMAIL PROTECTED] /cygdrive/d/wireshark-0.99.5
$ cd libpcap-0.7.2
- Original Message -
From: "Abhik Sarkar" <[EMAIL PROTECTED]>
To: "Manjunath P" <[EMAIL PROTECTED]>; "Developer support list for
Wireshark"
Sent: Monday, March 26, 2007 5:23 PM
Subject: Re: [Wireshark-dev] Regarding buiding Ethereal
> Hi Manjunath,
>
> On WIN32, there are several other requirements than just cygwin to
> compile WS. Please check out the documentation at
> http://wireshark.org/develop.html and
> http://wireshark.org/download/docs/developer-guide-a4.pdf to start
> with. If you follow the instructions in the developer guide without
> deviating, you can will almost certainly be successful on the first
> compile attempt.
>
> Regards,
> Abhik
>
> On 3/26/07, Manjunath P <[EMAIL PROTECTED]> wrote:
>>
>> I am a newbie to Wireshark development. My aim is to have a protocol
>> dissector.
>> I have Windows XP along with cygwin installed on my m/c.
>> I have downloaded source from
>> http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz
>> I read the "INSTALL" file and tried to do a "./configure" in wireshark
>> folder through cygwin.
>> Then, I got this error and stops.
>>
>> xxxstartxxx
>>
>> checking whether to use libpcap for packet capture... yes
>> checking for extraneous pcap header directories... not found
>> checking pcap.h usability... no
>> checking pcap.h presence... no
>> checking for pcap.h... no
>> configure: error: Header file pcap.h not found; if you installed libpcap
>> from source, did you also do "make install-incl", and if you installed a
>> binary package of libpcap, is there also a developer's package of
>> libpcap,
>> and did you also install that package?
>> xxxENDx
>>
>> I downloaded "libpcap" source from www.tcpdump.org and put inside
>> wireshark directory.
>> I tried to compile this libcap separately and got an error
>>
>>
>> checking for u_int16_t using gcc... yes
>> checking for u_int32_t using gcc... yes
>> checking how to run the C preprocessor... gcc -E
>> checking for sys/ioccom.h... no
>> checking for sys/sockio.h... no
>> checking for ifaddrs.h... no
>> checking for limits.h... yes
>> checking for netinet/if_ether.h... no
>> checking for ANSI ioctl definitions... no
>> configure: error: see the INSTALL for more info
>>
>>
>> How to move forward in the building process.???
>> ---Manju
>> SASKEN BUSINESS DISCLAIMER
> -
> This message may
>> contain confidential, proprietary or legally privileged information. In
>>
> case you are not the original intended Recipient of the message, you must
>> not, directly or
> indirectly, use, Disclose, distribute, print, or copy any
>> part of this message and you are
> requested to delete it and inform the
>> sender. Any views expressed in this message are
> those of the individual
>> sender unless otherwise stated. Nothing contained in this message
> shall be
>> construed as an offer or acceptance of any offer by Sasken Communication
>>
> Technologies Limited ("Sasken") unless sent with that express intent and
>> with due
> authority of Sasken. Sasken has taken enough precautions to
>> prevent the spread of
> viruses. However the company accepts no liability for
>> any damage caused by any virus
> transmitted by this email
>>
>> ___
>> Wireshark-dev mailing list
>> Wireshark-dev@wireshark.org
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>>
>
SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged
information. In
case you are not the original intended Recipient of the message, you must not,
directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message
and you are
requested to delete it and inform the sender. Any views expressed in this
message are
those of the individual sender unless otherwise stated. Nothing contained in
this message
shall be construed as an offer or acceptance of any offer by Sasken
Communication
Technologies Limited ("Sasken") unless sent with that express intent and with
due
authority of Sasken. Sasken has taken enough precautions to prevent the spread
of
viruses. However the company accepts no liability for any damage caused by any
virus
transmitted by this email
___
Wireshark-dev mailing list
Wireshark-de
Re: [Wireshark-dev] Compilation failure on MSVC 6.0 with Platform SDK
Graham Bloice wrote: > > From the include files. > > I haven't been able to check your changes yet, but I imagine that they > are close to my tests so that they should be OK. I'll check tomorrow. > In the meantime the buildbot found out that MSVC6 without PSDK doesn't compile, as _WINSOCK2API_ is already defined with it - but sockaddr_storage is not. After thinking about it, I've used WINVER for it (which basically should indicate the Platform SDK version), and checked in a change (you may have a look at the two files for details). So at least it's working on MSVC 6 without PSDK and MSVC 2005EE with PSDK. The less recent PSDK probably still in use is MSVC 2002 (and therefore the most probable to fail), we'll see if someone reports a problem on it now (so we might need to tweak the WINVER check). If you can verify MSVC 6 with PSDK, I think we're on the right way ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding buiding Ethereal
Hi Manjunath,
On WIN32, there are several other requirements than just cygwin to
compile WS. Please check out the documentation at
http://wireshark.org/develop.html and
http://wireshark.org/download/docs/developer-guide-a4.pdf to start
with. If you follow the instructions in the developer guide without
deviating, you can will almost certainly be successful on the first
compile attempt.
Regards,
Abhik
On 3/26/07, Manjunath P <[EMAIL PROTECTED]> wrote:
>
> I am a newbie to Wireshark development. My aim is to have a protocol
> dissector.
> I have Windows XP along with cygwin installed on my m/c.
> I have downloaded source from
> http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz
> I read the "INSTALL" file and tried to do a "./configure" in wireshark
> folder through cygwin.
> Then, I got this error and stops.
>
> xxxstartxxx
>
> checking whether to use libpcap for packet capture... yes
> checking for extraneous pcap header directories... not found
> checking pcap.h usability... no
> checking pcap.h presence... no
> checking for pcap.h... no
> configure: error: Header file pcap.h not found; if you installed libpcap
> from source, did you also do "make install-incl", and if you installed a
> binary package of libpcap, is there also a developer's package of libpcap,
> and did you also install that package?
> xxxENDx
>
> I downloaded "libpcap" source from www.tcpdump.org and put inside
> wireshark directory.
> I tried to compile this libcap separately and got an error
>
>
> checking for u_int16_t using gcc... yes
> checking for u_int32_t using gcc... yes
> checking how to run the C preprocessor... gcc -E
> checking for sys/ioccom.h... no
> checking for sys/sockio.h... no
> checking for ifaddrs.h... no
> checking for limits.h... yes
> checking for netinet/if_ether.h... no
> checking for ANSI ioctl definitions... no
> configure: error: see the INSTALL for more info
>
>
> How to move forward in the building process.???
> ---Manju
> SASKEN BUSINESS DISCLAIMER
-
This message may
> contain confidential, proprietary or legally privileged information. In
>
case you are not the original intended Recipient of the message, you must
> not, directly or
indirectly, use, Disclose, distribute, print, or copy any
> part of this message and you are
requested to delete it and inform the
> sender. Any views expressed in this message are
those of the individual
> sender unless otherwise stated. Nothing contained in this message
shall be
> construed as an offer or acceptance of any offer by Sasken Communication
>
Technologies Limited ("Sasken") unless sent with that express intent and
> with due
authority of Sasken. Sasken has taken enough precautions to
> prevent the spread of
viruses. However the company accepts no liability for
> any damage caused by any virus
transmitted by this email
>
> ___
> 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] Regarding buiding Ethereal
I am a newbie to Wireshark development. My aim is to have a protocol
dissector.
I have Windows XP along with cygwin installed on my m/c.
I have downloaded source from
http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz
I read the "INSTALL" file and tried to do a "./configure" in wireshark folder
through cygwin.
Then, I got this error and stops.
xxxstartxxx
checking whether to use libpcap for packet capture... yes
checking for extraneous pcap header directories... not found
checking pcap.h usability... no
checking pcap.h presence... no
checking for pcap.h... no
configure: error: Header file pcap.h not found; if you installed libpcap
from source, did you also do "make install-incl", and if you installed a
binary package of libpcap, is there also a developer's package of libpcap,
and did you also install that package?
xxxENDx
I downloaded "libpcap" source from www.tcpdump.org and put inside wireshark
directory.
I tried to compile this libcap separately and got an error
checking for u_int16_t using gcc... yes
checking for u_int32_t using gcc... yes
checking how to run the C preprocessor... gcc -E
checking for sys/ioccom.h... no
checking for sys/sockio.h... no
checking for ifaddrs.h... no
checking for limits.h... yes
checking for netinet/if_ether.h... no
checking for ANSI ioctl definitions... no
configure: error: see the INSTALL for more info
How to move forward in the building process.???
---Manju
SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged
information. In
case you are not the original intended Recipient of the message, you must not,
directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message
and you are
requested to delete it and inform the sender. Any views expressed in this
message are
those of the individual sender unless otherwise stated. Nothing contained in
this message
shall be construed as an offer or acceptance of any offer by Sasken
Communication
Technologies Limited ("Sasken") unless sent with that express intent and with
due
authority of Sasken. Sasken has taken enough precautions to prevent the spread
of
viruses. However the company accepts no liability for any damage caused by any
virus
transmitted by this email
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi Anders, It is in ETSI GSM MAP specification "GSM 09.02 version 4.19.1" -- short message service operation codes sendRoutingInfoForSM SendRoutingInfoForSM ::= 45 forwardSM ForwardSM ::= localValue 46 ... There is no distinction between mt-fsm and mo-fsm. Thanks for looking into this. No hurry. Regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote: > Hi, > In which specification is mt-fsm(MT-ForwardSM?) given with Opcode 46? > I supose a solution would be to introduce a preference if MAPv2 or V3 is > used. > I have little time to look at this currently. > Best regards > Anders > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Abhik Sarkar > Sent: den 26 mars 2007 11:31 > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] gsm_map dissector question > > Hi Anders, > > Thanks for your reply. Attached are sample captures. The MSUs are syslog > encapsulated, so you need to be running SVN rev 21109 or higher. Decode > UDP destination port 7890 as syslog and you will see the MTP3 and higher > layers. > > example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. > example2.cap : The gsm_map dissector throwing up a BER decode error > because it thinks there are some extra invalid field beyond the sm-RP-UI > of the mo-fsm, but the extra field is actually the more-messages-to-send > flag in a MAPv2 mt-fsm. > > I had one more example, but I can't find it anymore. I will send it on > if I do find it. > > Best regards, > Abhik. > > On 3/26/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote: > > Hi, > > If you could supply a sample trace we could see what can be done. > > Best regards > > Anders > > > > > > > > From: [EMAIL PROTECTED] on behalf of Abhik Sarkar > > Sent: Mon 3/26/2007 9:49 AM > > To: wireshark-dev@wireshark.org > > Subject: [Wireshark-dev] gsm_map dissector question > > > > > > > > Hi List, > > > > I have been capturing and decoding some live traffic on a GSM network, > > > and find a problem in decoding of GSM MAP operations. > > > > The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. > > This leads to incorrect decoding of packets which are working on lower > > > MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as > > MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to > > all kinds of warnings, and sometimes incorrect decoding. > > > > I don't suppose there is a (simple) way around this, is there? I guess > > > a complex (and resource hungry) method would be for the TCAP dissector > > > to follow dialogs and then pass the application context information to > > > the MAP dissector for MAP to interpret the operation based on the > > application context in addition to the op-code. > > > > I am sorry if this has already been discussed, I searched the > > archives, but could not find anything relevant... perhaps I didn't use > > > the correct search string. > > > > Thanks, > > Abhik. > > ___ > > 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 mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] bunch of warnings fixes
checked in On 3/26/07, Sebastien Tandel <[EMAIL PROTECTED]> wrote: > One big patch is provided to apply all the changes. > It contains warnings fixes and removed some declarations after statement > too. > > I also provide patch-per-file.tar.gz containing one patch for each file > affected by "big patch", in case some modifs have been committed on one > of these files : > packet-alcap > packet-ansi_637 > packet-ansi_a > packet-atalk > packet-beep > packet-ber > packet-bootp > packet-bpdu > packet-bthci_acl > packet-btsdp > packet-cops > packet-cups > packet-ssh > packet-synergy > packet-t38 > packet-tacacs > packet-tali > packet-tcp > packet-tds > packet-telnet > packet-ucp > packet-uma > packet-vtp > packet-wbxml > packet-who > packet-x11 > packet-x25 > packet-xdmcp > packet-xml > packet-yhoo > > > > Regards, > Sebastien Tandel > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Diameter AVP decoding : Same AVP codes with different names
Hello I have a question about the way Wireshark decodes Diameter AVP. Is the "ApplicationID" taken into account when Wireshark decodes an AVP ? Example : - in 3GPP CX/DX Application(ID=16777216, 3GPP TS 29.228 and 29.229), the AVP code 1 is "Visited-Network-Identifier". The vendor-Id for this AVP is TGPP (10415) - in 3GPP Gmb Application (ID=16777223, 3GPP TS 29.061), the AVP code 1 is "3GPP-IMSI". The vendor-Id for this AVP is also TGPP (10415) I created my own dictionnary for 3GPP Gmb Application and, normally, Wireshark should display the right name according to the "ApplicationID" but I don't think it is the case... Wireshark always displays me the value in 3GPP Gmb dictionnary. If I erase the AVP code 1 from my "3GPP Gmb" dictionnary, it displays the AVP name contained in the "3GPP CD/DX" dictionnary...as if it doesn't take into account the ApplicationID... Is it normal ? Do I make a mistake somewhere in my understanding ? Thanks by advance Xavier - Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi, In which specification is mt-fsm(MT-ForwardSM?) given with Opcode 46? I supose a solution would be to introduce a preference if MAPv2 or V3 is used. I have little time to look at this currently. Best regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhik Sarkar Sent: den 26 mars 2007 11:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] gsm_map dissector question Hi Anders, Thanks for your reply. Attached are sample captures. The MSUs are syslog encapsulated, so you need to be running SVN rev 21109 or higher. Decode UDP destination port 7890 as syslog and you will see the MTP3 and higher layers. example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. example2.cap : The gsm_map dissector throwing up a BER decode error because it thinks there are some extra invalid field beyond the sm-RP-UI of the mo-fsm, but the extra field is actually the more-messages-to-send flag in a MAPv2 mt-fsm. I had one more example, but I can't find it anymore. I will send it on if I do find it. Best regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote: > Hi, > If you could supply a sample trace we could see what can be done. > Best regards > Anders > > > > From: [EMAIL PROTECTED] on behalf of Abhik Sarkar > Sent: Mon 3/26/2007 9:49 AM > To: wireshark-dev@wireshark.org > Subject: [Wireshark-dev] gsm_map dissector question > > > > Hi List, > > I have been capturing and decoding some live traffic on a GSM network, > and find a problem in decoding of GSM MAP operations. > > The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. > This leads to incorrect decoding of packets which are working on lower > MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as > MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to > all kinds of warnings, and sometimes incorrect decoding. > > I don't suppose there is a (simple) way around this, is there? I guess > a complex (and resource hungry) method would be for the TCAP dissector > to follow dialogs and then pass the application context information to > the MAP dissector for MAP to interpret the operation based on the > application context in addition to the op-code. > > I am sorry if this has already been discussed, I searched the > archives, but could not find anything relevant... perhaps I didn't use > the correct search string. > > Thanks, > Abhik. > ___ > 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] [PATCH] bunch of warnings fixes
One big patch is provided to apply all the changes. It contains warnings fixes and removed some declarations after statement too. I also provide patch-per-file.tar.gz containing one patch for each file affected by "big patch", in case some modifs have been committed on one of these files : packet-alcap packet-ansi_637 packet-ansi_a packet-atalk packet-beep packet-ber packet-bootp packet-bpdu packet-bthci_acl packet-btsdp packet-cops packet-cups packet-ssh packet-synergy packet-t38 packet-tacacs packet-tali packet-tcp packet-tds packet-telnet packet-ucp packet-uma packet-vtp packet-wbxml packet-who packet-x11 packet-x25 packet-xdmcp packet-xml packet-yhoo Regards, Sebastien Tandel rev21208-dissectors-warnings-fixes.diff.gz Description: application/gzip patch-per-file.tar.gz Description: application/gzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi Anders, Thanks for your reply. Attached are sample captures. The MSUs are syslog encapsulated, so you need to be running SVN rev 21109 or higher. Decode UDP destination port 7890 as syslog and you will see the MTP3 and higher layers. example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. example2.cap : The gsm_map dissector throwing up a BER decode error because it thinks there are some extra invalid field beyond the sm-RP-UI of the mo-fsm, but the extra field is actually the more-messages-to-send flag in a MAPv2 mt-fsm. I had one more example, but I can't find it anymore. I will send it on if I do find it. Best regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) <[EMAIL PROTECTED]> wrote: Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ 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 example1.cap Description: Binary data example2.cap Description: Binary data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, > - in hf_register_info, there are two items of the same name : > hf_ipv6_shim6_opt_len This is fixed in the source and in the patch. > - you should create an helper function to add hf_ipv6_shim6_ct to the tree. I know, but at the moment I don't have the time to figure that out. > - instead of dissect_shim_ip_addr, use > proto_tree_add_item/proto_tree_add_ipv6. The type of the item is then > FT_IPv6. Replaced all occurences of dissect_shim_ip_addr. In two weeks time I should have more time. Than I will look at the hf_ipv6_shim6_ct. Expect a new patch at that time. Regards, Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB5JpNiaStnTWEtYRAhopAKC+IftlWBK+fuT0p3n9S9s8xD0E+wCcCdc3 eqOz1UMNMsmM0xc6n+T/r6c= =Fm6B -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compilation failure on MSVC 6.0 with Platform SDK
Ulf Lamping wrote: > Graham Bloice wrote: >> When compiling with MSVC 6.0 and the platform SDK, there are failures >> due to the redefinition of sockaddr_storage in capture_wpcap_packet.c >> and gtk/capture_if_details_dlg.c. >> >> The definition is conditional on the version of MSVC used, whereas the >> actual definition depends on the version of winsock defined, which is >> indicated by the symbol _WINSOCK2API_. I think that using this symbol >> would be preferable. >> >> > Ah, thanks for pointing this out. At the time I was implementing this, I > got the strong feeling that there might be a better way - but I was just > too lazy to find out :-) > > I've updated both files in SVN 21162. > > Could you have a try if it works with MSVC 6 & SDK? > > BTW: Is this official MSDN, or something you've got from the include files? > From the include files. I haven't been able to check your changes yet, but I imagine that they are close to my tests so that they should be OK. I'll check tomorrow. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ 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] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did indeed. I fixed the patch. Regards, Matthijs Sebastien Tandel wrote: > Hi, > your patch is malformed line 63. You've probably deleted some hf_items > or some comments directly in the patch but that must be reflected in the > "accounting numbers" of the patch format ;) > > > Regards, > Sebastien Tandel > > Matthijs Mekking wrote: >> Thanks for the advice. I have attached a new patch, were you can apply >> shim6 elements as filter easier. >> >> more info at www.pletterpet.nl/shim6/ >> >> Regards, >> >> Matthijs Mekking >> [EMAIL PROTECTED] >> NLNetLabs Amsterdam / Radboud University Nijmegen >> >> Sebastien Tandel wrote: >>> I think most the proto_tree_add_text could be replaced by >>> proto_tree_add_item which could allow (i.e. at least Sébastien Barré ;)) >>> to perform an easy search on specific items. ;) >> >>> Regards, >>> Sebastien Tandel >>> Matthijs Mekking wrote: Hello, The last two months I have been working on a SHIM6 enabled version of Wireshark. The subject of my final thesis is about SHIM6 and I >> needed to analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based solution for multihoming.(www.shim6.org) SHIM6 is handled as an IPv6 extension header. So I have changed the source and header files of packet-ipv6. I have added dissecting functions for different the message formats of the SHIM6 protocol. I also needed to change the ipproto files to add the new extension header. The included patch is pretty clear about that. The message formats are conform the latest draft specification of >> SHIM6: http://tools.ietf.org/html/draft-ietf-shim6-proto-07 http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07 Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen >>> ___ >>> 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB4diNiaStnTWEtYRAhp3AJwJnIepZKHOdyfWhwsfCMKnpalTggCgkFB0 u85t1UcbAfL1lRXeqRHYN3A= =+Juy -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Note that '==' is not portable on BSD unix. Jeff Morriss wrote: > Thanks & sorry for the trouble. Unfortunately something was stripping > the []'s out of the test in "configure.in" so the resulting "configure" > just had "if $? == 0 ;" which didn't work. I just checked in a new > version which should work for everyone. > > ronnie sahlberg wrote: > >> I just checked in a different test for configure.in in trunk that works for >> me. >> >> Please review. >> >> >> >> >> On 3/26/07, Jeff Morriss <[EMAIL PROTECTED]> wrote: >> >>> Hmmm, that's weird, it works for me. >>> >>> What version of GCC are you using? >>> >>> What does: >>> >>> echo yes | gcc -E -Wfoodeclaration-after-statement - >>> >>> produce for you? For me I get only: >>> >>> cc1: error: unrecognized command line option >>> "-Wfoodeclaration-after-statement" >>> # 1 "" >>> (but no "yes"). >>> >>> Oh, OK, it looks like older versions of GCC (I just tried 3.2) don't >>> error out when presented an invalid command line argument. >>> >>> Hmmm, at least it should still compile on those GCC versions, but now I >>> have to think of a different test... >>> >>> ronnie sahlberg wrote: >>> The checks in configure.in for this doesnt work properly for GCC versions which do not support this -W directive. Eventhough it is not supported by GCC AC_MSG_CHECKING(to see if we can add '-Wdeclaration-after-statement'... still adds it to the compile flags. I will see if i can figure out why the test fails. Me and automake/configure are not on friendly terms. On 3/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21195 > > User: morriss > Date: 2007/03/26 12:32 AM > > Log: > If we're using gcc, try to use -Wdeclaration-after-statement to catch > >>> more >>> > non-portable commits. I'm not sure if this is the Right Way to test to > >>> see >>> > if the compiler can handle a specific option but it's simple and > >>> efficient >>> > enough. > > Directory: /trunk/ > ChangesPathAction > +8 -0 configure.inModified > > ___ > Wireshark-commits mailing list > Wireshark-commits@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-commits > > ___ 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 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] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Thanks & sorry for the trouble. Unfortunately something was stripping the []'s out of the test in "configure.in" so the resulting "configure" just had "if $? == 0 ;" which didn't work. I just checked in a new version which should work for everyone. ronnie sahlberg wrote: > I just checked in a different test for configure.in in trunk that works for > me. > > Please review. > > > > > On 3/26/07, Jeff Morriss <[EMAIL PROTECTED]> wrote: >> Hmmm, that's weird, it works for me. >> >> What version of GCC are you using? >> >> What does: >> >> echo yes | gcc -E -Wfoodeclaration-after-statement - >> >> produce for you? For me I get only: >> >>> cc1: error: unrecognized command line option >> "-Wfoodeclaration-after-statement" >>> # 1 "" >> (but no "yes"). >> >> Oh, OK, it looks like older versions of GCC (I just tried 3.2) don't >> error out when presented an invalid command line argument. >> >> Hmmm, at least it should still compile on those GCC versions, but now I >> have to think of a different test... >> >> ronnie sahlberg wrote: >>> The checks in configure.in >>> for this doesnt work properly for >>> GCC versions which do not support this -W directive. >>> >>> Eventhough it is not supported by GCC >>> AC_MSG_CHECKING(to see if we can add '-Wdeclaration-after-statement'... >>> still adds it to the compile flags. >>> >>> I will see if i can figure out why the test fails. >>> Me and automake/configure are not on friendly terms. >>> >>> >>> >>> On 3/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21195 User: morriss Date: 2007/03/26 12:32 AM Log: If we're using gcc, try to use -Wdeclaration-after-statement to catch >> more non-portable commits. I'm not sure if this is the Right Way to test to >> see if the compiler can handle a specific option but it's simple and >> efficient enough. Directory: /trunk/ ChangesPathAction +8 -0 configure.inModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits >>> ___ >>> 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 mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did indeed! I deleted a line that didn't matter, but screwed up the accounting numbers apparently. It is now fixed. Regards, Matthijs Sebastien Tandel wrote: > Hi, > your patch is malformed line 63. You've probably deleted some hf_items > or some comments directly in the patch but that must be reflected in the > "accounting numbers" of the patch format ;) > > > Regards, > Sebastien Tandel > > Matthijs Mekking wrote: >> Thanks for the advice. I have attached a new patch, were you can apply >> shim6 elements as filter easier. >> >> more info at www.pletterpet.nl/shim6/ >> >> Regards, >> >> Matthijs Mekking >> [EMAIL PROTECTED] >> NLNetLabs Amsterdam / Radboud University Nijmegen >> >> Sebastien Tandel wrote: >>> I think most the proto_tree_add_text could be replaced by >>> proto_tree_add_item which could allow (i.e. at least Sébastien Barré ;)) >>> to perform an easy search on specific items. ;) >> >>> Regards, >>> Sebastien Tandel >>> Matthijs Mekking wrote: Hello, The last two months I have been working on a SHIM6 enabled version of Wireshark. The subject of my final thesis is about SHIM6 and I >> needed to analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based solution for multihoming.(www.shim6.org) SHIM6 is handled as an IPv6 extension header. So I have changed the source and header files of packet-ipv6. I have added dissecting functions for different the message formats of the SHIM6 protocol. I also needed to change the ipproto files to add the new extension header. The included patch is pretty clear about that. The message formats are conform the latest draft specification of >> SHIM6: http://tools.ietf.org/html/draft-ietf-shim6-proto-07 http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07 Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen >>> ___ >>> 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB4BUNiaStnTWEtYRAkKYAJ4xHOE+wwI4MPdd2hLeL95KHwosZACgmTvu khifVtUswHRLvaJDr9h9Q8c= =b38s -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
