date:20130731

[Wireshark-dev] Problems building installer on Windows 8

2013-07-31 Thread John OSullivan

Hi,

 

I have downloaded the latest code for wireshark to build on a Windows 8 (64
bit) machine.

I am building an x86 version and  can build all stages up to 

nmake -f Makefile.nmake packaging

At this point it fails with an error:

Internal Compiler Error: Installers shell constants are different than
uninstallers

Fatal error U1077:  makensis.exe

 

Any ideas why this step is failing?

 

 

___
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] Problems building installer on Windows 8

2013-07-31 Thread Anders Broman

Hi,
Have you set WIRESHARK_TARGET_PLATFORM=win32
And run .. \"vcvarsall.bat x86

Regards
Anders
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of John OSullivan
Sent: den 31 juli 2013 11:17
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Problems building installer on Windows 8

Hi,

I have downloaded the latest code for wireshark to build on a Windows 8 (64 
bit) machine.
I am building an x86 version and  can build all stages up to
nmake -f Makefile.nmake packaging
At this point it fails with an error:
Internal Compiler Error: Installers shell constants are different than 
uninstallers
Fatal error U1077:  makensis.exe

Any ideas why this step is failing?

___
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] Feeding the 802.15.4 Dissector

2013-07-31 Thread Rui Pedro Caldeira

Hey Tomasz, thanks for the anwser. But my main question is how to write the
bytes into the pipe so that Wireshark recognizes them as IEEE 802.15.4
packets, kinda like a structure that Wireshark is waiting for. I cannot
just write the packet into the pipe, Wireshark gives me an error :S

Thanks again

Cumprimentos,
Rui Pedro Caldeira


On Wed, Jul 31, 2013 at 6:35 AM, Tomasz Moń  wrote:

> On Tue, Jul 30, 2013 at 3:49 PM, Rui Pedro Caldeira
>  wrote:
> > Hello, I'm using Wireshark to read from a pipe and i'm using the native
> IEEE
> > 802.15.4 dissector, but I'm having trouble feeding Wireshark the proper
> > bytes. I've tried to search but I can't find the right sequence of bytes
> the
> > dissector is waiting for.
> >
> > Can anyone help me? Thanks in advance.
>
> Not sure if that's exactly what you are asking for, but:
>
> 802.15.4 dissector does following in proto_reg_handoff_ieee802154:
>
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE802_15_4,
> ieee802154_handle);
> dissector_add_uint("wtap_encap",
> WTAP_ENCAP_IEEE802_15_4_NONASK_PHY, ieee802154_nonask_phy_handle);
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE802_15_4_NOFCS,
> ieee802154_nofcs_handle);
> dissector_add_uint("sll.ltype", LINUX_SLL_P_IEEE802154,
> ieee802154_handle);
>
> If you look into wiretap/pcap-common.c you will find that following
> linktypes are assigned for the WTAP_ENCAP_ defines:
>
> /* IEEE 802.15.4 Wireless PAN */
> { 195, WTAP_ENCAP_IEEE802_15_4 },
> ...
> /* IEEE 802.15.4 Wireless PAN non-ASK PHY */
> { 215, WTAP_ENCAP_IEEE802_15_4_NONASK_PHY },
> ...
> /* IEEE 802.15.4 Wireless PAN no fcs */
> { 230, WTAP_ENCAP_IEEE802_15_4_NOFCS },
>
> Now, get over to the tcpdump linktypes [1] and check the descriptions
> for 195, 215, 230. Choose the one that is closest match to your data
> and then set that number as linktype in pcap header.
>
> [1] http://www.tcpdump.org/linktypes.html
> ___
> 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] Feeding the 802.15.4 Dissector

2013-07-31 Thread Guy Harris

On Jul 31, 2013, at 2:46 AM, Rui Pedro Caldeira  wrote:

> Hey Tomasz, thanks for the anwser. But my main question is how to write the 
> bytes into the pipe so that Wireshark recognizes them as IEEE 802.15.4 
> packets, kinda like a structure that Wireshark is waiting for. I cannot just 
> write the packet into the pipe, Wireshark gives me an error :S

