I suppose the difference here would be that you can't use the
"contains" keyword with "opcode" to do partial string matches. But
that's not nearly as useful with NFSv4 as with protocols with longer,
more complex names and/or many similar names (with roughly the sam
You're right - that's not a new issue in 33458. 33457 has the same problem.
-Ian
On Thu, Jul 8, 2010 at 4:21 AM, Guy Harris wrote:
> Did the build before 33458 work on PPC? I suspect not - that's an issue of
> the libraries with which wireshark-bin is built, and wir
r33458 Intel 64-bit now works for me. A couple of recent builds,
including 33452, did not (32-bit did and still does).
r33458 PPC crashes for me, with:
2010-07-07 11:31:06.785 defaults[24422:10b]
The domain/default pair of (kCFPreferencesAnyApplication,
AppleAquaColorVariant) does not exist
2010
Coincidentally,I happened to notice earlier today that automated x64
builds are happening now, and noticed that they're having the same
problem.
On Tue, Jul 6, 2010 at 9:13 PM, Sake Blok wrote:
> Great, that did the trick. I think we need to make SDKROOT determined at
> compile time so that the
Have you investigated just how much work is involved already and still
interested in pursuing this?
2010/6/9 luoyantai :
> And i have an another question,the dissectors,are they depend on
> platform?need i do some changes?
>
_
Thanks again, Guy. I'll think about it for a bit, but that's very
possibly what I'll do.
On Wed, Jun 2, 2010 at 6:57 PM, Guy Harris wrote:
>
> On Jun 1, 2010, at 10:10 PM, Ian Schorr wrote:
>
>> As you mention later, MS Visual Studio 2008 does not include those
>
On Wed, Jun 2, 2010 at 3:03 PM, Jaap Keuter wrote:
> Hi,
>
> With "%lu" you tell sprintf to expect a 32 bit value on the stack,
> while in fact you put 64 bit sized value 0 there. That reads like two
> times 32 bit sized value 0, hence the results you see.
>
> The rest is left as an exercise to th
On Wed, Jun 2, 2010 at 2:57 PM, Guy Harris wrote:
>
> On Jun 1, 2010, at 9:01 PM, Ian Schorr wrote:
>
> If you want the code to be portable, you'd have to hope that Microsoft
> provides the C99 PRI[doux]64 macros, even though Visual Studio doesn't claim
> to suppo
ike
it's actually being write twice, and sprintf is getting confused about
what to write where. g_sprintf has the same problem as well.
Bizarre.
Thanks,
Ian
On Wed, Jun 2, 2010 at 2:44 PM, Guy Harris wrote:
>
> On Jun 1, 2010, at 9:01 PM, Ian Schorr wrote:
>
>> The weird thing
ve
done something silly, though having a tough time guessing where.
I haven't tested yet to see if this is something specific to the dev
platform I'm using. At the moment that's Windows.
Thanks,
Ian
___
Yes, I believe a lot of those changes for MSVC2005/etc came in after 0.99.8.
On Mon, Jan 18, 2010 at 8:18 PM, Anders Broman
wrote:
> Hi,
> Didn't we make changes to the 1.x branch to make it compile with something
> else than MSVC6?
> As ian says why not try a recent version
Just curious - why are you trying to compile a 2 year old version?
On Mon, Jan 18, 2010 at 7:24 PM, Varun Gupta wrote:
> Hi All,
>
>
>
> I am trying to build wireshak 99.8.0 on my windows XP machine and facing an
> issue. I am using MS Visual C++ 2005EE for building the code.
>
> While compiling
Why the "please report this to the wireshark developers" message then?
On 16/01/2010, at 8:59 AM, Guy Harris wrote:
>
> On Jan 14, 2010, at 12:51 PM, Ing. Rodrigo Castro wrote:
>
>> Hi all. I am getting the following error:
>>
>> "
>> Error while capturing packets: read error: PacketReceivePacke
explit ASSERT but Wireshark is
printing nothing to the console.
Anyway, I've fixed all the bugs that are affecting processing of the
NFSv4 replies I've been working with - now I need to work through the
bugs affecting the calls.
Fortunately the bugs aren't my code =)
Thanks,
Ia
NFSv4 dissecting is doing at this point, it seems unusual. But I'll
keep looking. Thanks for the tip.
I'm still not clear on why your example is a problem though - what's
the logic error in doing this test during an "if (tree)" block?
Thanks,
Ian
__
more about how/when this flag would be changed, and
what a dissector could that would lead to a "second processing pass"
where this flag is set, I'd have a better chance of figuring out what
I can do about the prob
#3 is probably the "best" if you're willing to share the source and think
the code would be of use to others.
Advantages:
- Less work for you in the long run.
- Each time a new release of Wireshark comes out with changes that you
want, you'd need to release a newer version of your "custom" Wires
Very cool, I'll have to try it when I get home. Next big step would to make
it a self-contained binarily-distributable appbundle =)
On Wed, Oct 22, 2008 at 3:52 PM, Stephen Fisher <[EMAIL PROTECTED]>wrote:
> The native MacOS X GTK port is now in beta and a easy to install
> framework is availabl
I suppose this thread probably would be better to send to the developer list
at this point - so doing so.
On Sat, Aug 16, 2008 at 6:21 PM, Ian Schorr <[EMAIL PROTECTED]> wrote:
> Actually, now that I have a look at the Application Bundles...
>
> I see that in Wireshark 1.
Regards,
Ian
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
eason:
An incorrect mask when decoding 4 character SICs (with characters
[A-Z0-9]) results in data being lost:
bytes = 3;
value = (tvb_get_ntohl (tvb, offset) >> 8) & 0x1FF; The first
line correctly indicates that there is 3 bytes worth of data, but the
mask only caters for 2 b
This would be great. I've been wanting something like this for years. I've
been getting by using the -z "proto,colinfo" option, but there are so many
cases where it isn't ideal for scripted parsing or importing decoded output
into other tools.
This plus a more advanced MATE would be a dream com
that need to be made (i.e. a handful of fields that aren't
decoded) but the dissector is overall fairly complete and very usable.
Let me know if there are questions or feedback, or otherwise if other info
is needed (like sample captures, which I don't want to send out to the
mailing list)
On 1/6/07, Ulf Lamping < [EMAIL PROTECTED]> wrote:
>
> >
> > Ian wrote:
> > > I'm a Wireshark user and not a member of this list, so apologies if
> > > posting as a non-member is inappropriate. I will subscribe to the list
> > > if needs be.
rk is
passing bad data to the WinPcap driver?
Does anyone have any suggestions as to what I might try next?
Many thanks
Ian
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Hi,
The attached file should fix the following two bugs in the AJP dissector.
1) The dissector doesn't know about CPING/CPONG
2) The dissector misinterprets multiple requests in one connection if a
prior request has a Body request part.
Yours,
Ian
--
Ian Abel <[EMAIL PROTECTED]&
26 matches
Mail list logo
