[Wireshark-dev] buildbot failure in Wireshark 1.2 on Windows-7-x64
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark 1.2. Full details are available at: http://buildbot.wireshark.org/trunk-1.2/builders/Windows-7-x64/builds/4 Buildbot URL: http://buildbot.wireshark.org/trunk-1.2/ Buildslave for this Build: windows-7-x64 Build Reason: Build Source Stamp: 32655 Blamelist: gerald BUILD FAILED: failed nmake all sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark 1.2 on Ubuntu-10.04-x64
The Buildbot has detected a new failure of Ubuntu-10.04-x64 on Wireshark 1.2. Full details are available at: http://buildbot.wireshark.org/trunk-1.2/builders/Ubuntu-10.04-x64/builds/2 Buildbot URL: http://buildbot.wireshark.org/trunk-1.2/ Buildslave for this Build: ubuntu-10.04-x64 Build Reason: Build Source Stamp: 32655 Blamelist: gerald BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark 1.2 on Windows-XP-x86
The Buildbot has detected a new failure of Windows-XP-x86 on Wireshark 1.2. Full details are available at: http://buildbot.wireshark.org/trunk-1.2/builders/Windows-XP-x86/builds/4 Buildbot URL: http://buildbot.wireshark.org/trunk-1.2/ Buildslave for this Build: windows-xp-x86 Build Reason: Build Source Stamp: 32655 Blamelist: gerald BUILD FAILED: failed nmake all sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Solaris-10-SPARC
The Buildbot has detected a new failure of Solaris-10-SPARC on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Solaris-10-SPARC/builds/126 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: solaris-10-sparc Build Reason: Build Source Stamp: 32653 Blamelist: wmeier BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Windows-XP-x86
The Buildbot has detected a new failure of Windows-XP-x86 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Windows-XP-x86/builds/149 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: windows-xp-x86 Build Reason: Build Source Stamp: 32650 Blamelist: etxrab,morriss,wmeier BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Windows-7-x64
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/164 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: windows-7-x64 Build Reason: Build Source Stamp: 32651 Blamelist: morriss BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Ubuntu-10.04-x64
The Buildbot has detected a new failure of Ubuntu-10.04-x64 on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/Ubuntu-10.04-x64/builds/6 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: ubuntu-10.04-x64 Build Reason: Build Source Stamp: 32649 Blamelist: etxrab,wmeier BUILD FAILED: failed compile_2 sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to implement Flow graph ?
On Mon, May 03, 2010 at 04:55:43PM -, nikhil tripathi wrote: > I done code browsing and go through wireshark developers guide but > couldn't find the way to add Flow graph property. A lot of involved functionality such as this is, for better or worse, not always documented other than by source code. > Could you suggest me how to implement this? Take a look at gtk/flow_graph.c for a start. It looks like a tap is used (doc/README.tapping). -- Steve ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb
On Mon, May 03, 2010 at 11:14:15AM -0400, Jeremy O'Brien wrote: > Actually, is there a function that will just get the length of said > string? I don't need to do anything with the string itself other than > add it to the proto_tree and of course increment my offset. You could use tvb_get_ephemeral_stringz() to both fetch the string (and allocate memory) along with setting the length variable (passing it by reference as the third parameter). Then add the string to the tree using proto_tree_add_string() and pass the string and the length variables starting at the offset variable (set to 0 before starting). Then increment offset by the length This is basically what I did in epan/dissectors/packet-exec.c, but the packet data sounds a bit different from what you're working with. In the (r)exec protocol, there are four null-terminated strings that it looks for. Although, as Guy mentioned, you will have trouble (a thrown exception) with this if the final string really doesn't have a null. Perhaps you could do a search (perhaps by using tvb_find_guint8 with '\0' as your needle [search term]) to see if there is a null coming up before looking for it, otherwise just grab the final string without a null (tvb_get_string). -- Steve ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 32633: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ip.c
On Sun, May 02, 2010 at 09:17:20PM +0200, Stig Bj?rlykke wrote:
> Where did the tree entry "Flags" go?
> It used to be above "Fragment offset".
Sorry, attaching patch to restore it.
Anyway I'm not so sure about this patch being commited.
(maybe Attachment #4559 was better fix?)
Can it be reverted, and first we discuss how issue with ip flags (and other of
these kind)
should be fixed?
Thanks.
diff --git epan/dissectors/packet-ip.c epan/dissectors/packet-ip.c
index 4aa60f9..a22856d 100644
--- epan/dissectors/packet-ip.c
+++ epan/dissectors/packet-ip.c
@@ -1308,7 +1308,7 @@ guint16 ip_checksum(const guint8 *ptr, int len)
static void
dissect_ip(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree)
{
- proto_tree *ip_tree = NULL, *field_tree= NULL;
+ proto_tree *ip_tree = NULL, *field_tree;
proto_item *ti = NULL, *tf;
guint32addr;
intoffset = 0;
@@ -1447,7 +1447,7 @@ dissect_ip(tvbuff_t *tvb, packet_info *pinfo, proto_tree
*parent_tree)
iph->ip_off = tvb_get_ntohs(tvb, offset + 6);
if (tree) {
int bit_offset = (offset + 6) * 8;
-tf = proto_tree_add_bits_item(field_tree, hf_ip_flags, tvb, bit_offset +
0, 3, FALSE);
+tf = proto_tree_add_bits_item(ip_tree, hf_ip_flags, tvb, bit_offset + 0,
3, FALSE);
field_tree = proto_item_add_subtree(tf, ett_ip_off);
if (ip_security_flag) {
proto_item *sf;
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb
On May 3, 2010, at 8:08 AM, Jeremy O'Brien wrote: > Separated by. ...which means you can't use tvb_get_stringz() - or tvb_strsize() - for the *last* string, as there's no NUL at the end. That means that, if you don't know which string is the last one, you can't use it for *any* string - it means that a string is terminated either by NUL or by the end of the packet. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] How to implement Flow graph ?
Hi All, I have added a new plugin in wireshark source code and able to dissect packets. Now i want to to do Flow graph (Statistics --->Flow Graph) flow graph analysis.I done code browsing and go through wireshark developers guide but couldn't find the way to add Flow graph property. Could you suggest me how to implement this? Regards Nikhil ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb
Maybe this is what you're looking for? >From epan/tvbuff.h: /** Find size of stringz (NUL-terminated string) by looking for terminating * NUL. The size of the string includes the terminating NUL. * * If the NUL isn't found, it throws the appropriate exception. */ extern guint tvb_strsize(tvbuff_t *tvb, const gint offset); - Chris -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jeremy O'Brien Sent: Monday, May 03, 2010 11:14 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb Actually, is there a function that will just get the length of said string? I don't need to do anything with the string itself other than add it to the proto_tree and of course increment my offset. I know I could just g_free the string immediately after fetching it, but this seems like it has a little overhead. [snip] CONFIDENTIALITY NOTICE: The contents of this email are confidential and for the exclusive use of the intended recipient. If you receive this email in error, please delete it from your system immediately and notify us either by email, telephone or fax. You should not copy, forward, or otherwise disclose the content of the email. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Voip Graph: Port numbers too faint?
Hi folks, I really like the new pastel color tones of VoIP Graph, but honestly, the port numbers are barely visible now. (see attached png) Could they be made a little darker? Regards, Lars wireshark 1.3.4 (SVN Rev 32342 from /trunk) Copyright 1998-2010 Gerald Combs and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled with GTK+ 2.16.6, with GLib 2.22.4, with WinPcap (version unknown), with libz 1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.8.5, with Gcrypt 1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Mar 31 2010), with AirPcap, with new_packet_list. Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.1 (packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap. Built using Microsoft Visual C++ 9.0 build 30729 <>___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb
Actually, is there a function that will just get the length of said string? I don't need to do anything with the string itself other than add it to the proto_tree and of course increment my offset. I know I could just g_free the string immediately after fetching it, but this seems like it has a little overhead. On Mon, May 3, 2010 at 11:08, Jeremy O'Brien wrote: > Separated by. tvb_get_stringz is exactly what I was looking for. Thank you! > > On Fri, Apr 30, 2010 at 15:42, Guy Harris wrote: >> >> On Apr 30, 2010, at 12:33 PM, Jeremy O'Brien wrote: >> >>> So I have several strings in my protocol, which are separated by >>> NULL's. >> >> Separated by, or terminated by? >> >> I.e., is there a NUL at the end of the *last* string, or just in *between* >> strings? >> >>> There is no information contained in the packet that gives the >>> length of each string. Is there a better way to add these strings to >>> the protocol dissection besides doing a tvb_get_ephemeral_string() on >>> the section of the tvb in question, searching for the ending NULL's >>> for each string, and manually incrementing the offset for each one? >>> I'm just not sure if wireshark has any convenience functions that >>> would handle this sort of situation. >> >> /** >> * Given a tvbuff and an offset, with the offset assumed to refer to >> * a null-terminated string, find the length of that string (and throw >> * an exception if the tvbuff ends before we find the null), allocate >> * a buffer big enough to hold the string, copy the string into it, >> * and return a pointer to the string. Also return the length of the >> * string (including the terminating null) through a pointer. >> * >> * tvb_get_stringz() returns a string allocated by g_malloc() and therefore >> * MUST be g_free() by the caller in order not to leak >> * memory. >> * >> * tvb_get_ephemeral_stringz() returns a string that does not need to be >> freed, >> * instead it will automatically be freed once the next >> * packet is dissected. >> * >> * tvb_get_seasonal_stringz() returns a string that does not need to be >> freed, >> * instead it will automatically be freed when a new >> capture >> * or file is opened. >> */ >> extern guint8 *tvb_get_stringz(tvbuff_t *tvb, const gint offset, gint >> *lengthp); >> extern guint8 *tvb_get_ephemeral_stringz(tvbuff_t *tvb, const gint offset, >> gint *lengthp); >> extern guint8 *tvb_get_seasonal_stringz(tvbuff_t *tvb, const gint offset, >> gint *lengthp); >> >> You presumably want tvb_get_ephemeral_stringz(). >> ___ >> Sent via: Wireshark-dev mailing list >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe >> > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?
Bill Meier wrote: > Kaul wrote: >> On Mon, May 3, 2010 at 4:47 PM, Anders Broman >> wrote: >> >>> Hi, >>> Note that packet-kerberos-template.c isn't used to generate >>> packet-kerberos.c currently, I would guess >>> that the info in packet-kerberos-template.c is copied from the current hand >>> written dissector. >>> Regards >>> Anders >>> >> >> Yes, I've just discovered that. And indeed, changing the value in >> packet-kerberos.c seems to solve the issue. >> Y. >> >> > > When I looked at this some time back, I convinced myself (ISTR via > testing) that the 'dissect_ber_integer' in 'dissect_krb5_PA_DATA_type' > returned a 32-bit 'FF80' for a KRB5_PA_PAC_REQUEST byte of 0x80. > > The same appeared to also be true for KRB5_PA_S4U2SELF & > KRB5_PA_PROV_SRV_LOCATION. > > > Can you supply a capture so I can look into this ??? > > (Maybe the best way is to create a bug report and attach a capture file. > You can mark the attachment as private if needed). > > Thanks > > Bill > > > PS: remembering a bit more: This was my attempt to fix bug #4363. Suggestions are welcome as to a better fix ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Best way to handle a variable-length NULL-terminated string in a tvb
Separated by. tvb_get_stringz is exactly what I was looking for. Thank you! On Fri, Apr 30, 2010 at 15:42, Guy Harris wrote: > > On Apr 30, 2010, at 12:33 PM, Jeremy O'Brien wrote: > >> So I have several strings in my protocol, which are separated by >> NULL's. > > Separated by, or terminated by? > > I.e., is there a NUL at the end of the *last* string, or just in *between* > strings? > >> There is no information contained in the packet that gives the >> length of each string. Is there a better way to add these strings to >> the protocol dissection besides doing a tvb_get_ephemeral_string() on >> the section of the tvb in question, searching for the ending NULL's >> for each string, and manually incrementing the offset for each one? >> I'm just not sure if wireshark has any convenience functions that >> would handle this sort of situation. > > /** > * Given a tvbuff and an offset, with the offset assumed to refer to > * a null-terminated string, find the length of that string (and throw > * an exception if the tvbuff ends before we find the null), allocate > * a buffer big enough to hold the string, copy the string into it, > * and return a pointer to the string. Also return the length of the > * string (including the terminating null) through a pointer. > * > * tvb_get_stringz() returns a string allocated by g_malloc() and therefore > * MUST be g_free() by the caller in order not to leak > * memory. > * > * tvb_get_ephemeral_stringz() returns a string that does not need to be > freed, > * instead it will automatically be freed once the next > * packet is dissected. > * > * tvb_get_seasonal_stringz() returns a string that does not need to be freed, > * instead it will automatically be freed when a new capture > * or file is opened. > */ > extern guint8 *tvb_get_stringz(tvbuff_t *tvb, const gint offset, gint > *lengthp); > extern guint8 *tvb_get_ephemeral_stringz(tvbuff_t *tvb, const gint offset, > gint *lengthp); > extern guint8 *tvb_get_seasonal_stringz(tvbuff_t *tvb, const gint offset, > gint *lengthp); > > You presumably want tvb_get_ephemeral_stringz(). > ___ > Sent via: Wireshark-dev mailing list > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?
Kaul wrote: > On Mon, May 3, 2010 at 4:47 PM, Anders Broman > wrote: > >> Hi, >> Note that packet-kerberos-template.c isn't used to generate >> packet-kerberos.c currently, I would guess >> that the info in packet-kerberos-template.c is copied from the current hand >> written dissector. >> Regards >> Anders >> > > > Yes, I've just discovered that. And indeed, changing the value in > packet-kerberos.c seems to solve the issue. > Y. > > When I looked at this some time back, I convinced myself (ISTR via testing) that the 'dissect_ber_integer' in 'dissect_krb5_PA_DATA_type' returned a 32-bit 'FF80' for a KRB5_PA_PAC_REQUEST byte of 0x80. The same appeared to also be true for KRB5_PA_S4U2SELF & KRB5_PA_PROV_SRV_LOCATION. Can you supply a capture so I can look into this ??? (Maybe the best way is to create a bug report and attach a capture file. You can mark the attachment as private if needed). Thanks Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?
On Mon, May 3, 2010 at 4:47 PM, Anders Broman wrote: > Hi, > Note that packet-kerberos-template.c isn't used to generate > packet-kerberos.c currently, I would guess > that the info in packet-kerberos-template.c is copied from the current hand > written dissector. > Regards > Anders > Yes, I've just discovered that. And indeed, changing the value in packet-kerberos.c seems to solve the issue. Y. > > -- > *From:* wireshark-dev-boun...@wireshark.org [mailto: > wireshark-dev-boun...@wireshark.org] *On Behalf Of *Kaul > *Sent:* den 3 maj 2010 14:04 > *To:* Developer support list for Wireshark > *Subject:* [Wireshark-dev] Kerberos pre-auth type constants - MS > extensions are wrong? > > It appears like MS extensions for Kerberos pre-auth type constants, such > as: > #define KRB5_PA_PAC_REQUEST -128 /* = 0xFF80 = > (gint32)((gint8)0x80) MS extension */ > > are wrong - should be 128 (which is 0x80 btw), for example, based on a > capture I've done and on > http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf(see > section 3.1.5.1) > Is it OK to fix them in packet-kerberos-template.c? Anyone knows where the > mistake comes from? > > TIA, > Y. > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?
Hi, Note that packet-kerberos-template.c isn't used to generate packet-kerberos.c currently, I would guess that the info in packet-kerberos-template.c is copied from the current hand written dissector. Regards Anders From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Kaul Sent: den 3 maj 2010 14:04 To: Developer support list for Wireshark Subject: [Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong? It appears like MS extensions for Kerberos pre-auth type constants, such as: #define KRB5_PA_PAC_REQUEST -128 /* = 0xFF80 = (gint32)((gint8)0x80) MS extension */ are wrong - should be 128 (which is 0x80 btw), for example, based on a capture I've done and on http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf (see section 3.1.5.1) Is it OK to fix them in packet-kerberos-template.c? Anyone knows where the mistake comes from? TIA, Y. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Kerberos pre-auth type constants - MS extensions are wrong?
It appears like MS extensions for Kerberos pre-auth type constants, such as: #define KRB5_PA_PAC_REQUEST -128 /* = 0xFF80 = (gint32)((gint8)0x80) MS extension */ are wrong - should be 128 (which is 0x80 btw), for example, based on a capture I've done and on http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf(see section 3.1.5.1) Is it OK to fix them in packet-kerberos-template.c? Anyone knows where the mistake comes from? TIA, Y. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