You don't write packets to a pipe on which Wireshark is capturing; you write a 
byte stream that looks either like a pcap file:

http://www.tcpdump.org/manpages/pcap-savefile.5.html

or looks like a pcap-ng file:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html

Those types of file *include* packets, but they include more than just packet 
data.

So:

If you're writing a pcap file, the *first* thing you have to write is a pcap 
file header, including a "link-layer header type" value corresponding to the 
802.15.4 format you're using (see the LINKTYPE_ values in the tcpdump.org page 
Tomasz mentioned), and then, for each packet, a pcap per-packet header followed 
by the raw packet data.

If you're writing a pcap-ng file, the *first* thing you have to write is a 
Section Header Block:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionshb

followed by an Interface Description Block:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb

including a "LinkType" value corresponding the the 802.15.4 format you're using 
(see the LINKTYPE_ values in the tcpdump.org page Tomasz mentioned), and then, 
for each packet, an Enhanced Packet Block:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionepb

or, if you don't have time stamps for the packets, a Simple Packet Block:

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionpbs

containing the raw packet data.
___
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] Feeding the 802.15.4 Dissector

2013-07-31 Thread Rui Pedro Caldeira

Thank You so much Guy and Tomasz, that was exactly what I was looking for.

Best Regards,
Rui

Cumprimentos,
Rui Pedro Caldeira


On Wed, Jul 31, 2013 at 11:17 AM, Guy Harris  wrote:

>
> On Jul 31, 2013, at 2:46 AM, Rui Pedro Caldeira 
> wrote:
>
> > Hey Tomasz, thanks for the anwser. But my main question is how to write
> the bytes into the pipe so that Wireshark recognizes them as IEEE 802.15.4
> packets, kinda like a structure that Wireshark is waiting for. I cannot
> just write the packet into the pipe, Wireshark gives me an error :S
>
> You don't write packets to a pipe on which Wireshark is capturing; you
> write a byte stream that looks either like a pcap file:
>
> http://www.tcpdump.org/manpages/pcap-savefile.5.html
>
> or looks like a pcap-ng file:
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
>
> Those types of file *include* packets, but they include more than just
> packet data.
>
> So:
>
> If you're writing a pcap file, the *first* thing you have to write is a
> pcap file header, including a "link-layer header type" value corresponding
> to the 802.15.4 format you're using (see the LINKTYPE_ values in the
> tcpdump.org page Tomasz mentioned), and then, for each packet, a pcap
> per-packet header followed by the raw packet data.
>
> If you're writing a pcap-ng file, the *first* thing you have to write is a
> Section Header Block:
>
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionshb
>
> followed by an Interface Description Block:
>
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb
>
> including a "LinkType" value corresponding the the 802.15.4 format you're
> using (see the LINKTYPE_ values in the tcpdump.org page Tomasz
> mentioned), and then, for each packet, an Enhanced Packet Block:
>
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionepb
>
> or, if you don't have time stamps for the packets, a Simple Packet Block:
>
>
> http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionpbs
>
> containing the raw packet data.
> ___
> 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

[Wireshark-dev] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

2013-07-31 Thread Richard Sharpe

Hi folks,

This patch needs to be applied:

Index: epan/dissectors/packet-smb2.c
===
--- epan/dissectors/packet-smb2.c   (revision 51065)
+++ epan/dissectors/packet-smb2.c   (working copy)
@@ -7100,8 +7100,8 @@ proto_register_smb2(void)
{ "NT Status", "smb2.nt_status", FT_UINT32, BASE_HEX,
VALS(NT_errors), 0, "NT Status code", HFILL }},
{ &hf_smb2_seqnum,
-   { "Command Sequence Number", "smb2.seq_num", FT_INT64, BASE_DEC,
-   NULL, 0, "SMB2 Command Sequence Number", HFILL }},
+   { "Message ID", "smb2.msg_id", FT_INT64, BASE_DEC,
+   NULL, 0, "SMB2 Messsage ID", HFILL }},
{ &hf_smb2_tid,
{ "Tree Id", "smb2.tid", FT_UINT32, BASE_HEX,
NULL, 0, "SMB2 Tree Id", HFILL }},

