[Wireshark-dev] USB
I would like to start playing with the USB dissector in Wireshark. My USB capture hardware will give me complete USB packets, i.e. all of the data on the wire between the SOP and EOP markers. However, I'm not clear on how this fits into the DLT_USB or DLT_USB_LINUX capture types. It seems that even the "raw" DLT_USB is a higher-level view offb USB, above the actual USB packet format on the wire, in that it has complete URBs instead of actual packets like IN, DATA0, SOF, ACK, etc. Given that I have real raw USB packets, any suggestions on what to do to get those into Wireshark? Could the existing USB dissector still be useful or would this entail creating a whole new DLT_* type and dissector? -jim ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] USB
Jim Paris wrote: > Given that I have real raw USB packets, any suggestions on what to do > to get those into Wireshark? Could the existing USB dissector still > be useful or would this entail creating a whole new DLT_* type and > dissector? That would entail creating a new DLT_ type. That would need a new dissector - but if that dissector could construct URBs and hand them to the existing dissector, it wouldn't need a complete new dissector stack. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Regarding Winshark binaries
Hi all,
I hv a question.
Due to some dowloading problems, I am not able to build wireshark
on Windows. So, I hv decided to build WS source in Linux itself.
These are my queries
1) If I build WS, and write my own dissector (as a plugin or build with
source ) in Linux, can the .exe file so genrated be executable in
Windows OR is there any necessity for me to crs-compile??
2)Is there any other tool/library/software , I need to download to
compile(build) in Linux. I hv read the Dev guide. It says no extra
tools
--Thanks
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] Dissector over Ethernet
Hi all, I am looking for a dissector able to decode a specific protocol directly over Ethernet (no IP header). The dissector shall be able to decode the protocol by detecting the MAC destination and one field in the payload. I am totally newbie in "wireshark dissection". Could somebody send me one example of a such type of dissector ? I tried to start from the foo example described in the developper's guide but I am not sure this example is adapted to my needs (dissector over Ethernet). Sincerely, Fabrice This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dissector over Ethernet
Hi Fabrice, How about the ARP (packet-arp.c) dissector? One of the protocols ARP runs directly on is Ethernet. That should give you some ideas. Maybe packet-llc.c too. Hope this helps, Abhik. On 4/3/07, CANDIA, Fabrice <[EMAIL PROTECTED]> wrote: > Hi all, > > I am looking for a dissector able to decode a specific protocol directly over > Ethernet (no IP header). > The dissector shall be able to decode the protocol by detecting the MAC > destination and one field in the payload. > I am totally newbie in "wireshark dissection". > > Could somebody send me one example of a such type of dissector ? > > I tried to start from the foo example described in the developper's guide but > I am not sure this example is adapted to my needs (dissector over Ethernet). > > Sincerely, > > Fabrice > > > This e-mail is intended only for the above addressee. It may contain > privileged information. > If you are not the addressee you must not copy, distribute, disclose or use > any of the information in it. > If you have received it in error please delete it and immediately notify the > sender. > Security Notice: all e-mail, sent to or from this address, may be accessed by > someone other than the recipient, for system management and security reasons. > This access is controlled under Regulation of security reasons. > This access is controlled under Regulation of Investigatory Powers Act 2000, > Lawful Business Practises. > > > ___ > 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] dissector for OpenVPN
I understand. I think there is more than one person with a strong interest in this and I am certainly willing to help since it will provide me with additional debug capability. Bill Guy Harris <[EMAIL PROTECTED]> wrote: On Apr 2, 2007, at 2:27 PM, Bill Fassler wrote: > I opened a bug in bugzilla per Guy Harris' request. If I remember > correctly it is bug number 1463. I was under the impression that > someone on the development team would be assigned and write the > dissector for me. Wireshark isn't run the way commercial software projects tend to be run, with bugs being assigned to a member of the development team officially tasked with fixing the problem; it's more a case of members of the development team picking up items they see when they have time and an interest - Wireshark isn't a day job for many of us. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev - Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta.___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] buildbot failures
Apologies for turning the buildbot red, everyone... I'm working on it... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] USB
On 4/3/07, Jim Paris <[EMAIL PROTECTED]> wrote: > Given that I have real raw USB packets, any suggestions on what to do > to get those into Wireshark? Could the existing USB dissector still > be useful or would this entail creating a whole new DLT_* type and > dissector? To expand on what Guy said about constructing URBs, it's similar to the way that Wireshark can reassemble a TCP stream from individual TCP packets, or the way that fragmented packets are reassembled into full packets for higher-level dissectors. -- - Charles Lepple ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Ulf Lamping wrote: > I'm very pleased to notice that my "call for a warning free" Wireshark > was heard and was being answered ;-) > > The buildbot is now "all green" again, even with the "treat warning as > error" setting in the buildbot makefiles. > I guess I'm not quite up to speed with the state of this project... Am I right in thinking that warnings have only been purged successfully so far for the win32 build? I can't build on linux yet with --warnings-as-errors... Cheers Rich ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] packet-skinny: well formed DialedNumberMessage displayed as malformed.
This patch fixes the display of DialedNumberMessages. Well formed messages were being displayed as malformed, due to incorrect offsets in the packet dissector. Cheers, Alex Roberts Software Engineer CSC Australia, Module 7 Endeavour House, 4th Avenue, Mawson Lakes S.A. 5095 ph: (+618) 83438854 Email: [EMAIL PROTECTED] This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. packet-skinny.c.diff Description: Binary data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dissector over Ethernet
Thanks Abhik, ARP dissector is exactly what I need ! -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Abhik Sarkar Envoyé : mardi 3 avril 2007 14:03 À : Developer support list for Wireshark Objet : Re: [Wireshark-dev] Dissector over Ethernet Hi Fabrice, How about the ARP (packet-arp.c) dissector? One of the protocols ARP runs directly on is Ethernet. That should give you some ideas. Maybe packet-llc.c too. Hope this helps, Abhik. On 4/3/07, CANDIA, Fabrice <[EMAIL PROTECTED]> wrote: > Hi all, > > I am looking for a dissector able to decode a specific protocol directly over > Ethernet (no IP header). > The dissector shall be able to decode the protocol by detecting the MAC > destination and one field in the payload. > I am totally newbie in "wireshark dissection". > > Could somebody send me one example of a such type of dissector ? > > I tried to start from the foo example described in the developper's guide but > I am not sure this example is adapted to my needs (dissector over Ethernet). > > Sincerely, > > Fabrice > > > This e-mail is intended only for the above addressee. It may contain > privileged information. > If you are not the addressee you must not copy, distribute, disclose or use > any of the information in it. > If you have received it in error please delete it and immediately notify the > sender. > Security Notice: all e-mail, sent to or from this address, may be accessed by > someone other than the recipient, for system management and security reasons. > This access is controlled under Regulation of security reasons. > This access is controlled under Regulation of Investigatory Powers Act 2000, > Lawful Business Practises. > > > ___ > 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 mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding Winshark binaries
Manjunath P wrote: > Hi all, > I hv a question. > Due to some dowloading problems, I am not able to build > wireshark on Windows. So, I hv decided to build WS source in Linux itself. I assume you need to change Wireshark or add a new dissector or tap to Wireshark, as you don't need to build the standard version in order to run Wireshark on Windows (there's a pre-built binary). > These are my queries > 1) If I build WS, and write my own dissector (as a plugin or build > with source ) in Linux, can the .exe file so genrated be > executable in Windows I know of nothing similar to Wine that would help you by allowing Linux, or other UN*X, binaries to run on Windows. (No, the Interix subsystem doesn't do that, as far as I know.) I.e., an executable image for a UN*X such as Linux is not executable on Windows (and doesn't have a name ending with ".exe" - UN*X executables tend not to have any extension). > OR is there any necessity for me to crs-compile?? You would have to cross-compile; I don't know what tools there are for building Windows executables on Linux - or whether, if any exist, they can be used to build Wireshark. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
On Tue, Apr 03, 2007 at 03:11:38PM +0100, Richard van der Hoff wrote: > I guess I'm not quite up to speed with the state of this project... Am > I right in thinking that warnings have only been purged successfully > so far for the win32 build? I can't build on linux yet with > --warnings-as-errors... I can build on FreeBSD/gcc 4.2 using --with-warnings-as-errors without problems. However, on my Linux/gcc 4.1 box, there are a few warnings left that we need to get rid of (I'll try to work on it today). Then we'll be able to run the Unix/OS X buildbots with --with-warnings-as-errors like the Windows build. The Windows build actually defaults to making warnings errors already, but I'm hesistant to do it yet on the Unix builds until we iron out warnings on all the platforms/gcc versions. Non-gcc builds are never given -Werror by the way. On Unix, most directories are built with -Werror when using the configure option --with-warnings-as-errors except epan/dissectors, which has a few thousand warnings from the ASN1 auto-generated dissectors that we still need to clear up. After fixing the Linux/gcc In summary, We're almost there on Unix.. :) Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Protocol for DRDA / DB2
Hi Sebastien, Here is a re-submission of my new DRDA dissector with your comments addressed. For the compiler warnings, I removed them all, at least what MSVC6 is reporting. If your compiler reports more, please tell me the line number. As I do not have SVN installed but I compiled from the 0.99.5 tarball, please forgive me if I cannot easily generate diffs against current SVN (I tried my best with Cygwin). You will also find a sample capture file on which I ran 1200 loops of fuzz testing with no problem. I also added the sample capture file on the Wiki (drda_db2_sample.tgz). Please tell me if you have any outstanding comments. Regards, metatech Hi, It seems good (to me) with however some comments : Others details : P.S. : next time, please provide a *patch* ;) Sebastien Tandel packet-drda-patch.tgz Description: application/compressed ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Stephen Fisher wrote: > On Tue, Apr 03, 2007 at 03:11:38PM +0100, Richard van der Hoff wrote: > >> I guess I'm not quite up to speed with the state of this project... Am >> I right in thinking that warnings have only been purged successfully >> so far for the win32 build? I can't build on linux yet with >> --warnings-as-errors... > > I can build on FreeBSD/gcc 4.2 using --with-warnings-as-errors without > problems. However, on my Linux/gcc 4.1 box, there are a few warnings > left that we need to get rid of (I'll try to work on it today). Then > we'll be able to run the Unix/OS X buildbots with > --with-warnings-as-errors like the Windows build. I still have quite a few with 3.3. What does the buildbot use? > The Windows build actually defaults to making warnings errors already, > but I'm hesistant to do it yet on the Unix builds until we iron out > warnings on all the platforms/gcc versions. Agreed. > In summary, We're almost there on Unix.. :) :) I'll see what I can do to squash a few. Cheers Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Dissecting multiple protocol headers in a single plugin
Hi, I've got a plugin dissector working for the top-level header of a multi-layer protocol, and I need to add the subdissectors for the subsequent layers. I've tried doing this as separate plugins, and in a single plugin with multiple registered dissectors. However, whenever I call add_dissector for the second layer of the protocol, I get an error: Err file packet.c: line 672: assertion failed: (sub_dissectors) Looking at packet.c, it appears that the type of the HF name I'm passing as the first arg doesn't map to an acceptable type, but in fact I've declared that field with type FT_UINT8, which should be fine. Another possibility is that the fields haven't been registered yet so aren't recognized (it would be nice if this were a separate, distinguishable assertion error :(), but I only call the proto_register_* routine for the sub-layer after the proto_register_* for the higher layer has returned successfully, so I'd expect the fields to be registered at that point. Any clues as to what might be going wrong? Thanks, Bob ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Richard van der Hoff wrote: > Stephen Fisher wrote: >> On Tue, Apr 03, 2007 at 03:11:38PM +0100, Richard van der Hoff wrote: >> >>> I guess I'm not quite up to speed with the state of this project... Am >>> I right in thinking that warnings have only been purged successfully >>> so far for the win32 build? I can't build on linux yet with >>> --warnings-as-errors... >> I can build on FreeBSD/gcc 4.2 using --with-warnings-as-errors without >> problems. However, on my Linux/gcc 4.1 box, there are a few warnings >> left that we need to get rid of (I'll try to work on it today). Then >> we'll be able to run the Unix/OS X buildbots with >> --with-warnings-as-errors like the Windows build. > > I still have quite a few with 3.3. What does the buildbot use? It depends on the builder: Ubuntu: gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) OS X: gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) Solaris: gcc version 4.0.2 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dissecting multiple protocol headers in a single plugin
Bob Doolittle wrote: > Looking at packet.c, it appears that the type of the HF name > I'm passing as the first arg doesn't map to an acceptable type, > but in fact I've declared that field with type FT_UINT8, > which should be fine. Another possibility is that the > fields haven't been registered yet so aren't recognized (it > would be nice if this were a separate, distinguishable > assertion error :(), but I only call the proto_register_* > routine for the sub-layer after the proto_register_* > for the higher layer has returned successfully, so I'd expect > the fields to be registered at that point. Another possibility is that the first argument to dissector_add() is the name of a dissector table, not the name of a field, even though dissector tables are often - but *NOT* always! - given the same name as a field whose value is used as the key for looking up entries in that dissector table. That's the correct possibility. Dissector tables are not automatically created for fields; you need to create the dissector table explicitly with a call to register_dissector_table(). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
On Tue, Apr 03, 2007 at 10:57:11AM -0700, Gerald Combs wrote: > It depends on the builder: > > Ubuntu: gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) > OS X: gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) > Solaris: gcc version 4.0.2 btw: could buildbot send mails to wireshark-dev again in case of failed builds? Most of the time I don't check the buildbot after checking in changes. Just like I'm not a forum user, I'm not a check-check-buildbot-that-everything-is-fine user. I want to be notified when something is wrong. Polling is no longer used in the unix/windows world either. ciao Joerg -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Richard van der Hoff wrote:
> I'll see what I can do to squash a few.
I'm just wondering what to do about this one:
scanner.c:1571: warning: `yyunput' defined but not used
(for epan/dfilter/scanner.{c,l}, flex 2.5.33, gcc 3.3.6)
Ideally we'd add --nounput to the flex cmdline or "%option nounput" to
scanner.l, but they are both flex-only, so that's a bit hard.
The best I can come up with otherwise is
"static void yyunput (int, char*) _U_;"
in the declarations. Thoughts?
Cheers,
Rich
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
On Tue, Apr 03, 2007 at 07:26:18PM +0100, Richard van der Hoff wrote:
> Richard van der Hoff wrote:
> > I'll see what I can do to squash a few.
>
> I'm just wondering what to do about this one:
>
> scanner.c:1571: warning: `yyunput' defined but not used
>
> (for epan/dfilter/scanner.{c,l}, flex 2.5.33, gcc 3.3.6)
>
> Ideally we'd add --nounput to the flex cmdline or "%option nounput" to
> scanner.l, but they are both flex-only, so that's a bit hard.
What happens when non-flex lexes encounter that statement?
ciao
Joerg
--
Joerg Mayer <[EMAIL PROTECTED]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
I do not think other lex than flex would actually work with all our lexers.
As far as the generated dissectors are delivered in the src tarballs
there's no problem, as the source will compile anyway on any POSIX
system. Windows builds require flex and a make clean.
On the other side if I remember well, if yyunput is not generated
other warnings come up.
You can try... and see what happens.
Worst case scenario: you'll just have to revert a commit.
Luis
On 4/3/07, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
> Richard van der Hoff wrote:
> > I'll see what I can do to squash a few.
>
> I'm just wondering what to do about this one:
>
> scanner.c:1571: warning: `yyunput' defined but not used
>
> (for epan/dfilter/scanner.{c,l}, flex 2.5.33, gcc 3.3.6)
>
> Ideally we'd add --nounput to the flex cmdline or "%option nounput" to
> scanner.l, but they are both flex-only, so that's a bit hard.
>
> The best I can come up with otherwise is
> "static void yyunput (int, char*) _U_;"
> in the declarations. Thoughts?
>
> Cheers,
>
> Rich
> ___
> 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] The "war against warnings" - mission accomplished!
Right, it's done...
Luis Ontanon wrote:
> I do not think other lex than flex would actually work with all our lexers.
>
> As far as the generated dissectors are delivered in the src tarballs
> there's no problem, as the source will compile anyway on any POSIX
> system. Windows builds require flex and a make clean.
>
> On the other side if I remember well, if yyunput is not generated
> other warnings come up.
>
> You can try... and see what happens.
> Worst case scenario: you'll just have to revert a commit.
>
> Luis
>
> On 4/3/07, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
>> Richard van der Hoff wrote:
>>> I'll see what I can do to squash a few.
>> I'm just wondering what to do about this one:
>>
>> scanner.c:1571: warning: `yyunput' defined but not used
>>
>> (for epan/dfilter/scanner.{c,l}, flex 2.5.33, gcc 3.3.6)
>>
>> Ideally we'd add --nounput to the flex cmdline or "%option nounput" to
>> scanner.l, but they are both flex-only, so that's a bit hard.
>>
>> The best I can come up with otherwise is
>> "static void yyunput (int, char*) _U_;"
>> in the declarations. Thoughts?
>>
>> Cheers,
>>
>> Rich
>> ___
>> Wireshark-dev mailing list
>> Wireshark-dev@wireshark.org
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>
>
>
--
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] The "war against warnings" - mission accomplished!
On 4/3/07, Luis Ontanon <[EMAIL PROTECTED]> wrote:
> I do not think other lex than flex would actually work with all our lexers.
Few minutes later, Luis Ontanon <[EMAIL PROTECTED]> writes:
Now I'm sure they won't:
from http://www.gnu.org/software/flex/manual/html_chapter/flex_20.html
The following flex features are not included in lex or the POSIX specification:
C++ scanners
%option <=== THIS
start condition scopes
start condition stacks < THIS
interactive/non-interactive scanners
yy_scan_string() and friends < THIS
yyterminate() < THIS
yy_set_interactive()
yy_set_bol()
YY_AT_BOL()
<> < THIS
<*>
YY_DECL
YY_START
YY_USER_ACTION
YY_USER_INIT
#line directives
%{}'s around actions
multiple actions on a line
--
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] buildbot failures
Richard van der Hoff wrote: > Apologies for turning the buildbot red, everyone... I'm working on it... Hrm, it's still not quite there. Would somebody on Win32 mind running the test suite (in particular, option 5 - unit tests) and seeing if they can see wtf the matter with it is? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Luis Ontanon wrote: > On 4/3/07, Luis Ontanon <[EMAIL PROTECTED]> wrote: >> I do not think other lex than flex would actually work with all our lexers. > > Few minutes later, Luis Ontanon <[EMAIL PROTECTED]> writes: > > Now I'm sure they won't: Excellent. Wireshark trunk now seems to build cleanly with --with-warnings-as-errors on gcc-3.3, fwiw. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] The "war against warnings" - mission accomplished!
Richard van der Hoff wrote: > Luis Ontanon wrote: >> On 4/3/07, Luis Ontanon <[EMAIL PROTECTED]> wrote: >>> I do not think other lex than flex would actually work with all our lexers. >> Few minutes later, Luis Ontanon <[EMAIL PROTECTED]> writes: >> >> Now I'm sure they won't: > > Excellent. Wireshark trunk now seems to build cleanly with > --with-warnings-as-errors on gcc-3.3, fwiw. or it did, until your commit 50 minutes ago, Luis ... :'( ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21325: /trunk/epan/ /trunk/epan/: uat.c
oops! compiling on windows! On 4/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21325 > > User: richardv > Date: 2007/04/03 07:53 PM > > Log: > fix an 'unused parameter' warning > > Directory: /trunk/epan/ > ChangesPath Action > +1 -1 uat.c Modified > > ___ > Wireshark-commits mailing list > Wireshark-commits@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-commits > -- 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] [Patch] pragma warning
Now these changes are in the svn tree. Note that I've moved some dissectors from DISSECTOR_SRC to CLEAN_DISSECTOR_SRC but there are many others which could already be moved to CLEAN_DISSECTOR_SRC. Regards, Sebastien Tandel >> I made it partly for the Unix side. (Makefile.common and Makefile.am >> affected). >> The Makefile is, in fact, building now four libraries : >> - asn dissectors : libasndissectors.la >> - pidl dissectors : libpidldissectors.la >> - normal dissectors : libdissectors.la *and* libcleandissectors.la. I >> separated it in two libraries temporarily. The source files used to >> build libcleandissectors.la do not generate warning anymore and the >> -Werror is used to compile them. If we patch a dissector and it doesn't >> generate warning anymore, we have to move the filename dissector from >> DISSECTOR_SRC to CLEAN_DISSECTOR_SRC in epan/dissectors/Makefile.common. >> >> You can define specific cflags with, for example, >> libpidldissectors_la_CFLAGS. >> > > Did you already commit these changes? I don't see them in my svn tree. > We're still compiling epan/dissectors with a ton of warnings from > auto-generated dissectors on Unix. > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] File in makefile not in SVN
Hi, packet-drda.c is missing from SVN but included in latest commit of makefile.common. Best regards Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] File in makefile not in SVN
sorry, the review of the 'non-patch' of packet-drda.c where I've had to change the Makefile. Regards, Sebastien Tandel Anders Broman wrote: > Hi, > packet-drda.c is missing from SVN but included in latest commit of > makefile.common. > Best regards > Anders > > ___ > 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] Dissector over Ethernet
Hi, Depending of your dissector complexity, you may even consider ptvcursor API (see README.developer) packet-homeplug.c is an example of the use of ptvcursor which is also working on top of ethernet. If you intend to use proto_tree_* functions, please use proto_tree_add_item instead of proto_tree_add_[uint|string|...] whenever possible. Regards, Sebastien Tandel CANDIA, Fabrice wrote: > Thanks Abhik, ARP dissector is exactly what I need ! > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la part de Abhik Sarkar > Envoyé : mardi 3 avril 2007 14:03 > À : Developer support list for Wireshark > Objet : Re: [Wireshark-dev] Dissector over Ethernet > > > Hi Fabrice, > > How about the ARP (packet-arp.c) dissector? One of the protocols ARP > runs directly on is Ethernet. That should give you some ideas. > > Maybe packet-llc.c too. > > Hope this helps, > Abhik. > > On 4/3/07, CANDIA, Fabrice <[EMAIL PROTECTED]> wrote: > >> Hi all, >> >> I am looking for a dissector able to decode a specific protocol directly >> over Ethernet (no IP header). >> The dissector shall be able to decode the protocol by detecting the MAC >> destination and one field in the payload. >> I am totally newbie in "wireshark dissection". >> >> Could somebody send me one example of a such type of dissector ? >> >> I tried to start from the foo example described in the developper's guide >> but I am not sure this example is adapted to my needs (dissector over >> Ethernet). >> >> Sincerely, >> >> Fabrice >> >> >> This e-mail is intended only for the above addressee. It may contain >> privileged information. >> If you are not the addressee you must not copy, distribute, disclose or use >> any of the information in it. >> If you have received it in error please delete it and immediately notify the >> sender. >> Security Notice: all e-mail, sent to or from this address, may be accessed >> by someone other than the recipient, for system management and security >> reasons. This access is controlled under Regulation of security reasons. >> This access is controlled under Regulation of Investigatory Powers Act 2000, >> Lawful Business Practises. >> >> >> ___ >> 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 mail has originated outside your organization, either from an external > partner or the Global Internet. > Keep this in mind if you answer this message. > > > > This e-mail is intended only for the above addressee. It may contain > privileged information. > If you are not the addressee you must not copy, distribute, disclose or use > any of the information in it. > If you have received it in error please delete it and immediately notify the > sender. > Security Notice: all e-mail, sent to or from this address, may be accessed by > someone other than the recipient, for system management and security reasons. > This access is controlled under Regulation of security reasons. > This access is controlled under Regulation of Investigatory Powers Act 2000, > Lawful Business Practises. > > > ___ > 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 21328: /trunk/epan/dissectors/ /trunk/epan/dissectors/: Makefile.nmake
thx for the Ytpo xFi. Regards, Sebastien Tandel [EMAIL PROTECTED] wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21328 > > User: lego > Date: 2007/04/03 08:52 PM > > Log: > xFi a Ytpo > > Directory: /trunk/epan/dissectors/ > ChangesPath Action > +6 -4 Makefile.nmakeModified > > ___ > 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] Protocol for DRDA / DB2
Hi, commit as rev21331. Thanks. Regards, Sebastien Tandel metatech wrote: > Hi Sebastien, > > Here is a re-submission of my new DRDA dissector with your comments > addressed. > For the compiler warnings, I removed them all, at least what MSVC6 is > reporting. If your compiler reports more, please tell me the line > number. > As I do not have SVN installed but I compiled from the 0.99.5 tarball, > please forgive me if I cannot easily generate diffs against current > SVN (I tried my best with Cygwin). > You will also find a sample capture file on which I ran 1200 loops of > fuzz testing with no problem. > I also added the sample capture file on the Wiki (drda_db2_sample.tgz). > > Please tell me if you have any outstanding comments. > > Regards, > > metatech > > >> Hi, >> >> It seems good (to me) with however some comments : >> Others details : >> P.S. : next time, please provide a *patch* ;) >> Sebastien Tandel > > > ___ > 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 21332: /trunk/epan/ /trunk/epan/: exceptions.h
Oops it is Bug 1342 not 1334. On 4/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21332 > > User: lego > Date: 2007/04/03 10:06 PM > > Log: > Make sure that when a windows exception is thrown ENDTRY gets evaluated. > > fix for one of the various issues that cause bug 1334 > > Directory: /trunk/epan/ > ChangesPathAction > +17 -4 exceptions.hModified > > ___ > Wireshark-commits mailing list > Wireshark-commits@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-commits > -- 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] 1 packet triggers 4 bugs, is it a record?
If you take a look to the attachment http://bugs.wireshark.org/bugzilla/attachment.cgi?id=605 of bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342 You'll have a perfect example of an "evil" packet (not malicious but certainly evil) that causes 4(3?) bugs to be triggered. This malformed packet causes a recursion loop in AccessResult via dissect_ber_choice() because the choice's data is a sequence of 00s. Other than the bug in the code that generated the packet (which is not our business). We got one or two bugs here: - dissect_ber_choice() must stop looping without advancing. - and MMS's AccessResult/success1 might be IMPLICIT (I tried to make it implicit and it stopped the loop marking these packets as malformed). That causes a stack overflow which hides more bugs: One of the bugs I just fixed it, where a windows exception thrown up in the stack will skip all the ENDTRY groups causing a crash later in except_pop() when called by the ENDTRY of dissect_packet() Once fixed the file is read ok with tshark (even with -V but there you can see the effect of the loop). On WS (on Windows), on the other hand, the packet list is made OK but if you click on the "evil" packet (21) WS just shuts down (no dump to the debugger, no signs of why!). I believe this to be a out of memory error when generating the tree after dissection but honestly I do not know how to deal with this. I'll investigate the last issue (the shut down) but someone that knows how dissect_ber_choice() works should take a look at it. Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dissecting multiple protocol headers in a single plugin
Guy Harris wrote: > Bob Doolittle wrote: > > >> Looking at packet.c, it appears that the type of the HF name >> I'm passing as the first arg doesn't map to an acceptable type, >> but in fact I've declared that field with type FT_UINT8, >> which should be fine. Another possibility is that the >> fields haven't been registered yet so aren't recognized (it >> would be nice if this were a separate, distinguishable >> assertion error :(), but I only call the proto_register_* >> routine for the sub-layer after the proto_register_* >> for the higher layer has returned successfully, so I'd expect >> the fields to be registered at that point. >> > > Another possibility is that the first argument to dissector_add() is the > name of a dissector table, not the name of a field, even though > dissector tables are often - but *NOT* always! - given the same name as > a field whose value is used as the key for looking up entries in that > dissector table. > > That's the correct possibility. Dissector tables are not automatically > created for fields; you need to create the dissector table explicitly > with a call to register_dissector_table(). Thanks. My subdissector is now being called, and is updating the List window properly. But for some odd reason the sub-protocol isn't appearing in the Details window tree, and I'm handling it identically to how I handled the parent protocol, which is drawing properly. I've verified that the proto has been registered properly. I've verified that the same tree is being passed into the subdissector, and that it's making the proto_tree_add_item call for the proto in the parent tree, but it's not appearing. Is there something special that has to occur for a single plugin to add two separate protos to the tree? Are there any good examples of dissectors in the wireshark source that add multiple protocol layers to the tree? Is this bad practice - should I be using multiple plugins for multiple layers, and if so, how do I force them to be initialized in the necessary order (e.g. so that the parent proto can create the dissector table before the child proto adds itself :)? Thanks, as always, Bob ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dissecting multiple protocol headers in a single plugin
On Apr 3, 2007, at 4:53 PM, Bob Doolittle wrote: > Thanks. My subdissector is now being called, and is updating the List > window > properly. But for some odd reason the sub-protocol isn't appearing > in the > Details window tree, and I'm handling it identically to how I handled > the parent > protocol, which is drawing properly. I've verified that the proto > has been > registered properly. I've verified that the same tree is being > passed into the subdissector, and that it's making the > proto_tree_add_item call > for the proto in the parent tree, but it's not appearing. So the "tree" argument to the subdissector is non-null? What's the code in the subdissector that adds the top-level entry for the protocol? > Is there something special that has to occur for a single plugin to > add two > separate protos to the tree? A single plugin can contain multiple dissectors; they can be in a single source file, or multiple source files. The only thing that's necessary for a single source file to contain multiple dissectors is to make sure that the registration and handoff- registration routines in that source file (there can be more than one such routine) register all the dissectors properly. > Are there any good examples of dissectors in the wireshark source > that add > multiple protocol layers to the tree? Is this bad practice - should > I be > using multiple plugins for multiple layers, and if so, how do I > force them > to be initialized in the necessary order (e.g. so that the parent > proto can > create the dissector table before the child proto adds itself :)? You should be using multiple *dissectors* for multiple protocol layers, but it sounds as if you're already doing that. The problem probably has nothing to do with multiple dissectors in a plugin. That works (see, for example, the DOCSIS plugin). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Windows Buildbot failing on emem.c after recent changes
Hi, The buildbot is failing. I'm not sure which of the recent changes that caused this. Best regards Anders emem.c C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(99) : error C2011: 'fd_set' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(134) : warning C4005: 'FD_SET' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(83) : see previous definition of 'FD_SET' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(143) : error C2011: 'timeval' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(199) : error C2011: 'hostent' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(212) : error C2011: 'netent' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(219) : error C2011: 'servent' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(226) : error C2011: 'protoent' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(310) : error C2011: 'in_addr' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(368) : error C2011: 'sockaddr_in' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(378) : error C2011: 'WSAData' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(430) : warning C4005: 'SO_DONTLINGER' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(391) : see previous definition of 'SO_DONTLINGER' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(483) : warning C4005: 'AF_IPX' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(449) : see previous definition of 'AF_IPX' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(506) : warning C4005: 'AF_MAX' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(468) : see previous definition of 'AF_MAX' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(512) : error C2011: 'sockaddr' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(521) : error C2011: 'sockproto' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(560) : error C2011: 'linger' : 'struct' type redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(573) : warning C4005: 'SOMAXCONN' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(533) : see previous definition of 'SOMAXCONN' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(598) : warning C4005: 'FD_READ' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(551) : see previous definition of 'FD_READ' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(601) : warning C4005: 'FD_WRITE' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(552) : see previous definition of 'FD_WRITE' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(604) : warning C4005: 'FD_OOB' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(553) : see previous definition of 'FD_OOB' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(607) : warning C4005: 'FD_ACCEPT' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(554) : see previous definition of 'FD_ACCEPT' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(610) : warning C4005: 'FD_CONNECT' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(555) : see previous definition of 'FD_CONNECT' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(613) : warning C4005: 'FD_CLOSE' : macro redefinition C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(556) : see previous definition of 'FD_CLOSE' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1427) : error C2375: 'accept' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(707) : see declaration of 'accept' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1448) : error C2375: 'bind' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(710) : see declaration of 'bind' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1467) : error C2375: 'closesocket' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(712) : see declaration of 'closesocket' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1486) : error C2375: 'connect' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(714) : see declaration of 'connect' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1507) : error C2375: 'ioctlsocket' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(716) : see declaration of 'ioctlsocket' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1528) : error C2375: 'getpeername' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(718) : see declaration of 'getpeername' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1549) : error C2375: 'getsockname' : redefinition; different linkage C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock.h(721) : see declaration of 'getsockname' C:\PROGRA~1\MICROS~2\VC98\INCLUDE\winsock2.h(1572) : error C2375:
