[Wireshark-dev] 16 khz Voip Calls
Hi there, I asked some time ago, if it was possible to decode 16 khz PCMA (or PCMU) RTP streams with wireshark. If I do so, I only get a flat line, but nothing useful. Will there be support in future versions or are there other possibilities for me? Regards, Guido___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Python wrappers for pcapio.[ch]
Shehjar Tikoo wrote: I am looking for Python wrappers for writing pcap files and I havent been able to find a library that does it or does it cleanly. PS: I ask because I intend to use pcapio.c to create a wrapper. PS2: I've looked at both pcap, pylibpcap and pcapy modules for this functionality. Hi Shehjar, I also had this problem a while ago, and wrote this minimal module wrapping libpcap using pyrex: http://people.0x63.nu/~andersg/pcapdump.pyx anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] filters diameter
On Tue, Jul 10, 2007 at 08:42:15PM +0200, Luis EG Ontanon wrote: A year or more ago I abandoned a way towards (3) (similar to what I did for radius dictionary) a while ago, due to a personal lack of diameter use after switching jobs and a stall about how to handle recursion in attribute_groups. I will be able to get back into it in September (I'll be off-contract and unable to move from Rome). Please remind me then or as an alternative I could send the work-in-progress for someone else to deal with it. cristian: o.k. since I have started all this, I guess I could try having a look. so, luis if you can send me please the patches or whatever you have already impl. bye now! cristian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] filters diameter
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote: A year or more ago I abandoned a way towards (3) (similar to what I did for radius dictionary) a while ago, due to a personal lack of diameter use after switching jobs and a stall about how to handle recursion in attribute_groups. I will be able to get back into it in September (I'll be off-contract and unable to move from Rome). Please remind me then or as an alternative I could send the work-in-progress for someone else to deal with it. I think this would make the Diameter dissector much more useful to users who are trying to understand diameter message flows. My personal use of the dissector is mainly to help verify that our implementation of the various interfaces we support encodes and decodes properly (hence my modifications to find and diagnose undecoded or malformed AVPs)... BTW In an early MATE prototype (befor having it defining fields for every user defined element) I used string fields like mate.pdu_avp == avp_name=string_repr_of_value, those allow to actually filter. I thought about this quick and dirty solution for radius before writing its dictionary support. I wondered if MATE or the LUA support could make this kind of filtering possible, but dynamically creating filters is obviously the right way to do it. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] filters diameter
On Tue, Jul 10, 2007 at 06:49:37PM +0100, Martin Mathieson wrote: OK, I just implemented (2) with change 22284. You should be able to right-click on a whole AVP that matches the code you're interested in, choose 'Prepare as Filter | Selected', edit the last 4 bytes and apply it. cristian: o.k. thanks a lot for letting me know. I did not know that my misinterpretation of the semantics of wireshark diameter filtering capabilities will trigger some new feature implementation... :-) bye now! cristian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Python wrappers for pcapio.[ch]
Guy Harris wrote: On Jul 10, 2007, at 6:08 PM, Shehjar Tikoo wrote: Does anyone know of Python bindings for the pcapio.[ch] code in Wireshark source root? I am looking for Python wrappers for writing pcap files and I havent been able to find a library that does it or does it cleanly. Shehjar PS: I ask because I intend to use pcapio.c to create a wrapper. .. .. pylibpcap and pcapy both appear to support writing pcap files, so presumably, if you haven't been able to find a library that does that or does it cleanly, neither of them do it cleanly. What's unclean about how they do it? Neither of them seem to provide a way to write the pcap_pkthdr's for individual packets. To me, it looks like pylibpcap depends on libpcap's internal routing of packets from the capture source to the dump file. That wont work for me because I am constructing the packets in-memory. With pcapy, I dont think it exports/wraps/exposes the struct pcap_pkthdr which is required by its dump method. Shehjar ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] capturing data from a propietary device
[EMAIL PROTECTED] wrote on 07/10/2007 07:41:52 PM:
On Jul 10, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote:
I'm trying to figure out how to format (or where to place the data)
in the pcap buffer when capturing my WAN protocols.
I've built a system that will capture the data and feed it via pcap
to wireshark, and I've got it working for Ethernet data and for
frame relay data, but I'm having trouble dealing with getting the
proprietary data into wireshark intact so that I can later write a
disector.
(I'm going to test everything out before submitting my requests for
a set of DLT_ mumbers for these protocols. In the mean time, I've
just taken the next few currently un-assigned ones while I work on
my code).
The trouble is that I don't know what values to put into:
off_linktype, off_nl and off_nl_nosnap for my DLT cases. (And I
think thats where my problem lies.)
Given that off_linktype, off_nl, and off_nl_nosnap are used *only* by
the BPF code generator when it generates code for a capture filter, I
really really really don't think that's where your problem lies,
unless your problem is a problem with capture filters, and from what
you say, it's *not* a problem with capture filters (as capture filters
only control which packets are captured, they don't control the format
of the packet).
OK. And yes, one of the goals is to be able to use BPF.
But I think I'm beginning to agree with you, its not on the
'off_xxx' variables. Nothing I do there seems to change
the symptoms. But I'd still like to know what the appropriate
values would be. -1 to disable or zero as the offset.
The reason I ask is because I intend to insert a few bytes
of 'level 1 signalling/status info that would have to be
skipped by the display routines.
Right now, the first thing in each received buffer is the typical 16
bytes of: timestamp_sec, timestamp_usec, capture_len, pkt_len, which
is followed by 'n' bytes of my protocol's data.
I.e., each received buffer is a struct pcap_pkthdr, followed by the
packet data.
Presumably, if you've implemented a libpcap module for this (if that's
what capture the data and feed it via pcap means), then, presumably,
your read_op routine is calling the callback routine with the second
argument pointing to the 16-byte struct pcap_pkthdr header and the
third argument pointing to the protocol data.
Yes, and yes.
When Wireshark goes to display it, the Protocol column says
'unknown', which I can understand, because I don't have any
disectors for that DLT (WTYP_ENCAP) type yet.
The Info column says WTAP_ENCAP = 94. (I don't see where it gets
the value of '94' from.)
Presumably, in order for your file to be read *at all* by Wireshark,
you modified Wireshark so that the pcap_to_wtap_map[] array in wiretap/
libpcap.c maps the relevant currently un-assigned DLT_ values you're
using (note that the the next few currently un-assigned values start
at 196; *ALL* values from 100 through 196 are assigned) to some
WTAP_ENCAP value. If it maps it to 94, then that's where the 94 comes
from - but 94 is, in the top-of-tree version of Wireshark,
WTAP_ENCAP_NETTL_RAW_TELNET, so you probably don't want to map
anything to that.
At the time I started this project (Jan) 94 was un-assigned,
(unfortunaltely I've had to set the project aside until now.)
And after I sent my email I then recognized the DLT to WTAP
mapping table in wireshark... so that explains that.
It still leaves my issue/question about the data length and
the offset that wireshark seems to see and use.
The summary pane (for the first message) says:
Frame 1 had (6 bytes on wire, 6 bytes captured)
Data (6 bytes)
and the (related) detail pane says:
7f 56 ae 93 46 7e
Then the capture file that Wireshark is reading, if it's a libpcap-
format file, must have had a capture_len value of 6 and a len value of
6.
Where did that file come from? Did you modify libpcap so that it can
capture from your device, and did you use Wireshark to capture the
traffic, or do you have some other program capturing from your device
and writing out a libpcap-format file?
Yes. I have a modified libpcap that allows it to capture from my device
and I used Wireshark to initiate the capture.
No I am not currently using Wireshark to write/read a libpcap-format file.
I was going to verify that portion after getting the capture/display
part working.
So since the struct pcap_pkthdr specified a length of 0xb bytes and
the u_char *user pointer was pointing at the first byte of the data pkt
I'm at a loss to explain the 6 byte length wireshark sees.
You've convinced me that my changes to libpcap are probably correct
and I should now be focusing on wireshark and the data it sees coming
in for decode/display.
... snip ...
Did you noticed
http://wiki.wireshark.org/Development/LibpcapFileFormat?
Yes, I did, and I am in theory following it.
The difference is that the document
[Wireshark-dev] GPL license question
I'm concerned about the requirements of the GPLv2 license. If I write a plugin for Wireshark, which compiles to a plugin DLL only, and then I distribute the plugin DLL, am I required by the GPL license to distribute the source (and for anyone I distribute it to, they can redistribute the source even if I don't want them to)? I'm wondering if I can legally distribute only the plugin DLL (and limit the distribution of it), and not distribute the source at all. -Jon ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
No, you can't keep the code for you nor limit the distribution of the plugin object code. It is the basic principle of the GPL. If you're distributing/selling your plugin, you have to distribute the code. And everyone receiving (paying for) this code may distribute it again and again ... without your permission :) Regards, Sebastien Tandel Jon Andersen wrote: I'm concerned about the requirements of the GPLv2 license. If I write a plugin for Wireshark, which compiles to a plugin DLL only, and then I distribute the plugin DLL, am I required by the GPL license to distribute the source (and for anyone I distribute it to, they can redistribute the source even if I don't want them to)? I'm wondering if I can legally distribute only the plugin DLL (and limit the distribution of it), and not distribute the source at all. -Jon ___ 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] GPL license question
On Wed, Jul 11, 2007 at 10:29:44AM -0400, Jon Andersen wrote: If I write a plugin for Wireshark, which compiles to a plugin DLL only, and then I distribute the plugin DLL, am I required by the GPL license to distribute the source (and for anyone I distribute it to, they can redistribute the source even if I don't want them to)? Yes. (AFAIK and IANAL etc.) I'm wondering if I can legally distribute only the plugin DLL (and limit the distribution of it), and not distribute the source at all. No. (AFAIK and IANAL etc.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
[EMAIL PROTECTED] wrote on 07/11/2007 10:45:27 AM: No, you can't keep the code for you nor limit the distribution of the plugin object code. It is the basic principle of the GPL. If you're distributing/selling your plugin, you have to distribute the code. And everyone receiving (paying for) this code may distribute it again and again ... without your permission :) Actually, I'd dissagree. With GPL v2, there is a clause that a developer can invoke if they write their code appropriately, and if the 'infrastructure' can support it. GPL 2 Section 2 paragraph 2, 3 and 4 cover this aspect. (Note GPL v3, no longer appears to have these clauses.) Basically... a) if the infrastructure can support 3rd party code invoked dynamically at run time, and b) if the infrastructure does not 'depend' on the 3rd party code for its operation, and c) if your code is not statically linked with GPL'ed code then you can release a binary-only version of your code without providing source. So to paraphrase: - if Wireshark isn't linked with your code, and - Wireshark can still function without your code, and - your code isn't linked to GPL'ed code, and - someone can replace your code with an equivalent (but seperately developed) module then your OK. FYI. Those paragraphs state: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.\ In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Jon Andersen wrote: I'm concerned about the requirements of the GPLv2 license. If I write a plugin for Wireshark, which compiles to a plugin DLL only, and then I distribute the plugin DLL, am I required by the GPL license to distribute the source (and for anyone I distribute it to, they can redistribute the source even if I don't want them to)? I'm wondering if I can legally distribute only the plugin DLL (and limit the distribution of it), and not distribute the source at all. This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] filters diameter
On 7/11/07, Martin Mathieson [EMAIL PROTECTED] wrote:
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
I wondered if MATE or the LUA support could make this kind of
filtering possible, but dynamically creating filters is obviously the
right way to do it.
In MATE there's no way (mate fields are unmodifiable strings
containing the text representation of another field).
But Lua could do (since you added diameter.avp): a postdissector
fetches the diameter.avp finfos gets the tvb of them and redissects
each field.
A dictionary parser in lua should be easy to write (there's ton's of
xml parsers written for every purpose arrount to start from)...
But I fully agree that dynamically creating filters is obviously the
right way to do it... and C does it better.
The issue that blocked me was on how to handle Group AVPs, I cannot
just ignore them (e.g. an hypotetical group {addr,prt} could lead to
server.addr and server.prt vs client.addr and client.prt and they
should be different), Group AVPs lead to recursion (if the recurring
subgroup is non Mandatory it might be possible to have them but
http://tools.ietf.org/html/rfc3588#section-4.4 says nothing about it)
--
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] filters diameter
Am I right in believing that the Diameter dissector currently ignores
the gavp entries within a grouped avp?
It may be just as useful (and much less effort?) to only filter based
on the innermost AVP without embedding them.
e.g. just support e.g.
- diameter.avp.server
- diameter.avp.client
- diameter.avp.addr (may be inside a client or server)
- diameter.avp.port (may be inside a client or server)
rather than
- diameter.avp.server
- diameter.avp.client
- diameter.avp.server.addr
- diameter.avp.server.port
- diameter.avp.client.addr
- diameter.avp.client.port
If we only supported the second form, there will be times when you
want to filter based on just the value of addr (i.e. the first form).
It would be confusing to have both in the tree.
But like I said, I've never really had to follow a diameter message
flow, so I could be wrong about which form of filters would be the
most useful.
On 7/11/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
On 7/11/07, Martin Mathieson [EMAIL PROTECTED] wrote:
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
I wondered if MATE or the LUA support could make this kind of
filtering possible, but dynamically creating filters is obviously the
right way to do it.
In MATE there's no way (mate fields are unmodifiable strings
containing the text representation of another field).
But Lua could do (since you added diameter.avp): a postdissector
fetches the diameter.avp finfos gets the tvb of them and redissects
each field.
A dictionary parser in lua should be easy to write (there's ton's of
xml parsers written for every purpose arrount to start from)...
But I fully agree that dynamically creating filters is obviously the
right way to do it... and C does it better.
The issue that blocked me was on how to handle Group AVPs, I cannot
just ignore them (e.g. an hypotetical group {addr,prt} could lead to
server.addr and server.prt vs client.addr and client.prt and they
should be different), Group AVPs lead to recursion (if the recurring
subgroup is non Mandatory it might be possible to have them but
http://tools.ietf.org/html/rfc3588#section-4.4 says nothing about it)
--
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 mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
[EMAIL PROTECTED] wrote on 07/11/2007 01:16:26 PM: Hi, Actually I disagree ;) From reading below the question is is it an independent and separate work? The GNU FAQ says its not: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins Unfortunately, the FAQ is a FAQ and not the license. As you can see, this is someones interpretation of a vague agreement, just as mine is/was. Even the FAQ uses non-firm phrases like we believe, and 'borderline case', then there will be questions. And thats why those 'interpretable' statements were removed from GPL 3. This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
Do you really think this case is a borderline one if the plugin is using the wireshark dissection API? The FAQ pointed by Jaap is about the plug-in mechanism but the plugin is linked with libwireshark which *is* GPLv2. Of course, if you're not dissecting your protocol with the wireshark API, we might start again this discussion but I doubt you can write a functional wireshark plugin dissector without linking to libwireshark. Regards, Sebastien Tandel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 07/11/2007 01:16:26 PM: Hi, Actually I disagree ;) From reading below the question is is it an independent and separate work? The GNU FAQ says its not: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins Unfortunately, the FAQ is a FAQ and not the license. As you can see, this is someones interpretation of a vague agreement, just as mine is/was. Even the FAQ uses non-firm phrases like we believe, and 'borderline case', then there will be questions. And thats why those 'interpretable' statements were removed from GPL 3. This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. ___ 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] GPL license question
Unfortunately this appears to be the case, which is possibly a shame as we have a bunch of plug-in dissectors we would willingly release for free download, but it would be a cold day in hell before our lawyers agreed to release the source code, even though I doubt there's anything of proprietry value in there. -- Martin Jaap Keuter wrote the following on 07/11/2007 06:16 PM: Hi, Actually I disagree ;) From reading below the question is is it an independent and separate work? The GNU FAQ says its not: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins Thanx, Jaap [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 07/11/2007 10:45:27 AM: No, you can't keep the code for you nor limit the distribution of the plugin object code. It is the basic principle of the GPL. If you're distributing/selling your plugin, you have to distribute the code. And everyone receiving (paying for) this code may distribute it again and again ... without your permission :) Actually, I'd dissagree. With GPL v2, there is a clause that a developer can invoke if they write their code appropriately, and if the 'infrastructure' can support it. GPL 2 Section 2 paragraph 2, 3 and 4 cover this aspect. (Note GPL v3, no longer appears to have these clauses.) Basically... a) if the infrastructure can support 3rd party code invoked dynamically at run time, and b) if the infrastructure does not 'depend' on the 3rd party code for its operation, and c) if your code is not statically linked with GPL'ed code then you can release a binary-only version of your code without providing source. So to paraphrase: - if Wireshark isn't linked with your code, and - Wireshark can still function without your code, and - your code isn't linked to GPL'ed code, and - someone can replace your code with an equivalent (but seperately developed) module then your OK. FYI. Those paragraphs state: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.\ In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Jon Andersen wrote: I'm concerned about the requirements of the GPLv2 license. If I write a plugin for Wireshark, which compiles to a plugin DLL only, and then I distribute the plugin DLL, am I required by the GPL license to distribute the source (and for anyone I distribute it to, they can redistribute the source even if I don't want them to)? I'm wondering if I can legally distribute only the plugin DLL (and limit the distribution of it), and not distribute the source at all. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev jy�u�U2�צ�m �rV�j��z�b��,� ڶ�V���]jם�g��u�^����m4 -- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Wed Jul 11 18:33:21 2007 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
I agree 100% ... and challenging doesn't even begin to describe it, I've beaten my head head against a brick wall for 5 years trying to get them to agree to release source to the dissectors we've written, even arguing the exact same points you've mentioned. My boss is converted! lawyers unfortunately are a different species altogether ;-) Still one day you never know... - Martin Ulf Lamping wrote the following on 07/11/2007 09:25 PM: Martin Warnes schrieb: Unfortunately this appears to be the case, which is possibly a shame as I wouldn't call the GPL a shame ;-) we have a bunch of plug-in dissectors we would willingly release for free download, but it would be a cold day in hell before our lawyers agreed to release the source code, even though I doubt there's anything of proprietry value in there. Well, there must be a reason that Wireshark contains a lot of dissector code from company's that rarely do this otherwise. IMHO: If Wireshark would have been released under a BSD style license (which would allow what you think of), we would probably have a lot less dissector variety - as you're probably not the only one thinking this way. You might argue to your lawyers (or your boss), that releasing the code might be beneficial because of a lot less maintenance and might even be a good marketing thing: - available to your customers - being nice to the open source worldIt's not so much that the code is proprietry, more I suspect that they are - ... You might even be promissed, that there already were some ideas of your executives in the open source direction, and Wireshark code could act as a test how it's working. However, I know from my own experience, that arguing this way can be challenging ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev jy�u�U2�צ�m �rV�j��z�b��,� ڶ�V���]jם�g��u�_����m4 -- Scanned by ClamAV antivirus system - http://www.clamav.net Virus signatures last updated: Wed Jul 11 21:33:21 2007 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
Essentially, you cannot comply with point c in a Wireshark plug-in DLL; in order to compile the DLL, you must have the Wireshark source available, parts of which are linked into the DLL. As Wireshark is GPL, so is the DLL. -- Phil On 7/11/07 8:46 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Actually, I'd dissagree. With GPL v2, there is a clause that a developer can invoke if they write their code appropriately, and if the 'infrastructure' can support it. GPL 2 Section 2 paragraph 2, 3 and 4 cover this aspect. (Note GPL v3, no longer appears to have these clauses.) Basically... a) if the infrastructure can support 3rd party code invoked dynamically at run time, and b) if the infrastructure does not 'depend' on the 3rd party code for its operation, and c) if your code is not statically linked with GPL'ed code ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Python wrappers for pcapio.[ch]
Anders Waldenborg wrote: Shehjar Tikoo wrote: I am looking for Python wrappers for writing pcap files and I havent been able to find a library that does it or does it cleanly. PS: I ask because I intend to use pcapio.c to create a wrapper. PS2: I've looked at both pcap, pylibpcap and pcapy modules for this functionality. Hi Shehjar, I also had this problem a while ago, and wrote this minimal module wrapping libpcap using pyrex: http://people.0x63.nu/~andersg/pcapdump.pyx anders That looks like what I need. Thanks. Shehjar ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] IEEE 802.15.4 dissectors and libpcap support.
Hi Owen, I've just had a very brief skim through this; A couple of points: * The ccitt crc16 routines are already in crc16.h - please could you use them rather than reinventing this particular wheel? * Your patch messes up the indentation in libpcap.c - please can you sort it out? * I'm not generally a fan of 500-line functions - any chance the offender could be split up a bit? * Please could you create a Protocols/ieee802154 page on the wiki, and add an example capture, so we can see what your dissector does? Many thanks for your contribution. Richard Owen Kirby wrote: Wireshark-dev, Following the discussion with Mikko Saarnivala from Sensinode, and Guy Harris, I have revised the IEEE 802.15.4 patch to use a standard pseudo-header. The updated patch has been tested using the Wireshark SVN sources as of yesterday. This patch adds the dissectors for the IEEE 802.15.4 MAC layer, as well as support for the DLT_IEEE802_15_4 type. Thanks, Owen Kirby ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] GPL license question
On 7/11/07, Ulf Lamping [EMAIL PROTECTED] wrote: Martin Warnes schrieb: Unfortunately this appears to be the case, which is possibly a shame as I wouldn't call the GPL a shame ;-) we have a bunch of plug-in dissectors we would willingly release for free download, but it would be a cold day in hell before our lawyers agreed to release the source code, even though I doubt there's anything of proprietry value in there. Well, there must be a reason that Wireshark contains a lot of dissector code from company's that rarely do this otherwise. IMHO: If Wireshark would have been released under a BSD style license (which would allow what you think of), we would probably have a lot less dissector variety - as you're probably not the only one thinking this way. I think instead that , there would be hundreds of wireshark derivatives some commercial and mostly closed source, none of which would offer a tenth of the functionality offered by The One GPLd Wireshark. To quote Linus But for a project I actually care about, I would never choose the BSD license. The license doesn't encode my fundamental beliefs of fairness. I think the BSD license encourages a everybody for himself mentality, and doesn't encourage people to work together, and to merge. -- 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