See section 2.2.1.1. The field is called the Message ID, not the
Command Sequence Number.

That confusion has probably caused one of the WAN Accelerator
companies to break SMB2 Signing by mishandling that field. Not sure
which one it is, since the customer hasn't told me whose WAN
Accelerator they use. (Hint, it is possible for those numbers to be
out of order in a TCP stream.)

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
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] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

2013-07-31 Thread Jeff Morriss

On 07/31/13 09:00, Richard Sharpe wrote:
> Hi folks,
> 
> This patch needs to be applied:

Checked in r51066.

___
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] Feeding the 802.15.4 Dissector

2013-07-31 Thread Rui Pedro Caldeira

Hey Tomasz, thanks for the anwser. But my main question is how to write the
bytes into the pipe so that Wireshark recognizes them as IEEE 802.15.4
packets, kinda like a structure that Wireshark is waiting for. I cannot
just write the packet into the pipe, Wireshark gives me an error :S

Thanks again

Cumprimentos,
Rui Pedro Caldeira
Mestrado em Engenharia Informática
Departamento de Informática
Faculdade de Ciências da Universidade de Lisboa
http://webpages.alunos.fc.ul.pt/~fc38848


On Wed, Jul 31, 2013 at 6:35 AM, Tomasz Moń  wrote:

> On Tue, Jul 30, 2013 at 3:49 PM, Rui Pedro Caldeira
>  wrote:
> > Hello, I'm using Wireshark to read from a pipe and i'm using the native
> IEEE
> > 802.15.4 dissector, but I'm having trouble feeding Wireshark the proper
> > bytes. I've tried to search but I can't find the right sequence of bytes
> the
> > dissector is waiting for.
> >
> > Can anyone help me? Thanks in advance.
>
> Not sure if that's exactly what you are asking for, but:
>
> 802.15.4 dissector does following in proto_reg_handoff_ieee802154:
>
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE802_15_4,
> ieee802154_handle);
> dissector_add_uint("wtap_encap",
> WTAP_ENCAP_IEEE802_15_4_NONASK_PHY, ieee802154_nonask_phy_handle);
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE802_15_4_NOFCS,
> ieee802154_nofcs_handle);
> dissector_add_uint("sll.ltype", LINUX_SLL_P_IEEE802154,
> ieee802154_handle);
>
> If you look into wiretap/pcap-common.c you will find that following
> linktypes are assigned for the WTAP_ENCAP_ defines:
>
> /* IEEE 802.15.4 Wireless PAN */
> { 195, WTAP_ENCAP_IEEE802_15_4 },
> ...
> /* IEEE 802.15.4 Wireless PAN non-ASK PHY */
> { 215, WTAP_ENCAP_IEEE802_15_4_NONASK_PHY },
> ...
> /* IEEE 802.15.4 Wireless PAN no fcs */
> { 230, WTAP_ENCAP_IEEE802_15_4_NOFCS },
>
> Now, get over to the tcpdump linktypes [1] and check the descriptions
> for 195, 215, 230. Choose the one that is closest match to your data
> and then set that number as linktype in pcap header.
>
> [1] http://www.tcpdump.org/linktypes.html
> ___
> 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

[Wireshark-dev] Wireshark trunk does not compile without HAVE_LIBGNUTLS

2013-07-31 Thread Anders Broman

Index: epan/dissectors/packet-ssl-utils.h
===
--- epan/dissectors/packet-ssl-utils.h  (revision 2107)
+++ epan/dissectors/packet-ssl-utils.h  (working copy)
@@ -30,6 +30,7 @@

#include 
#include 
+#include 

