Hello,
I've just committed the last "big" patch to convert the asn dissection
generators Makefiles. From my point of view there are a few things left:
1) at least on my system when I call the generator for external cnf
files, MAKEFILEFLAGS somehow gets set to "w". This looks like
"(cd ../x5
The Ubuntu builder is down due to problems with a hard drive upgrade. It
should be back up in the next day or so.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
some comments
1, the libfile should be a header file packet-cmf.h with the usual
boilerplates included
2, all value strings must be terminated with a {0,NULL} entry or else
you risk reading beyond the end of the array.
3, get rid of theif (proto_cfm == -1) {
this function should only be
I have opened the following bugzilla:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1905
Hopefully I have done it correctly, and have provided the needed material as
this is the first time I have ever done this. :)
This plugin will enable the dissection of CFM EOM ethernet packe
On Wed, 10 Oct 2007 15:56:53 -0700, Guy Harris wrote
> On Oct 7, 2007, at 5:04 PM, Didier wrote:
>
> > Is it ok if I upload the diff (~ 250 KB) in the wiki?
>
> From looking at the version you uploaded as an attachment to
>
> http://wiki.wireshark.org/Development/Optimization
>
> it look
Since it is an ASN file, and since it is freely downloadable from their website
as i read hte section below we should be ok :
http://www.itu.int/ITU-T/ipr/
# ITU-T Software Copyright Guidelines
[Download Word or PDF file]
2.2 Software that should not raise any IPR issues when includin
On Oct 7, 2007, at 5:04 PM, Didier wrote:
> Is it ok if I upload the diff (~ 250 KB) in the wiki?
From looking at the version you uploaded as an attachment to
http://wiki.wireshark.org/Development/Optimization
it looks as if one of the components is a new CList implementation.
Is tha
On Tue, 09 Oct 2007 08:08:29 +0200, Jaap Keuter wrote
> >
> > When trying to attach a one line patch.
> Hmm, better follow the suggestion of Anders and post it on the Wiki.
Done at http://wiki.wireshark.org/Development/Optimization, currently only the
patch, writing some stuff about it.
Didier
Hi,
At least the file is freely downloadable from
http://www.itu.int/ITU-T/asn1/database/iso/8571-4/1988/index.html
If (strict)copyright is to be applied to ASN1 or PIDL and other protocol
Describing languages any one using it in open source can only publish the
Generated code I suppose.
But s
Someone recently pointed out that the top of asn1/ftam/ISO8571-FTAM.asn has the
following notice:
-- Module ISO8571-FTAM (ISO 8571-4:1988)
--
-- Copyright ? ISO/IEC 1988. This version of
-- this ASN.1 module is part of ISO/IEC 8571-4:1988;
-- see the ISO|IEC text itself for full legal notices.
Do
> How do the review process works?
That's pretty much it.
By the way, since you seem to be an edonkey/emule expert, maybe you can
take a look at this bug and provide an appropriate patch for the edonkey
dissector: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1802. The
bug has to do with the
Hi,
I've filed a "bug" in bugzilla attaching a patch that updates the edonkey
dissector.
The vanilla edonkey dissector did not decode any kademlia packet.
Kademlia packet are udp packets that recent emule/amule clients use to create a
serverless P2P network.
As the only reference for the protoc
On Wed, Oct 10, 2007 at 12:08:25PM -0400, Bill Meier wrote:
> [EMAIL PROTECTED] wrote:
> > Log:
> > Fix two typos: ansi_tcap --> ansi-tcap
...
> I've done the above to get the buildbots running again.
>
> However, I'm not really sure if the correct fix is that ans1/ansi-tcap
> directory is reall
Hello All,
>>> Ulf Lamping <[EMAIL PROTECTED]> 10/10/07 11:29 AM >>>
> > The "temporary file model" is working in Wiresharks "update list of
> > packets" mode for quite a while and is working ok.
>
When doing a "live capture" in Wireshark on Windows
platforms I've really come to depend on dump
Ulf Lamping wrote:
>> Packets should be lost going from the kernel up to dumpcap, not between
>> dumpcap and *shark (unless I miss something: normally I would expect
>> that writing to a full pipe results in your write blocking, not message
>> disposal). So how is that different then the old
>
> I didn't follow the thread too closely, so it's just "my two cents".
>
> Be careful with the "temporary file model". Writing packets to disk can be
> slw, so things can get even worse (you drop more packets because tshark
> is slow *and* you are dumping to disk).
>
> At least on windo
[EMAIL PROTECTED] wrote:
> Log:
> Fix two typos: ansi_tcap --> ansi-tcap
>
> Directory: /trunk/asn1/
> ChangesPath Action
> +1 -1 Makefile.amModified
>
> Directory: /trunk/
> ChangesPathAction
> +1 -1 configure.inModified
>
I've done the
I didn't follow the thread too closely, so it's just "my two cents".
Be careful with the "temporary file model". Writing packets to disk can be
slw, so things can get even worse (you drop more packets because tshark
is slow *and* you are dumping to disk).
At least on windows it looks like i
>
> Packets should be lost going from the kernel up to dumpcap, not between
> dumpcap and *shark (unless I miss something: normally I would expect
> that writing to a full pipe results in your write blocking, not message
> disposal). So how is that different then the old model where *shark
>
Hi,
Is there any clue on using mingw to cross compile plugins?
Cheers
Selon samy chbinou <[EMAIL PROTECTED]>:
> Hello all,
> I just wrote my little foo dissector plugin on my linux machine. I would like
> to port it on an other platform: windows, mac, etc...
> Instead of setting up an entire deve
Hmm, I wonder what the point of doing "tshark -w - > /some/file" is when
you could just do "tshark -w /some/file"?
Anyway, I tried it and it seems to work better, although compared to the
0.99.6 version, the output differs given the same options. I would
expect the output to be the same, no?
Run
Hi can one help me on this.
I had one query regarding MMSE protocol.
MMSE specs defined by OMA say the following:
7.4 Header Field Names and Assigned Numbers
Bcc0x01
Cc 0x02
X-Mms-Content-Location
Ulf Lamping wrote:
> However, if noone is going to solve the current situation, tshark will
> keep the limitations that it currently has - I don't plan to spend any
> more effort on this topic ... if someone is seriously going to improve
> the current situation, I'm really willing to explain d
Maynard, Chris wrote:
> FYI: I was able to test this on a Windows PC, but it doesn't appear to be
> working. I could be doing something wrong since I hardly ever use tshark,
> but I compared the output of a 0.99.6-tshark with the output of an
> SVN-23125-tshark with the following command line
On Wed, Oct 10, 2007 at 03:10:53PM +0200, Antoine Gardiol - FiveCo wrote:
> I understand that backward compatibility is hard to keep, but when we
> thought about plugins, we understand plug(&play)in(the software) no ?
> My point of view is that backward compatibility should be kept for plugins
> an
Hello All,
I understand that backward compatibility is hard to keep, but when we
thought about plugins, we understand plug(&play)in(the software) no ?
My point of view is that backward compatibility should be kept for plugins
and could be broken for embedded disectors.
Rgds
Antoine
-Messag
Hello,
On Wed, Oct 10, 2007 at 11:29:14AM +0200, Sake Blok wrote:
> Sorry for breaking your plugin-distribution, but it has been my understanding
> that all plugins need to be compiled against the sources of the version you
> want to use them with. So every Wireshark version has it's own
> plug
Michael Lum wrote:
> I tried this, the command-line I used to generate the .i file was:
>
>
> filesystem.c
> C:\PROGRA~1\MICROS~3\VC98\INCLUDE\exdisp.h(3766) : fatal error C1070:
> mismatched #if/#endif pair in fi
> le 'C:\PROGRA~1\MICROS~3\VC98\INCLUDE\exdisp.h'
>
> The file date is consistent
This is true.
But since this is very annoying for plugin-developers, it would be
nevertheless very nice of the core coders to avoid changing the plugin-API
whenever possible. Especially I don't see the addition of enum values in the
middle of existing ones as a sufficiently strong reason for chang
Hello Sake,
Thanks for your answer.
For a plugin, it's a little bit a pitty to have to recompile it for each new
version of the software but ... that's life.
A good work around could be to have a function returning column number based
on ASCII column title. What do you thing about that ?
Thanks
On Wed, Oct 10, 2007 at 10:44:25AM +0200, Kukosa, Tomas wrote:
> I have updated this solution a little bit with the rev 23130.
> I hope we are near to a stable solution. :)
Seems OK. I updated, went to asn1/h225/, regenerated the Makefile,
did a make clean and both, "make" and "make generate_expor
On Wed, Oct 10, 2007 at 11:30:46AM +0200, Kukosa, Tomas wrote:
> > Thanks! Is there a reason why you modified M.am and M.nmake instead of
> > M.inc and M.inc.nmake in asn1/ ? That way I'll only need to change the
> > M.common files.
>
> The reason is that MAKE_CNF_EXPORT has to be defined before M
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=23128
> >
> > Log:
> > solution for different submake calling on Windows and Linux
> > only one dissector is committed to test it
> >
> > Directory: /trunk/asn1/h225/
> > ChangesPath Action
> > +2 -0 M
MessageHi Antoine,
Sorry for breaking your plugin-distribution, but it has been my understanding
that all plugins need to be compiled against the sources of the version you
want to use them with. So every Wireshark version has it's own plugin-binaries.
If sometimes plugins can be used with mult
Hi,
I'm writting a plugin for a specific protocol of my company and I found that
a recent change to the file column_info.h (rev 23058) introduce an issue
with the check_col function when the plugin is used with a previous version
of wireshark (ie 0.99.6).
The change had added two new columns in
On Wed, Oct 10, 2007 at 08:14:43AM +, [EMAIL PROTECTED] wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=23128
>
> Log:
> solution for different submake calling on Windows and Linux
> only one dissector is committed to test it
>
> Directory: /trunk/asn1/h225/
> Ch
> > > > BTW: format rules for dependency in Makefile.common files
> > does not work for Windows nmake. The $(MAKE) $(MAKEFLAGS)
> > does not work well.
> > >
> > > What exactly is not working well? What is a working syntax
> > with nmake?
> > >
> > > I was too lazy to investigate it till now.
> > > BTW: format rules for dependency in Makefile.common files
> does not work for Windows nmake. The $(MAKE) $(MAKEFLAGS)
> does not work well.
> >
> > What exactly is not working well? What is a working syntax
> with nmake?
> >
> > I was too lazy to investigate it till now. I will look at
On Tue, Oct 09, 2007 at 10:05:45PM +0200, Kukosa, Tomas wrote:
>
> > BTW: format rules for dependency in Makefile.common files does not work for
> > Windows nmake. The $(MAKE) $(MAKEFLAGS) does not work well.
>
> What exactly is not working well? What is a working syntax with nmake?
>
> I was
39 matches
Mail list logo
