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 woul
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 g
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
Essentially, you cannot comply with point 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:
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 unfort
[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
>
> Unf
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 rele
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 proprietr
[EMAIL PROTECTED] wrote on 07/11/2007 03:44:13 PM:
> Do you really think this case is a "borderline" one if the plugin is
> using the wireshark dissection API?
No, I am not saying anything. I don't know enough about the details
of Wireshark plug-in/dissector development. I'm still trying to f
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
[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
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 c
Doesn't developing a dissector or a plug-in for wireshark always
involve including/linking code from the core of wireshark? That would
make any plug-in a derivative work of wireshark which is GPL'ed and
hence the derivative work must also be distributed under GPL?
On 7/11/07, [EMAIL PROTECTED] <[E
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
- diam
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
[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 f
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
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 yo
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 e
[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 an
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 cle
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:
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
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_gro
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
> f
25 matches
Mail list logo