#ifdef HAVE_LIBGNUTLS
#include 
@@ -39,7 +40,6 @@
#include 
#include "ws_symbol_export.h"

-#include 

/* #define SSL_FAST 1 */
#define SSL_DECRYPT_DEBUG
___
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] Problems building installer on Windows 8

2013-07-31 Thread John OSullivan

Yes,
I have set WIRESHARK_TARGET_PLATFORM=win32 And run .. \"vcvarsall.bat x86
And generally followed instructions on:
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

nmake -f Makefile.nmake all
builds without error
Everything builds fine up to the build of the installer:
nmake -f Makefile.nmake packaging
which then fails with

Internal Compiler Error: Installers shell constants are different than
uninstallers

Fatal error U1077:  makensis.exe

--

Message: 7
Date: Wed, 31 Jul 2013 10:16:47 +0100
From: "John OSullivan" 
To: 
Subject: [Wireshark-dev] Problems building installer on Windows 8
Message-ID:
<001e01ce8dce$afe08770$0fa19650$@osulli...@cloudiumsystems.com>
Content-Type: text/plain; charset="us-ascii"

Hi,

 

I have downloaded the latest code for wireshark to build on a Windows 8 (64
bit) machine.

I am building an x86 version and  can build all stages up to 

nmake -f Makefile.nmake packaging

At this point it fails with an error:

Internal Compiler Error: Installers shell constants are different than
uninstallers

Fatal error U1077:  makensis.exe

 

Any ideas why this step is failing?

 

 

-- next part --
An HTML attachment was scrubbed...
URL:
<http://www.wireshark.org/lists/wireshark-dev/attachments/20130731/8c03efa0/
attachment.html>

--

Message: 8
Date: Wed, 31 Jul 2013 09:25:07 +
From: Anders Broman 
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Problems building installer on Windows 8
Message-ID:
<43c5658ba3fb7b48a6f38eed0b6253f11a676...@esessmb105.ericsson.se>
Content-Type: text/plain; charset="us-ascii"

Hi,
Have you set WIRESHARK_TARGET_PLATFORM=win32 And run .. \"vcvarsall.bat x86

Regards
Anders
*

___
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 trunk does not compile without HAVE_LIBGNUTLS

2013-07-31 Thread Evan Huus

Sorry about that, fixed in r51067.

On Wed, Jul 31, 2013 at 11:28 AM, Anders Broman
 wrote:
> Index: epan/dissectors/packet-ssl-utils.h
>
> ===
>
> --- epan/dissectors/packet-ssl-utils.h  (revision 2107)
>
> +++ epan/dissectors/packet-ssl-utils.h  (working copy)
>
> @@ -30,6 +30,7 @@
>
>
>
> #include 
>
> #include 
>
> +#include 
>
>
>
> #ifdef HAVE_LIBGNUTLS
>
> #include 
>
> @@ -39,7 +40,6 @@
>
> #include 
>
> #include "ws_symbol_export.h"
>
>
>
> -#include 
>
>
>
> /* #define SSL_FAST 1 */
>
> #define SSL_DECRYPT_DEBUG
>
>
> ___
> 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] Problems building installer on Windows 8

2013-07-31 Thread Anders Broman

Hi,
No real clues...does if fail building for 64bit as well? Not sure how many 
builds on Win 8. I have Win 7.

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of John OSullivan
Sent: den 31 juli 2013 17:40
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Problems building installer on Windows 8

Yes,
I have set WIRESHARK_TARGET_PLATFORM=win32 And run .. \"vcvarsall.bat x86 And 
generally followed instructions on:
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

nmake -f Makefile.nmake all
builds without error
Everything builds fine up to the build of the installer:
nmake -f Makefile.nmake packaging
which then fails with

Internal Compiler Error: Installers shell constants are different than 
uninstallers

Fatal error U1077:  makensis.exe

--

