Re: [Wireshark-dev] DISSECTOR_ASSERT_NOT_REACHED in WLCCP decode...

On Tue, May 29, 2007 at 09:54:56AM -0400, Kevin A. Noll wrote: > I am building on Suse Linux. Me too. > I'd be happy to post the entire dissector and a sample capture file if > someone has the time to look at it. Yes please as long as the capture file isn't excessivly large. Ciao Joerg --

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

Guy Harris wrote: > Jeff Morriss wrote: >> Guy Harris wrote: >>> Jeff Morriss wrote: Problem is that how you print 64-bit numbers varies. %llu doesn't always work >>> ...and neither does "long long" as a data type. >>> (for example the Windoze buildbot is now red). Instead the

Re: [Wireshark-dev] Missing files inwireshark-0.99.6-SVN-XXXXX.tar.gz

|> Anyone knows why those files are missing? | |Because they were missing from asn1/Makefile.am. I've checked in a fix. Thanks! ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Missing files in wireshark-0.99.6-SVN-XXXXX.tar.gz

On May 29, 2007, at 6:34 PM, SAWADA Kentaro wrote: > Anyone knows why those files are missing? Because they were missing from asn1/Makefile.am. I've checked in a fix. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/

[Wireshark-dev] Missing files in wireshark-0.99.6-SVN-XXXXX.tar.gz

Hi all, I downloaded source codes a few times from http://www.wireshark.org/download/automated/src/ but the "distclean" on Windows XP (VC++) always failed due to the lack of the following files or directory. /asn1/mpeg/Makefile.nmake /asn1/pkcs12 /asn1/pkcs12/Makefile

Re: [Wireshark-dev] [Wireshark-commits] rev 21995: /trunk/ /trunk/: acinclude.m4

On May 29, 2007, at 4:29 PM, [EMAIL PROTECTED] wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21995 > > User: sahlberg > Date: 2007/05/29 11:29 PM > > Log: > we dont link with g_snprintf in the configure for gtk1-2 We appear to *use* g_snprintf in the build for GTK+ 1.

Re: [Wireshark-dev] packet-v5ua.c

OK, sounds good. I'll change that. Best regards Michael On May 29, 2007, at 10:04 PM, Luis Ontanon wrote: > On 5/29/07, Stephen Fisher <[EMAIL PROTECTED]> wrote: >> On Tue, May 29, 2007 at 07:59:59AM +0200, Michael Tuexen wrote: >> >>> is there any reason why the V5UA plugin does not use the IAN

Re: [Wireshark-dev] packet-v5ua.c

On 5/29/07, Stephen Fisher <[EMAIL PROTECTED]> wrote: > On Tue, May 29, 2007 at 07:59:59AM +0200, Michael Tuexen wrote: > > > is there any reason why the V5UA plugin does not use the IANA > > registered port 5675, but 10001? The code just says: > > I'm not sure. > > > /* In RFC specification the SC

[Wireshark-dev] Problems with asn2wrs -X option for LDAP

Hi, Without the -X option this code snippet looks like: static int dissect_vals_item(proto_tree *tree _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_) { return dissect_ldap_AttributeValue(FALSE, tvb, offset, actx, tree, hf_ldap_vals_item); } static const ber_old_sequ

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

Guy Harris wrote: > Jeff Morriss wrote: ... >> Should the PRI*64 macros (which I just recently started adding--meaning >> there were some there before, it's just that only recently did /I/ add >> some) be replaced with G_GINT64_MODIFIER? > > Yes I've done that. > (except for calls th

Re: [Wireshark-dev] packet-v5ua.c

On Tue, May 29, 2007 at 07:59:59AM +0200, Michael Tuexen wrote: > is there any reason why the V5UA plugin does not use the IANA > registered port 5675, but 10001? The code just says: I'm not sure. > /* In RFC specification the SCTP registered User Port Number > Assignment for V5UA is 5675 */

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

Jeff Morriss wrote: > > Guy Harris wrote: >> Jeff Morriss wrote: >>> Problem is that how you print 64-bit numbers varies. %llu doesn't >>> always work >> ...and neither does "long long" as a data type. >> >>> (for example the Windoze buildbot is now red). Instead the >>> PRI*64 macros should b

Re: [Wireshark-dev] patch for new encapsulation protocol FCoE - FibreChannel over Ethernet

*> From*: Jaap Keuter <[EMAIL PROTECTED] > *> **Date*: Thu, 24 May 2007 08:13:56 +0200 (CEST) *> *Hi, *> *The code looks oke, one question though. Why is the ethertype in a *> *preference? Are there non-IEEE-ethertype-standard implementations in the *> *wild, or is thi

Re: [Wireshark-dev] DISSECTOR_ASSERT_NOT_REACHED in WLCCP decode...

I am building on Suse Linux. I checked the ulimit setting and it was already set to unlimited (I reset it anyway). I don't see any core files anywhere in the directories that I'm working with. I'm assuming it would drop the core file in the current running directory? I changed the display for th

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

sorry for the inconvenience. Regards, Sebastien Tandel On 29 May 2007, at 05:39, Jeff Morriss wrote: Guy Harris wrote: Jeff Morriss wrote: Problem is that how you print 64-bit numbers varies. %llu doesn't always work ...and neither does "long long" as a data type. (for example the Wind

[Wireshark-dev] Compiler flag ignored on VS 2005

FWIW the compiler options for packet-rrc.c in epan/dissectors/Makefile.nmake are ignored on VS2005 as the -Zd flag no longer exists: # disabled debug for large dissectors packet-rrc.obj : packet-rrc.c $(CC) $(CVARSDLL) $(CFLAGS) -Zd -Fd.\ -c $? I presume this does achieve something on MSVC6.

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

Guy Harris wrote: > Jeff Morriss wrote: >> Problem is that how you print 64-bit numbers varies. %llu doesn't >> always work > > ...and neither does "long long" as a data type. > >> (for example the Windoze buildbot is now red). Instead the >> PRI*64 macros should be used. > > Or the G_GINT

Re: [Wireshark-dev] [PATCH] Fix compilation failures on x86_64-unknown-linux-gnu

Jeff Morriss wrote: > Problem is that how you print 64-bit numbers varies. %llu doesn't > always work ...and neither does "long long" as a data type. > (for example the Windoze buildbot is now red). Instead the > PRI*64 macros should be used. Or the G_GINT64_MODIFIER macro. I seem to rememb