Re: [Wireshark-dev] SVN doesn't compile under MacOS X
On 01.02.2007, at 02:39, Stephen Fisher wrote:On Thu, Feb 01, 2007 at 02:01:41AM +0100, Andreas Fink wrote: current SVN seems to have some double defined symbol conflict:ld_classic: multiple definitions of symbol _svnversionversion_info.o definition of _svnversion in section (__DATA,__data)gtk/libui.a(main.o) definition of _svnversion in section (__DATA,__common)gtk/libui.a(about_dlg.o) definition of _svnversion in section (__DATA,__common) This sounds like bug #1289. Want to apply the patch from it and see if it works? http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1289Thie patch from bug 1289 did in fact make it work. except I had to manually edit version_info.h.I had to modify two other minor things.1. Index: epan/crypt/airpdcap_interop.h: size_t double definition2. When launching it for the first time I get an error saying "error while loading 'dfilter_macros'. No such file or directory'. The file doesnt exist until you open the dfilter macros section for the first time. As it is perfectly ok to not have it, the warning can be safely removed.Can someone with svn access maybe commit this patch? macosx.diff Description: Binary data Andreas FinkFink Consulting GmbHGlobal Networks Schweiz AGBebbiCell AG---Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333Address: Clarastrasse 3, 4058 Basel, SwitzerlandE-Mail: [EMAIL PROTECTED]www.finkconsulting.com www.global-networks.ch www.bebbicell.ch---ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfinkYahoo: finkconsulting SMS: +41792457333 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Overriding existing RPC-TCP heuristic dissector with another heuristic one
Hi, The solution is to improve the heuristics until they can figure out which dissector is the correct one. Thanx, Jaap On Thu, 1 Feb 2007, Shehjar Tikoo wrote: > Hi all > > I am writing a RPC over TCP heuristic dissector but the RPC dissector(in > packet-rpc.c) also registers a heuristic RPC over TCP dissector. > > It is possible that the packet my heuristic dissector needs, > gets routed to the existing dissector. > > From the list archives I see discussions about overriding regular > dissectors with heuristic dissectors( using tcp.try_heuristic_first) but > how can I override an existing heuristic dissector with another one. > > Thanks > Shehjar ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Overriding existing RPC-TCP heuristic dissector with another heuristic one
Hi all I am writing a RPC over TCP heuristic dissector but the RPC dissector(in packet-rpc.c) also registers a heuristic RPC over TCP dissector. It is possible that the packet my heuristic dissector needs, gets routed to the existing dissector. From the list archives I see discussions about overriding regular dissectors with heuristic dissectors( using tcp.try_heuristic_first) but how can I override an existing heuristic dissector with another one. Thanks Shehjar ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Multiple pdus atop TCP -- a lie in README.developer?
Guy Harris wrote: > Then > > 1) have a dissector for a single one of your PDUs; > > 2) use that dissector with tcp_dissect_pdus() when dissecting your > protocol over TCP; > > 3) write your own reassembly code for other protocols and call your > single-PDU dissector from that code. And implement equivalents for tcp_dissect_pdus() for the other transport protocols? Ok; that makes some sense I guess (although seems to tie together the dissectors unnecessarily). But my real question still stands: does the technique in README.developer section 2.7.2, with updating pinfo->desegment_offset and pinfo->desegment_len, not work? -- Richard van der Hoff <[EMAIL PROTECTED]> Systems Analyst Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] "Cisco format" MAC addresses in display filters?
On Tue, Jan 30, 2007 at 02:12:28PM -0800, Stephen Fisher wrote: > How hard would it be to allow the display filter to accept "Cisco > format" MAC addresses (..) and still match the usual > format (xx:xx:xx:xx:xx:xx)? Where would I change this? I have committed SVN revision 20660 that allows this format of MAC addresses to be specified and match the traditional format MAC addresses seen in Wireshark. For the record, I had to modify hex_str_to_bytes() in strutil.c because the FT_ETHER type uses the same functions that FT_BYTES uses: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=20660 Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SVN doesn't compile under MacOS X
On Thu, Feb 01, 2007 at 02:01:41AM +0100, Andreas Fink wrote: > current SVN seems to have some double defined symbol conflict: > > ld_classic: multiple definitions of symbol _svnversion > version_info.o definition of _svnversion in section (__DATA,__data) > gtk/libui.a(main.o) definition of _svnversion in section > (__DATA,__common) > gtk/libui.a(about_dlg.o) definition of _svnversion in section > (__DATA,__common) This sounds like bug #1289. Want to apply the patch from it and see if it works? http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1289 Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] SVN doesn't compile under MacOS X
current SVN seems to have some double defined symbol conflict: ld_classic: multiple definitions of symbol _svnversion version_info.o definition of _svnversion in section (__DATA,__data) gtk/libui.a(main.o) definition of _svnversion in section (__DATA,__common) gtk/libui.a(about_dlg.o) definition of _svnversion in section (__DATA,__common) Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --- Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --- ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [patch] address_to_str_buf not checking available buffer length
Checked in, with the error string changed to "[Buffer too small]". Thanks! Andrej Mikus wrote: > Accepted or not, I needed to do something to get my working copy > compiled. Attached is the patch if you like to use it. > > Thanks > Andrej > > On Wed, 31.Jan.07 12:29:30 +0100, Andrej Mikus wrote: >> On Mon, 29.Jan.07 12:49:00 -0800, Gerald Combs wrote: >>> Andrej Mikus wrote: >>> In file to_str.c I notice function address_to_str_buf that takes buf_len as argument, but does not use it for IPv4 and IPv6 addresses: >>> Unfortunately, there wasn't a mechanism to ensure that the buffer was >>> big enough. I've checked in a change (r20607) that should fix this. It >>> looks like this could potentially affect the ISUP statistics, so I'll >>> add it to the advisory list for 0.99.5. >> I was planning to propose a patch already (attached), so this allowed me >> to see how Subversion handles conflicts :-) >> >> IMO, the function should return an error string instead of cowardly >> bailing out with an empty string. >> >> inet_ntop does the latter by default, so it does not need any additional >> check, just passing buf_len instead of INET6_ADDRSTRLEN. >> >> At the other side I like the check you made into ip_to_str_buf. >> >> My proposal would be to combine the patches and use MAX_IP_STR_LEN, >> and approach below for both IPv4 and IPv6 in address_to_str_buf. >> >>case AT_IPv6: >> +<<< .mine >> +if ( inet_ntop(AF_INET6, addr->data, buf, buf_len) == NULL ) /* Returns >> NULL if no space and does not touch buf */ >> + g_snprintf ( buf, buf_len, "" ); /* Let the >> unexpected value alert user */ >> >> If accepted, I am ready to supply a patch on top of current rev .r20649 >> Let me know pls. >> >> Andrej > > >> ___ >> 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] bootstrapping SVN checkout
On Jan 31, 2007, at 3:07 PM, Andreas Fink wrote: > thanks. It does in fact. Current SVN version hits me size_t in > aircap code (easy to fix, size_t is already there). As far as I know, the airpcap code shouldn't even be built unless you're building on Windows. (If any file is built even if you don't have AirPcap support, it probably should have "airpcap" removed from its name if it's currently there) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] bootstrapping SVN checkout
thanks. It does in fact. Current SVN version hits me size_t in aircap code (easy to fix, size_t is already there). Hi, ./autogen.sh && ./configure && make usually does the trick. Thanx, Jaap On Wed, 31 Jan 2007, Andreas Fink wrote: Hello, I've just done a SVN checkout of the sources into a new directory. I have troubles to "bootstrap" this version as there is no "configure" file. So I run automake (version 1.6.3 is installed) and I get: andreas10:~/development/ws/wireshark afink$ automake configure.in:17: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:17: probably because aclocal.m4 is missing... configure.in:17: You should run aclocal to create this file, then configure.in:17: run automake again. configure.in: required file `./mkinstalldirs' not found configure.in: required file `./missing' not found configure.in:1348: required file `./config.h.in' not found Makefile.am: required file `./depcomp' not found /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in . ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --- Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --- ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] U3 questions/remarks
Sorry, let me clarify my preference. I don't mean for the binary executable itself to include the version, but rather the desktop and menu shortcuts would be sufficient enough for me. On UN*X, I guess if there are any symbolic links to the binary, then that might also be useful as well. The situation is a little more confusing for us (me) because I build customized versions of Wireshark and differentiate it from the off-the-shelf version by appending a suffix to the version via VERSION_EXTRA in config.nmake. Anyway, to know that the actual customized version has been installed rather than the off-the-shelf version, it would help us (me especially) to have the shortcuts named as "Wireshark-VERSION_MAJOR.VERSION_MINOR.VERSION.MICRO.VERSION_EXTRA", rather than simply "Wireshark". Not a big deal though; I'm used to it the way it is, but if others are also interested, then perhaps it could be changed. Thanks, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris Sent: Wednesday, January 31, 2007 1:46 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] U3 questions/remarks Maynard, Chris wrote: > Just one comment about the name: Personally, I prefer the version as > part of the program name, not just for U3, but I would prefer it for all > installs actually. I would strongly prefer it *NOT* be part of the file name (i.e., *NOT* part of the last component of the path name), at least on UN*X, as I tend to run Wireshark from the command line. If that's not what "part of the program name" means (i.e., if it's still "wireshark" on UN*X), that's OK. I'd be willing to put up with it being part of the file name if it's Windows-only, although there might be Windows users who would find that inconvenient - especially for tshark users, as tshark is *intended* to be run from the command line or in a script. Scripts are another place where the program has to be invokable with the same name from release to release. - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] U3 questions/remarks
Guy Harris wrote: > Maynard, Chris wrote: > >> Just one comment about the name: Personally, I prefer the version as >> part of the program name, not just for U3, but I would prefer it for all >> installs actually. >> > > I would strongly prefer it *NOT* be part of the file name (i.e., *NOT* > part of the last component of the path name), at least on UN*X, as I > tend to run Wireshark from the command line. > > If that's not what "part of the program name" means (i.e., if it's still > "wireshark" on UN*X), that's OK. > > I'd be willing to put up with it being part of the file name if it's > Windows-only, although there might be Windows users who would find that > inconvenient - especially for tshark users, as tshark is *intended* to > be run from the command line or in a script. Scripts are another place > where the program has to be invokable with the same name from release to > release. > Missunderstanding. This is about how the name is displayed on the screen (especially the U3 Launchpad - you might remember the subject), not about the real file name to start the program. The file name will remain wireshark.exe. To Chris: Spreading the version number all over the GUI is NOT recommended by ALL Human Interface Guidelines I know of (GNOME, KDE, Win32). Being the only U3 program that displays the version in the U3 Launchpad (BTW: this is somewhat "similiar" to the Windows StartMenu), makes me think if it's a good idea. Reading the version number over and over again from the places you've mentioned is really a dump way to handle this. I would recommend to can get that version number from the uninstall registry setting: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Wireshark\DisplayVersion AFAIK, if you have the required rights, you could even read these registry info remotely. I've never done that myself, so can't give you more help on this. BTW: One of the next releases will hopefully contain an automatic updater, so if a new version is available it will ask you if you want to install it (like Firefox does it already today). If that's available, you don't even need to check the versions manually. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] bootstrapping SVN checkout
Hi, ./autogen.sh && ./configure && make usually does the trick. Thanx, Jaap On Wed, 31 Jan 2007, Andreas Fink wrote: > Hello, > > I've just done a SVN checkout of the sources into a new directory. > I have troubles to "bootstrap" this version as there is no > "configure" file. > So I run automake (version 1.6.3 is installed) and I get: > > andreas10:~/development/ws/wireshark afink$ automake > configure.in:17: no proper implementation of AM_INIT_AUTOMAKE was found, > configure.in:17: probably because aclocal.m4 is missing... > configure.in:17: You should run aclocal to create this file, then > configure.in:17: run automake again. > configure.in: required file `./mkinstalldirs' not found > configure.in: required file `./missing' not found > configure.in:1348: required file `./config.h.in' not found > Makefile.am: required file `./depcomp' not found > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in >. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] bootstrapping SVN checkout
Hello, I've just done a SVN checkout of the sources into a new directory. I have troubles to "bootstrap" this version as there is no "configure" file. So I run automake (version 1.6.3 is installed) and I get: andreas10:~/development/ws/wireshark afink$ automake configure.in:17: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:17: probably because aclocal.m4 is missing... configure.in:17: You should run aclocal to create this file, then configure.in:17: run automake again. configure.in: required file `./mkinstalldirs' not found configure.in: required file `./missing' not found configure.in:1348: required file `./config.h.in' not found Makefile.am: required file `./depcomp' not found /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL configure.in:1335: required file `./ltmain.sh' not found ... and so forth anyone have a hint to get started on the SVN? compilation of the normal tar.gz files works usually (besides all the bugs which have been fixed in the meantime) Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --- Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --- ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] packet statistics screen
My suggestion would be tshark -z io,stat,60 -q -r capturefile and then sort accordingly. I am new here, but I feel that this type of question is perhaps better for user list rather than dev. Andrej On Wed, 31.Jan.07 12:12:05 -0500, Aamer Akhter wrote: > Hello, > > I'm looking at the ethereal screen in Statistics->Summary and was > wondering if there is a way to calculate the highest pps and bitrate > within a 1 min window. Right now, the stats seem to be over the entire > length of the file... > > Any other tools that might do this? > > -- > Aamer Akhter / [EMAIL PROTECTED] > ___ > 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] Is anyone working/planning ANSI C12.22
On Jan 31, 2007, at 1:34 PM, [EMAIL PROTECTED] wrote: > Is anyone working on or planning a ANSI C12.22 dissector? C12.22 is > the > designation of a new standard that is being developed to allow the > transport of ANSI C12.19 table data over networked connections. > > If not, I'd like to get it on the wish list. The closest things we have to a wish list are 1) the wish list on the Wireshark Wiki, at http://wiki.wireshark.org/WishList and 2) the bug database, at http://bugs.wireshark.org/ where one can file a "bug" of severity "Enhancement". Note, however, that neither of those guarantee that it will be put on any schedule. By and large, dissectors are written by the people who need them, so you might have to wait until somebody who needs that dissector implements it. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Is anyone working/planning ANSI C12.22
Hi folks, Is anyone working on or planning a ANSI C12.22 dissector? C12.22 is the designation of a new standard that is being developed to allow the transport of ANSI C12.19 table data over networked connections. If not, I'd like to get it on the wish list. Thanx, ~Jim ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] New menu items to copy packet data
On Wed, Jan 31, 2007 at 09:14:24AM -, Douglas Pratley wrote: > Ok, I've attached the text as well. > > I must have done something odd with tar and gzip (you can probably > tell that I'm more familiar with Windows than UNIX tools). Will be > more cautious next time... The attachment came across fine this time. I've committed your changes to the xml document and the two png files as SVN revision 20654. Thanks! Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Multiple pdus atop TCP -- a lie in README.developer?
On Jan 31, 2007, at 12:02 PM, Richard van der Hoff wrote: > Sorry - I meant that my pdu reassembly needs to work over myriad other > protocols too (my pdus don't align with UDP pdus). Then 1) have a dissector for a single one of your PDUs; 2) use that dissector with tcp_dissect_pdus() when dissecting your protocol over TCP; 3) write your own reassembly code for other protocols and call your single-PDU dissector from that code. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] packet statistics screen
On Wed, Jan 31, 2007 at 12:12:05PM -0500, Aamer Akhter wrote: > I'm looking at the ethereal screen in Statistics->Summary and was > wondering if there is a way to calculate the highest pps and bitrate > within a 1 min window. Right now, the stats seem to be over the entire > length of the file... You can do it with Wireshark. First, apply a display filter matching what you want to include. If you want to include the first 60 seconds of a capture (or 60 seconds after a time reference mark), then use this filter: frame.time_relative <= 60 Then hit enter or click apply and go back to the statistics->summary. There will be a second column for statistics on the displayed packets only. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Multiple pdus atop TCP -- a lie in README.developer?
Anders Broman wrote: >> (I don't want to use tcp_dissect_pdus as this protocol can run over a > > You can solve that by having a separate entry for TCP and call the main > dissector from there. (See SIP, DIAMETER etc). Sorry - I meant that my pdu reassembly needs to work over myriad other protocols too (my pdus don't align with UDP pdus). Thanks though, Richard -- Richard van der Hoff <[EMAIL PROTECTED]> Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Multiple pdus atop TCP -- a lie in README.developer?
>(I don't want to use tcp_dissect_pdus as this protocol can run over a http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Multiple pdus atop TCP -- a lie in README.developer?
Hi, I'm trying to write a dissector for a protocol which consists of a series of small (160 bytes or so) PDUs, over TCP. That obviously means that PDUs can span TCP segment boundaries, and each TCP segment can contain several PDUs. README.developer (section 2.7.2) implies that I can just dissect one PDU at a time, update pinfo->desegment_offset and pinfo->desegment_len, and the TCP dissector will call my dissector for each PDU: "Wireshark allows dissectors to process PDUs in an idempotent way--dissectors only need to consider one PDU at a time" However, when I do this, only the first PDU in each TCP segment is dissected. Obviously, I can work around it by looping over the entire segment, but I'm curious - is what README.developer says just a complete lie? Am I doing something wrong? (I don't want to use tcp_dissect_pdus as this protocol can run over a myriad other protocols than TCP.) Thanks, -- Richard van der Hoff <[EMAIL PROTECTED]> Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] New dissector - FMP
Hello, Please consider for checkin the following new dissectors, for the FMP protocol. FMP (File Mapping Protocol) is the network protocol basis for EMC's HighRoad (MPFS) technology. Highroad is used to allow multiple clients to share access to NAS-shared files while allowing clients to directly access data volumes (via, for example, Fibre Channel or iSCSI). EMC currently uses this technology in our Celerra NAS servers, and we're currently in the process of open sourcing portions of the technology. FMP actually consists of two ONC/RPC-based protocols - the core FMP protocol, and FMP/Notify. The latter is used as an asynchronous callback to inform clients of status changes, such as lock revocation. We'd like to offer these dissectors to Wireshark users for help in debugging or otherwise troubleshooting MPFS-related problems. There are still a few minor changes that need to be made (i.e. a handful of fields that aren't decoded) but the dissector is overall fairly complete and very usable. Let me know if there are questions or feedback, or otherwise if other info is needed (like sample captures, which I don't want to send out to the mailing list). Thanks, Ian Schorr EMC Corporation packet-fmp.tar.gz Description: GNU Zip compressed data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Bogus length reported for reassembled UDP packets
Hi, Wireshark complains about bogus udp length when processing last fragment of UDP data. It compares length field from UDP header with payload size of last fragment. Attached is my attempt to fix this by referring to tvp->length instead of pinfo->iplen - pinfo->iphdrlen. Not entirely sure if it is the best way, but appears to work for me. Attached is also sample capture file. With reference to my earlier message, do not worry about output above UDP layer. http://www.wireshark.org/lists/wireshark-dev/200701/msg00265.html Regards Andrej wccpfrag.pcap Description: Binary data udplen.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] U3 questions/remarks
Maynard, Chris wrote: > Just one comment about the name: Personally, I prefer the version as > part of the program name, not just for U3, but I would prefer it for all > installs actually. I would strongly prefer it *NOT* be part of the file name (i.e., *NOT* part of the last component of the path name), at least on UN*X, as I tend to run Wireshark from the command line. If that's not what "part of the program name" means (i.e., if it's still "wireshark" on UN*X), that's OK. I'd be willing to put up with it being part of the file name if it's Windows-only, although there might be Windows users who would find that inconvenient - especially for tshark users, as tshark is *intended* to be run from the command line or in a script. Scripts are another place where the program has to be invokable with the same name from release to release. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] User can select dissector based on packet matching display filter
Douglas Pratley wrote: > b) Adds functionality analogous to dissector tables, but instead of > directing by field values, there is a list of display-filter / > sub-dissector pairs. A sub-dissector is called if the display filter is > matched by the packet. Display filter values are available only if a protocol tree is being constructed. This means that, if this mechanism is enabled, you have to force the construction of a protocol tree; presumably, if it's *not* enabled, construction of a protocol tree is *not* forced (forcing the construction of a protocol tree if the protocol tree won't be used imposes a significant performance cost). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] What about a universal XML parsing dissector
On 1/30/07, Guy Harris <[EMAIL PROTECTED]> wrote: > > On Jan 30, 2007, at 11:07 AM, John R. wrote: > > > Sequence, iteration, algorithms, > > etc. are more naturally handled in code than XML document (that didn't > > stop the abomination that is XSLT though ;-) ). > > Nor did it stop NetPDL: > Another approach to the same problem, here's a paper that describes a language without all the <> noise: http://www.cs.cmu.edu/~dbrumley/pubs/gapa-ndss-07.pdf The packet formats are described in BNF to the degree possible, which is probably more natural for most computer science types. It has a built-in programming language which would be easier than programming in an XML programming language. It would be nice if there were some middle ground between building in a toy language and describing packets mostly in code and hand-built tables. What one wants I think is the equivalent of Lex and Yacc but less slanted towards parsing programming languages. You would describe 90% of the protocol in BNF, and then write the remaining glue logic in C or some other language. -- John. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] U3 questions/remarks
Just one comment about the name: Personally, I prefer the version as part of the program name, not just for U3, but I would prefer it for all installs actually. Wireshark gets installed on quite a few of our servers and the only way to know which version has been installed, and thus which ones need upgrading, is either to start the program and read the version from "Help -> About Wireshark", or on Windows at least, to either view the program in "Add/Remove Programs" or look in "C:\Program Files\Wireshark\plugins\" for the version. None of these methods are particularly convenient though, especially when having to deal with multiple servers, as we do. - Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf Lamping Sent: Tuesday, January 30, 2007 11:30 PM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] U3 questions/remarks Hi List! As I'm a proud owner of an U3 stick now, I can test this ;-) Some minor things I've noticed: - All programs I've installed on the stick (OpenOffice, Firefox, Winamp, ) either shows only the program name "Winamp", or the suffix "for U3" like in "Mozilla Firefox for U3". Wireshark shows "Wireshark 0.99.5pre2". Should the version number be replaced by "for U3"? - After installation, WS was in the "more programs" area (there are only space for 9 programs - and I've installed more) - but it doesn't showed an icon! Other programs didn't had such problems. Has this something to do with the icon problem recently mentioned on the list? Interestingly, after I've moved WS up in the list (into the "normal" area) the icon is shown now. Any ideas? - if running under U3, this should be mentioned in the About box (appended to "Running on ...")? WinPcap: - if WinPcap was manually uninstalled (without a reboot in the meantime), starting WS from U3 won't ask for a new WinPcap install (the detection logic might better use the uninstall string from the registry) However, it's working just fine (keep up the good work Graeme :-)! Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] packet statistics screen
Hello, I'm looking at the ethereal screen in Statistics->Summary and was wondering if there is a way to calculate the highest pps and bitrate within a 1 min window. Right now, the stats seem to be over the entire length of the file... Any other tools that might do this? -- Aamer Akhter / [EMAIL PROTECTED] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] col_add_fstr doesn't _add_ string to column
Hi, col_append_fstr() could be used. cheers, Amit Wiese, Hendrik wrote: >Hi list, > >I've got another problem here developing a dissector: why doesn't >col_add_fstr() really _add_ (append) a string to the selected column, >but clears the column and fills it with a new one? > >I've got some TPKT encapsulated messages here inside a single TCP packet >and I'd like to get all of them displayed in the COL_INFO column one >after another. Fetching the messages out of the TPKT encapsulation >already works but only the last fetched message is displayed in the >column. So I think col_add_fstr erases the column before adding the >string. > >Is there any kind of 'Wireshark API' function reference somewhere on the >web? How do I really _append_ a text to a column? > >Thanks alot > >regards, >Hendrik >___ >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] col_add_fstr doesn't _add_ string to column
Hi, Sure: http://anonsvn.wireshark.org/wireshark/trunk/epan/column-utils.h Thanx, Jaap On Wed, 31 Jan 2007, Wiese, Hendrik wrote: > Hi list, > > I've got another problem here developing a dissector: why doesn't > col_add_fstr() really _add_ (append) a string to the selected column, > but clears the column and fills it with a new one? > > I've got some TPKT encapsulated messages here inside a single TCP packet > and I'd like to get all of them displayed in the COL_INFO column one > after another. Fetching the messages out of the TPKT encapsulation > already works but only the last fetched message is displayed in the > column. So I think col_add_fstr erases the column before adding the > string. > > Is there any kind of 'Wireshark API' function reference somewhere on the > web? How do I really _append_ a text to a column? > > Thanks alot > > regards, > Hendrik > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] col_add_fstr doesn't _add_ string to column
Hi list, I've got another problem here developing a dissector: why doesn't col_add_fstr() really _add_ (append) a string to the selected column, but clears the column and fills it with a new one? I've got some TPKT encapsulated messages here inside a single TCP packet and I'd like to get all of them displayed in the COL_INFO column one after another. Fetching the messages out of the TPKT encapsulation already works but only the last fetched message is displayed in the column. So I think col_add_fstr erases the column before adding the string. Is there any kind of 'Wireshark API' function reference somewhere on the web? How do I really _append_ a text to a column? Thanks alot regards, Hendrik ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [patch] address_to_str_buf not checking available buffer length
Accepted or not, I needed to do something to get my working copy compiled. Attached is the patch if you like to use it. Thanks Andrej On Wed, 31.Jan.07 12:29:30 +0100, Andrej Mikus wrote: > On Mon, 29.Jan.07 12:49:00 -0800, Gerald Combs wrote: > > Andrej Mikus wrote: > > > > > In file to_str.c I notice function address_to_str_buf that takes buf_len > > > as argument, but does not use it for IPv4 and IPv6 addresses: > > > > > Unfortunately, there wasn't a mechanism to ensure that the buffer was > > big enough. I've checked in a change (r20607) that should fix this. It > > looks like this could potentially affect the ISUP statistics, so I'll > > add it to the advisory list for 0.99.5. > > I was planning to propose a patch already (attached), so this allowed me > to see how Subversion handles conflicts :-) > > IMO, the function should return an error string instead of cowardly > bailing out with an empty string. > > inet_ntop does the latter by default, so it does not need any additional > check, just passing buf_len instead of INET6_ADDRSTRLEN. > > At the other side I like the check you made into ip_to_str_buf. > > My proposal would be to combine the patches and use MAX_IP_STR_LEN, > and approach below for both IPv4 and IPv6 in address_to_str_buf. > >case AT_IPv6: > +<<< .mine > +if ( inet_ntop(AF_INET6, addr->data, buf, buf_len) == NULL ) /* Returns > NULL if no space and does not touch buf */ > + g_snprintf ( buf, buf_len, "" ); /* Let the > unexpected value alert user */ > > If accepted, I am ready to supply a patch on top of current rev .r20649 > Let me know pls. > > Andrej > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev my_patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Fix bugs in IuUP
Hello While I reading source code of IuUP dissector, I notice some obvious bugs inside the code. One is a missing assignment that causes the following "if (iuup_circuit)" block to never execute. Another is wrong field names. Althoug both won't show up in final result (for the first bug, the call to g_hash_table_insert several lines later will do the right thing anyway; for the second bug, there is no services utilizing more than 3 subflows), I think it is better to have them fixed. Patch is in the attachment. Best regards Kriang Lerdsuwanakij patch-iuup.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] address_to_str_buf not checking available buffer length
On Mon, 29.Jan.07 12:49:00 -0800, Gerald Combs wrote: > Andrej Mikus wrote: > > > In file to_str.c I notice function address_to_str_buf that takes buf_len > > as argument, but does not use it for IPv4 and IPv6 addresses: > > > Unfortunately, there wasn't a mechanism to ensure that the buffer was > big enough. I've checked in a change (r20607) that should fix this. It > looks like this could potentially affect the ISUP statistics, so I'll > add it to the advisory list for 0.99.5. I was planning to propose a patch already (attached), so this allowed me to see how Subversion handles conflicts :-) IMO, the function should return an error string instead of cowardly bailing out with an empty string. inet_ntop does the latter by default, so it does not need any additional check, just passing buf_len instead of INET6_ADDRSTRLEN. At the other side I like the check you made into ip_to_str_buf. My proposal would be to combine the patches and use MAX_IP_STR_LEN, and approach below for both IPv4 and IPv6 in address_to_str_buf. case AT_IPv6: +<<< .mine +if ( inet_ntop(AF_INET6, addr->data, buf, buf_len) == NULL ) /* Returns NULL if no space and does not touch buf */ + g_snprintf ( buf, buf_len, "" ); /* Let the unexpected value alert user */ If accepted, I am ready to supply a patch on top of current rev .r20649 Let me know pls. Andrej to_str.patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Use ethereal as a proprietary protocol parser; no ethernet/IP decoding
Tom will be distributing the code since his company will be selling the communications systems to the utility industry. I still don't see a problem though, it just means the utility company will be entitled to the source code, and have to be told they are entitled to it. If the proprietary protocol belongs to the utility that is not a problem, Tom only needs to give the source to the utility not the whole world. If the protocol is 'secret' to Tom's company then there is a problem because the utility is still entitled to the source and they can then give it free to the world if they want. Hal From: Jaap Keuter <[EMAIL PROTECTED]> Reply-To: Developer support list for Wireshark To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Use ethereal as a proprietary protocol parser; no ethernet/IP decoding Date: Wed, 31 Jan 2007 12:05:47 +0100 (CET) Hi, You surely can make a dissector for a proprietary protocol, you just can't distribute it without source code. From that sourcecode one can easily write a protocol spec, or at least the static part of it. So don't distribute it and you're fine. The keyword here is distribution. Thanx, Jaap On Wed, 31 Jan 2007, Abhik Sarkar wrote: > Hi, > > I don't know if I am straying from the core of the topic here, but > this particular topic has always foxed me. > > If a protocol is proprietery (in the sense that the specifications are > not open and they might be released only under NDA), then wouldn't > writing a dissector for it create legal problems one way or the other. > If the dissector was written and made available to the world (as the > GPL license would require) then the specifications would essentially > be made public, which is not desired. On the other hand, if a company > made a dissector for its own use for such a protocol, but did not make > it public, then it would be a violation of the GPL! > > Tom, I guess the answer to your question would largely depend on what > you mean by "proprietery". However, to dissect the protocol, I think > some programming is needed, it might not be possible using > configuration only. > > Best regards, > Abhik. > > On 1/31/07, Hal Lander <[EMAIL PROTECTED]> wrote: > > Hi Tom, > > > > I am just starting to learn how to use Wireshark myself (it used to be > > Ethereal),messing about with a protocol sent within TCP. > > > > You should probably start by downloading Wireshark and running it on your > > network to see what it does. It will capture and decode the TCP which it > > knows about, but will not understand your proprietary protoco - though you > > will see the bytesl. If you write a new dissector plugin for your protocol > > Wireshark will then be able to decode it as well as the TCP. > > > > One problem will be that you seem to be wanting to run from log files, which > > are probably not in a format that Wireshark can read. > > > > So, yes I would use Wireshark but I would try and capture the network data > > using packages that already exist and which save a format that Wireshark can > > already read. > > > > Hal > > > > > > >From: Tom McLaughlin <[EMAIL PROTECTED]> > > >Reply-To: Developer support list for Wireshark > > > > > >To: wireshark-dev@wireshark.org > > >Subject: [Wireshark-dev] Use ethereal as a proprietary protocol parser;no > > >ethernet/IP decoding > > >Date: Tue, 30 Jan 2007 15:09:09 -0800 (PST) > > > > > >Hello, > > >I work for a company that build proprietary communication systems for the > > >utility industry. We have a proprietary communcation protocol that can be > > >wrapped in several standard protocols. I would like to build a log parser > > >that looks like Ethereal for our protocol if possible. This would not be a > > >new dissector from what I understand for other protocols wrapped in > > >Ethernet or IP. > > > > > >Basically, get Ethereal to read in a file with a bunch of hex strings, > > >somewhere define what the fields are, and use the Ethereal gui. > > > > > >Possible? Thoughts? > > > > > >Or would it be better to just start from scratch? > > > > > >Tom > > >___ > > >Wireshark-dev mailing list > > >Wireshark-dev@wireshark.org > > >http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > _ > > Valentine�s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping > > http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline > > > > > > > > ___ > > 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
Re: [Wireshark-dev] Use ethereal as a proprietary protocol parser; no ethernet/IP decoding
Hi, You surely can make a dissector for a proprietary protocol, you just can't distribute it without source code. From that sourcecode one can easily write a protocol spec, or at least the static part of it. So don't distribute it and you're fine. The keyword here is distribution. Thanx, Jaap On Wed, 31 Jan 2007, Abhik Sarkar wrote: > Hi, > > I don't know if I am straying from the core of the topic here, but > this particular topic has always foxed me. > > If a protocol is proprietery (in the sense that the specifications are > not open and they might be released only under NDA), then wouldn't > writing a dissector for it create legal problems one way or the other. > If the dissector was written and made available to the world (as the > GPL license would require) then the specifications would essentially > be made public, which is not desired. On the other hand, if a company > made a dissector for its own use for such a protocol, but did not make > it public, then it would be a violation of the GPL! > > Tom, I guess the answer to your question would largely depend on what > you mean by "proprietery". However, to dissect the protocol, I think > some programming is needed, it might not be possible using > configuration only. > > Best regards, > Abhik. > > On 1/31/07, Hal Lander <[EMAIL PROTECTED]> wrote: > > Hi Tom, > > > > I am just starting to learn how to use Wireshark myself (it used to be > > Ethereal),messing about with a protocol sent within TCP. > > > > You should probably start by downloading Wireshark and running it on your > > network to see what it does. It will capture and decode the TCP which it > > knows about, but will not understand your proprietary protoco - though you > > will see the bytesl. If you write a new dissector plugin for your protocol > > Wireshark will then be able to decode it as well as the TCP. > > > > One problem will be that you seem to be wanting to run from log files, which > > are probably not in a format that Wireshark can read. > > > > So, yes I would use Wireshark but I would try and capture the network data > > using packages that already exist and which save a format that Wireshark can > > already read. > > > > Hal > > > > > > >From: Tom McLaughlin <[EMAIL PROTECTED]> > > >Reply-To: Developer support list for Wireshark > > > > > >To: wireshark-dev@wireshark.org > > >Subject: [Wireshark-dev] Use ethereal as a proprietary protocol parser;no > > >ethernet/IP decoding > > >Date: Tue, 30 Jan 2007 15:09:09 -0800 (PST) > > > > > >Hello, > > >I work for a company that build proprietary communication systems for the > > >utility industry. We have a proprietary communcation protocol that can be > > >wrapped in several standard protocols. I would like to build a log parser > > >that looks like Ethereal for our protocol if possible. This would not be a > > >new dissector from what I understand for other protocols wrapped in > > >Ethernet or IP. > > > > > >Basically, get Ethereal to read in a file with a bunch of hex strings, > > >somewhere define what the fields are, and use the Ethereal gui. > > > > > >Possible? Thoughts? > > > > > >Or would it be better to just start from scratch? > > > > > >Tom > > >___ > > >Wireshark-dev mailing list > > >Wireshark-dev@wireshark.org > > >http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > _ > > Valentine???s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping > > http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline > > > > > > > > ___ > > 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] Use ethereal as a proprietary protocol parser; no ethernet/IP decoding
Hi, I don't know if I am straying from the core of the topic here, but this particular topic has always foxed me. If a protocol is proprietery (in the sense that the specifications are not open and they might be released only under NDA), then wouldn't writing a dissector for it create legal problems one way or the other. If the dissector was written and made available to the world (as the GPL license would require) then the specifications would essentially be made public, which is not desired. On the other hand, if a company made a dissector for its own use for such a protocol, but did not make it public, then it would be a violation of the GPL! Tom, I guess the answer to your question would largely depend on what you mean by "proprietery". However, to dissect the protocol, I think some programming is needed, it might not be possible using configuration only. Best regards, Abhik. On 1/31/07, Hal Lander <[EMAIL PROTECTED]> wrote: > Hi Tom, > > I am just starting to learn how to use Wireshark myself (it used to be > Ethereal),messing about with a protocol sent within TCP. > > You should probably start by downloading Wireshark and running it on your > network to see what it does. It will capture and decode the TCP which it > knows about, but will not understand your proprietary protoco - though you > will see the bytesl. If you write a new dissector plugin for your protocol > Wireshark will then be able to decode it as well as the TCP. > > One problem will be that you seem to be wanting to run from log files, which > are probably not in a format that Wireshark can read. > > So, yes I would use Wireshark but I would try and capture the network data > using packages that already exist and which save a format that Wireshark can > already read. > > Hal > > > >From: Tom McLaughlin <[EMAIL PROTECTED]> > >Reply-To: Developer support list for Wireshark > > > >To: wireshark-dev@wireshark.org > >Subject: [Wireshark-dev] Use ethereal as a proprietary protocol parser;no > >ethernet/IP decoding > >Date: Tue, 30 Jan 2007 15:09:09 -0800 (PST) > > > >Hello, > >I work for a company that build proprietary communication systems for the > >utility industry. We have a proprietary communcation protocol that can be > >wrapped in several standard protocols. I would like to build a log parser > >that looks like Ethereal for our protocol if possible. This would not be a > >new dissector from what I understand for other protocols wrapped in > >Ethernet or IP. > > > >Basically, get Ethereal to read in a file with a bunch of hex strings, > >somewhere define what the fields are, and use the Ethereal gui. > > > >Possible? Thoughts? > > > >Or would it be better to just start from scratch? > > > >Tom > >___ > >Wireshark-dev mailing list > >Wireshark-dev@wireshark.org > >http://www.wireshark.org/mailman/listinfo/wireshark-dev > > _ > Valentine�s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping > http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline > > > > ___ > 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] New menu items to copy packet data
> > Stephen Fisher wrote: > > On Mon, Jan 29, 2007 at 10:22:15AM -, Douglas Pratley wrote: > > > >> Are there any other encodings / decodings it would be worth having > >> available (uuencode? zip?). This might be better done as a full > >> "Select bytes and decode / encode" feature rather than > something in a > >> copy menu. > >> > > Good point. For viewing encoded e-mail contents, uudecode > support may > > be useful, though it's not very popular these days as far > as I can tell. > > We could go the whole way and even add viewers for images contained > > within capture files. I'm not sure how useful this would be? > > > > Every program attempts to expand until it can read mail ;-))) ...and browse the web, these days. Wouldn't take much to integrate an HTML display engine into Wireshark, surely ;-) > > Ok, serious again, this is more of a question about a > general way to copy/export/display "generic objects". Why not > be able to copy/export/display a picture from a HTTP capture, > or a HTML page, or ... > > Other analyzers will provide you with a list of files, > derived from the captured HTTP packets, with an option to > display/export it. > > That reminds me of the media dissector which already gets in > that direction - we are getting more and more into the > application layer - and I like it :-) Given time, I'd tackle it like this, in three layers. 1) Provide the user with ways to select bytes of interest: a) User can select exactly the bytes they want [New feature] b) User can select the bytes represented by a line in the packet details pane; dissectors can be "helpful" here, by breaking packets down appropriately [Existing feature] c) Specialist analysis for content-rich formats (mail, HTTP); I don't know what is already in Wireshark. These could provide lists of embedded data. 2) Ability to apply decodings / encodings to bytes of interest; I think this should _not_ be built into the dissectors, as you then have to repeat the code, or find you can't actually apply it to the exact set of bytes that you want. A "reflective" architecture where encodings are registered would make sense - easy to generate lists. 3) Ability to move encoded bytes (encoding may have been a NOOP) to file, clipboard, viewers (again, registered viewers). Each layer should be available, and hence re-usable, from within the whole UI codebase, so defining decent interfaces would be important. If this makes sense (some might think it over-engineered), I'll put together a wish-list entry, and also put it forward as a suggestion in our internal process. Unfortunately, I'm not free to tackle something this large off my own bat in work time (and I'm organising my upcoming wedding in my free time, so am not my own boss there either!). It's possible that I'll get a chance to work on it later, or someone else might like the idea enough to pick it up and run with it. Cheers Doug This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies. Detica Limited is registered in England under No: 1337451. Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Use ethereal as a proprietary protocol parser; no ethernet/IP decoding
Hi Tom, I am just starting to learn how to use Wireshark myself (it used to be Ethereal),messing about with a protocol sent within TCP. You should probably start by downloading Wireshark and running it on your network to see what it does. It will capture and decode the TCP which it knows about, but will not understand your proprietary protoco - though you will see the bytesl. If you write a new dissector plugin for your protocol Wireshark will then be able to decode it as well as the TCP. One problem will be that you seem to be wanting to run from log files, which are probably not in a format that Wireshark can read. So, yes I would use Wireshark but I would try and capture the network data using packages that already exist and which save a format that Wireshark can already read. Hal From: Tom McLaughlin <[EMAIL PROTECTED]> Reply-To: Developer support list for Wireshark To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] Use ethereal as a proprietary protocol parser;no ethernet/IP decoding Date: Tue, 30 Jan 2007 15:09:09 -0800 (PST) Hello, I work for a company that build proprietary communication systems for the utility industry. We have a proprietary communcation protocol that can be wrapped in several standard protocols. I would like to build a log parser that looks like Ethereal for our protocol if possible. This would not be a new dissector from what I understand for other protocols wrapped in Ethernet or IP. Basically, get Ethereal to read in a file with a bunch of hex strings, somewhere define what the fields are, and use the Ethereal gui. Possible? Thoughts? Or would it be better to just start from scratch? Tom ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Problem with uint preference
Hi Jeff, That did the trick :-) I had seen the defines for the various bases so when the function asked for a base I just plugged BASE_DEC in. The old documentation did misslead me but I could kick myself for not plugging in the obvious 10 ! Thanks for clearing that up. Hal From: Jeff Morriss <[EMAIL PROTECTED]> Reply-To: Developer support list for Wireshark To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Problem with uint preference Date: Wed, 31 Jan 2007 10:05:41 +0800 Hal Lander wrote: > I registered a boolean preference and it worked. > However, when I try and follow the same process with a uint it fails > when I try and edit the preference and 'apply' the change. The message I > get is; > > "The value for "xxTitle" isn't a valid number." [...] > The code I am using is given below, along with the edit I tried on > preferences. > > Should I be editing the preferences file by hand to add in the variable. No, there should never be any need to edit the preferences file by hand. > Any ideas what I am doing wrong? [...] > static gboolean prefTick; > static guint prefVer; > >prefTick=TRUE; >prefVer=123; > > prefs_register_bool_preference(foo_module,"tick","TickTitle","TickDescription",&prefTick); > prefs_register_uint_preference(foo_module,"xx","xxTitle","xxDescription",BASE_DEC,&prefVer); The 'base' field in 'prefs_register_uint_preference()' is the base used by 'strtoul()' when converting the string "123" into an unsigned integer. Don't use BASE_DEC (whose value is 1) here but rather 0 or 10 if you want to input a decimal number. I just checked in a change to README.developer to explain what this parameter should be. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ FREE online classifieds from Windows Live Expo buy and sell with people you know http://clk.atdmt.com/MSN/go/msnnkwex001001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] New menu items to copy packet data
Ok, I've attached the text as well. I must have done something odd with tar and gzip (you can probably tell that I'm more familiar with Windows than UNIX tools). Will be more cautious next time... Cheers Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Fisher Sent: 30 January 2007 19:28 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [PATCH] New menu items to copy packet data On Mon, Jan 29, 2007 at 10:04:20AM -, Douglas Pratley wrote: > Try this - the tar / gzip tools I have on Windows seem to be a bit > tempermental, which is why I have been avoiding them, but if Outlook > is going to mangle the files... I got the images but not the patch this time ;). The documentation patch file is just a tar of the images again. Go ahead and send the documentation patch within an e-mail's body. Thanks, Steve Index: docbook/wsug_src/WSUG_chapter_work.xml === --- docbook/wsug_src/WSUG_chapter_work.xml (revision 20523) +++ docbook/wsug_src/WSUG_chapter_work.xml (working copy) @@ -166,7 +166,87 @@ + + Copy/ Summary (Text) + - + + + Copy the summary fields as displayed to the clipboard, as tab-separated text. + + + + + Copy/ Summary (CSV) + - + + + Copy the summary fields as displayed to the clipboard, as comma-separated text. + + + + + Copy/ Hex and Text + - + + + Copy the packet bytes to the clipboard in hexdump-like format; similar to the Packet Bytes Pane + "Copy/ All Information" command. + + + + + Copy/ Text Only + - + + + Copy the packet bytes to the clipboard as ASCII text; similar to the Packet Bytes Pane + "Copy/ Text Only" command. + + + + + Copy/ Hex Columns + - + + + Copy the packet bytes to the clipboard in hexdump-like format, but without the text portion. + + + + + Copy/ Hex Stream + - + + + Copy the packet bytes to the clipboard as an unpunctuated list of hex digits. + + + + + Copy/ Base64 Stream + - + + + Copy the packet bytes to the clipboard as a Base64 text encoding. + + + + + Copy/ Binary Stream + - + + + Copy the packet bytes to the clipboard as raw binary. The data is stored in the + clipboard as MIME-type "application/octect-stream". + This option is not available in versions of Wireshark built using GTK+ 1.x. + + + - + + + + Decode As... Analyze @@ -225,21 +305,6 @@ - Copy - - - - - Copy the displayed text of the selected field to the system - clipboard. - - - - - - - - - - Expand Subtrees View @@ -275,6 +340,79 @@ + Copy + - + + + Copy the displayed text of the selected field to the system + clipboard. + + + + + Copy Selected Bytes As/ Hex and Text + - + + + Copy the selected packet bytes to the clipboard in hexdump-like format; similar to the Packet Bytes Pane + "Copy/ All Information" command, but copies only the bytes relevant to the selected part of the tree (the bytes selected + in the Packet Bytes Pane). + + + + + Copy Selected Bytes As/ Text Only +
Re: [Wireshark-dev] How do I get my dissector to work in theDisplay Filter
In the function proto_register_foo(void) I register the protocol using the
line;
proto_foo = proto_register_protocol("Top level text for foo","foo", "foo");
I notice you say lineS, am I missing something?
The thing is the dissector is called and the all the other fields are
visible in the 'expressions' dialog so it looks as if the registration
worked, but there is something not quite right.
Thanks for looking at this
Hal
>From: Stephen Fisher <[EMAIL PROTECTED]>
>Reply-To: Developer support list for Wireshark
>
>To: Developer support list for Wireshark
>Subject: Re: [Wireshark-dev] How do I get my dissector to work in
>theDisplay Filter
>Date: Tue, 30 Jan 2007 12:05:57 -0800
>
>On Tue, Jan 30, 2007 at 01:02:33AM -0900, Hal Lander wrote:
>
> > My plugin heuristic dissector foo seems to work fine, except I cannot
> > filter on it. If I type foo in the filter box the box goes pink.
> > However if I type foo.len (one of my fields), the box goes green. If I
> > click the 'Expression...' button I can see my protocol and all the
> > fields I declared.
> >
> > I must be missing some some step registering the protocol, but if I am
> > I don't understand how I can manage to filter on a field. Other
> > plugins seem to let you just type the protocol name and they filter on
> > it, so I should be able to do what I want.
> >
> > Anybody got any clues about what I am doing wrong or missing?
>
>What lines are you using to register the protocol?
>
>
>Steve
>
>___
>Wireshark-dev mailing list
>Wireshark-dev@wireshark.org
>http://www.wireshark.org/mailman/listinfo/wireshark-dev
_
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [REPOST][PATCH] update USB dissector
Hello, On Tue, 2007-01-30 at 12:19 -0800, Guy Harris wrote: > You might want to check to make sure that file (written out in > big-endian format) can be read by your little-endian machine; I've > attached that capture. It works also on my machine. > I modified the code to make the Linux-specific header a "pseudo-header", > so that it doesn't show up in the packet data; The only issue I see is that this way the user can't relate the header fields to the corresponding byte into the captured packet, which is quite useful (especially for debug purpose). That said, this implementation seams a lot better. Thanks for all the great work! Best regards, Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Corso base ASP Gratis - Video con trucchi e segreti per imparare a creare il tuo Sito Web Dinamico con la tecnologia ASP Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5146&d=31-1 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] update wiretap and USB dissector
Hello, On Tue, 2007-01-30 at 13:27 -0800, Guy Harris wrote: > Paolo Abeni wrote: > > This new API should be available > > in the linux kernel starting from version 2.6.21 or 2.6.22. > > but kernel.org only has 2.6.19 as the current version and 2.6.20 as the > upcoming version. Should it just speak of a future kernel release, > without committing to a number, until the new mechanism shows up in a > prepatch? Also, is a patch with the new binary API available somewhere? The patch as been 'accepted' by the maintainer of the Linux USB subsystem (Greg K.H.) and is available here: http://kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-usb/usb-add-binary-api-to-usbmon.patch It should apply to linux 2.6.20-rc6, but it depends on other patches present in the Greg archive. To get the thing working, the easier way should be to apply: http://kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.20-rc6.patch which contains all the stuff maintained by Greg and should apply cleanly to linux 2.6.20-rc6. Due to it's current state, I think that the binary API patch will not be included into linux vanilla 2.6.20 but I hope that it will enter into 2.6.21. I suppose that a generic 'future release' is a more safe guess, but I think/hope that such statement will be outdated soon :-) Best regards, Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Refill s.r.l. - Cartucce compatibili e kit di ricarica per tutti i modelli di stampante. Acquista al telefono o online: consegna in tutta Italia in 48 ore! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5190&d=31-1 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