Message: 7
Date: Wed, 31 Jul 2013 10:16:47 +0100
From: "John OSullivan" 
To: 
Subject: [Wireshark-dev] Problems building installer on Windows 8
Message-ID:
<001e01ce8dce$afe08770$0fa19650$@osulli...@cloudiumsystems.com>
Content-Type: text/plain; charset="us-ascii"

Hi,

 

I have downloaded the latest code for wireshark to build on a Windows 8 (64
bit) machine.

I am building an x86 version and  can build all stages up to 

nmake -f Makefile.nmake packaging

At this point it fails with an error:

Internal Compiler Error: Installers shell constants are different than 
uninstallers

Fatal error U1077:  makensis.exe

 

Any ideas why this step is failing?

 

 

-- next part --
An HTML attachment was scrubbed...
URL:
<http://www.wireshark.org/lists/wireshark-dev/attachments/20130731/8c03efa0/
attachment.html>

--

Message: 8
Date: Wed, 31 Jul 2013 09:25:07 +
From: Anders Broman 
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Problems building installer on Windows 8
Message-ID:
<43c5658ba3fb7b48a6f38eed0b6253f11a676...@esessmb105.ericsson.se>
Content-Type: text/plain; charset="us-ascii"

Hi,
Have you set WIRESHARK_TARGET_PLATFORM=win32 And run .. \"vcvarsall.bat x86

Regards
Anders
*

___
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] Problems building installer on Windows 8

2013-07-31 Thread Graham Bloice

On 31 July 2013 10:16, John OSullivan wrote:

> Hi,
>
> ** **
>
> I have downloaded the latest code for wireshark to build on a Windows 8
> (64 bit) machine.
>
> I am building an x86 version and  can build all stages up to 
>
> nmake –f Makefile.nmake packaging
>
> At this point it fails with an error:
>
> Internal Compiler Error: Installers shell constants are different than
> uninstallers
>
> Fatal error U1077:  makensis.exe
>
> ** **
>
> Any ideas why this step is failing?
>
> ** **
>
>
>
Looks to be either an issue in nsis, or something wrong in the nsis scripts
(*.nsi).  Look for recent changes in either of those or any files they
include.

Graham
___
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] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

2013-07-31 Thread Dirk Jagdmann

while you are renaming the displayed name of this variable, the rest of the SMB2
dissector is using the term "sequence number" in many places. It's now confusing
if source code comments talk about sequence numbers and use them in hash tables,
while the dissection shows it as Message ID. To really wrap this up, you might
want to rename hf_smb2_seqnum, but then also struct smb2_saved_info_t and code
using that struct.

On 2013-07-31 06:00, Richard Sharpe wrote:
> Hi folks,
> 
> This patch needs to be applied:
> 
> Index: epan/dissectors/packet-smb2.c
> ===
> --- epan/dissectors/packet-smb2.c (revision 51065)
> +++ epan/dissectors/packet-smb2.c (working copy)
> @@ -7100,8 +7100,8 @@ proto_register_smb2(void)
>   { "NT Status", "smb2.nt_status", FT_UINT32, BASE_HEX,
>   VALS(NT_errors), 0, "NT Status code", HFILL }},
>   { &hf_smb2_seqnum,
> - { "Command Sequence Number", "smb2.seq_num", FT_INT64, BASE_DEC,
> - NULL, 0, "SMB2 Command Sequence Number", HFILL }},
> + { "Message ID", "smb2.msg_id", FT_INT64, BASE_DEC,
> + NULL, 0, "SMB2 Messsage ID", HFILL }},
>   { &hf_smb2_tid,
>   { "Tree Id", "smb2.tid", FT_UINT32, BASE_HEX,
>   NULL, 0, "SMB2 Tree Id", HFILL }},
> 
> See section 2.2.1.1. The field is called the Message ID, not the
> Command Sequence Number.
> 
> That confusion has probably caused one of the WAN Accelerator
> companies to break SMB2 Signing by mishandling that field. Not sure
> which one it is, since the customer hasn't told me whose WAN
> Accelerator they use. (Hint, it is possible for those numbers to be
> out of order in a TCP stream.)
___
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 50896: / /trunk/doc/: README.qt /trunk/epan/: prefs-int.h prefs.c prefs.h uat-int.h uat.h /trunk/ui/qt/: CMakeLists.txt Makefile.common QtShark.pro elided_l

