ng on data that's in the packet.
Instead, it's just a nice warning message that something is wrong with the
packet format.
What's the best way to handle this?
(apologies if this has come to the list multiple times, we just changed our
mail system and I've not been seeing my own
That makes perfect sense.
Thanks for the explanation.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
Sent: Thursday, May 31, 2007 3:36 PM
To: Developer support list
instead of
throwing an error.
I'm still wondering why this makes a difference, though.
Thanks!
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent: Thursday, May 31, 2007 10:21 AM
To: D
I'll make that change, but can you point me to an explanation of the
difference between these two? I'm sure it's something to do with unsigned
versus signed, but why does it affect what I'm doing here?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
So I'm looking at the value strings, and I'm wondering why we should
terminate them with {0, NULL} and what happens if one of the value pairs
needs to be {0, "a real string"} ?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796
I think I understand... It's sort of like a null-terminated string, but it's
a null-terminated array?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796-1936
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
I think I understand... It's sort of like a null-terminated string, but it's
a null-terminated array?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent:
So I'm looking at the value strings, and I'm wondering why we should
terminate them with {0, NULL} and what happens if one of the value pairs
needs to be {0, "a real string"} ?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
-Original Messa
lem when I'm decoding
the TLVs.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796-1936
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent: Wednesday, May 30, 2007 10:42 AM
To: Developer sup
nd that those packets are also throwing the
error. In these cases we're nowhere close to the end of the tvbuff, so I
think that observation was bogus.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTEC
lue,
{"MIC Value", "wlccp.mic_value",
FT_UINT_BYTES, BASE_DEC, NULL, 0,
"MIC value", HFILL }
}
I get the error even if I set the value of mic_length to something I know
does not overrun the end of tvb.
I would greatly appreciate any suggestions on how to
printed when it aborts.
What does this exception mean and what might I be doing incorrectly to cause
this?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.
make display filtering dorky, I
think.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796-1936
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent: Wednesday, May 23, 2007 1:13 PM
To: Developer su
make display filtering dorky, I
think.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796-1936
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joerg Mayer
Sent: Wednesday, May 23, 2007 1:13 PM
To: Deve
v_type,
{ "TLV Type", "wlccp.wlccp_tlv_type",
FT_UINT8, BASE_DEC, VALS(wlccp_tlv_type_id), 0,
"TLV Type", HFILL}
}
I'm not a very good programmer, so I'm grasping for any help I can get.
Thanks!
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, I
er in the first two
bytes. The problem is that there are TLVs that are group=0x0, so I have to
potentially "poke" beyond the length of the packet to find out if there's a
real type value there.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED
uld be the
top layer protocol, so I wouldn't need to hand it off to another recipient.
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL PROTECTED]
+1-717-796-1936
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
Sent
's any other kind of TLV, it is likely to start
with a zero and then be followed by another value that indicates the actual
type.
How do I check for that second byte without reading past the end of the
packet buffer?
--kan--
--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Versatile, Inc.
[EMAIL P
What I've done so far has been contributed in bugzilla ticket 1522. I added
very high-level information to the decode that was already in the WLCCP
dissector.
I'm just now trying to dig deeper.
I'll give your example a try and see what happens.
Thanks!
--kan--
--
Kevin A. No
I need to be able to call the external EAPOL dissector and return to the
WLCCP dissector to finish dissecting the WLCCP headers and TLVs.
I would be much obliged if someone could give me a pointer on how to do this
and/or to a dissector that does something similar.
Thanks!
--kan--
--
Kevin A. No
20 matches
Mail list logo
