On 31 July 2013 22:42, Jakub Zawadzki darkjames...@darkjames.pl wrote:
SNIP
--- 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_2.c2013-07-31
22:50:46.144101741 +0200
+++ 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_1.c2013-07-31
22:50:36.800818660 +0200
Totally off-topic rant, but
2013/8/1 Graham Bloice graham.blo...@trihedral.com:
On 31 July 2013 22:42, Jakub Zawadzki darkjames...@darkjames.pl wrote:
SNIP
--- 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_2.c2013-07-31
22:50:46.144101741 +0200
+++ 9d519b5659aa8c0c4aa984bc6169909eb31be7d6_1.c2013-07-31
Hi,
The problem appears to be with NSIS version 3.0a1, there are no problems
with version NSIS 2.46. The problem is also evident on earlier versions of
the wireshark source if NSIS 3.0a1 is used. I will try and confirm if this
is also the case on non-windows 8 builds. I have been building the 32
Hi Richard,
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
I took a half-educated whack at fixing those in r51080. Thanks for
pointing it out (and feel free to point out any mistakes I may have made).
On 07/31/13 17:08, Dirk Jagdmann wrote:
while you are renaming the displayed name of this variable, the rest of the SMB2
dissector is using the term