2013-07-31 Thread Gerald Combs

On 7/30/13 1:00 PM, Joerg Mayer wrote:
> On Tue, Jul 30, 2013 at 11:41:09AM -0700, Gerald Combs wrote:
>> BTW, it looks like you can pull Makefile-style definitions into CMake.
>> This would make maintenance easier everywhere, not just in ui/qt:
>>
>> https://github.com/berenm/xoreos/blob/a187e94eca041c7c53c76e943483fcaa612cbf4a/cmake/CMakeAM.cmake
> 
> It looks like it does not really what I want - it seems to read configure.ac
> and Makefile.am files and create the targets from that. Doing that would be
> "not helpful (tm)", as we would loose all the features that prompted me to
> start the cmake stuff in the first place.

I was assuming that we could pass "Makefile.common" to parse_automake.
Is that not the case? Either way, Beren Minor was kind enough to add a
license in the event that we can make use of it:

https://raw.github.com/berenm/xoreos/master/cmake/CMakeAM.cmake
___
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] Recent changes in composite TVB (extra changes beside move)

2013-07-31 Thread Jakub Zawadzki

Hi,

I should've first commit this changes and later move composite stuff to another 
file, but I haven't thought.
Sorry. Anyway, attaching diff with important changes.

If anyone has some time to do review it'd be great.

Thanks,
Kuba.

--- 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_2.c2013-07-31 
22:50:46.144101741 +0200
+++ 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_1.c2013-07-31 
22:50:36.800818660 +0200
@@ -32,11 +32,10 @@
guint   i, num_members;
tvb_comp_t *composite;
tvbuff_t   *member_tvb = NULL;
-   guint   member_offset, member_length;
+   guint   member_offset;
GSList *slist;
-   int exception;
 
-   DISSECTOR_ASSERT(tvb->ops == get_tvb_composite_ops());
+   /* DISSECTOR_ASSERT(tvb->ops == &tvb_composite_ops); */
 
/* Maybe the range specified by offset/length
 * is contiguous inside one of the member tvbuffs */
@@ -52,16 +51,14 @@
}
DISSECTOR_ASSERT(member_tvb);
 
-   exception = check_offset_length_no_exception(member_tvb,
-abs_offset - 
composite->start_offsets[i],
-abs_length, &member_offset, 
&member_length);
+   member_offset = abs_offset - composite->start_offsets[i];
 
-   if (!exception) {
+   if (tvb_bytes_exist(member_tvb, member_offset, abs_length)) {
/*
 * The range is, in fact, contiguous within member_tvb.
 */
DISSECTOR_ASSERT(!tvb->real_data);
-   return ensure_contiguous_no_exception(member_tvb, 
member_offset, member_length, NULL);
+   return tvb_get_ptr(member_tvb, member_offset, abs_length);
}
else {
tvb->real_data = (guint8 *)tvb_memdup(tvb, 0, -1);
@@ -72,7 +69,7 @@
 }
 
 static void *
-composite_memcpy(tvbuff_t *tvb, void* _target, guint abs_offset, size_t 
abs_length)
+composite_memcpy(tvbuff_t *tvb, void* _target, guint abs_offset, guint 
abs_length)
 {
struct tvb_composite *composite_tvb = (struct tvb_composite *) tvb;
guint8 *target = (guint8 *) _target;
@@ -81,10 +78,9 @@
tvb_comp_t *composite;
tvbuff_t   *member_tvb = NULL;
guint   member_offset, member_length;
-   int exception;
GSList *slist;
 
-   DISSECTOR_ASSERT(tvb->ops == get_tvb_composite_ops());
+   /* DISSECTOR_ASSERT(tvb->ops == &tvb_composite_ops); */
 
/* Maybe the range specified by offset/length
 * is contiguous inside one of the member tvbuffs */
@@ -100,12 +96,11 @@
}
DISSECTOR_ASSERT(member_tvb);
 
-   exception = check_offset_length_no_exception(member_tvb, abs_offset - 
composite->start_offsets[i],
-   (gint) abs_length, &member_offset, 
&member_length);
+   member_offset = abs_offset - composite->start_offsets[i];

-   if (!exception) {
+   if (tvb_bytes_exist(member_tvb, member_offset, abs_length)) {
DISSECTOR_ASSERT(!tvb->real_data);
-   return tvb_memcpy(member_tvb, target, member_offset, 
member_length);
+   return tvb_memcpy(member_tvb, target, member_offset, 
abs_length);
}
else {
/* The requested data is non-contiguous inside
@@ -113,12 +108,10 @@
 * then iterate across the other member tvb's, copying their 
portions
 * until we have copied all data.
 */
-   exception = compute_offset_and_remaining(member_tvb, abs_offset 
- composite->start_offsets[i],
-   &member_offset, &member_length);
-   DISSECTOR_ASSERT(!exception);
+   member_length = tvb_length_remaining(member_tvb, member_offset);
 
/* composite_memcpy() can't handle a member_length of zero.  */
-   DISSECTOR_ASSERT(member_length);
+   DISSECTOR_ASSERT(member_length > 0);
 
tvb_memcpy(member_tvb, target, member_offset, member_length);
abs_offset  += member_length;
___
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-bugs] [Bug 8995] build fails if system python is version 3+

2013-07-31 Thread Gerald Combs

On 7/31/13 3:49 PM, bugzilla-dae...@wireshark.org wrote:
> *Comment # 8
>  on bug
> 8995  from Guy
> Harris  *
> 
> (In reply to comment #3 )
>> Created attachment 11305  [details] 
>> 
>> Python 2+3 compatibility for make-dissector-reg.py
>> 
>> The attached patch works for Python 2 and 3 on my system. It also makes a
>> couple of changes suggested by "2to3". If no one has any objections I'll
>> check it in.
> 
> Doesn't work on the OS X 10.5 buildbot, though:
> 
>
> http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/6517/steps/compile/logs/stdio
> 
> ...
> 
> Traceback (most recent call last):
>   File "../../tools/make-dissector-reg.py", line 288, in 
> new_hash = hashlib.sha1(bytes(reg_code.encode('utf-8'))).hexdigest()
> NameError: name 'bytes' is not defined

This should be fixed in r51079.
___
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] Problems building installer on Windows 8

Re: [Wireshark-dev] Problems building installer on Windows 8

Re: [Wireshark-dev] Feeding the 802.15.4 Dissector

Re: [Wireshark-dev] Feeding the 802.15.4 Dissector

Re: [Wireshark-dev] Feeding the 802.15.4 Dissector

[Wireshark-dev] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

Re: [Wireshark-dev] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

Re: [Wireshark-dev] Feeding the 802.15.4 Dissector

[Wireshark-dev] Wireshark trunk does not compile without HAVE_LIBGNUTLS

Re: [Wireshark-dev] Problems building installer on Windows 8

Re: [Wireshark-dev] Wireshark trunk does not compile without HAVE_LIBGNUTLS

Re: [Wireshark-dev] Problems building installer on Windows 8

Re: [Wireshark-dev] Problems building installer on Windows 8

Re: [Wireshark-dev] The field called Command Sequence Number in the SMB2 dissector is actually the Message ID

Re: [Wireshark-dev] [Wireshark-commits] rev 50896: / /trunk/doc/: README.qt /trunk/epan/: prefs-int.h prefs.c prefs.h uat-int.h uat.h /trunk/ui/qt/: CMakeLists.txt Makefile.common QtShark.pro elided_l

[Wireshark-dev] Recent changes in composite TVB (extra changes beside move)

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 8995] build fails if system python is version 3+

17 matches

Site Navigation

Mail list logo

Footer information