Re: [Wireshark-dev] IAX2 and LTE captures

2015-09-02 Thread Tyson Key
Aha - for what it's worth, http://www.ng4t.com/wireshark.html seems pretty
promising - although it seems that they're synthetic traces, generated by a
simulator. Covers S1AP, NAS-EPS, RANAP, HNBAP, GSM A-I/F DTAP, and a bunch
of other interesting protocols, on the cell/eNodeB side (mostly
encapsulated in SCTP).

Tyson.

2015-09-02 22:28 GMT+01:00 Gerald Combs :

> Does anyone have any IAX2 or LTE captures that they can share, either
> publicly or privately? Otherwise porting the remaining telephony dialogs is
> going to be a bit tricky.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] IAX2 and LTE captures

2015-09-02 Thread Tyson Key
Hi Gerald,

I don't have any new, original ones to share - although I've seen a few
LTE-related traces, whilst digging around in my archives of the
Wireshark-Bugs list (bugs #5536, #8303. #5511, and #10699 immediately come
to mind), and there's the IAX2_incoming_call.acp trace on the Wiki - but I
don't know how much of the relevant dissectors, and in turn, the legacy GTK
dialogues they exercise.

I hope that helps,

Tyson.

2015-09-02 22:28 GMT+01:00 Gerald Combs :

> Does anyone have any IAX2 or LTE captures that they can share, either
> publicly or privately? Otherwise porting the remaining telephony dialogs is
> going to be a bit tricky.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Npcap 0.03 call for test

2015-08-01 Thread Tyson Key
Hmm, this is interesting...

When I removed the old WinPCap, and installed the new NPCap, and then
started Wireshark under WinDBG, immediately after, it didn't crash - but at
the same time, it didn't detect any interfaces, either.

However, when I rebooted, and tried to start Wireshark under WinDBG, I was
able to capture packets from my WLAN adapter (using the Qt UI), and then
stop capturing, and then quit the Qt UI, and start the GTK one (under
WDBG), and capture from all interfaces, including the NPCap Loopback - at
the cost of my Internet connection being knocked out, for some unknown
reason:

Pinging 192.168.1.1 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

In both cases, I didn't receive any BSoD, or general signs of slowness, or
instability (although I didn't stress things hard, and only captured a
total of about 3000 packets). (I haven't tried capturing without running
Wireshark in the debugger, yet).

This is what gets loaded:

ModLoad: 7ff8`5acc 7ff8`5ace
C:\WINDOWS\SYSTEM32\CRYPTSP.dll
ModLoad: 7ff8`5a8e 7ff8`5a916000
C:\WINDOWS\system32\rsaenh.dll
ModLoad: 7ff8`5af6 7ff8`5af86000
C:\WINDOWS\SYSTEM32\bcrypt.dll
Application "\??\C:\Program Files\Wireshark\gspawn-win64-helper.exe" found
in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
ModLoad: 7ff8`5ad2 7ff8`5ad2c000
C:\WINDOWS\SYSTEM32\Secur32.dll
ModLoad: 7ff8`5b27 7ff8`5b29e000
C:\WINDOWS\SYSTEM32\SSPICLI.DLL
ModLoad: 7ff8`58d7 7ff8`58d7c000
C:\WINDOWS\SYSTEM32\ondemandconnroutehelper.dll
ModLoad: 7ff8`5365 7ff8`53719000
C:\WINDOWS\SYSTEM32\winhttp.dll
ModLoad: 7ff8`5a44 7ff8`5a4a2000
C:\windows\system32\nuragoLSPService64.DLL
ModLoad: 7ff8`5ac6 7ff8`5acb9000
C:\WINDOWS\SYSTEM32\MSWSOCK.dll
ModLoad: 7ff8`55e9 7ff8`55ea6000
C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL
ModLoad: 7ff8`560a 7ff8`560ba000
C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL
ModLoad: 7ff8`54e1 7ff8`54f95000
C:\WINDOWS\SYSTEM32\urlmon.dll
ModLoad: 7ff8`52f7 7ff8`52f88000
C:\windows\system32\wlidnsp.dll
ModLoad: 7ff8`59fd 7ff8`59fda000   C:\WINDOWS\SYSTEM32\DPAPI.DLL
ModLoad: `65d5 `65d76000   C:\Program
Files\Bonjour\mdnsNSP.dll
ModLoad: 7ff8`52f6 7ff8`52f6a000
C:\Windows\System32\rasadhlp.dll
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)

Unsure of why the Nurago/Gacela LSP is still being loaded, despite
supposedly no longer being installed, though. In order to restore network
connectivity, I had to disable the "NPcap Loopback Adapter", and a
vestigial "KM-TEST Loopback Adaptor", and reboot my PC, though.

Tyson.

2015-08-01 17:22 GMT+01:00 Tyson Key :

> Also found this, in a dumpcap MiniDump:
>
>
> Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\MiniDumps\072715-31968-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
>
> * Symbol Path validation summary **
> Response Time (ms) Location
> Deferred   SRV*C:\Symbols\*
> http://msdl.microsoft.com/download/symbols
> Symbol search path is: SRV*C:\Symbols\*
> http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows 8 Kernel Version 9600 MP (4 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS Personal
> Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
> Machine Name:
> Kernel base = 0xf801`0668c000 PsLoadedModuleList = 0xf801`06965850
> Debug session time: Mon Jul 27 19:02:32.113 2015 (UTC + 1:00)
> System Uptime

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-08-01 Thread Tyson Key
000`15dd6000 : e000`161aad28 e000`1a182210
e000`161aac90 f801`1cb609c0 : 0xe000`15dd6098
d000`2324f490 e000`161aad28 : e000`1a182210 e000`161aac90
f801`1cb609c0 e000`16c102e0 : 0xe000`15dd6000
d000`2324f498 e000`1a182210 : e000`161aac90 f801`1cb609c0
e000`16c102e0 e000`16c103b0 : 0xe000`161aad28
d000`2324f4a0 e000`161aac90 : f801`1cb609c0 e000`16c102e0
e000`16c103b0 e000`15dd6000 : 0xe000`1a182210
d000`2324f4a8 f801`1cb609c0 : e000`16c102e0 e000`16c103b0
e000`15dd6000 e000`174edee0 : 0xe000`161aac90
d000`2324f4b0 e000`16c102e0 : e000`16c103b0 e000`15dd6000
e000`174edee0 e000`16c102e0 : npf+0x29c0
d000`2324f4b8 e000`16c103b0 : e000`15dd6000 e000`174edee0
e000`16c102e0 f801`06aaedd1 : 0xe000`16c102e0
d000`2324f4c0 e000`15dd6000 : e000`174edee0 e000`16c102e0
f801`06aaedd1 `00a5 : 0xe000`16c103b0
d000`2324f4c8 e000`174edee0 : e000`16c102e0 f801`06aaedd1
`00a5 d000`2324f7e1 : 0xe000`15dd6000
d000`2324f4d0 e000`16c102e0 : f801`06aaedd1 `00a5
d000`2324f7e1 ` : 0xe000`174edee0
d000`2324f4d8 f801`06aaedd1 : `00a5 d000`2324f7e1
` `0040 : 0xe000`16c102e0
d000`2324f4e0 f801`06b35dc4 : ` `
e000`174edd60 e000`174edd60 : nt!IopParseDevice+0x6c1
d000`2324f700 f801`06ac36b3 : ` d000`2324f8a8
`0040 e000`153eca90 : nt!ObpLookupObjectName+0x784
d000`2324f830 f801`06adc4db : `0001 e000`1a1822a8
`0001 `0020 : nt!ObOpenObjectByName+0x1e3
d000`2324f960 f801`06adc15c : 0017`feefcbb8 `c0100080
0017`feefcc10 e000`1646e080 : nt!IopCreateFile+0x36b
d000`2324fa00 f801`067e84b3 : e000`1a537080 d000`2324fb80
d000`2324faa8 0017`feefcb60 : nt!NtCreateFile+0x78
d000`2324fa90 7ff8`1110171a : ` `
` ` : nt!KiSystemServiceCopyEnd+0x13
0017`feefcb38 ` : ` `
` ` : 0x7ff8`1110171a


FOLLOWUP_IP:
npf+26b9
f801`1cb606b9 ??  ???

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  npf+26b9

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: npf

IMAGE_NAME:  npf.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  55b5ffcd

STACK_COMMAND:  .cxr 0xd0002324e980 ; kb

FAILURE_BUCKET_ID:  0x3B_npf+26b9

BUCKET_ID:  0x3B_npf+26b9

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x3b_npf+26b9

FAILURE_ID_HASH:  {3d7b38a9-fc4b-1ac1-803d-31b7fb0e6e7f}

Followup: MachineOwner
-


2015-08-01 16:07 GMT+01:00 Tyson Key :

> Hi Yang,
>
> Not sure if these are any use, since I'm still downloading various
> symbols, but I've just started looking at some MiniDumps, and spotted these:
>
>
> Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\Windows\Minidump\072715-48062-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
>
> * Symbol Path validation summary **
> Response Time (ms) Location
> Deferred   SRV*C:\Symbols\*
> http://msdl.microsoft.com/download/symbols
> Symbol search path is: SRV*C:\Symbols\*
> http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows 8 Kernel Version 9600 MP (4 procs) Free x64
> Product: WinNt, suite: TerminalServer SingleUserTS Personal
> Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
> Machine Name:
> Kernel base = 0xf801`03606000 PsLoadedModuleList = 0xf801`038df850
> Debug session time: Mon Jul 27 17:00:25.098 2015 (UTC + 1:00)
> System Uptime: 0 days 0:49:51.971
> Loading Kernel Symbols
> .
>
> Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads
> that take too long.
> Run !sym noisy before .reload to track down problems loading symbols.
>
> ..
> 
> 
> ..
> Loading User Symbols
> Loading unloaded module list
> ..
>
> ***
> *
> *
> *Bugcheck Analysis
>*
> *
> *
>
> ***
>
> Use !analyze -v to get detailed debugging informa

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-08-01 Thread Tyson Key
1acf0f8 `0001 : nt!NtDeviceIoControlFile+0x56
d000`9bba6a90 7ff8`24c3123a : ` `
` ` : nt!KiSystemServiceCopyEnd+0x13
0031`01ace928 ` : ` `
` ` : 0x7ff8`24c3123a


STACK_COMMAND:  kb

FOLLOWUP_IP:
NETIO!NetioCompleteCloneNetBufferListChain+1508d
f801`14a2f83d 90  nop

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME:  NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  540ebbe6

IMAGE_VERSION:  6.3.9600.17337

BUCKET_ID_FUNC_OFFSET:  1508d

FAILURE_BUCKET_ID:  0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

BUCKET_ID:  0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:
 km:0xc2_7_ndnd_netio!netiocompleteclonenetbufferlistchain

FAILURE_ID_HASH:  {ec09700b-3916-f849-b5d5-75c2ba7b02db}

Followup: MachineOwner
-

However, they seem to correlate with your debugging from earlier...

Tyson.

2015-08-01 14:30 GMT+01:00 Tyson Key :

> Hi Yang,
>
> Thanks for looking at this. I've just enabled full memory dumps, after
> reading https://support.microsoft.com/en-us/kb/969028 - but I'll need to
> do the Right Ctrl + Scroll Lock X2 trick at a time when I can afford to
> lose state data.
>
> I've got the Windows SDK installed (but not the WinDBG?), if I remember
> correctly - but I'll install the symbols, and WDK, when I get time. In the
> meantime, since I've got a %SystemRoot%\MEMORY.DMP file from some crash,
> but don't know how big it is (since I now have 6GB of RAM, and probably
> only had 4GB, when it was generated - assuming that "automatic" dumps are
> "full" dumps), I guess that I've got something to practice post-mortem on...
>
> Tyson.
>
> 2015-08-01 4:18 GMT+01:00 Yang Luo :
>
>> Hi Tyson,
>>
>> I think I have reproduced the BAD_POOL_CALLER error, the step is: 1)
>> reboot the system, 2) start Wireshark UI, 3) Open VMware Workstation. As
>> you installed VMware Player, maybe it's the same reason. I will look into
>> this later. And I found that a full dump file (memory.dmp) has more useful
>> information (the error position in Npcap driver) than a minidump, so if you
>> can provide full dumps, it will be better.  A simpler way is you open the
>> full dump file by yourself using WinDBG (with suitable symbols) and type in
>> "!analyze -v", and then paste the output in this thread, so you don't need
>> to upload such a big dump file.
>>
>> Get WinDBG:
>>
>> https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx?f=255&MSPPError=-2147217396
>>
>> Get Windows symbols:
>> https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
>>
>>
>> Cheers,
>> Yang
>>
>> On Tue, Jul 28, 2015 at 11:09 PM, Tyson Key  wrote:
>>
>>> Aah, I had a look at "Programs, and Features", and it says that the
>>> AppEx thing is "AMD Quick Stream" 3.4.4.0, published by AppEx Networks, of
>>> Beijing (http://www.appexnetworks.com.cn/). I found a marketing
>>> document regarding it at
>>> http://support.amd.com/en-us/kb-articles/Pages/AMDQuickStreamTechnology.aspx
>>> .
>>>
>>> Tyson.
>>>
>>> 2015-07-28 16:03 GMT+01:00 Tyson Key :
>>>
>>>> Hi Yang,
>>>>
>>>> Thanks for looking at these dumps.
>>>>
>>>> Yup, I think I enabled the verifier, a few months ago, whilst trying to
>>>> debug some other issue (probably related to the AppEx thing), and I forgot
>>>> that I kept it enabled.
>>>>
>>>> As for the dumpcap arguments, I just let Wireshark invoke it, through
>>>> the GUI - so the arguments are whatever it spits out by default, to set up
>>>> various pipes. I'd have to surgically remove NPCap, and replace it with
>>>> regular WinPCap, and then try to trace Wireshark Qt/GTK, to learn the
>>>> arguments (or see if "tasklist /V", or some other utility reveals them).
>>>> I'd expect that they'd look similar to the ones issued under Linux, modulo
>>>> device names, though.
>>>>
>>>> I'm kinda surprised that Asset is responsible for some of the crashes,
>>>> to be honest. Sure, it does funny things with multicasting, as a UPnP
>>>> server implementation, but it's usually pretty reliable, in general
>>>> operation. Might be worth me reporting 

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-08-01 Thread Tyson Key
Hi Yang,

Thanks for looking at this. I've just enabled full memory dumps, after
reading https://support.microsoft.com/en-us/kb/969028 - but I'll need to do
the Right Ctrl + Scroll Lock X2 trick at a time when I can afford to lose
state data.

I've got the Windows SDK installed (but not the WinDBG?), if I remember
correctly - but I'll install the symbols, and WDK, when I get time. In the
meantime, since I've got a %SystemRoot%\MEMORY.DMP file from some crash,
but don't know how big it is (since I now have 6GB of RAM, and probably
only had 4GB, when it was generated - assuming that "automatic" dumps are
"full" dumps), I guess that I've got something to practice post-mortem on...

Tyson.

2015-08-01 4:18 GMT+01:00 Yang Luo :

> Hi Tyson,
>
> I think I have reproduced the BAD_POOL_CALLER error, the step is: 1)
> reboot the system, 2) start Wireshark UI, 3) Open VMware Workstation. As
> you installed VMware Player, maybe it's the same reason. I will look into
> this later. And I found that a full dump file (memory.dmp) has more useful
> information (the error position in Npcap driver) than a minidump, so if you
> can provide full dumps, it will be better.  A simpler way is you open the
> full dump file by yourself using WinDBG (with suitable symbols) and type in
> "!analyze -v", and then paste the output in this thread, so you don't need
> to upload such a big dump file.
>
> Get WinDBG:
>
> https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx?f=255&MSPPError=-2147217396
>
> Get Windows symbols:
> https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
>
>
> Cheers,
> Yang
>
> On Tue, Jul 28, 2015 at 11:09 PM, Tyson Key  wrote:
>
>> Aah, I had a look at "Programs, and Features", and it says that the AppEx
>> thing is "AMD Quick Stream" 3.4.4.0, published by AppEx Networks, of
>> Beijing (http://www.appexnetworks.com.cn/). I found a marketing document
>> regarding it at
>> http://support.amd.com/en-us/kb-articles/Pages/AMDQuickStreamTechnology.aspx
>> .
>>
>> Tyson.
>>
>> 2015-07-28 16:03 GMT+01:00 Tyson Key :
>>
>>> Hi Yang,
>>>
>>> Thanks for looking at these dumps.
>>>
>>> Yup, I think I enabled the verifier, a few months ago, whilst trying to
>>> debug some other issue (probably related to the AppEx thing), and I forgot
>>> that I kept it enabled.
>>>
>>> As for the dumpcap arguments, I just let Wireshark invoke it, through
>>> the GUI - so the arguments are whatever it spits out by default, to set up
>>> various pipes. I'd have to surgically remove NPCap, and replace it with
>>> regular WinPCap, and then try to trace Wireshark Qt/GTK, to learn the
>>> arguments (or see if "tasklist /V", or some other utility reveals them).
>>> I'd expect that they'd look similar to the ones issued under Linux, modulo
>>> device names, though.
>>>
>>> I'm kinda surprised that Asset is responsible for some of the crashes,
>>> to be honest. Sure, it does funny things with multicasting, as a UPnP
>>> server implementation, but it's usually pretty reliable, in general
>>> operation. Might be worth me reporting a bug to Illustrate, when I get
>>> chance; and I'll see what happens if I uninstall it, in the meantime.
>>>
>>> As for AppEx, I'm pretty sure that I removed its driver from all of my
>>> interfaces, but I wouldn't be surprised if there's not something vestigial.
>>> Going to see if I can fully cleanse it from my system, since it was an
>>> OEM-supplied product, and not something that I opted to install. (And I've
>>> had BSoDs from it before, whilst trying to diagnose some WLAN problems). I
>>> think it's supposed to be some sort of "game/multimedia quality-of-service
>>> optimisation" tool.
>>>
>>> Take care,
>>>
>>> Tyson.
>>>
>>> 2015-07-28 12:41 GMT+01:00 Yang Luo :
>>>
>>>> Hi Tyson,
>>>>
>>>> I have analyzed the five dumps you provided:
>>>>
>>>> 1) 072715-32078-01.dmp
>>>> This dump is caused by nt!VerifierBugCheckIfAppropriate+0x3c code from
>>>> process svchost.exe, and it seems to be that you switched on Verifier
>>>> function for your system. I think there's no relationship with Npcap.
>>>>
>>>> 2) 072715-31968-01.dmp and 072715-32468-01.dmp
>>>> this dump provides BSoD about SYSTEM_SERVICE_EXCEPTION. It is caused
>>

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-28 Thread Tyson Key
Aah, I had a look at "Programs, and Features", and it says that the AppEx
thing is "AMD Quick Stream" 3.4.4.0, published by AppEx Networks, of
Beijing (http://www.appexnetworks.com.cn/). I found a marketing document
regarding it at
http://support.amd.com/en-us/kb-articles/Pages/AMDQuickStreamTechnology.aspx
.

Tyson.

2015-07-28 16:03 GMT+01:00 Tyson Key :

> Hi Yang,
>
> Thanks for looking at these dumps.
>
> Yup, I think I enabled the verifier, a few months ago, whilst trying to
> debug some other issue (probably related to the AppEx thing), and I forgot
> that I kept it enabled.
>
> As for the dumpcap arguments, I just let Wireshark invoke it, through the
> GUI - so the arguments are whatever it spits out by default, to set up
> various pipes. I'd have to surgically remove NPCap, and replace it with
> regular WinPCap, and then try to trace Wireshark Qt/GTK, to learn the
> arguments (or see if "tasklist /V", or some other utility reveals them).
> I'd expect that they'd look similar to the ones issued under Linux, modulo
> device names, though.
>
> I'm kinda surprised that Asset is responsible for some of the crashes, to
> be honest. Sure, it does funny things with multicasting, as a UPnP server
> implementation, but it's usually pretty reliable, in general operation.
> Might be worth me reporting a bug to Illustrate, when I get chance; and
> I'll see what happens if I uninstall it, in the meantime.
>
> As for AppEx, I'm pretty sure that I removed its driver from all of my
> interfaces, but I wouldn't be surprised if there's not something vestigial.
> Going to see if I can fully cleanse it from my system, since it was an
> OEM-supplied product, and not something that I opted to install. (And I've
> had BSoDs from it before, whilst trying to diagnose some WLAN problems). I
> think it's supposed to be some sort of "game/multimedia quality-of-service
> optimisation" tool.
>
> Take care,
>
> Tyson.
>
> 2015-07-28 12:41 GMT+01:00 Yang Luo :
>
>> Hi Tyson,
>>
>> I have analyzed the five dumps you provided:
>>
>> 1) 072715-32078-01.dmp
>> This dump is caused by nt!VerifierBugCheckIfAppropriate+0x3c code from
>> process svchost.exe, and it seems to be that you switched on Verifier
>> function for your system. I think there's no relationship with Npcap.
>>
>> 2) 072715-31968-01.dmp and 072715-32468-01.dmp
>> this dump provides BSoD about SYSTEM_SERVICE_EXCEPTION. It is caused
>> by ndis!NdisFOidRequest+62 code from process dumpcap.exe. As Npcap uses
>> NdisFOidRequest calls, I think it's possibly a bug. I'd like to know how
>> you used dumpcap.exe, like parameters?
>>
>> 3) 072715-33859-01.dmp and 072715-48062-01.dmp
>> It is caused by Asset-uPNP.exe, from Asset audio server software provided
>> by illustrate. I think maybe you would like to disable or uninstall it
>> first, to see if the fault still happens. WinDbg also reports
>> that OVERLAPPED_MODULE: Address regions for 'nwifi' and 'appexDrv.sys'
>> overlap. 'appexDrv.sys''s description is " "AppEx Accelerator LWF/WFP
>> Driver L.E."".  nwifi.sys seems to be a Microsoft built-in component,
>> and AppEx Networks Accelerator seems to be a VPN software, unfortunately, I
>> didn't find a download link. But this is maybe not the main cause, whatever
>> you can try to shutdown it to see if there's any change.
>>
>> 072715-48062-01.dmp's report is pasted here:
>>
>>
>> ***
>> *
>> *
>> *Bugcheck Analysis
>>  *
>> *
>> *
>>
>> ***
>>
>> Use !analyze -v to get detailed debugging information.
>>
>> BugCheck C2, {7, 1200, 0, e0008d01cbf8}
>>
>> f80059152240: Unable to get special pool info
>> f80059152240: Unable to get special pool info
>> unable to get nt!MmPoolCodeStart
>> unable to get nt!MmPoolCodeEnd
>> Probably caused by : NETIO.SYS (
>> NETIO!NetioCompleteCloneNetBufferListChain+1508d )
>>
>> Followup: MachineOwner
>> -
>>
>> 0: kd> !analyze -v
>>
>> ***
>> *
>> *
>> *Bugcheck Analysis
>>  *
>> *
>> *
>>
>> *

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-28 Thread Tyson Key
; PROCESS_NAME:  Asset-uPNP.exe
>
> CURRENT_IRQL:  2
>
> LAST_CONTROL_TRANSFER:  from f8005912fff2 to f80058fdbca0
>
> STACK_TEXT:
> d000`27118f88 f800`5912fff2 : `00c2 `0007
> `1200 ` : nt!KeBugCheckEx
> d000`27118f90 f800`3763083d : ` e000`8d596040
> 08fe`0010 0014` : nt!ExAllocatePoolWithTag+0x1102
> d000`27119080 f800`376023f1 : ` e000`8ceb3740
> ` ` :
> NETIO!NetioCompleteCloneNetBufferListChain+0x1508d
> d000`271190f0 ` : ` `
> ` ` :
> NETIO!NetioDereferenceNetBufferListChain+0x2d1
>
>
> STACK_COMMAND:  kb
>
> FOLLOWUP_IP:
> NETIO!NetioCompleteCloneNetBufferListChain+1508d
> f800`3763083d 90  nop
>
> SYMBOL_STACK_INDEX:  2
>
> SYMBOL_NAME:  NETIO!NetioCompleteCloneNetBufferListChain+1508d
>
> FOLLOWUP_NAME:  MachineOwner
>
> MODULE_NAME: NETIO
>
> IMAGE_NAME:  NETIO.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP:  540ebbe6
>
> FAILURE_BUCKET_ID:
>  X64_0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain+1508d
>
> BUCKET_ID:
>  X64_0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain+1508d
>
> Followup: MachineOwner
> -
>
> On Tue, Jul 28, 2015 at 3:12 PM, Tyson Key  wrote:
>
>> I just uploaded my MiniDumps to
>> https://dl.dropboxusercontent.com/u/670345/MiniDump.rar, if it makes
>> debugging this easier.
>>
>> Tyson.
>>
>> 2015-07-28 8:08 GMT+01:00 Tyson Key :
>>
>>> Hi Yang,
>>>
>>> Thanks for looking into this.
>>>
>>> I can't remember when/how I installed Win10PCap (guessing that I briefly
>>> had a look, but couldn't get it to do anything on my machine, and just
>>> removed it), but I'm using VMware Player 6.0.7 build-2844087 (haven't got
>>> Workstation/Server installed); and I tried a dance of
>>> upgrading/downgrading/upgrading my AR9485WB-EG WLAN driver (first by
>>> downloading the package from
>>> http://support.lenovo.com/us/en/downloads/ds032333, to take me from
>>> 10.0.0.242, to 10.0.0.75; and then using Device Manager's driver update
>>> function, to take me to 3.0.1.155 (which I'm guessing is probably older
>>> than 242 - I'm just guessing from the sketchy build dates) - which gave me
>>> a different type of BSoD, initially, after starting Wireshark, but let me
>>> capture traffic for a little while, after rebooting.
>>>
>>> Here's all of the MiniDump summaries that I could find:
>>>
>>> ==
>>> Dump File : 072715-31968-01.dmp
>>> Crash Time: 27/07/2015 07:02:32 pm
>>> Bug Check String  : SYSTEM_SERVICE_EXCEPTION
>>> Bug Check Code: 0x003b
>>> Parameter 1   : `c005
>>> Parameter 2   : f801`1be5d485
>>> Parameter 3   : d000`2324e980
>>> Parameter 4   : `
>>> Caused By Driver  : ntoskrnl.exe
>>> Caused By Address : ntoskrnl.exe+150ca0
>>> File Description  : NT Kernel & System
>>> Product Name  : Microsoft® Windows® Operating System
>>> Company   : Microsoft Corporation
>>> File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
>>> Processor : x64
>>> Crash Address : ntoskrnl.exe+150ca0
>>> Stack Address 1   :
>>> Stack Address 2   :
>>> Stack Address 3   :
>>> Computer Name :
>>> Full Path : C:\WINDOWS\Minidump\072715-31968-01.dmp
>>> Processors Count  : 4
>>> Major Version : 15
>>> Minor Version : 9600
>>> Dump File Size: 281,520
>>> Dump File Time: 27/07/2015 07:03:33 pm
>>> ==
>>>
>>> ==
>>> Dump File : 072715-32078-01.dmp
>>> Crash Time: 27/07/2015 06:47:01 pm
>>> Bug Check String  : BAD_POOL_CALLER
>>> Bug Check Code: 0x00c2
>>> Parameter 1   : `0099
>>> Parameter 2   : e000`7d4b31b8
>>> Parameter 3   : `
>>> Parameter 4   : `
>>> Caused By Driver  : tcpip.sys
>>> Caused By Address : tcpip.sys+42856
>>> File Description  : TCP/IP Driver
>>> Product Name  : Microsoft® Windows® Oper

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-28 Thread Tyson Key
I just uploaded my MiniDumps to
https://dl.dropboxusercontent.com/u/670345/MiniDump.rar, if it makes
debugging this easier.

Tyson.

2015-07-28 8:08 GMT+01:00 Tyson Key :

> Hi Yang,
>
> Thanks for looking into this.
>
> I can't remember when/how I installed Win10PCap (guessing that I briefly
> had a look, but couldn't get it to do anything on my machine, and just
> removed it), but I'm using VMware Player 6.0.7 build-2844087 (haven't got
> Workstation/Server installed); and I tried a dance of
> upgrading/downgrading/upgrading my AR9485WB-EG WLAN driver (first by
> downloading the package from
> http://support.lenovo.com/us/en/downloads/ds032333, to take me from
> 10.0.0.242, to 10.0.0.75; and then using Device Manager's driver update
> function, to take me to 3.0.1.155 (which I'm guessing is probably older
> than 242 - I'm just guessing from the sketchy build dates) - which gave me
> a different type of BSoD, initially, after starting Wireshark, but let me
> capture traffic for a little while, after rebooting.
>
> Here's all of the MiniDump summaries that I could find:
>
> ==
> Dump File : 072715-31968-01.dmp
> Crash Time: 27/07/2015 07:02:32 pm
> Bug Check String  : SYSTEM_SERVICE_EXCEPTION
> Bug Check Code: 0x003b
> Parameter 1   : `c005
> Parameter 2   : f801`1be5d485
> Parameter 3   : d000`2324e980
> Parameter 4   : `
> Caused By Driver  : ntoskrnl.exe
> Caused By Address : ntoskrnl.exe+150ca0
> File Description  : NT Kernel & System
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\072715-31968-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 27/07/2015 07:03:33 pm
> ==
>
> ==
> Dump File : 072715-32078-01.dmp
> Crash Time: 27/07/2015 06:47:01 pm
> Bug Check String  : BAD_POOL_CALLER
> Bug Check Code: 0x00c2
> Parameter 1   : `0099
> Parameter 2   : e000`7d4b31b8
> Parameter 3   : `
> Parameter 4   : `
> Caused By Driver  : tcpip.sys
> Caused By Address : tcpip.sys+42856
> File Description  : TCP/IP Driver
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\072715-32078-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 27/07/2015 06:48:04 pm
> ==
>
> ==
> Dump File : 072715-32468-01.dmp
> Crash Time: 27/07/2015 06:34:37 pm
> Bug Check String  : SYSTEM_SERVICE_EXCEPTION
> Bug Check Code: 0x003b
> Parameter 1   : `c005
> Parameter 2   : f801`962a446e
> Parameter 3   : d001`1bd0f980
> Parameter 4   : `
> Caused By Driver  : ndis.sys
> Caused By Address : ndis.sys+546e
> File Description  : Network Driver Interface Specification (NDIS)
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\072715-32468-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 27/07/2015 06:35:48 pm
> ==
>
> ==
> Dump File : 072715-33859-01.dmp
> Crash Time: 27/07/2015 05:11:25 pm
> Bug Check String  : BAD_POOL_CALLER
> Bug Check Code: 0x00c2
> Parameter 1   : `0007
> Parameter 2

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-28 Thread Tyson Key
1,520
Dump File Time: 27/07/2015 05:12:34 pm
==

==
Dump File : 072715-48062-01.dmp
Crash Time: 27/07/2015 05:00:25 pm
Bug Check String  : BAD_POOL_CALLER
Bug Check Code: 0x00c2
Parameter 1   : `0007
Parameter 2   : `1200
Parameter 3   : `
Parameter 4   : e000`4bc1b4c8
Caused By Driver  : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+150ca0
File Description  : NT Kernel & System
Product Name  : Microsoft® Windows® Operating System
Company   : Microsoft Corporation
File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1   :
Stack Address 2   :
Stack Address 3   :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-48062-01.dmp
Processors Count  : 4
Major Version : 15
Minor Version : 9600
Dump File Size: 281,520
Dump File Time: 27/07/2015 05:01:58 pm
==

Frustratingly, since there are so many variables involved (unscientific
method!), it seems like I'm playing a Jenga game with trying to make this
work, since if I remove, or change something, it works for a little while,
and then crashes in a creative, new way. (And I don't want to reinstall
everything, since I don't have a disk big enough to back everything up). :(

I've uploaded a copy of the Nurago Web Meter to
https://dl.dropboxusercontent.com/u/670345/nurago%20web%20meter.exe, and I
seem to also have an older installer for it in my "Downloads" directory,
which may exercise the LSP architecture of WinSock differently.

The SYSTEM_SERVICE_EXCEPTION error is interesting, as it is one of the few
that reveals a problem in WinSock/NDIS...

I would try it in a virtual machine - but it wouldn't get us any closer to
diagnosing why it fails to work, with my not-so-unique configuration.

Tyson.

2015-07-28 7:27 GMT+01:00 Yang Luo :

>
>
> On Mon, Jul 27, 2015 at 10:42 PM, Tyson Key  wrote:
>
>> After rebooting from uninstalling MS NetMon, I restarted Wireshark, and
>> got the usual "NPF service not running; no interfaces available" note. This
>> persists, even if I try "NPFInstall -r", and Wireshark still claims that no
>> interfaces are available.
>>
>>
> "*NPFInstall -r*" isn't used in Npcap. "*NPF service not running; no
> interfaces available*" is a common problem for Npcap previous versions.
> And I think it should disappear if you have uninstalled previous versions
> totally.
>
>
>> Eventually, after uninstalling NPCap, removing all of the loopback
>> interfaces, and running CCleaner to remove any residual registry data, and
>> then rebooting yet again, I could start Wireshark, and list the installed
>> interfaces - but unsurprisingly, a few moments later, I received another
>> BSoD.
>>
>> If it helps, my Wireshark version is:
>>
>> Version 1.99.8-492-g3f0f49d (v1.99.8rc0-492-g3f0f49d from master)
>>
>> Copyright 1998-2015 Gerald Combs  and contributors.
>> License GPLv2+: GNU GPL version 2 or later <
>> http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
>> 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 (64-bit) with GTK+ 2.24.23, with Cairo 1.12.16, with Pango
>> 1.36.8, with
>> WinPcap (unknown), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with
>> c-ares 1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with
>> MIT
>> Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 22 2015), with
>> AirPcap.
>>
>> Running on 64-bit Windows 8.1, build 9600, with locale English_United
>> Kingdom.1252, with Npcap version 0.01 (packet.dll version 0.03), based on
>> WinPcap version 4.1.3 (packet.dll version 4.1.0.3001), based on libpcap
>> version
>> 1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2,
>> without
>> AirPcap.
>> AMD A6-5200 APU with Radeon(TM) HD Graphics (with SSE4.2), with
>> 5577MB of
>> physical memory.
>>
>>
>> Built using Microsoft Visual C++ 12.0 build 31101
>>
>> Wireshark is Open Source Software released under the GNU General Public
>> License.
>>
>> Check the man page and http://www.wireshark.org for more information.
>>
>
> I used Wireshark latest stable version: Version 1.12.6 (v1.12.6-0-gee1fce6
> from master-1.12). But I don't think it makes a difference by using stable
> version or development version, as its WinPcap related low-level code
> ra

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-27 Thread Tyson Key
Hi Yang,

Finally, after removing the Nurago Web Meter, and its Gacela LSP stack
(which is supposedly user-mode-only) (and upgrading VMware Player to 6.0.7,
from 6.0.4), running CCleaner again, and quickly starting Wireshark,
quitting it, and then restarting it, I am able to capture packets (14k, so
far) using NPCap (including from loopback).

I think I'll need to keep things running for a couple of hours, to see if I
have any other crashes - but since Gacela seems to be installed by a lot of
third-party software, it may be worth investigating this incompatibility.

If it helps, I can provide you with a copy of the Nurago/Gacela software,
for investigation. (Builds of this are personalised with a per-user ID,
prior to downloading from a UK/Germany-based Internet activity research
site, and it seems that the download server is currently offline).

Tyson.

2015-07-27 15:42 GMT+01:00 Tyson Key :

> After rebooting from uninstalling MS NetMon, I restarted Wireshark, and
> got the usual "NPF service not running; no interfaces available" note. This
> persists, even if I try "NPFInstall -r", and Wireshark still claims that no
> interfaces are available.
>
> Eventually, after uninstalling NPCap, removing all of the loopback
> interfaces, and running CCleaner to remove any residual registry data, and
> then rebooting yet again, I could start Wireshark, and list the installed
> interfaces - but unsurprisingly, a few moments later, I received another
> BSoD.
>
> If it helps, my Wireshark version is:
>
> Version 1.99.8-492-g3f0f49d (v1.99.8rc0-492-g3f0f49d from master)
>
> Copyright 1998-2015 Gerald Combs  and contributors.
> License GPLv2+: GNU GPL version 2 or later <
> http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
> 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 (64-bit) with GTK+ 2.24.23, with Cairo 1.12.16, with Pango
> 1.36.8, with
> WinPcap (unknown), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with
> c-ares 1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT
> Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 22 2015), with
> AirPcap.
>
> Running on 64-bit Windows 8.1, build 9600, with locale English_United
> Kingdom.1252, with Npcap version 0.01 (packet.dll version 0.03), based on
> WinPcap version 4.1.3 (packet.dll version 4.1.0.3001), based on libpcap
> version
> 1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2,
> without
> AirPcap.
> AMD A6-5200 APU with Radeon(TM) HD Graphics (with SSE4.2), with 5577MB
> of
> physical memory.
>
>
> Built using Microsoft Visual C++ 12.0 build 31101
>
> Wireshark is Open Source Software released under the GNU General Public
> License.
>
> Check the man page and http://www.wireshark.org for more information.
>
> Other than NetMon (which I've removed), the only other things that I think
> could be causing a conflict are either the VMware host-only networking
> filters; the networking components included with whatever Bluetooth stack
> Lenovo shipped; the massive pile of hacks installed by the Gacela component
> of "Nurago Web Meter", or my Atheros WLAN drivers (which caused Acrylic
> Wi-Fi's NDIS filters to crash, when I briefly had that installed, a while
> ago).
>
> In the meantime, I'm going to upgrade my VMware Player installation to the
> latest version, and see if it includes newer networking components.
>
> Tyson.
>
> 2015-07-27 14:46 GMT+01:00 Tyson Key :
>
>> Annoying, because Microsoft Network Monitor 3.4 is the only tool that can
>> capture 802.11 traffic in monitor mode even semi-reliably (although it
>> seems that the buffer gets full, and then it stops capturing, after about
>> 30 minutes), with my Atheros WLAN adapter, under Windows - but it seems
>> that if I disable the NetMon 3.4 driver on the NPCap Loopback Interface, I
>> can then start Wireshark, and then capture for about a minute, before I
>> receive another BSoD:
>>
>> ==
>> Dump File : 072715-30015-01.dmp
>> Crash Time: 27/07/2015 02:14:04 pm
>> Bug Check String  : BAD_POOL_CALLER
>> Bug Check Code: 0x00c2
>> Parameter 1   : `0007
>> Parameter 2   : `1200
>> Parameter 3   : `d9c696f2
>> Parameter 4   : e000`fad2a488
>> Caused By Driver  : ntoskrnl.exe
>> Caused By Address : ntoskrnl.exe+150ca0
>> File Description  : NT Kernel & System
>> Product Name  : Microsoft® Windows® Operating System
>> Company   : Microsoft 

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-27 Thread Tyson Key
After rebooting from uninstalling MS NetMon, I restarted Wireshark, and got
the usual "NPF service not running; no interfaces available" note. This
persists, even if I try "NPFInstall -r", and Wireshark still claims that no
interfaces are available.

Eventually, after uninstalling NPCap, removing all of the loopback
interfaces, and running CCleaner to remove any residual registry data, and
then rebooting yet again, I could start Wireshark, and list the installed
interfaces - but unsurprisingly, a few moments later, I received another
BSoD.

If it helps, my Wireshark version is:

Version 1.99.8-492-g3f0f49d (v1.99.8rc0-492-g3f0f49d from master)

Copyright 1998-2015 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later <
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 (64-bit) with GTK+ 2.24.23, with Cairo 1.12.16, with Pango 1.36.8,
with
WinPcap (unknown), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with
c-ares 1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 22 2015), with
AirPcap.

Running on 64-bit Windows 8.1, build 9600, with locale English_United
Kingdom.1252, with Npcap version 0.01 (packet.dll version 0.03), based on
WinPcap version 4.1.3 (packet.dll version 4.1.0.3001), based on libpcap
version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without
AirPcap.
AMD A6-5200 APU with Radeon(TM) HD Graphics (with SSE4.2), with 5577MB
of
physical memory.


Built using Microsoft Visual C++ 12.0 build 31101

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.

Other than NetMon (which I've removed), the only other things that I think
could be causing a conflict are either the VMware host-only networking
filters; the networking components included with whatever Bluetooth stack
Lenovo shipped; the massive pile of hacks installed by the Gacela component
of "Nurago Web Meter", or my Atheros WLAN drivers (which caused Acrylic
Wi-Fi's NDIS filters to crash, when I briefly had that installed, a while
ago).

In the meantime, I'm going to upgrade my VMware Player installation to the
latest version, and see if it includes newer networking components.

Tyson.

2015-07-27 14:46 GMT+01:00 Tyson Key :

> Annoying, because Microsoft Network Monitor 3.4 is the only tool that can
> capture 802.11 traffic in monitor mode even semi-reliably (although it
> seems that the buffer gets full, and then it stops capturing, after about
> 30 minutes), with my Atheros WLAN adapter, under Windows - but it seems
> that if I disable the NetMon 3.4 driver on the NPCap Loopback Interface, I
> can then start Wireshark, and then capture for about a minute, before I
> receive another BSoD:
>
> ==
> Dump File : 072715-30015-01.dmp
> Crash Time: 27/07/2015 02:14:04 pm
> Bug Check String  : BAD_POOL_CALLER
> Bug Check Code: 0x00c2
> Parameter 1   : `0007
> Parameter 2   : `1200
> Parameter 3   : `d9c696f2
> Parameter 4   : e000`fad2a488
> Caused By Driver  : ntoskrnl.exe
> Caused By Address : ntoskrnl.exe+150ca0
> File Description  : NT Kernel & System
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\072715-30015-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 27/07/2015 02:15:06 pm
> ==
>
> Usually, the NetMon, and WinPCap (and VMware passthrough) drivers can
> safely co-exist on a machine, without issues - but having had bad
> experiences with an "AppEx Networks Accelerator" (QoS) filter driver
> causing blue-screens, in the past, I'm starting to suspect that only a few
> filter drivers can safely hook the same points of the networking stack,
> before they trample over each other...
>
> As an experiment, I'm going to see what happens if I remove both the
> NetMon driver, and the "Npcap Packet Driver (NPCAP)", and replace them with
> "Win10Pcap Packet Capture Driver", despite using Windows 8.1, instead of
> Windows 10:
>
> I get prompted with &

Re: [Wireshark-dev] Npcap 0.03 call for test

2015-07-27 Thread Tyson Key
Annoying, because Microsoft Network Monitor 3.4 is the only tool that can
capture 802.11 traffic in monitor mode even semi-reliably (although it
seems that the buffer gets full, and then it stops capturing, after about
30 minutes), with my Atheros WLAN adapter, under Windows - but it seems
that if I disable the NetMon 3.4 driver on the NPCap Loopback Interface, I
can then start Wireshark, and then capture for about a minute, before I
receive another BSoD:

==
Dump File : 072715-30015-01.dmp
Crash Time: 27/07/2015 02:14:04 pm
Bug Check String  : BAD_POOL_CALLER
Bug Check Code: 0x00c2
Parameter 1   : `0007
Parameter 2   : `1200
Parameter 3   : `d9c696f2
Parameter 4   : e000`fad2a488
Caused By Driver  : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+150ca0
File Description  : NT Kernel & System
Product Name  : Microsoft® Windows® Operating System
Company   : Microsoft Corporation
File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1   :
Stack Address 2   :
Stack Address 3   :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-30015-01.dmp
Processors Count  : 4
Major Version : 15
Minor Version : 9600
Dump File Size: 281,520
Dump File Time: 27/07/2015 02:15:06 pm
==

Usually, the NetMon, and WinPCap (and VMware passthrough) drivers can
safely co-exist on a machine, without issues - but having had bad
experiences with an "AppEx Networks Accelerator" (QoS) filter driver
causing blue-screens, in the past, I'm starting to suspect that only a few
filter drivers can safely hook the same points of the networking stack,
before they trample over each other...

As an experiment, I'm going to see what happens if I remove both the NetMon
driver, and the "Npcap Packet Driver (NPCAP)", and replace them with
"Win10Pcap Packet Capture Driver", despite using Windows 8.1, instead of
Windows 10:

I get prompted with "The file 'Win10Pcap.sys' on Win10Pcap Packet Capture
Driver Installation Disk is needed. Type the path where the file is
located, and then click OK", and the default search path is set to
"C:\Program Files (x86)\Win10Pcap\x64\drivers\win78". Unsurprisingly,
neither "C:\Program Files\Win10Pcap\x64\", nor "C:\Program Files
(x86)\Win10Pcap\x64\" exist - so I'll have to scrap that idea, and try just
reinstalling the regular NPCap driver, as a "service", using the .inf file
in "C:\Program Files\Npcap"..

Now, I get "The NPF driver isn't running.  You may have trouble capturing
or listing interfaces", when restarting Wireshark, but at least it doesn't
BSoD. I'll try rebooting, and see what happens...

2015-07-27 14:08 GMT+01:00 Tyson Key :

> Hi Yang,
>
> I just tried this version on my machine (after uninstalling WinPCap,
> rebooting, installing NPCap, and then rebooting again), and it seems that
> during starting Wireshark, I still receive the BAD_POOL_CALLER BSoD:
>
> ==
> Dump File : 072715-38828-01.dmp
> Crash Time: 27/07/2015 01:55:12 pm
> Bug Check String  : BAD_POOL_CALLER
> Bug Check Code: 0x00c2
> Parameter 1   : `0007
> Parameter 2   : `1200
> Parameter 3   : `
> Parameter 4   : e000`53e2a9c8
> Caused By Driver  : ntoskrnl.exe
> Caused By Address : ntoskrnl.exe+150ca0
> File Description  : NT Kernel & System
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.17736 (winblue_r9.150322-1500)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\072715-38828-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 27/07/2015 01:56:27 pm
> ==
>
> If it helps, here's the list of loaded drivers, and DLLs, at the time of
> crashing:
>
> dump_diskdump.sys f800`bd725000 f800`bd731000 0xc000
> 0x5215f8a2 22/08/2013 12:40:18 pm
> dump_amd_sata.sys f800`bd731000 f800`bd74e000 0x0001d000
> 0x50b875ba 30/11/2012 10:00:42 am
> dump_dumpfve.sys f800`bd74e000 f800`bd764000 0x00016000 0x530894b8 
> 22/02/2014
> 01:14:48 pm
> X5XSEx_Pr148.Sys f800`bec0 f800`bec12000 0x00012000 0x501a77cf 
> 02/08/2012
> 01:51:27 pm
> ATMFD.

Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)

2015-07-19 Thread Tyson Key
Sorry for the further spam, but this is an interesting (and annoying!)
development...

After rebooting from the last BSOD, I tried running Wireshark, and received
the usual error about the NPF server not running. However, after quitting
it, I decided to try disabling the "Microsoft Network Monitor 3 Driver"
(which seems to coexist with regular WinPCap, without problems), and ran
"sc start npf":

C:\WINDOWS\system32>sc start npf

SERVICE_NAME: npf
TYPE   : 1  KERNEL_DRIVER
STATE  : 4  RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT : 0x0
WAIT_HINT  : 0x0
PID: 0
FLAGS  :

C:\WINDOWS\system32>

After waiting a little while, I started wireshark-gtk.exe, and discovered
that the interface list was populated. However, after about 45 seconds, I
received yet another BSOD:

==
Dump File : 071915-30828-01.dmp
Crash Time: 19/07/2015 07:18:16 pm
Bug Check String  : BAD_POOL_CALLER
Bug Check Code: 0x00c2
Parameter 1   : `0099
Parameter 2   : e001`e8f04148
Parameter 3   : `
Parameter 4   : `
Caused By Driver  : tm.sys
Caused By Address : tm.sys+e29ef9
File Description  : Kernel Transaction Manager Driver
Product Name  : Microsoft® Windows® Operating System
Company   : Microsoft Corporation
File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1   :
Stack Address 2   :
Stack Address 3   :
Computer Name :
Full Path : C:\WINDOWS\Minidump\071915-30828-01.dmp
Processors Count  : 4
Major Version : 15
Minor Version : 9600
Dump File Size: 281,520
Dump File Time: 19/07/2015 07:20:06 pm
==

Would be interesting to know why the BSOD occurs in the Kernel Transaction
Manager, this time...

Tyson.



2015-07-19 19:13 GMT+01:00 Tyson Key :

> ...and after rebooting, and reinstalling the various components using
> NPFInstall, and launching Wireshark, no interfaces are detected. However,
> after trying "sc start npf", and waiting a while, I'm greeted with another
> BSOD, of the same kind as last time:
>
> ==
> Dump File : 071915-35687-01.dmp
> Crash Time: 19/07/2015 07:03:01 pm
> Bug Check String  : BAD_POOL_CALLER
> Bug Check Code: 0x00c2
> Parameter 1   : `0007
> Parameter 2   : `1200
> Parameter 3   : `0003
> Parameter 4   : e000`99fa1008
> Caused By Driver  : tcpip.sys
> Caused By Address : tcpip.sys+1c2180
> File Description  : TCP/IP Driver
> Product Name  : Microsoft® Windows® Operating System
> Company   : Microsoft Corporation
> File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
> Processor : x64
> Crash Address : ntoskrnl.exe+150ca0
> Stack Address 1   :
> Stack Address 2   :
> Stack Address 3   :
> Computer Name :
> Full Path : C:\WINDOWS\Minidump\071915-35687-01.dmp
> Processors Count  : 4
> Major Version : 15
> Minor Version : 9600
> Dump File Size: 281,520
> Dump File Time: 19/07/2015 07:04:09 pm
> ==
>
> Tyson.
>
> 2015-07-19 17:05 GMT+01:00 Pascal Quantin :
>
>> Hi Yang,
>>
>> 2015-07-19 15:55 GMT+02:00 Yang Luo :
>>
>>> Hi Jim,
>>>
>>> Thanks for testing!
>>>
>>> On Sun, Jul 19, 2015 at 12:25 AM, Jim Young  wrote:
>>>
>>>>  Hello Yang,
>>>>
>>>>  Two comments on all for 2nd test.
>>>>
>>>>  1 - Should the name of the newer package reflect that this is a
>>>> different Npcap package from the 1st one?  The 2nd package is named
>>>> identical to the 1st one of npcap-nmap-0.01.exe.  The newly downloaded one
>>>> was saved by the browser as npcap-nmap-0.01(1).exe to avoid clobbering the
>>>> 1st one still in the Download folder.
>>>>
>>>>
>>> From now on, I will use installer name such as npcap-nmap-0.01-r2.exe,
>>> which means revision 2 under version 0.01. I don't want to change version
>>> numbers, as current Npcap has many bugs and can't be released as a stable
>>> version yet.
>>>
>>>
>>>>  2 - After uninstalling WinPcap, but not rebooting, I started
>>>> installing the newest Npcap package but the new i

Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)

2015-07-19 Thread Tyson Key
...and after rebooting, and reinstalling the various components using
NPFInstall, and launching Wireshark, no interfaces are detected. However,
after trying "sc start npf", and waiting a while, I'm greeted with another
BSOD, of the same kind as last time:

==
Dump File : 071915-35687-01.dmp
Crash Time: 19/07/2015 07:03:01 pm
Bug Check String  : BAD_POOL_CALLER
Bug Check Code: 0x00c2
Parameter 1   : `0007
Parameter 2   : `1200
Parameter 3   : `0003
Parameter 4   : e000`99fa1008
Caused By Driver  : tcpip.sys
Caused By Address : tcpip.sys+1c2180
File Description  : TCP/IP Driver
Product Name  : Microsoft® Windows® Operating System
Company   : Microsoft Corporation
File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1   :
Stack Address 2   :
Stack Address 3   :
Computer Name :
Full Path : C:\WINDOWS\Minidump\071915-35687-01.dmp
Processors Count  : 4
Major Version : 15
Minor Version : 9600
Dump File Size: 281,520
Dump File Time: 19/07/2015 07:04:09 pm
==

Tyson.

2015-07-19 17:05 GMT+01:00 Pascal Quantin :

> Hi Yang,
>
> 2015-07-19 15:55 GMT+02:00 Yang Luo :
>
>> Hi Jim,
>>
>> Thanks for testing!
>>
>> On Sun, Jul 19, 2015 at 12:25 AM, Jim Young  wrote:
>>
>>>  Hello Yang,
>>>
>>>  Two comments on all for 2nd test.
>>>
>>>  1 - Should the name of the newer package reflect that this is a
>>> different Npcap package from the 1st one?  The 2nd package is named
>>> identical to the 1st one of npcap-nmap-0.01.exe.  The newly downloaded one
>>> was saved by the browser as npcap-nmap-0.01(1).exe to avoid clobbering the
>>> 1st one still in the Download folder.
>>>
>>>
>> From now on, I will use installer name such as npcap-nmap-0.01-r2.exe,
>> which means revision 2 under version 0.01. I don't want to change version
>> numbers, as current Npcap has many bugs and can't be released as a stable
>> version yet.
>>
>>
>>>  2 - After uninstalling WinPcap, but not rebooting, I started
>>> installing the newest Npcap package but the new install is hung at the
>>> step:
>>>
>>>  Execute: "C:\Program Files\Npcpa\NPFInstall.exe" -il
>>>
>>>
>> I have improved this part logic, plz test the latest installer:
>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01-r2.exe
>>
>> This operation takes some time indeed, but should be less than 20s.
>>
>
> I just gave a quick test to 0.1-r2 version on my Windows 10 virtual
> machine.
> - I uninstalled WinPcap and installed Npcap in Winpcap mode without
> reboot. I got the same warning as Tyson regarding the upgrade of npf.sys
> file, presumably because yours as version 0.1.0.710 against Winpcap that
> uses version 4.1.0.2980. Maybe you should advice to reboot the PC after
> uninstalling Winpcap.
> - The loopback interface is still named 'Ethernet 2'. I run on Windows
> 10.0.10240 with French local in case this matters.
> - After reboot, Wireshark could not see any interface. I doubled checked
> the driver state and saw that it was stopped. Manually starting it with 'sc
> npf start' command allowed Wireshark to see interfaces. After reboot the
> service does not start automatically.
>
> I will try to test the WWAN capture beginning of next week.
>
> Pascal.
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Npcap 0.01 call for test about Windows loopback traffic capture feature

2015-07-19 Thread Tyson Key
Hi Yang,

Sorry for the late reply about the BSOD issue (especially in this thread),
but here is my debugging information, from BlueScreenView;

==
Dump File : 071115-33031-01.dmp
Crash Time: 11/07/2015 08:56:46 pm
Bug Check String  : BAD_POOL_CALLER
Bug Check Code: 0x00c2
Parameter 1   : `0007
Parameter 2   : `1200
Parameter 3   : `0c00
Parameter 4   : e001`f29be558
Caused By Driver  : tcpip.sys
Caused By Address : tcpip.sys+1c2180
File Description  : TCP/IP Driver
Product Name  : Microsoft® Windows® Operating System
Company   : Microsoft Corporation
File Version  : 6.3.9600.16384 (winblue_rtm.130821-1623)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1   :
Stack Address 2   :
Stack Address 3   :
Computer Name :
Full Path : C:\WINDOWS\Minidump\071115-33031-01.dmp
Processors Count  : 4
Major Version : 15
Minor Version : 9600
Dump File Size: 281,456
Dump File Time: 11/07/2015 08:57:50 pm
==

I don't know if they're related to NPCap, or WinPCap (since BSV seems to
load the current executable/DLL images from disk, to resolve the vendor
names; and the nature of npf.sys is that it's always RAM-resident, and
loaded into the TCP/IP stack), but I also have MiniDumps with
SYSTEM_SERVICE_EXCEPTION, and SYSTEM_THREAD_EXCEPTION_NOT_HANDLED errors.

Tyson.

2015-07-17 1:57 GMT+01:00 Yang Luo :

> Hi Tyson,
>
> On Thu, Jul 16, 2015 at 6:10 PM, Tyson Key  wrote:
>
>> Hi Yang,
>>
>> Come to think of it, I got exactly the same BSoD error as Jim (
>> BAD_POOL_CALLER).
>>
>
> About this BAD_POOL_CALLER BSOD, I think there may be some bugs in
> allocating pool memory. I have found this in MS:
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff560185(v=vs.85).aspx.
> It needs the four parameters in your BSOD screen to check the detailed
> crash reason. It's good if you can provide it:)
>
>>
>> However, my configuration is different (I have a bunch of VMware
>> interfaces, and an Atheros AR9485WB-EG WLAN adaptor, which is also
>> semi-supported by Acrylic Wi-Fi - but BSoDs for a different reason (seems
>> to be related to NDIS drivers, with that)), and multiple loopback adaptors
>> were created on my machine (named "Microsoft KM-TEST Loopback Adaptor",
>> instead of "NPCap Loopback", if memory serves correctly).
>>
>
> If you run "NPFInstall.exe -il" one time, Npcap will install one adapter
> for you. This is why you have so many loopback adapters. You should run
> "NPFInstall.exe -ul" to uninstall the lastest loopback adapter.
> And it seems that Npcap's renaming adapter to "Npcap Loopback Adapter"
> code doesn't work on Win10 and with no obvious reason. I have reported this
> to Microsoft to see if there's a solution.
>
>
>> Bizarrely, even after uninstalling NPCap, and replacing it with WinPCap,
>> these KM-TEST adaptors still persist across reboots:
>> [image: 埋め込み画像 1]
>>
>> I assume that these are a side-effect of manually installing the .ini
>> file, after attempting to run the set-up tool ("npfinstall -r", "npfinstall
>> -li", and then "npfinstall -i") via a batch script with Administrator
>> privileges.
>>
>> I also found that although I could see packets containing a MAC address
>> with the mnemonic "LOOP", I could not capture any ICMP traffic, when trying
>> to ping 127.0.0.1, or ::1 (using both Microsoft Network Monitor, and
>> Wireshark - the latter of which would not detect any interfaces, after
>> reinstalling NPCap a few times, before eventually replacing it with
>> WinPCap, until I rebooted).
>>
>
> If you have installed multiple loopback adapters using  "NPFInstall.exe
> -il", Npcap will view only the last one as the real "Npcap Loopback
> Adapter", so in your picture, it is only "Ethernet 4" that can be
> recognized by Npcap as loopback adapter. In this adapter, you should be
> able to see the loopback traffic.
>
>>
>> If I get time, I'm going to see if I can reproduce the BSoD, and try
>> writing down the steps involved.
>>
>> If you found another BSOD, perhaps you can take a picture of it, so I can
> get enough details about the causes and parameters about it.
>
>
>> Tyson.
>>
>>
> Cheers,
> Yang
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wir

Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)

2015-07-19 Thread Tyson Key
PS - No joy with manually running "NPFInstall.exe -ul" multiple times, to
remove the redundant interfaces, so I had to resort to uninstalling them
using Device Manager, and then rebooting.

2015-07-19 15:37 GMT+01:00 Tyson Key :

> Hi Yang,
>
> Just downloaded your latest package, and here's my experience, so far:
>
> After uninstalling the old WinPCap 4.1.3, and installing your new package
> (without rebooting), I get as far as "NPFInstall.exe - il" (which stalls
> for a while, but then continues, on my machine), and then continue to
> "NPFInstall.exe -iw".
>
> At this stage, it appears that some driver files from the old version are
> still present, and Windows Explorer asks me if I want to replace them with
> "older" (i.e. the latest?) versions, for some reason (maybe the uninstaller
> isn't cleaning things up properly, on x86-64 machines?); before the
> correctly-named "Npcap Loopback Adaptor" gets installed (and then does a
> quick vanishing act (guessing that it tried to rename one of the myriad
> KM-TEST interfaces from earlier), before reappearing). Afterwards, I
> receive "The npf service for Win7 and Win8 was successfully created" - but
> starting Wireshark results in "The NPF driver isn't running.  You may have
> trouble
> capturing or listing interfaces".
>
> I'll follow up with my results of rebooting, shortly - but in the
> meantime, it might be a good idea to have the installer (and uninstaller)
> be smarter about removing older copies of the drivers, and try to
> automatically purge old instances of the loopback adaptor, if they exist.
>
> I hope that helps,
>
> Tyson.
>
> 2015-07-18 13:13 GMT+01:00 Yang Luo :
>
>> Hi list,
>>
>> Thanks for your tests for the first version Npcap, in this 2nd version, I
>> have fixed several problems as following:
>> 1) Npcap driver fails to start after system reboot.
>> 2) Adapter name is not changed to "Npcap Loopback Adapter" on Win10.
>> 3) BSoD caused by BAD_POOL_CALLER. I can't promise this BSoD is 100%
>> fixed, but I have secured pool memory free function calls which may lead to
>> BSoD. If this still occurs, please let me know.
>> 4) Npcap now will try to capture WAN adapter packets, I only switched on
>> this feature and it does not get tested, as I don't have a WAN adapter on
>> hand. If this feature has caused problems, or you know how to simulate a
>> WAN adapter for me to test, please tell me.
>>
>> The latest Npcap installer is:
>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01.exe
>>
>> I have tested this version Npcap under Wireshark 1.12.6 x64, in Windows 7
>> x86, Windows 8.1 x64 and Windows Server 2016 TP2.
>>
>> Notice: You need to try it under Win7 and later, and no need to change
>> the installation options, just click the "Next"s. Npcap installed in
>> "WinPcap Compatible Mode" is exclusive with WinPcap, so you must uninstall
>> WinPcap first (installer will prompt you this).
>>
>> The README is:
>> https://github.com/nmap/npcap
>>
>>
>> Cheers,
>> Yang
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
>
> --
>   Fight Internet Censorship!
> http://www.eff.org
> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
> 00447934365844
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Npcap 0.01 call for test (2nd)

2015-07-19 Thread Tyson Key
Hi Yang,

Just downloaded your latest package, and here's my experience, so far:

After uninstalling the old WinPCap 4.1.3, and installing your new package
(without rebooting), I get as far as "NPFInstall.exe - il" (which stalls
for a while, but then continues, on my machine), and then continue to
"NPFInstall.exe -iw".

At this stage, it appears that some driver files from the old version are
still present, and Windows Explorer asks me if I want to replace them with
"older" (i.e. the latest?) versions, for some reason (maybe the uninstaller
isn't cleaning things up properly, on x86-64 machines?); before the
correctly-named "Npcap Loopback Adaptor" gets installed (and then does a
quick vanishing act (guessing that it tried to rename one of the myriad
KM-TEST interfaces from earlier), before reappearing). Afterwards, I
receive "The npf service for Win7 and Win8 was successfully created" - but
starting Wireshark results in "The NPF driver isn't running.  You may have
trouble
capturing or listing interfaces".

I'll follow up with my results of rebooting, shortly - but in the meantime,
it might be a good idea to have the installer (and uninstaller) be smarter
about removing older copies of the drivers, and try to automatically purge
old instances of the loopback adaptor, if they exist.

I hope that helps,

Tyson.

2015-07-18 13:13 GMT+01:00 Yang Luo :

> Hi list,
>
> Thanks for your tests for the first version Npcap, in this 2nd version, I
> have fixed several problems as following:
> 1) Npcap driver fails to start after system reboot.
> 2) Adapter name is not changed to "Npcap Loopback Adapter" on Win10.
> 3) BSoD caused by BAD_POOL_CALLER. I can't promise this BSoD is 100%
> fixed, but I have secured pool memory free function calls which may lead to
> BSoD. If this still occurs, please let me know.
> 4) Npcap now will try to capture WAN adapter packets, I only switched on
> this feature and it does not get tested, as I don't have a WAN adapter on
> hand. If this feature has caused problems, or you know how to simulate a
> WAN adapter for me to test, please tell me.
>
> The latest Npcap installer is:
> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01.exe
>
> I have tested this version Npcap under Wireshark 1.12.6 x64, in Windows 7
> x86, Windows 8.1 x64 and Windows Server 2016 TP2.
>
> Notice: You need to try it under Win7 and later, and no need to change the
> installation options, just click the "Next"s. Npcap installed in "WinPcap
> Compatible Mode" is exclusive with WinPcap, so you must uninstall WinPcap
> first (installer will prompt you this).
>
> The README is:
> https://github.com/nmap/npcap
>
>
> Cheers,
> Yang
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Npcap 0.01 call for test about Windows loopback traffic capture feature

2015-07-16 Thread Tyson Key
Hi Yang,

Come to think of it, I got exactly the same BSoD error as Jim (
BAD_POOL_CALLER).

However, my configuration is different (I have a bunch of VMware
interfaces, and an Atheros AR9485WB-EG WLAN adaptor, which is also
semi-supported by Acrylic Wi-Fi - but BSoDs for a different reason (seems
to be related to NDIS drivers, with that)), and multiple loopback adaptors
were created on my machine (named "Microsoft KM-TEST Loopback Adaptor",
instead of "NPCap Loopback", if memory serves correctly).

Bizarrely, even after uninstalling NPCap, and replacing it with WinPCap,
these KM-TEST adaptors still persist across reboots:
[image: 埋め込み画像 1]

I assume that these are a side-effect of manually installing the .ini file,
after attempting to run the set-up tool ("npfinstall -r", "npfinstall -li",
and then "npfinstall -i") via a batch script with Administrator privileges.

I also found that although I could see packets containing a MAC address
with the mnemonic "LOOP", I could not capture any ICMP traffic, when trying
to ping 127.0.0.1, or ::1 (using both Microsoft Network Monitor, and
Wireshark - the latter of which would not detect any interfaces, after
reinstalling NPCap a few times, before eventually replacing it with
WinPCap, until I rebooted).

If I get time, I'm going to see if I can reproduce the BSoD, and try
writing down the steps involved.

Tyson.

2015-07-16 10:56 GMT+01:00 Yang Luo :

> Hi Tyson,
>
> Thanks for testing Npcap and I already knew what to do about the service
> not start issue. It would be better if you can provide the BSOD issue
> reproduce steps because I never encountered this. I also encountered the
> connection loss problem sometimes, but it happens in a random way and I
> still don't know how to reproduce it.
>
> Cheers,
> Yang
>
>
> On Wed, Jul 15, 2015 at 7:03 PM, Tyson Key  wrote:
>
>> Hi Yang,
>>
>> Thank you for looking into implementing this. Sadly, I tried your package
>> on my Win8.1 x86-64 machine, and found that not only did the new NPF
>> service not start after uninstalling "real" WinPCap (running the
>> installation tool manually, with the -il, and -i options didn't seem to do
>> anything, until rebooting), and then your new NPCap in "compatibility
>> mode", I had problems connecting to my WLAN, after rebooting (and I also
>> received a BSOD, at one stage whilst trying to capture on multiple
>> interfaces).
>>
>> Unfortunately, I don't know if I can reproduce these issues, or provide
>> any logging information, this time - but if I get chance, I'll have another
>> look.
>>
>> Take care,
>>
>> Tyson.
>>
>> 2015-07-11 10:15 GMT+01:00 Yang Luo :
>>
>>> Hi list,
>>>
>>> In order not to diverge with WinPcap interfaces, I have made a "WinPcap
>>> Mode" for Npcap, it uses the same system32 directory to put DLLs and has
>>> the same "npf" service and driver name. So it can be directly used in
>>> Wireshark without any patch.
>>>
>>> Another news is that I have finished Windows loopback packet capture
>>> feature in Npcap, Npcap will install an adapter named "Npcap Loopback
>>> Adapter". And I can see the loopback traffic using Wireshark now (See the
>>> attached pic). It seems to still have problems, like the "(no response
>>> found!)" in the ICMPv6 packets (ping ::1) in the pic. I don't know why
>>> Wireshark shows like this, perhaps you guys can provide me a clue.
>>>
>>> The latest Npcap installer is:
>>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01.exe
>>>
>>> I have tested this version Npcap under Wireshark 1.12.6 x64, in Windows
>>> 8.1 x64 and Windows Server 2016 TP2.
>>>
>>> Notice: You need to try it under Win7 and later, and no need to change
>>> the installation options, just click the "Next"s. Npcap installed in
>>> "WinPcap Mode" is exclusive with WinPcap, so you must uninstall WinPcap
>>> first (installer will prompt you this).
>>>
>>> The README is:
>>> https://github.com/nmap/npcap
>>>
>>> The implementation internal about loopback traffic feature is:
>>> http://seclists.org/nmap-dev/2015/q3/35
>>>
>>>
>>> Cheers,
>>> Yang
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>

Re: [Wireshark-dev] Npcap 0.01 call for test about Windows loopback traffic capture feature

2015-07-15 Thread Tyson Key
Hi Yang,

Thank you for looking into implementing this. Sadly, I tried your package
on my Win8.1 x86-64 machine, and found that not only did the new NPF
service not start after uninstalling "real" WinPCap (running the
installation tool manually, with the -il, and -i options didn't seem to do
anything, until rebooting), and then your new NPCap in "compatibility
mode", I had problems connecting to my WLAN, after rebooting (and I also
received a BSOD, at one stage whilst trying to capture on multiple
interfaces).

Unfortunately, I don't know if I can reproduce these issues, or provide any
logging information, this time - but if I get chance, I'll have another
look.

Take care,

Tyson.

2015-07-11 10:15 GMT+01:00 Yang Luo :

> Hi list,
>
> In order not to diverge with WinPcap interfaces, I have made a "WinPcap
> Mode" for Npcap, it uses the same system32 directory to put DLLs and has
> the same "npf" service and driver name. So it can be directly used in
> Wireshark without any patch.
>
> Another news is that I have finished Windows loopback packet capture
> feature in Npcap, Npcap will install an adapter named "Npcap Loopback
> Adapter". And I can see the loopback traffic using Wireshark now (See the
> attached pic). It seems to still have problems, like the "(no response
> found!)" in the ICMPv6 packets (ping ::1) in the pic. I don't know why
> Wireshark shows like this, perhaps you guys can provide me a clue.
>
> The latest Npcap installer is:
> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.01.exe
>
> I have tested this version Npcap under Wireshark 1.12.6 x64, in Windows
> 8.1 x64 and Windows Server 2016 TP2.
>
> Notice: You need to try it under Win7 and later, and no need to change the
> installation options, just click the "Next"s. Npcap installed in "WinPcap
> Mode" is exclusive with WinPcap, so you must uninstall WinPcap first
> (installer will prompt you this).
>
> The README is:
> https://github.com/nmap/npcap
>
> The implementation internal about loopback traffic feature is:
> http://seclists.org/nmap-dev/2015/q3/35
>
>
> Cheers,
> Yang
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] On which platforms is there a need for Wireshark to have a "Language" preference?

2014-11-06 Thread Tyson Key
Hi Guy,

Right now, iTunes, SoftMaker Office, Shareaza, RealPlayer, and Google
Chrome are the most apparent examples (from memory) of relatively-popular
applications for Windows that expose a preference in their configuration
GUIs, to support changing the program language on-the-fly.

I'm sure that there are others, too...

Tyson.
___
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] Qt License Change

2014-08-21 Thread Tyson Key
Hi,

I'm not a lawyer - but judging by that post, and the statements "...we are
now adding LGPL v3 as a licensing option to Qt 5.4 in addition to LGPL
v2.1", and "All modules that existed in Qt 5.3 will still be available
under LGPL v2.1. So if you are using Qt under the GPL v2 or LGPL v2.1,
nothing changes as long as you don’t use any of the new modules that are
only available under LGPL v3", we should be OK, as long as we're careful
about using some of the New Shiny(TM) stuff in 5.4.

That said, to be honest, I can't see us moving the UI to Qt Quick; or using
WebGL, or the new HTML renderer, any time soon, anyway...

Tyson.


2014-08-20 17:31 GMT+01:00 Evan Huus :

> http://blog.qt.digia.com/blog/2014/08/20/adding-lgpl-v3-to-qt/
>
> I don't *think* this affects us, but I haven't thought about it too hard.
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Difference between wiretap, winpcap and libpcap

2014-04-01 Thread Tyson Key
Hi Vishnu,

WinPCap is effectively an external "branch" (not sure if "fork" is the correct 
term, since the devs track upstream libpcap) of the libpcap library (which is 
designed to abstract the packet capturing APIs of at least various UNIXesque 
OSes, and also MS-DOS) for 32-bit, and 64-bit Windows.

Wiretap is Wireshark's abstraction layer for interfacing with libpcap/WinPCap, 
and various other capturing mechanisms, as well as parsing various file 
formats. It also contains infrastructure for discriminating against protocol 
payload types.

To support privilege separation, a shim binary (dumpcap) is used to actually 
perform capturing.

I hope that explanation is accurate, and makes sense.

Tyson.
-Original Message-
From: Vishnu Bhatt 
Sender: wireshark-dev-bounces@wireshark.orgDate: Tue, 1 Apr 2014 12:50:12 
To: wireshark-dev@wireshark.org
Reply-To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Difference between wiretap, winpcap and libpcap

___
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] Win64 BuildBot down?

2014-01-12 Thread Tyson Key
Hi Pascal,

Thanks for confirming. I was just wondering, since I haven't gotten around
to setting up a Wireshark build environment in a Linux VM on this new PC,
and I tend to use the binary snapshots as a convenient way of testing the
latest changes.

Funnily enough, I did see that  the Mac OS X bots are still alive, just
now.

No big deal, though.

Tyson.


2014/1/12 Pascal Quantin 

> Hi Tyson,
>
> numerous buildbots are down, as seen on
> http://buildbot.wireshark.org/trunk/waterfall
> I can build locally without any problem for win64.
>
> Pascal.
>
>
> 2014/1/12 Tyson Key 
>
>> Hi list,
>>
>> It seems that there haven't been any more Win64 CI builds since the 9th...
>>
>> Please forgive me for asking - but is this since someone accidentally
>> broke the build, or due to infrastructure migration?
>>
>> Thanks,
>>
>> Tyson.
>> --
>>   Fight Internet Censorship!
>> http://www.eff.org
>> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
>> 00447934365844
>>
>>
>> ___
>> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Win64 BuildBot down?

2014-01-12 Thread Tyson Key
Hi list,

It seems that there haven't been any more Win64 CI builds since the 9th...

Please forgive me for asking - but is this since someone accidentally broke
the build, or due to infrastructure migration?

Thanks,

Tyson.
-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Thoughts on disabling an old dissector

2013-12-18 Thread Tyson Key
Hi Evan,

Hmm, now that's an interesting dilemma. Couldn't we rename the old
dissector to something like "tpncp_old", "tpncpv1", or "tpncp_legacy"?

That said, it'd probably be a disservice to completely remove a dissector
that folks are probably using to dissect "legacy" TPNCP packets in old
trace files.

Tyson.


2013/12/18 Evan Huus 

> This was originally filed as bug 9569. The situation is sufficiently
> unusual that I really don't know what the best solution is, so I
> figured I'd ask for general comments from the list. The company who
> created and used the TPNCP protocol (and submitted the packet-tpncp.c
> dissector) wants to reuse that name for a new, different protocol and
> are asking us to disable the old dissector to avoid conflicts. The bug
> has more detail.
>
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9569
>
> Thoughts?
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Unused dissector tables

2013-12-12 Thread Tyson Key
Hi Gerald,

Although the USB CCID, and packet-rfid-* dissectors invoke others to do payload 
dissection, I believe that the unused dissector table registration code was a 
left-over from initial design attempts - so it's probably safe to remove it.

I hope that helps,

Tyson.
-Original Message-
From: Gerald Combs 
Sender: wireshark-dev-bounces@wireshark.orgDate: Thu, 12 Dec 2013 09:03:57 
To: Developer support list for Wireshark
Reply-To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Unused dissector tables

The following dissectors create dissector tables but don't appear to use
them:

packet-aim.c
packet-fcp.c
packet-rfid-mifare.c
packet-rfid-pn532.c
packet-rsvp.c
packet-usb-ccid.c

Should the registration code be disabled or removed?
___
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] What is the history and status of PCAP Next Generation?

2013-10-09 Thread Tyson Key
Apologies for the thread hijacking...

For what it's worth, I've just had a play with the latest build of CommView
(6.5, build 734), and it seems to have basic support for writing PCAP-NG
files. (Emits no packet comments, and doesn't use any nifty features like
storing application/machine info).

Since I haven't got a tool for reverse-engineering PCAP-NG traces handy
(other than looking at strings in a text editor), I'm assuming that they're
generating very bare-bones IDBs, and using (Simple?) Packet Blocks for
storing the packet data. I don't know if it'll preserve unrecognised
block/field types, or comments, either.

>From testing with some of the traces that I've attached to bug reports
related to CommView .NCF support in Wireshark, it seems that I can export
Ethernet packets with full fidelity; although exporting 802.11 captures is
a lossy process (the RSSI, band/frequency, and bandwidth/link speed field
values are lost).

In fact, it seems that even though the .NCF format supports multiple link
layer types (and converting 802.11-only captures works fine), attempting to
export a sample file containing 802.11, Ethernet, and Token Ring packets to
PCAP-NG results in a useless file with all of the packets assigned to a
single interface with an Ethernet link type.

So I guess that it's a good start from the TamoSoft folks - but they've got
a little more work to do, before they can call their product
fully-interoperable with PCAP-NG.

I still don't know if any of MS's offerings support writing files in this
format, though.

Tyson.


2013/10/9 Jasper Bongertz 

> Sorry to answer this late; I saw this email a week ago but didn't
> manage to reply - the todo got swapped out but never swapped in again.
> Graham gave me a heads up (that I didn't see until now, either,
> *sigh*), so here I go.
>
> >>  Q2: What is the status of pcap-ng?
> >>
> >>  * "it works fine, everyone's using it, it just isn't an RFC"
> >>   or * "it's an abandoned effort, plain pcap is good enough"
> >>   or * "all development has moved to X, take a look at X"
>
> > "It works fine, some software's using it, and there's no RFC for
> > pcap format, either, although there probably should be informative
> > RFCs for both of them at some point."
>
> At Sharkfest 2013 we (me, plus the Wireshark devs that were "in
> range") had a impromptu meeting regarding the status of the PCAP-ng
> specifications.
>
> I offered to see if we can go in the direction of an RFC, but got a
> bit sidetracked. I had checked how the procedures work in July/August, but
> at the time the RFC submission process was closed for new submissions.
> It should be open again by now, so I'll try to go forward asap.
>
> Oh, and regarding the status of PCAP-ng I'd say it is more like "a
> couple of tools are using it, but most are still stuck on pcap for
> whatever  reason."
>
> Cheers,
> Jasper
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] reported_length < -1

2013-09-07 Thread Tyson Key
Hi folks,

Sorry for hijacking the thread, but come to think of it, would it make more
sense to test if it's >0, rather than testing for !=0?

Tyson.


2013/9/7 Martin Kaiser 

> Dear all,
>
> I stumbled on
>
> tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb,
> 1) - 2));
>
> If tvb_get_guint8(tvb, 1)==0, we throw an exception because of
> backing_length - that makes sense.
>
> As for reported_length<-1, it looks like that's ok when the tvb is
> created. There'll be an exception when it's accessed, we'll always be
> out of bounds.
>
> Is there a valid use case for reported_length<-1?
>
> Thanks,
> Martin
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Jurassic packets

2013-06-13 Thread Tyson Key
Heh, couldn't you try to install the Open Source version of CDE? Or is that
too retro/now ironically incompatible with such an old distribution?

Tyson.


2013/6/13 Gerald Combs 

> On 6/13/13 1:52 PM, Jeff Morriss wrote:
> > On 06/13/13 14:09, Gerald Combs wrote:
> >> For Monday's Sharkfest keynote I wanted to show everyone what things
> >> looked like back in the early days of the project. After doing
> >> unspeakable things to a Red Hat 6.2 VM I managed to get a copy of
> >> Ethereal 0.2.0 up and running. Screenshot attached.
> >
> > You've really gotta replace the window dressing (whatever you call that
> > bar with the X to close it) with a Motif one (or something like that)!
> :-)
>
> I tried configuring XFree86 and then a bunch of unpleasant memories
> resurfaced and then I stopped.
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Icon Poll - is this OK?

2013-04-10 Thread Tyson Key
Hmm, what about a cassette tape?

Tyson.


2013/4/10 Shawn T Carroll 

> What dimensions are you shooting for with the icon? Is there a set __ x __
> pixels?
>
> My wife is a professional graphic designer, and is called upon regularly
> to design or redesign icons.  If the goal is to figure out ways to have a
> "record" button not look like an indicator light or stop sign, I bet she
> would have some ideas.
>
> If you def want to go with the "record" paradigm, I believe there are some
> pretty well-established norms for this in the icon world.
>
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
>   --
> *From:* Eric Wedel 
> *To:* Developer support list for Wireshark 
> *Sent:* Tuesday, April 9, 2013 7:43 PM
> *Subject:* Re: [Wireshark-dev] Icon Poll - is this OK?
>
>   Thanks for the graphics.
>
> Funny, on the text-only poll I voted for record/stop, as this is
> intuitively correct.
> [One can get in trouble for playing packets back into a live network. :-) ]
> But it seems that the record button (small red dot on a large button)
> doesn't
> transfer well to the screen, looking instead like an indicator light.
>
> Also, the fourth example has no shape distinction at all, so people with
> red/green
> color blindness would need to rely on tooltips / button placement.
>
>
>  *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Laura Chappell
> *Sent:* Tuesday, April 09, 2013 4:05 PM
> *To:* wireshark-dev@wireshark.org
> *Subject:* [Wireshark-dev] Icon Poll - is this OK?
>
> Check out https://www.surveymonkey.com/s/wsiconpoll.
>
> See the pretty pictures? 
>
> I can send this to about 25,000 folks on our mailing lists and hit
> Twitter/Facebook.
>
> Will provide feedback to the –dev list.
>
> Laura
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Cannot launch newly-built SVN "tshark" binaries under Ubuntu 11.10

2013-02-04 Thread Tyson Key
2013/1/20 Jaap Keuter 

> WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 ./wireshark &
>




-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] WhatsApp dissector

2013-02-02 Thread Tyson Key
Hi David,

That sounds like a pretty interesting dissector, to me. In order to
kick-start the contribution process, I recommend doing the following:

   - Registering at http://bugs.wireshark.org
   - Converting your code into a "build-in" dissector (a relatively trivial
   process that involves removing the plug-in configuration source file,
   checking the use of certain APIs, and then modifying
   /epan/dissectors/Makefile.common, and /epan/CMakeLists.txt*)*
   - Generating an SVN Diff-style patch, after placing your new source
   files in /epan/dissectors
   - Filing a new bug at Bugs.Wireshark.org -taking care to attach your
   patch, and preferably a trace file that exercises it

I hope that helps.

Thanks,

Tyson.
2013/2/1 David Guillen Fandos 

> Hello folks,
>
> I've developed a WhatsApp protocol dissector. Are you interested in
> merging the plugin in wireshark source?
> The plugin features packet dissection with decryption (only if the key is
> known). It's still very basic but very useful for protocol implementation
> and testing. I used it successfully to test a PC whatsapp client.
>
> Thank you,
>
> David
> __**__**
> ___
> 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-request@**wireshark.org
> ?subject=**unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Cannot launch newly-built SVN "tshark" binaries under Ubuntu 11.10

2013-01-18 Thread Tyson Key
Hi list,

Apologies if it sounds as if I'm doing something stupid, or missing
something obvious; and for the verbosity of this e-mail.

Over the past day or so, I've ended up upgrading one of my Ubuntu
installations from 11.04, to 11.10, as a result of some problems regarding
building against the GTK packages that I had installed, whilst trying to
test a dissector that I'm working on. I also decided to upgrade my LibPCap
version to 1.4.0-PRE-GIT_2013_01_18, from a customised build of an earlier
Git revision.

Now, attempting to build Wireshark from source (using either the
automatically-generated archives, or by manually checking out the
repository trunk) seemingly succeeds, and running "make install" works as
expected. However, attempting to run either the GTK-based Wireshark
application, or the TShark utility fails with a multitude of errors (some
related to inconsistencies in the plug-in ABI/missing symbols - despite
doing clean installations, every time).

If I try to launch the GTK application, I see a chain of dialogues stating:
*Couldn't load module
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/wimaxasncp/.libs/wimaxasncp.so:
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/wimaxasncp/.libs/wimaxasncp.so:
undefined symbol: eap_type_vals_ext

Couldn't load module
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/mate/.libs/mate.so:
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/mate/.libs/mate.so:
undefined symbol: prefs_register_filename_preference

Couldn't load module
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/asn1/.libs/asn1.so:
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/asn1/.libs/asn1.so:
undefined symbol: prefs_register_filename_preference

Couldn't load module
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/stats_tree/.libs/stats_tree.so:
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/stats_tree/.libs/stats_tree.so:
undefined symbol: prefs_register_stat

Couldn't load module
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/profinet/.libs/profinet.so:
/home/tysonkey/wireshark-1.9.0-SVN-47138/plugins/profinet/.libs/profinet.so:
undefined symbol: crc16_plain_tvb_offset_seed

*Eventually, after dismissing them all, the app unceremoniously quits,
after printing the following to the terminal:
***
ERROR:about_dlg.c:271:splash_update: assertion failed: (ul_sofar <=
ul_count)
Aborted*

If I try to launch "tshark" without any arguments, I see either "*Segmentation
fault*" (with no other output), or similar output to that shown in the GTK
app's dialogues, plus the SEGFAULT error.

Running "tshark" under GDB eventually reveals:
*Program received signal SIGSEGV, Segmentation fault.
main (argc=1, argv=0x7fffe128) at tshark.c:1899
1899((prefs_p->capture_device) && (*prefs_p->capture_device !=
'\0')) ? get_if_name(prefs_p->capture_device) : NULL);*

The output of "tshark -v" from my latest build attempt says:
*TShark 1.9.0-SVN-47138 (SVN Rev Unknown from unknown)

Copyright 1998-2013 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 (64-bit) with GLib 2.30.0, with libpcap, with libz 1.2.3.4, with
POSIX
capabilities (Linux), without libnl, without SMI, without c-ares, without
ADNS,
with Lua 5.1, without Python, with GnuTLS 2.8.6, with Gcrypt 1.4.6, with MIT
Kerberos, without GeoIP.

Running on Linux 2.6.38-16-generic, with locale en_GB.UTF-8, with libpcap
version 1.4.0-PRE-GIT_2013_01_18, with libz 1.2.3.4.*

Any ideas?

Thanks in advance,

Tyson.


-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Skype protocol dissector

2012-08-09 Thread Tyson Key
Hi Matthias,

I'll admit that project sounds pretty cool - and I don't want to discourage
you from working on it; but I suspect that implementing that sort of
functionality in Wireshark might open a giant can of worms, legally.
(Especially since MS now own Skype's developers). ;)

Anyway, for getting started with writing dissectors, I'd recommend looking
at the documentation in http://anonsvn.wireshark.org/viewvc/trunk/doc/
(especially
"README.developer"), and reading the source code of existing dissectors.
When working on new dissectors, I tend to take one of my existing ones, and
modify it accordingly, in order to meet the needs of the new protocol in
question.

All dissectors are written against a "lowest common denominator" variant of
C (C89? C99?), and the EPAN APIs, to ensure portability, and consistency.

I hope that helps,

Tyson.

2012/8/9 Matthias Bock 

> Hi everybody,
>
> there is a project at GitHub,
> uncovering the protocol structure of Skype.
> Currently only UDP is documented (there is also
> a TCP component somehow).
>
> https://github.com/matthiasbock/OpenSkype/wiki/Skype's-UDP-Format
>
> Documentation is not completed, but quite far
> and dissecting (and decrypting) pcap captures
> using Python on the console already works.
>
> The "next step" would be to implement a Wireshark
> dissector for "SkypeUDP".
>
> I have no idea, how to do this ...
> Anybody here who would like to help me? ;-)
>
> Cheers, Matthias
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] RFD: New language to write dissectors

2012-07-25 Thread Tyson Key
Hmm, I did briefly think that if we ever moved all dissectors into plug-in
form (which would be unlikely, given the drive to make as many built-in as
possible), we could package them according to protocol family/purpose, so
that users could select only the ones that were necessary - but many have
complex interdependencies; and there's always going to be a number of
people who'll complain if they can't find an obscure dissector in their
installation.

That said, one of the appeals of Wireshark to me is that it "only does
everything" (to steal Sony's slogan); and that the current
licencing/project maintenance arrangements encourage people to contribute
new dissectors/features (even if not everything gets accepted 100% of the
time), and participate in their maintenance - so that everyone receives a
better product in the long term.

(I'm not opposed to the implementation of new mechanisms that potentially
make it easier to enhance, and extend Wireshark, though).

Just my 0.02p,

Tyson.

2012/7/25 Guy Harris 

>
> On Jul 24, 2012, at 1:23 PM, Jakub Zawadzki wrote:
>
> > From my perspective: I really use ~ 20 dissectors, why I need all of
> them?
>
> ...and if they're loaded at startup time and either interpreted or
> translated after being loaded, it might be easier to choose a subset of
> protocols (NetMon lets you do that, although I don't remember whether you
> can specify an arbitrary subset or if they just let you choose from subsets
> they've defined).
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] NPL to Wireshark compiler/converter

2012-07-21 Thread Tyson Key
Hi Richard,

That sounds fairly impressive - even if it doesn't do much, right now.

I don't know if you've already seen them; or even if they're helpful, but
have you had a look at
http://nmparsers.codeplex.com/SourceControl/list/changesets for examples of
parser code? (I believe that most files are covered under the BSD Licence,
if the tab on that project microsite is to be believed - so it should be
safe to use them for what you're trying to do (but don't quote me on that)).

I look forward to seeing more, soon...

Tyson.

2012/7/21 Richard Sharpe 

> I have started working on an NPL to Wireshark compiler/converter ...
>
> At this stage all I have is an initial Flex scanner file and a simple
> Lemon grammar and some test files. The grammar is conflict free, but
> not necessarily complete (lacking in examples and there does not seem
> to be a spec from Microsoft :-(). I have been working from the
> example/s in the Microsoft document I posted a link to a few days ago
> called "Writing a Parser from Wire to Window."
>
> The next steps are to:
>
> 1. Get the grammar working more, and in particular, generate an AST,
> 2. Add more to the grammar
> 3. Generate dissectors in C.
>
> What I have is attached for those who are curious and for feedback.
>
> --
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] RFD: New language to write dissectors

2012-07-15 Thread Tyson Key
Hmm,

What about implementing a compiler that generates C dissector source code,
from NPLt m, or WSGD dissector code? Or would that be overkill for what
we're trying to do?

Just my 0.02p...

Tyson.

2012/7/15 Jakub Zawadzki 

> On Sat, Jul 14, 2012 at 03:31:06PM -0700, Guy Harris wrote:
> >
> > On Jul 14, 2012, at 8:26 AM, Jakub Zawadzki wrote:
> >
> > > It'd be great if we have some abstract and pure (no C/assembly inline)
> language to write dissectors.
> >
> > Or "to describe protocols and the way packets for those protocols are
> displayed" - the languages in question wouldn't be as procedural as
> C/Lua/etc, they'd be more descriptive.
> >
> > > We could invent yet another protocol desciption language,
> >
> > ...but, as you suggest, we probably shouldn't.
>
> http://imgs.xkcd.com/comics/standards.png ;-)
>
> > I'm not sure it has to be a choice, though - we could implement both,
> resources permitting, of course.  (And, of course, given that there are
> many already-existing languages that describe protocols - ASN.1, {OSF
> IDL/MIDL/PIDL} for DCE RPC, rpcgen for ONC RPC, CORBA IDL, xcb for X11 - we
> will probably never have the One True Protocol Description Language.)
>
> I'd rather support one, and later have some compiler from language A to B.
>
>
> > > I'm bigger fan of NPL (...) but there might exists some legal (patents
> for grammar/implementation?!) issues.
> >
> > That would be one concern - even having "our own" language, such as
> wsgd, runs the risk of infringing a patent, but, well, *writing software of
> just about any sort* runs the risk of infringing a patent;
> > however, we're dealing with a large corporation in the case of NPL, so
> there's probably a greater risk that some or all of it is covered by
> patents.
> > Were Microsoft to explicitly state that there are no patents on
> NPL-the-language or that they're granting a royalty-free license for all
> implementations (perhaps with a "mutual assured destruction" clause,
> > so that were we to patent some feature of Wireshark and sue Microsoft
> for violating that patent, our license for their patents would terminate),
> and the same applied to any patents they hold on their
> > implementation of NPL that would block independent useful
> implementations, that might help.
>
> I'm not sure if it was covered by recent Oracle vs Google lawsuits.
> Maybe Riverbed could help us with it? Gerald?
>
> > > With wsgd we could reuse some existing code of plugin.
> >
> > ...and we also have more freedom to extend the language, e.g. to support
> preferences for a protocol
>
> or support for columns/expert info.
>
> > Were there an "Open NPL Consortium" of some sort where multiple
> implementers of NPL could propose extensions, and perhaps a way an
> implementation could offer private extensions without worrying about
> colliding with other implementations or future standards, that might help.
>
> It'd also clear legal status of NPL language.
>
>
> > (It also raises the question of whether interpreted execution of that
> "machine code" or translation to C or machine language will be faster -
> interpreted execution *could* result in a smaller cache footprint if the
> interpreter is small enough and the code "high-level" enough to be fairly
> dense, although it does involve difficult-at-best-to-predict branches in
> the interpretive loop.)
>
> I was thinking to use LLVM. For built-in dissectors we could compile
> dissectors to object file/ assembly, for user dissectors we'll benefit from
> LLVM JIT.
> But anyway we need compiler to C. For prototype (does it work?) and later
> as fallback for people who don't have LLVM.
> ... Or can LLVM libraries be strong dependency?
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] 1.8 branch + release schedule

2012-06-08 Thread Tyson Key
For what it's worth, MS have decided to renege on their "Metro development
only" plans for the next version of Visual Studio Express, if
http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx
is
to be believed.

I haven't had chance to investigate the new tools, though.

Tyson.

2012/6/1 Graham Bloice 

>
>
> > -Original Message-
> > From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
> > boun...@wireshark.org] On Behalf Of Gerald Combs
> > Sent: 31 May 2012 19:59
> > To: Developer support list for Wireshark
> > Subject: [Wireshark-dev] 1.8 branch + release schedule
> >
> > Hi,
> >
> > I'd like to branch off 1.8 next Monday (June 4) so that we can start
> making
> > release candidates followed by the official 1.8.0 release:
> >
> > 1.8.0rc1: June 4
> > 1.8.0rc2: June 11 (if needed)
> > 1.8.0:June 18
> >
> > The schedule is a little aggressive. I don't mind postponing the
> official release
> > until after Sharkfest if needed.
> >
> > I'd also like to make Visual Studio 2010 the default for Windows builds
> before
> > the branch. According to some news sources it will be the last version
> of VS
> > to ship with a C/C++ compiler in the Express edition so we may as well
> > standardize on it now.
> >
>
> Visual Studio Express 2012 for Windows 8 can still compile C/C++, but the
> limited in some way to producing Metro apps.  I guess that it won't ship
> with the ordinary Windows (non-Metro) headers and libraries.  Apparently
> these (along with the compilers) have also been removed from the Windows 8
> SDK so that can't be used as an alternative method.   I'll download some
> stuff  this weekend and see what happens when trying to build Wireshark.
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Make "giop plugins" built in dissectors?

2012-06-05 Thread Tyson Key
Hi Jeff,

I've also noticed that with a modern x86-64-based machine (with 3GB of RAM,
and a triple-core AMD Phenom II CPU), and a recent-ish version of GCC
running under *buntu. It certainly seems like a good stress test for any
compiler/OS/machine combination.

With that in mind, just what is packet-parlay.c being used for, anyway?
(And why is it so large?)

Apologies in advance for the stupid questions,

Tyson.

2012/6/5 Jeff Morriss 

> Jeff Morriss wrote:
>
>> Anders Broman wrote:
>>
>>> Hi,
>>> It should be possible to make the giop plugins built in dissectors now,
>>> is that something we'd want to do?
>>>
>>
>> I'd be all for it mainly so/if we can put packet-parlay.c at the top of
>> the list of dissectors so that my "make -j X" can start the 15 minutes it
>> takes to compile that beast as early as possible!  (Okay, 15 minutes is
>> probably an exaggeration, but it does take a *very* long time to compile.)
>>
>
> Haha, thought this was funny: today I did a build on Solaris 10/SPARC with
> GCC 4.6.3 and, after about 45(!) minutes (yeah, I know, SPARCs aren't
> fast), got this when compiling packet-parlay.c:
>
>  epan/dissectors/packet-parlay.**c:96834:17: note: variable tracking size
>> limit
>>
> > exceeded with -fvar-tracking-assignments, retrying without
>
> I wonder if modern GCCs will have that problem or if it's just this
> version or (doubtful) the architecture.  It would be really nice if this
> file could be split up.
>
>
> __**__**
> ___
> 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-request@**wireshark.org
> ?subject=**unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Add new plugin in trunk

2012-06-02 Thread Tyson Key
Hi Alexis,

Out of curiosity - whilst we're thinking of absorbing externally-developed
dissectors, do you think that investigating
http://code.google.com/p/wireshark-nfc/ (which is currently being developed
by Google - and I don't know what their plans for upstreaming are), and
https://git.ring0.de/isi-wireshark-plugin/ (has multiple contributors,
including myself) would be a good idea?

Thanks,

Tyson.

2012/6/1 Alexis La Goutte 

> Hi,
>
> I hope to include 2 new dissectors before the 1.8 release.
>
>- WSE Remote Ethernet protocol (
>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7260 )
>- SPDY dissector (  http://code.google.com/p/spdyshark/ )
>
> This dissector has actually "plugin" dissector.
> It makes sense to include in trunk in plugin form or i will include in
> build-in dissector ?
>
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] SVN HEAD not building

2012-05-27 Thread Tyson Key
Hi Akos,

I haven't looked at that portion of the codebase (so I don't know how
they've integrated the new UI code), but from experience with Qt
development, that header file is supposed to be automatically generated, if
I remember correctly.

Tyson.

2012/5/27 Akos Vandra 

> Yep, that helped, thanks!
>
> However when I tried to take a sneak peek at how the qt inteface looks
> like, I found that the build fails because of a missing file?
> I know it is experimental only, but it should build, right?
>
> Making all in ui/qt
> make[2]: Entering directory
> `/home/akos/projects/c/wireshark/wireshark/ui/qt'
> g++ -DHAVE_CONFIG_H -I. -I../..  -I../.. -I../../wiretap-DINET6
> -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DQT_GUI_LIB
> -D_FORTIFY_SOURCE=2 -D_U_="__attribute__((unused))"
> -I/home/akos/projects/c/wireshark/bin/include -I/usr/local/include
> -I/home/akos/projects/c/wireshark/bin/include/pcap
>
> '-DPLUGIN_DIR="/home/akos/projects/c/wireshark/bin/lib/wireshark/plugins/1.7.2"'
>  -g -O2 -Wall -W -Wextra -Wendif-labels -Wpointer-arith -Warray-bounds
> -Wcast-align -Wformat-security -DQT_SHARED -I/usr/include/qt4
> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui   -pthread
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -MT
> main_window.o -MD -MP -MF .deps/main_window.Tpo -c -o main_window.o
> main_window.cpp
> main_window.cpp:25: fatal error: ui_main_window.h: No such file or
> directory
> compilation terminated.
> make[2]: *** [main_window.o] Error 1
> make[2]: Leaving directory
> `/home/akos/projects/c/wireshark/wireshark/ui/qt'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/akos/projects/c/wireshark/wireshark'
> make: *** [all] Error 2
>
> Regards,
>  Ákos Vandra
>
>
> On 27 May 2012 08:40, Guy Harris  wrote:
> >
> > On May 26, 2012, at 7:30 PM, Bill Meier wrote:
> >
> >> I did (had to do ?) a complete rm config.cache, ./autogen.sh and
> ./configure sequence before doing  make to get rid of the error.
> >
> > I had a similar problem, but I didn't have to do "rm config.cache" -
> re-running autogen.sh and configure was sufficient.
> >
> >> (I was too lazy to determine the actual reason for the error).
> >
> > I think the actual reason for the error is "automake does not generate
> Makefile.in files that have a sufficient number of dependencies to force a
> rebuild of everything that needs to be rebuilt if something included by a
> Makefile.am file is changed". :-)  Perhaps, due to limitations of (GNU)
> make, "does not" should be replaced by "cannot".
> >
> ___
> > 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] New developer - how to start?

2012-05-25 Thread Tyson Key
Hi Dipanjan,

There isn't really a formal registration process, but registering at
http://bugs.wireshark.org/ is a good place to start. As for "tasks" - there
isn't a formal list of mandatory activities (but there is a wishlist on the
wiki, which might be vaguely interesting); and things are fairly ad-hoc -
you just think "I'd like to implement feature X", do it, and post a diff on
the bug tracker.

If you think that you're going to do something that conflicts with what
others are doing, then it's a good idea to ask on this list, first.

I hope that helps - and welcome aboard!

Tyson.

2012/5/25 Dipanjan Das 

>
> Hi Developers,
>
> I want to get myself involved in the development of Wireshark. Can anybody
> please let me know about the following:
>
>1. Is there anywhere I need to get myself registered as a developer?
>2. How are the tasks splitted across?
>3. How is the synchronization among developers done?
>
> TIA.
>
> --
>
> Thanks & Regards,
> Dipanjan
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Store selected Wireshark prefs in pcapng capture file ?

2012-03-05 Thread Tyson Key
Hi Bill,

I don't know if the format's developers ever contemplated that use
case - although they designed it to be fairly extensible, and I'm sure
that someone could design a new type of block that stores serialised
application preferences (in compressed XML, JSON, or some other
format?), after requesting an type ID for it.

I haven't thought too much about how you'd actually go about deciding
upon the preferences to store - although adding a universal "Save
Current Preferences" option to the file saving dialogue, and having an
option in the corresponding file opening dialogue to temporarily
import/set those preferences might work.

I'm sure that others will come up with better ideas, though...

Tyson.

On 5 March 2012 18:26, Bill Meier  wrote:
> Would it make any sense to be able to store "application specific"
> information in a pcapng file ?
>
> E.g., selected Wireshark prefs so that Wireshark can act on same ?
>
> This would be useful when a capture file reqires specific dissector
> preferences to properly dissect the file.
>
> Would this fit (at all) within the design goals for pcapng ?
> Is there be a way to do this reasonably cleanly with the existing format ?
>
> How might one indicate the prefs which should to be stored ?
>
> 
>
> 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



-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Query

2012-03-01 Thread Tyson Key
Hi Krishnamurthy,

Whilst I'm not a core developer, I don't see why that would be a
problem. (In fact, that's how I submitted some of my own dissectors).

Tyson.

On 1 March 2012 03:01, Krishnamurthy Mayya  wrote:
> Hi all,
> Is it ok if we create a new bug in wireshark bugzilla to say that we are
> working on writing the decoding module for these protocols and attach the
> patches, packets after we are done with it??
> I just wanted to avoid the duplicate work getting done by many. I am
> currently working on writing the decoding modules based on few RFCs and will
> actually take some time to submit it back.
>
> Thanks in advance for the reply.
>
> Thanks and regards
> Krishnamurthy Mayya
>
> ___
> 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



-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Regression in SVN revision ~41162?

2012-02-23 Thread Tyson Key
Thanks Jeff,

I eventually managed to narrow it down to having two instances of
"packet-mpeg-pat.c" and "packet-mpeg-sect.c" in
/wireshark/epan/dissectors/Makefile.common, for reasons that somewhat
elude me, right now.

I suspect that wanting to try the latest MPEG-2 changes a while ago,
and forgetting to update that file after updating to the latest SVN
revision might have had something to do with it, though. (Even though
I ran the "autogen.sh" script, and the usual "./configure && make &&
sudo make install" commands, afterwards).

Oh well.

Tyson.

On 23 February 2012 15:08, Jeff Morriss  wrote:
> Tyson Key wrote:
>>
>> Hi list,
>>
>> It seems that as of revision 41162 (or maybe a few before?), I am no
>> longer able to completely compile and link the EPAN/dissectors portion
>> of the codebase under Ubuntu. I suspect that recent modifications to
>> the MPEG-related dissectors may have caused this, given by the errors
>> from the linker that I receive:
>
> [...]
>
>> In function `proto_register_mpeg_pat':
>> /home/tyson/wireshark/epan/dissectors/packet-mpeg-pat.c:134: multiple
>> definition of `proto_register_mpeg_pat'
>>
>> dissectors/.libs/libdissectors.a(libdissectors_la-packet-mpeg-pat.o):/home/tyson/wireshark/epan/dissectors/packet-mpeg-pat.c:134:
>> first defined here
>> dissectors/.libs/libdissectors.a(lt2-libdissectors_la-packet-mpeg-pat.o):
>> In function `proto_reg_handoff_mpeg_pat':
>> /home/tyson/wireshark/epan/dissectors/packet-mpeg-pat.c:199: multiple
>> definition of `proto_reg_handoff_mpeg_pat'
>>
>> dissectors/.libs/libdissectors.a(libdissectors_la-packet-mpeg-pat.o):/home/tyson/wireshark/epan/dissectors/packet-mpeg-pat.c:199:
>> first defined here
>
>
> Have you tried a "make clean"?
>
> Have you changed libtool versions recently?  I note that you have both a
> "libdissectors_la-packet-mpeg-pat.o" and a
> "lt2-libdissectors_la-packet-mpeg-pat.o", not sure what that's about.
> ___
> 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



-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Regression in SVN revision ~41162?

2012-02-23 Thread Tyson Key
Hi list,

It seems that as of revision 41162 (or maybe a few before?), I am no
longer able to completely compile and link the EPAN/dissectors portion
of the codebase under Ubuntu. I suspect that recent modifications to
the MPEG-related dissectors may have caused this, given by the errors
from the linker that I receive:

libtool: link: rm -fr  .libs/libwireshark.ver
libtool: link: echo "{ global:" > .libs/libwireshark.ver
libtool: link:  cat libwireshark.sym | sed -e "s/\(.*\)/\1;/" >>
.libs/libwireshark.ver
libtool: link:  echo "local: *; };" >> .libs/libwireshark.ver
libtool: link:  gcc -shared  -fPIC -DPIC
.libs/libwireshark_la-addr_and_mask.o
.libs/libwireshark_la-addr_resolv.o
.libs/libwireshark_la-address_to_str.o .libs/libwireshark_la-adler32.o
.libs/libwireshark_la-afn.o .libs/libwireshark_la-asn1.o
.libs/libwireshark_la-atalk-utils.o .libs/libwireshark_la-base64.o
.libs/libwireshark_la-bitswap.o
.libs/libwireshark_la-camel-persistentdata.o
.libs/libwireshark_la-charsets.o .libs/libwireshark_la-circuit.o
.libs/libwireshark_la-codecs.o .libs/libwireshark_la-column.o
.libs/libwireshark_la-column-utils.o
.libs/libwireshark_la-conversation.o .libs/libwireshark_la-crc16-tvb.o
.libs/libwireshark_la-crc32-tvb.o .libs/libwireshark_la-crc8-tvb.o
.libs/libwireshark_la-dissector_filters.o .libs/libwireshark_la-emem.o
.libs/libwireshark_la-epan.o .libs/libwireshark_la-ex-opt.o
.libs/libwireshark_la-except.o .libs/libwireshark_la-expert.o
.libs/libwireshark_la-filesystem.o
.libs/libwireshark_la-filter_expressions.o
.libs/libwireshark_la-follow.o .libs/libwireshark_la-frame_data.o
.libs/libwireshark_la-frequency-utils.o .libs/libwireshark_la-funnel.o
.libs/libwireshark_la-gcp.o .libs/libwireshark_la-geoip_db.o
.libs/libwireshark_la-golay.o .libs/libwireshark_la-guid-utils.o
.libs/libwireshark_la-h225-persistentdata.o
.libs/libwireshark_la-in_cksum.o .libs/libwireshark_la-ipproto.o
.libs/libwireshark_la-ipv4.o .libs/libwireshark_la-next_tvb.o
.libs/libwireshark_la-nstime.o .libs/libwireshark_la-oids.o
.libs/libwireshark_la-osi-utils.o .libs/libwireshark_la-packet.o
.libs/libwireshark_la-plugins.o .libs/libwireshark_la-prefs.o
.libs/libwireshark_la-proto.o .libs/libwireshark_la-range.o
.libs/libwireshark_la-reassemble.o .libs/libwireshark_la-reedsolomon.o
.libs/libwireshark_la-report_err.o
.libs/libwireshark_la-req_resp_hdrs.o
.libs/libwireshark_la-sigcomp_state_hdlr.o
.libs/libwireshark_la-sigcomp-udvm.o .libs/libwireshark_la-sminmpec.o
.libs/libwireshark_la-sna-utils.o
.libs/libwireshark_la-stat_cmd_args.o
.libs/libwireshark_la-stats_tree.o .libs/libwireshark_la-strutil.o
.libs/libwireshark_la-stream.o .libs/libwireshark_la-t35.o
.libs/libwireshark_la-tap.o
.libs/libwireshark_la-tcap-persistentdata.o
.libs/libwireshark_la-timestamp.o .libs/libwireshark_la-tfs.o
.libs/libwireshark_la-to_str.o .libs/libwireshark_la-tvbparse.o
.libs/libwireshark_la-tvbuff.o .libs/libwireshark_la-uat.o
.libs/libwireshark_la-value_string.o .libs/libwireshark_la-xdlc.o
-Wl,--whole-archive ./.libs/libwireshark_generated.a
./.libs/libwireshark_asmopt.a crypt/.libs/libairpdcap.a
ftypes/.libs/libftypes.a dfilter/.libs/libdfilter.a
dissectors/.libs/libdissectors.a dissectors/.libs/libdirtydissectors.a
wslua/.libs/libwslua.a -Wl,--no-whole-archive  -Wl,-rpath
-Wl,/home/tyson/wireshark/wiretap/.libs -Wl,-rpath
-Wl,/home/tyson/wireshark/wsutil/.libs -L/usr/local/lib -llua5.1
-ladns -L/lib/i386-linux-gnu -lgcrypt
/usr/lib/i386-linux-gnu/libgnutls.so -L/usr/lib -lsmi
../wiretap/.libs/libwiretap.so
/usr/lib/i386-linux-gnu/libgthread-2.0.so
/usr/lib/i386-linux-gnu/libgmodule-2.0.so -lrt
/usr/lib/i386-linux-gnu/libglib-2.0.so ../wsutil/.libs/libwsutil.so
-lm -lz  -O2 -pthread -Wl,--as-needed -pthread -Wl,--export-dynamic
-pthread -Wl,-soname -Wl,libwireshark.so.0 -Wl,-version-script
-Wl,.libs/libwireshark.ver -o .libs/libwireshark.so.0.0.1
dissectors/.libs/libdissectors.a(lt1-libdissectors_la-packet-mpeg-sect.o):
In function `dissect_mpeg_sect':
/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:140: multiple
definition of `dissect_mpeg_sect'
dissectors/.libs/libdissectors.a(libdissectors_la-packet-mpeg-sect.o):/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:140:
first defined here
dissectors/.libs/libdissectors.a(lt1-libdissectors_la-packet-mpeg-sect.o):
In function `proto_register_mpeg_sect':
/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:212: multiple
definition of `proto_register_mpeg_sect'
dissectors/.libs/libdissectors.a(libdissectors_la-packet-mpeg-sect.o):/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:212:
first defined here
dissectors/.libs/libdissectors.a(lt1-libdissectors_la-packet-mpeg-sect.o):
In function `proto_reg_handoff_mpeg_sect':
/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:267: multiple
definition of `proto_reg_handoff_mpeg_sect'
dissectors/.libs/libdissectors.a(libdissectors_la-packet-mpeg-sect.o):/home/tyson/wireshark/epan/dissectors/packet-mpeg-sect.c:267:
first defined here
diss

[Wireshark-dev] User-Customisable Payload Dissection

2012-02-06 Thread Tyson Key
Hi,

Now that the GSM SIM/ISO 7816 protocol dissector has been integrated,
it might be useful to provide a "Payload Protocol" option for the CCID
dissector - so that users can switch appropriately between treating
payloads as either plain data, or as GSM SIM/ISO 7816 packets.

With that in mind, please can someone provide some pointers as to how
I'd go about implementing such a feature? I've seen some of the
preferences-related notes in the ReadMe files; and the thread on the
"Decode As..." dialogue - but I'm unsure if there's a generic approach
to dealing with that sort of thing in dissectors.

Thanks,

Tyson.

-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Iteration in dissectors?

2012-01-23 Thread Tyson Key
I eventually managed to get thing working by using a combination of a
modified version of Chris's second approach, and use of
tvb_new_subset_remaining() to capture data after the Number of Blocks
byte.

Since I've also managed to get Polling Request/Response, and Read
Without Encryption Response packets mostly dissected (apart from a few
context-dependent data tables related to Status Flags), I might submit
the dissector for review.

Of course, there are other commands - although some are undocumented
and aren't present in the FeliCa Lite protocol "profile"/subset (e.g.
the authentication-related ones - which only get a brief mention in
the FeliCa Standard datasheets, and in the relevant Japanese
Industrial Standard (JIS X 6319-4)); and Write Without Encryption
Request/Response doesn't appear in my traces, so I can't easily test
an implementation of it.

Thanks once again,

Tyson.

On 22 January 2012 21:41, Tyson Key  wrote:
> Thanks Chris,
>
> If I remember correctly, apart from an annoying, misleading "malformed
> packet" error, I eventually managed to dump all of the block IDs (1-4)
> using either :
>
> /* Start counting from 13 */
>             for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos+=2) 
> {
>               proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
> rwe_pos+1, 1, ENC_BIG_ENDIAN);
>             }
>
> or
>
> /* Start counting from 13 */
>             for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) 
> {
>               proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
> rwe_pos+1, 1, ENC_BIG_ENDIAN);
>             }
>
> I've found that removing the extraneous "+1" from that code will cause
> all of the IDs to be "128" (which is incorrect) - so it's probably
> just a case of trying to break the loop at the right time.
>
> For what it's worth, this also seems to work (with caveats):
>
>            /* Start counting from 13 */
>             for (rwe_pos = 13; tvb_get_guint8(tvb, 12) < rwe_pos; rwe_pos+=2) 
> {
>               printf (rwe_pos);
>
>               proto_tree_add_item(felica_tree, hf_felica_block_nbr,
> tvb, rwe_pos+1, 1, ENC_BIG_ENDIAN);
>             }
>
> In that case, I see the following error messages on stdout:
>
> 21:01:04          Warn Dissector bug, protocol FeliCa, in packet 5:
> More than 100 items in the tree -- possible infinite loop
> 21:01:04          Warn Dissector bug, protocol FeliCa, in packet 8:
> More than 100 items in the tree -- possible infinite loop
>
> After trying your initial examples, and doing some of my own
> experimentation, I've came to the conclusion that I can either
> "successfully fail" and obtain all of the block IDs along with an
> error message; or "fail successfully" and obtain nothing - since the
> conditions being tested are contradictory (e.g. the number of blocks
> is less than the position - therefore, we don't move the cursor).
>
> Tyson.
>
> On 22 January 2012 18:16, Chris Maynard  wrote:
>> Tyson Key  writes:
>>
>>> My (partially working) iteration code looks like:
>>>
>>>            /* Start counting from 13 */
>>>            for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos++) 
>>> {
>>>              proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
>>> rwe_pos + 1, 1, ENC_BIG_ENDIAN);
>>>            }
>>
>> How about something like this:
>>
>>    /* Start counting from 14 */
>>    for (rwe_pos = 14; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
>>        proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 1,
>> ENC_BIG_ENDIAN);
>>    }
>>
>> ... or if you want the 0x80 byte highlighted as part of the block number
>> (instead of skipping it), then do something like:
>>
>>    /* Start counting from 13 */
>>    for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
>>        proto_tree_add_uint(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 2,
>> tvb_get_guint8(tvb, rwe_pos + 1));
>>    }
>>
>> - Chris
>>
>>
>> ___
>> 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
>
>
>
> --
>                                           Fight Internet Censorship!
> http://www.eff.org
> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
> 00447934365844



-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Iteration in dissectors?

2012-01-22 Thread Tyson Key
Thanks Chris,

If I remember correctly, apart from an annoying, misleading "malformed
packet" error, I eventually managed to dump all of the block IDs (1-4)
using either :

/* Start counting from 13 */
 for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos+=2) {
   proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
rwe_pos+1, 1, ENC_BIG_ENDIAN);
 }

or

/* Start counting from 13 */
 for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
   proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
rwe_pos+1, 1, ENC_BIG_ENDIAN);
 }

I've found that removing the extraneous "+1" from that code will cause
all of the IDs to be "128" (which is incorrect) - so it's probably
just a case of trying to break the loop at the right time.

For what it's worth, this also seems to work (with caveats):

/* Start counting from 13 */
 for (rwe_pos = 13; tvb_get_guint8(tvb, 12) < rwe_pos; rwe_pos+=2) {
   printf (rwe_pos);

   proto_tree_add_item(felica_tree, hf_felica_block_nbr,
tvb, rwe_pos+1, 1, ENC_BIG_ENDIAN);
 }

In that case, I see the following error messages on stdout:

21:01:04          Warn Dissector bug, protocol FeliCa, in packet 5:
More than 100 items in the tree -- possible infinite loop
21:01:04          Warn Dissector bug, protocol FeliCa, in packet 8:
More than 100 items in the tree -- possible infinite loop

After trying your initial examples, and doing some of my own
experimentation, I've came to the conclusion that I can either
"successfully fail" and obtain all of the block IDs along with an
error message; or "fail successfully" and obtain nothing - since the
conditions being tested are contradictory (e.g. the number of blocks
is less than the position - therefore, we don't move the cursor).

Tyson.

On 22 January 2012 18:16, Chris Maynard  wrote:
> Tyson Key  writes:
>
>> My (partially working) iteration code looks like:
>>
>>            /* Start counting from 13 */
>>            for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos++) {
>>              proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
>> rwe_pos + 1, 1, ENC_BIG_ENDIAN);
>>            }
>
> How about something like this:
>
>    /* Start counting from 14 */
>    for (rwe_pos = 14; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
>        proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 1,
> ENC_BIG_ENDIAN);
>    }
>
> ... or if you want the 0x80 byte highlighted as part of the block number
> (instead of skipping it), then do something like:
>
>    /* Start counting from 13 */
>    for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 12); rwe_pos+=2) {
>        proto_tree_add_uint(felica_tree, hf_felica_block_nbr, tvb, rwe_pos, 2,
> tvb_get_guint8(tvb, rwe_pos + 1));
>    }
>
> - Chris
>
>
> ___
> 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



-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Iteration in dissectors?

2012-01-22 Thread Tyson Key
Hi,

I'm currently working on a dissector for Sony's FeliCa application
layer protocol; and things seem to be progressing nicely. However, I'm
facing some issues surrounding iterating through list data structures
in a non-standard manner.

The data structure in question is a list of memory block IDs separated
with 0x80, like:
06 01 27 00 5d 1a 05 8a cd 01 0b 00 [04] {80 01 80 02 80 03 80 04} -
where [04] represents a decimal count of 4 blocks, and the values in
accolades are the decimal block IDs themselves.

My (partially working) iteration code looks like:

 /* Start counting from 13 */
 for (rwe_pos = 13; rwe_pos < tvb_get_guint8(tvb, 13); rwe_pos++) {
   proto_tree_add_item(felica_tree, hf_felica_block_nbr, tvb,
rwe_pos + 1, 1, ENC_BIG_ENDIAN);
 }

The "rwe_pos" variable is defined near the start of the
dissect_felica() method, and initialised to 0 - although that value
doesn't matter in practice. (I assume that it doesn't quite fit with
the usual Wireshark coding conventions - but it was the most obvious
way of making things work within a switch() case).

The result of using that code, in the context of my dissector (at
https://gist.github.com/1657044) is:

DLT: 160
Sony FeliCa
Command: Read Without Encryption (0x06)
IDm (Manufacture ID)/NFCID2: 0x0127005d1a058acd
Number of Services: 1
Service Code: 0x0b00
Number of Blocks: 4
Block Number: 1
Block Number: 128
Block Number: 2
Block Number: 128
Block Number: 3
Block Number: 128
Block Number: 4
[Malformed Packet: FeliCa]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]

Obviously, I need to skip every second byte (instances of 0x80 for
padding) - except for cases where 0x80 0x80 is present (since we have
a block 128), to achieve something that looks like:

DLT: 160
Sony FeliCa
Command: Read Without Encryption (0x06)
IDm (Manufacture ID)/NFCID2: 0x0127005d1a058acd
Number of Services: 1
Service Code: 0x0b00
Number of Blocks: 4
Block Number: 1
Block Number: 2
Block Number: 3
Block Number: 4

(through to at least ~136 (if necessary) from looking at the FeliCa
Lite User Manual at
http://www.sony.net/Products/felica/business/tech-support/data/fl_usmnl_1.2.pdf)

Any thoughts?

Thanks in advance,

Tyson.

-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Affix bluetooth stack

2011-10-31 Thread Tyson Key
PS - I've just had a play with the "virtual HCI" implementation in the
Linux kernel version shipped with *buntu 11.04, and it appears that the
maintainers of their LibPCap builds have thoughtfully decided to disable
support for capturing on Bluetooth interfaces, for some unknown reason.

In this case, your best bet would be to install the "libbluetooth-dev"
package, and build a non-crippled version of LibPCap (and Wireshark?) from
source, with the appropriate "./configure" argument specified.

Sorry for disappointing you,

Tyson.

On 31 October 2011 18:21, Tyson Key  wrote:

> Yes.
>
> Please see the newly-updated wiki page regarding this (at
> http://wiki.wireshark.org/CaptureSetup/Bluetooth). It's been a long time
> since I've worked with Bluetooth, but I clearly remember it working under
> Fedora without any additional configuration, or effort on my part.
>
> A "hcidump" utility from the developers of the Linux Bluetooth stack/BlueZ
> also exists, should you prefer to use it to generate (Wireshark-compatible)
> logs, instead - although it doesn't quite meet the criteria of "live
> capturing and display" (since you have to manually reload its generated log
> in Wireshark).
>
> You could also try running "tshark -D | grep bluetooth*" (or "tshark -D |
> grep hci*") as root, or using "sudo" to see if your Bluetooth interface
> appears.
>
> I hope that helps,
>
> Tyson.
>
>
> On 31 October 2011 18:13, vijay  wrote:
>
>> Hi Tyson,
>>
>>   I need to do a live capture on Bluetooth traffic does wireshark support
>> capture with BLueZ stack in linux ?
>>
>> Vijay
>>
>>
>> On Mon, Oct 31, 2011 at 3:10 AM, Tyson Key  wrote:
>>
>>> Hi Vijay,
>>>
>>> There's no need to install Affix under KUbuntu (although installing
>>> other stuff from the repositories related to Bluetooth wouldn't hurt). Just
>>> enable Bluetooth connectivity as normal, and connect your adapter if
>>> necessary.
>>>
>>> Tyson.
>>>
>>> On 31 October 2011 08:03, vijay  wrote:
>>>
>>>> Hi,
>>>>
>>>> I not sure if this is the correct forum to post this but, Could some
>>>> one tell me if it is possible to install affix bluetooth stack in kubuntu?
>>>> Currently BLueZ bluetooth stack is installed and wireshark requires
>>>> Affix stack for live capture of bluetooth traffic.
>>>>
>>>> The affix website says that it can be installed in a kernel with
>>>> version 2.6.x or higher, and the version of the kernel I have installed is
>>>> 3.0.X. Now can
>>>> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> ___
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>>   Fight Internet Censorship!
>>> http://www.eff.org
>>> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
>>> 00447934365844
>>>
>>>
>>> ___
>>> 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
>>
>
>
>
> --
>   Fight Internet Censorship!
> http://www.eff.org
> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
> 00447934365844
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Affix bluetooth stack

2011-10-31 Thread Tyson Key
Yes.

Please see the newly-updated wiki page regarding this (at
http://wiki.wireshark.org/CaptureSetup/Bluetooth). It's been a long time
since I've worked with Bluetooth, but I clearly remember it working under
Fedora without any additional configuration, or effort on my part.

A "hcidump" utility from the developers of the Linux Bluetooth stack/BlueZ
also exists, should you prefer to use it to generate (Wireshark-compatible)
logs, instead - although it doesn't quite meet the criteria of "live
capturing and display" (since you have to manually reload its generated log
in Wireshark).

You could also try running "tshark -D | grep bluetooth*" (or "tshark -D |
grep hci*") as root, or using "sudo" to see if your Bluetooth interface
appears.

I hope that helps,

Tyson.

On 31 October 2011 18:13, vijay  wrote:

> Hi Tyson,
>
>   I need to do a live capture on Bluetooth traffic does wireshark support
> capture with BLueZ stack in linux ?
>
> Vijay
>
>
> On Mon, Oct 31, 2011 at 3:10 AM, Tyson Key  wrote:
>
>> Hi Vijay,
>>
>> There's no need to install Affix under KUbuntu (although installing other
>> stuff from the repositories related to Bluetooth wouldn't hurt). Just
>> enable Bluetooth connectivity as normal, and connect your adapter if
>> necessary.
>>
>> Tyson.
>>
>> On 31 October 2011 08:03, vijay  wrote:
>>
>>> Hi,
>>>
>>> I not sure if this is the correct forum to post this but, Could some one
>>> tell me if it is possible to install affix bluetooth stack in kubuntu?
>>> Currently BLueZ bluetooth stack is installed and wireshark requires
>>> Affix stack for live capture of bluetooth traffic.
>>>
>>> The affix website says that it can be installed in a kernel with version
>>> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
>>> Now can
>>> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>>>
>>> Thanks
>>>
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>>   Fight Internet Censorship!
>> http://www.eff.org
>> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
>> 00447934365844
>>
>>
>> ___
>> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Affix bluetooth stack

2011-10-31 Thread Tyson Key
Hi Vijay,

There's no need to install Affix under KUbuntu (although installing other
stuff from the repositories related to Bluetooth wouldn't hurt). Just
enable Bluetooth connectivity as normal, and connect your adapter if
necessary.

Tyson.

On 31 October 2011 08:03, vijay  wrote:

> Hi,
>
> I not sure if this is the correct forum to post this but, Could some one
> tell me if it is possible to install affix bluetooth stack in kubuntu?
> Currently BLueZ bluetooth stack is installed and wireshark requires Affix
> stack for live capture of bluetooth traffic.
>
> The affix website says that it can be installed in a kernel with version
> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
> Now can
> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>
> Thanks
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Feature Request - Comments attached to a packet

2011-08-11 Thread Tyson Key
Right. Feel free to disregard my previous e-mail, then. :)

Sorry for the inconvenience/false hope,

Tyson.

On 11 August 2011 19:24, Guy Harris  wrote:

>
> On Aug 11, 2011, at 11:16 AM, Tyson Key wrote:
>
> > Whilst no-one's looking into implementing support for attaching comments
> to packets (as far as I'm aware); someone recently wrote a patch to enable
> reading comments from pcap-ng/NTAR files, and attached it to bug #6229.
>
> Actually, that bug sounds more like "if a packet has a comment attached to
> it, Wireshark won't even read the packet data correctly"; the fix doesn't
> cause Wireshark to process the comment, it just causes it not to screw up if
> a packet *has* a comment.  I.e., we need to fix this before we even consider
> allowing comments to be added to packets, and should backport the fix to the
> 1.6 and 1.4 branches (that might still leave older versions of Wireshark
> incapable of reading pcap-ng files with comments attached to them).
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Feature Request - Comments attached to a packet

2011-08-11 Thread Tyson Key
Hi Alex,

Whilst no-one's looking into implementing support for attaching comments to
packets (as far as I'm aware); someone recently wrote a patch to enable
reading comments from pcap-ng/NTAR files, and attached it to bug #6229.

Tyson.

On 11 August 2011 19:04, Alex Lindberg  wrote:

> Has anyone looked into creating the ability to attach comments to a capture
> file or to a specific packet?
>
> It would make sharing decode efforts easier.
>
> Any input would be welcome.
>
> Alex Lindberg
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Duplicating TCP dissector

2011-06-30 Thread Tyson Key
Hi Randy,

Whilst it's probably not the best way, you might want to investigate the
technique that I used when developing a dissector for Apple's USBMUX
protocol (which is used to transport TCP data over USB, without IP framing
of any kind).

See bug #6045 on bugs.wireshark.org for the code, and feel free to comment.

I hope that helps,

Tyson.

On 29 June 2011 23:52, Randy Buck  wrote:

> Hi,
>
> I am building many new versions of TCP in user space.  All packet headers
> are the same (IP, then TCP).  The packets will be sent/received over raw
> sockets.  So I can filter out my TCP versions with actual kernel TCP I am
> using other protocol numbers besides 6.  I wish to view these traces in
> wireshark to ensure that the implementations are correct.  I am logging all
> packets to a pcap file and am able to view them fine in wireshark.  The
> issue at hand is that wireshark will only recognize TCP packets if the
> protocol number in the IP field is 6.  I wish to view these packets as a TCP
> trace in wireshark.  As far as I see it, I have a couple of options:
>
> 1. Change the source such that it will recognize the protocol numbers that
> I wish to view as TCP.  I have already changed the IP_PROTO_TCP macro in
> epan/ipproto.h to one of the protocol numbers that I am using, recompiled
> and successfully viewed the trace.  I can see how I could modify all places
> this macro is being used and check for all versions that I have.  This
> approach is neither very  clean nor easily extensible for new protocols and
> could potentially break something if multiple flows evaluated to the same
> protocol. I have also thought of changing the macro to a global variable
> which is set via a command line option.  This would limit wireshark to only
> recognizing one type of flow at a time which is okay, but not perfect.
>
> 2. Use a dissector to duplicate the TCP dissector that exists.  The problem
> here is that I am not sure if writing a dissector for a TCP implementation
> that I am using will still allow me to use the graphing, following, etc. of
> TCP traces.  (This is some of the main functionality that I would like.)
>
> I am open for other suggestions, but my question is, what is the best way
> to view TCP packets/traces in wireshark that do not use protocol 6 in the IP
> header?
>
> --
> Randy Buck
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Handing off payloads to the TCP dissector?

2011-06-18 Thread Tyson Key
Hi folks,

I'm currently in the process of writing a dissector for Apple's USBMUX
protocol (which encapsulates TCP frames with a non-IP-based 8 byte header),
as used by their seemingly ubiquitous iProduct family.

So far, I've managed to dissect the "TCP port" and packet length portions of
the header - although I'm struggling to actually deal with the TCP payload
(which is obviously the interesting bit). I don't see any reason as to why
it shouldn't be possible though, given that I can extract the payload from a
USB packet and use it to create a trace file with text2pcap plus a custom
user-defined DLT value, which can be parsed in Wireshark by adding a new
DLT_USER rule that skips the 8 byte preamble...

Having looked at the IPv4 and TCP dissectors for inspiration, I decided to
add "*dissector_add_uint("usbmux.data", IP_PROTO_TCP, tcp_handle);*" to the
"*proto_reg_handoff_tcp(void)*" method in packet-tcp.c - which results in a
successful build; although Wireshark bails out during launch with
"*ERROR:packet.c:719:dissector_add_uint:
assertion failed: (sub_dissectors)*"). I've also attempted to remove "*
IP_PROTO_TCP*" from the aforementioned addition - although it predictably
causes a build error.

I've also briefly skimmed the header files for the IPv4 and TCP dissectors,
and planned on trying tcp_dissect_pdus() - although I (probably
misleadingly) get the impression that it relates to an internal mechanism
for parsing chunks of packets by higher-level (than IP or TCP itself)
dissectors, instead.

Any thoughts from others who are more experienced with that portion of the
codebase?

In the meantime, I've published my rough initial attempt at
https://bitbucket.org/vmlemon/usb_isi_dissector_for_wireshark/src/7c4567e148e1/usbmux/packet-usb-apple-usbmux.c
.

Thanks in advance,

Tyson.

-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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 with capturing on multiple interfaces

2011-05-20 Thread Tyson Key
Hmm, wouldn't using "any" was a means of nullifying other interfaces break
concurrent capturing on both the "any interface" and Bluetooth or USB
interfaces?

Still, I agree with Chris's suggestions, with regards to weak emulation of
an "any interface" under Windows; and "speculative capturing" (i.e. waiting
for a device to appear before capturing relevant traffic).

I'm liking the feature so far otherwise, though. (It means that I no longer
have to launch Wireshark or TShark *8* times, and dismiss a tonne of warning
dialogues just to do USB capturing).

Thanks, and keep up the good work!

Tyson.

On 20 May 2011 15:25, Chris Maynard  wrote:

> Michael Tüxen  writes:
>
> > You actually need:
> > -n to use pcapng
> > and
> > -t to use threads.
> >
> > It is simple to add -n and -t if you are specifying more than one
> interface
> > (actually this is what tshark and wireshark do). I wanted to be explicit
> > since I consider it currently an experimental feature. But, if the groups
> > prefers, we can add -n and -t if there is more than one interface
> specified.
>
> To me, if it doesn't work without -n and -t, then it makes it that much
> more
> user-friendly to automatically use pcapng and threads whenever multiple
> interfaces are specified.
>
> I understand this is still a work in progress, but something else I was
> thinking
> about was the "-i any" interface.  What will happen if someone specifies
> something like, "-i eth0 -i any -i lo" or variations thereof?  I assume it
> would
> be treated as "-i any" only?
>
> And speaking of "-i any", obviously on Windows, that isn't supported ...
> but a
> neat thing would be if it could be by internally scanning all interfaces
> and
> treating it as if "-i 1 -i 2 ... -i n" were specified.
>
> And while I'm at it ... another feature that I think would be nice to have
> would
> be to be able to specify capturing on an interface that doesn't yet exist,
> such
> as ppp0.  For my USB/PPP capturing, currently to get a capture of all
> traffic
> over that interface, I either have to use usbmon or ppp's record option to
> generate a pppdump file.  (OK, this last one isn't really specific to
> capturing
> on multiple interfaces, but it's related to capturing so ...)
>
> > Thanks for the feedback.
> You're welcome ... thanks for the feature!
> - Chris
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Extending the USB dissector with subclass/protocol ID annotations?

2011-05-12 Thread Tyson Key
Hi folks,

Over the past few hours, I've been reading version 1.2 of the USB Forum's
Communications Device Class and Ethernet Control Model Subclass
specifications; and now I'm left wondering what the best/most lightweight
way to annotate the *bInterfaceSubClass* and *bInterfaceProtocol* fields of
"*Get Descriptor Response Configuration*" packets would be.

That said, I'm not particularly interested in implementing every aspect of
those specs, right now.

Obviously, a set of new field pointers and value lookup tables would be
necessary - although having looked at the source code for the HID and Hub
dissectors, it seems that a lot of additional infrastructure is necessary*,
just to connect those, in order to provide such annotations...

Does anyone with greater familiarity of the USB dissector have any ideas?

Thanks,

Tyson.

* (Much of what I consider to be extraneous for this case is naturally the
"value added" bits that cover everything else in the appropriate specs)

-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Any interest in a USB-encapsulated AT/Hayes Commands dissector?

2011-04-28 Thread Tyson Key
Right, so I've just added the latest revisions of the source files to a new
bug report (5868).

Please feel free to play with the code, and provide
comments/criticism/suggestions for improvement.

Tyson.

On 28 April 2011 15:42, Chris Maynard  wrote:

> Stephen Fisher  writes:
>
> > > If there's any interest, I'd be willing to try and clean it up for
> > > potential submission into mainline Wireshark.
> >
> > Sure, why not contribute it.  I'm sure someone will find it useful at
> > some point.
>
> Oops, meant to respond sooner, but yes, I for one would be interested.
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Any interest in a USB-encapsulated AT/Hayes Commands dissector?

2011-04-26 Thread Tyson Key
Hi folks,

I've just stumbled upon an old, experimental plug-in dissector that I wrote
to dissect "raw" AT/Hayes commands in USB traces, during the process of
working on another, otherwise unrelated dissector. (See
https://bitbucket.org/vmlemon/usb_isi_dissector_for_wireshark/src/eec3bf16fedf/at-hayes/
for
the source).

It's very rough; and I don't know what the best way to deal with displaying
and manipulating strings of an unknown length is - although it nicely filled
a need that I had at the time (identifying AT commands traffic amongst a
proprietary protocol and other "line noise", in order to filter them out).

If there's any interest, I'd be willing to try and clean it up for potential
submission into mainline Wireshark.

Tyson.

-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] IMSI Dissection API?

2011-01-06 Thread Tyson Key
Probably bad form to reply to my own post, but I've found that adding " -g
-D_U_="__attribute__((unused))"" to the end of my CFLAGS line in my
Makefile, without the surrounding quotes makes things build successfully
when including epan/dissectors/packet-gsm_map.h.

I hope that helps others.
___
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] IMSI Dissection API?

2011-01-06 Thread Tyson Key
Hi Anders,

Thanks for the suggestion. Sadly, it seems that there's still no joy, after
including the epan/asn1.h header. (I receive the same compilation error as
previously).

I've also briefly tried to adapt the implementation from packet-gtpv2.c, to
no avail.

I'll keep trying to see if I can come up with something - although I'd
rather not reinvent the wheel, if possible.

Tyson.
___
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] IMSI Dissection API?

2011-01-06 Thread Tyson Key
Hi,

I'm currently working on enhancing an *external dissector for Nokia's
Intelligent Service Interface protocol.

So far, pretty much everything seems to work nicely, although I'm struggling
to find the best way to dissect the IMSI strings in certain packets produced
by the SIM resource, such as this one (starts after the Service Type byte):

No. TimeSourceDestination   Protocol
Resource   Info
   436 36.824462   Modem Unknown   ISI  SIM
   Read IMSI Response

Frame 436: 37 bytes on wire (296 bits), 37 bytes captured (296 bits)
Linux cooked capture
Intelligent Service Interface
   Receiver Device: Unknown (0x10)
   Sender Device: Modem (0x00)
   Resource: SIM (0x09)
   Length: 15
   Receiver Object: 0x42
   Sender Object: 0x34
   Packet ID: 8
   Payload
   Message ID: SIM_IMSI_RESP_READ_IMSI (0x1e)
   Service Type: READ_IMSI (0x2d)

  00 00 03 34 00 01 1b 1c df 82 91 45 00 00 00 f5   ...4...E
0010  10 00 09 00 0f 42 34 08 1e 2d 01 08 29 43 01 70   .B4..-..)C.p
0020  33 65 49 32 fc3eI2.

I've tried to import the epan/dissectors/packet-gsm_map.h header in order to
use the dissect_gsm_map_IMSI() method, although my code doesn't even compile
afterwards - it bails out with a stream of errors such as:

[CC] src/isi-sim.c
In file included from src/isi-sim.c:27:
packet-gsm_map-template.h:54: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-template.h:55: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
In file included from src/isi-sim.c:27:
packet-gsm_map-exp.h:4: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
In file included from src/isi-sim.c:27:
packet-gsm_map-exp.h:8: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-exp.h:14: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-exp.h:15: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-exp.h:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-exp.h:17: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’
packet-gsm_map-exp.h:18: error: expected ‘;’, ‘,’ or ‘)’ before ‘_U_’

[Stream of messages continues to line 102 of that file]

I'm currently using Wireshark 1.5.0-SVN-35030 under Fedora 12, although I
plan to update this machine to a newer SVN revision soon.

* https://bitbucket.org/vmlemon/usb_isi_dissector_for_wireshark/

Thanks,
Tyson.

-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] wireless nic is not showing in wireshark

2010-10-02 Thread Tyson Key
Hi Nikhil,

Under Windows 7, the 802.11 interface is simply named "Microsoft" for some
unfathomable reason.

Unfortunately, because WinPCap (and by extension Wireshark) does not utilise
the new APIs/mechanisms for capturing raw 802.11 frames that are provided by
NDIS 6, you'll only see synthetic Ethernet frames if you capture in "Local
Mode"/Station Mode.

However, it is possible to use Microsoft's Network Monitor 3.4 to capture
802.11 frames (with a poorly-designed, proprietary pseudo-header, of course)
to a file that can be read by recent versions of Wireshark; in either Local
Mode or Monitor Mode - providing that you're willing to accept various
caveats:

   - 802.1X frames from Ad-Hoc networks are seemingly ignored/dropped -
   although other data and management frames are captured
   - Wireshark cannot currently handle "type 7"/Raw IPv6 frames in NetMon
   capture files - so some frames may appear to be missing, or your file might
   not load as you'd expect
   - The capture engine and pseudo-header have a habit of causing management
   frames to be corrupted or treated as Malformed packets within Wireshark (and
   I've encountered Beacon frames that have invalid TLV data blobs attached to
   them post-capture, which were never generated or transmitted)

I hope that helps,

Tyson.

On 2 October 2010 03:20, Nikil Roy  wrote:

> hi
>
> am nikhil, i have an issue with wireshark. am using windows 7 home premium,
> the other i have installed wireshark and when i started to capture its only
> showing the Fast Ethernet NIC Wat's the problem. is it the problem with my
> laptop or something else?  I hope i may get a reply soon.
>
> thank you
> Nikhil
>
> --
>
> (¨`·.·´¨) Always
> `·.¸(¨`·.·´¨) Keep
> (¨`·.·´¨)¸.·´ Smiling!
>  `·.¸.·´   With prayer and love
> Nikhil Roy, Muvattupuzha
> nihkilro...@gmail.com
>  mob:09025523721
> http://www.nikhilroy.110mb.com
>
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] get some information to develop a new protocol

2010-09-17 Thread Tyson Key
P.S. I neglected to mention in my previous e-mail that there's a *dbus-monitor
*utility which listens on either the system bus, or the session bus and
dumps a textual copy of traffic to the shell. You might want to
reverse-engineer the mechanisms used by that for capturing, and re-implement
them in LibPCap or a custom application.

On 17 September 2010 09:02, Thomas PABST  wrote:

> Hi,
>
> I'm going to make a new dissector for a new protocol. However, I would like
> to get some information before to start to be sure wireshark will be able to
> do it.
>
> The protocol referred is D-Bus. However it seems D-Dbus use only UNIX
> Socket to communicate.
> The purpose of this is to determine the better way to analyze all D-Bus
> message. Use wireshark or make my own application.
>
> Best Regards
>
>
> -
> Thomas PABST
> thomas.pa...@gmail.com
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] get some information to develop a new protocol

2010-09-17 Thread Tyson Key
Hi Thomas,

If I remember correctly*, there is a method of forcing the D-BUS server and
client to use TCP over the loopback interface for various purposes.

When I was interested in working with IPC systems, about a year ago, I
managed to build a reasonably large library of trace files that way
(although I can't locate any at the moment), and I would have been
interested in a D-BUS dissector for Wireshark.

* According to the manual page for the D-BUS Daemon , adding *
tcp:host=localhost,port=1234* to one of the D-BUS
configuration files, substituting *1234* in the example for your chosen port
number should enable you for handling traffic via TCP.

I hope that helps.

Tyson.

On 17 September 2010 09:02, Thomas PABST  wrote:

> Hi,
>
> I'm going to make a new dissector for a new protocol. However, I would like
> to get some information before to start to be sure wireshark will be able to
> do it.
>
> The protocol referred is D-Bus. However it seems D-Dbus use only UNIX
> Socket to communicate.
> The purpose of this is to determine the better way to analyze all D-Bus
> message. Use wireshark or make my own application.
>
> Best Regards
>
>
> -
> Thomas PABST
> thomas.pa...@gmail.com
>
> ___
> 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
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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] Unable to Compile Wireshark from SVN on Fedora 11

2009-08-24 Thread Tyson Key
Hi Bill,
On another note, I've discovered an unrelated issue when trying to
build an RPM from an SVN snapshot - during RPM creation, the rpmbuild
tool chokes on the hyphens in the version information, as written in
the .spec file. I'm unsure of the best way to fix that, though, short
of changing the version scheme slightly, or fixing rpmbuild itself.

Tyson.

On Mon, Aug 24, 2009 at 2:04 PM, Bill Meier wrote:
> Bill Meier wrote:
>>
>> OK: I've committed (SVN #29532) a slight reworking of the code in
>> packet-icmpv6.c to prevent the GCC "strict-aliasing" message.
>>
>>
>
> It turns out that there's at least two more files which cause the
> "strict aliasing" warning with gcc 4.4.1:
>
> dissectors/packet-ssl-utils.c
> epan/sctp-stat.c
>
> I'll see what I can do to revise the code in the next day or so.
>
>
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
   ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon | +447549728105
___
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] Unable to Compile Wireshark from SVN on Fedora 11

2009-08-23 Thread Tyson Key
Hi, Bill.
Thanks for the tips on the compilation control flags, I'll give them a
go, and see what happens. I usually stick with whatever default
optimisations a "./configure" run would utilise, so I'm unaware of
anything that could adversely affect compilation.

As for the source code itself, my C knowledge isn't all that great, so
I have no idea about where I should begin, as far as fixing the
defective code goes.

Tyson.

On Sun, Aug 23, 2009 at 9:24 PM, Bill Meier wrote:
> Tyson Key wrote:
>> Hi,
>> I'm unsure if this is the best venue to report the issue, but is
>> anyone else having problems building a current SVN snapshot of
>> Wireshark on Fedora 11?
>>
>> Currently, I'm able to complete most of the "make" process, before
>> attempting to build the ICMPv6 dissector fails with the following:
>> cc1: warnings being treated as errors
>> packet-icmpv6.c: In function ‘dissect_icmpv6’:
>> packet-icmpv6.c:1580: error: dereferencing pointer ‘ni’ does break
>> strict-aliasing rules
>> packet-icmpv6.c:1562: error: dereferencing pointer ‘ni’ does break
>> strict-aliasing rules
>> packet-icmpv6.c:1561: error: dereferencing pointer ‘ni’ does break
>> strict-aliasing rules
>> packet-icmpv6.c:1560: note: initialized from here
>
> Yep: I get the same error when I compile with GCC v4.4.1 (on my
> Fedora 11 system) if I use the -O2 option.  (I normally use -O0).
>
>  From the GCC documentation:
>
> `-fstrict-aliasing'
>
> 
>
>      The `-fstrict-aliasing' option is enabled at levels `-O2', `-O3',
>      `-Os'.
>
>
> I'll see what I can do to change the icmpv6 code 
>
> (Do you have any suggestions ?)
>
> (PS: You can, of course, temporarily use -fno-strict-aliasing).
> ___
> 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



-- 
Fight Internet Censorship! http://www.eff.org
   ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon | +447549728105
___
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] Unable to Compile Wireshark from SVN on Fedora 11

2009-08-23 Thread Tyson Key
Hi,
I'm unsure if this is the best venue to report the issue, but is
anyone else having problems building a current SVN snapshot of
Wireshark on Fedora 11?

Currently, I'm able to complete most of the "make" process, before
attempting to build the ICMPv6 dissector fails with the following:
cc1: warnings being treated as errors
packet-icmpv6.c: In function ‘dissect_icmpv6’:
packet-icmpv6.c:1580: error: dereferencing pointer ‘ni’ does break
strict-aliasing rules
packet-icmpv6.c:1562: error: dereferencing pointer ‘ni’ does break
strict-aliasing rules
packet-icmpv6.c:1561: error: dereferencing pointer ‘ni’ does break
strict-aliasing rules
packet-icmpv6.c:1560: note: initialized from here
make[4]: *** [libdissectors_la-packet-icmpv6.lo] Error 1
make[4]: Leaving directory
`/home/tyson/wireshark-1.3.0-SVN-29504/epan/dissectors'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/tyson/wireshark-1.3.0-SVN-29504/epan/dissectors'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tyson/wireshark-1.3.0-SVN-29504/epan'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tyson/wireshark-1.3.0-SVN-29504'
make: *** [all] Error 2

Thanks,
Tyson.

-- 
Fight Internet Censorship! http://www.eff.org
   ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon | +447549728105
___
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] Help

2009-08-12 Thread Tyson Key
Hi, Divya.
You'll want to run ./wireshark in the directory that you've built it
in. It should then launch, if it was built fully.

Tyson.

On Wed, Aug 12, 2009 at 5:15 PM, divya
kothapally wrote:
>
> Hello,
> Iam trying to launch wireshark by just doing a make on it. It is giving me
> following errors:
> gcc: sync_pipe_write.o: No such file or directory
> gcc: util.o: No such file or directory
> gcc: tap-rtp-common.o: No such file or directory
> gcc: capture_info.o: No such file or directory
> gcc: epan/.libs/libwireshark.so: No such file or directory
>
> Is there any way that i could launch the wireshark without doing a make
> install after make ?
> --
> Best,
> Divya Kothapally
>
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
   ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon | +447549728105
___
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] A Mini-Challenge/A Feature Request: Support for Dissecting Bluetooth HCI Frames over USB?

2009-06-28 Thread Tyson Key
Hi,
I have just captured* a session of using a connecting and initialising a USB
Bluetooth adapter, before performing pairing/authentication, and receiving a
file over OBEX from a mobile phone. It appears that the Bluetooth (HCI H1?
HCI H4?) frames are carried over either URB_BULK or URB_INTERRUPT
"channels", depending upon the size or type of the payload, although I'm
unsure exactly of what protocols/frame types are in each payload from
looking at the raw trace file, at present (although the actual OBEX traffic
is split across several USB frames).

Would it be feasible/easily possible to add support for dissecting Bluetooth
traffic at this level? I was initially going to post this over on the
Bugzilla instance, although I felt it was better suited to the mailing list.

* The capture file is now on the SampleCaptures page of the Wireshark Wiki
as "Bluetooth_HCI_and_OBEX_Transaction_over_USB.ntar.gz", if anyone wants a
look

Thanks in advance,
Tyson.
-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] offline dissection of network protocols

2009-05-29 Thread Tyson Key
Hi Selçuk, if you're doing anything involving multiple link types and
Wireshark/dumpcap, you'll want to check out the enhanced pcap-ng file format
support in the latest SVN versions of Wireshark. So it seems, mergecap
doesn't support merging multiple link-layer types in pcap-ng files yet,
although as a workaround, you can concatenate the files (dumped with dumpcap
-n) in order of date/time created, and receive a usable result.

Otherwise, if you ended up with a "cooked" capture file (as produced by
capturing on the Linux "any" pseudo-device), you'll only get useful data
from some of the packets.

As with the pcap file format, I believe that the pcap_* APIs only let you
work with one link-layer type at a time, although others are free to correct
me on that, since I haven't worked with them directly.

I hope that helps,
Tyson.

On Fri, May 29, 2009 at 1:23 PM, Selçuk Cevher  wrote:

> Hi Everybody,
>
> First of all, I am not sure if this is the right place to ask this
> question.
>
> How can I determine the protocol running on data link layer (i.e.,
> Ethernet, Wi-Fi 802.11, etc) while analyzing packets in a "merged" dumped
> file with pcap format if the pcap file contains a mixture of packets with
> various data link layer protocols ?
>
> libpcap has pcap_datalink(...) function allowing us to determine the data
> link layer protocol for live capture -- it gets this information directly
> from the actual network interface that is sniffed on.
>
> However, in the case of offline analysis, it seems pcap_datalink() will
> not work since it is not possible to know what kind of interface those
> packets came from.
>
> Any idea ?
>
> Thanks.
>
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] get a pcapNG file

2009-05-27 Thread Tyson Key
Hi Soltani.
The latest SVN versions of Wireshark support multiple link types in pcap-ng
files, although to capture on non-Ethernet link types you have to use
dumpcap. There was an issue where pcap-ng files created by earlier versions
of Wireshark weren't being handled by newer versions, and vice-versa (i.e.
packets appear, but link type information is missing).

If they help, there are a number of sample files at
http://wiki.wireshark.org/Development/PcapNg, at
http://code.google.com/p/understand/downloads/list and there might be some
floating around this mailing list, although most were sent to developers
off-list to examine, from what I can tell.

If you need anything else, just ask.

Tyson.

On Wed, May 27, 2009 at 10:37 AM, SOLTANI FATEN <
faten.solt...@alcatel-lucent.com> wrote:

> Hi helpful people
> I want to know if Wireshark is able to read a PcapNG file or not, that's
> why I'm looking for an example of PcapNG file.
> Someone can tell me where I can find that
> Regards
> Faten
>
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] writing non-Ethernet pcapng files

2009-05-22 Thread Tyson Key
Hi Michael. Thanks for clarifying that for me.

On Fri, May 22, 2009 at 3:30 PM, Michael Tüxen <
michael.tue...@lurchi.franken.de> wrote:

> Hi Tyson,
>
> 1.0.7 does only support one section header and one interface header at
> the
> beginning of the pcapng file. The current svn version, allows one
> section
> header at the beginning and multiple interface headers, but not multiple
> sections headers. Basically, Wireshark (the svn version) can currently
> only read pcapng files containing one section. That is the reason why
> you can not just concatenate several pcapng files and read the
> resulting file.
> So it is not a limitation of pcapng, but of its current implementation
> in Wireshark.
>
> Best regards
> Michael
>
> On May 22, 2009, at 1:27 PM, Tyson Key wrote:
>
> > Hi.
> > Out of interest, are there supposed to be issues with Ethernet Pcap-
> > NG files/packets appended to other Pcap-NG files generated with
> > Wireshark 1.0.7 having an unrecognised link type in later (SVN)
> > versions of Wireshark? At the same time, it seems that 1.0.7 has
> > issues reading packets in Pcap-NG files from later versions (i.e.
> > it'll try to recognise a few frames, and if the link type is
> > Ethernet, show them in the packet pane, but it'll complain about a
> > decompression error when trying to view them, or it'll just show one
> > packet with an unknown link type (usally 0 or 113 here), depending
> > on how packets were combined).
> >
> > I've attached some samples for reference.
> >
> > Thanks,
> > Tyson.
> >
> > On Fri, May 22, 2009 at 6:35 AM, Ulf Lamping 
> > wrote:
> > Aaron Turner schrieb:
> > > On Thu, May 21, 2009 at 12:20 PM, Michael Tüxen
> > >  wrote:
> > >> On May 21, 2009, at 9:15 PM, Aaron Turner wrote:
> > >>
> > >>> On Thu, May 21, 2009 at 11:55 AM, Michael Tüxen
> > >>>  wrote:
> > >>>> Hi Aaron,
> > >>>>
> > >>>> can you check also with the latest svn version?
> > >>> This was trunk-1.0 r28436.  Are you working in trunk (wireshark
> > >>> 1.1.x)?
> > >> Yes, I'm working in 1.1.x...
> > >
> > >
> > > I just looked at the lastest trunk, and it too hard codes only
> > > ethernet as supported:
> > >
> > > from wiretap/pcapng.c pcapng_dump_can_write_encap():
> > >
> > >   /* XXX - for now we only support Ethernet */
> > >   if (encap != WTAP_ENCAP_ETHERNET)
> > >   return WTAP_ERR_UNSUPPORTED_ENCAP;
> > >
> >
> > Hi!
> >
> > This comment is from the time when I started to experimentally
> > implement
> > pcapng.
> >
> > This was only a rough prototype at that time and as I'm personally
> > only
> > using Ethernet, I've only implemented the absolutely necessary stuff.
> >
> > It's very long ago so I can't remember if there are any further
> > problems
> > with anything else then Ethernet.
> >
> > Seems that you're the first one trying to use it in this way ...
> >
> > Regards, ULFL
> >
> ___
> > 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
> >
> >
> >
> > --
> > Fight Internet Censorship! http://www.eff.org
> >   ~
> > http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
> > +447549728105
> > <
> > Cooked_DC28436
> > -107_Ethernet_Concat
> > .ntar
> > >
> > <
> > Cooked_Dumpcap_SVN_28436
> > .ntar
> > >
> > <
> > Ethernet_Dumpcap_SVN_28436
> > .ntar
> > >
> > <
> > Ethernet_Wireshark_1.0.7
> > .ntar
> > >
> >
> ___
> > 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
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] writing non-Ethernet pcapng files

2009-05-22 Thread Tyson Key
Hi.
Out of interest, are there supposed to be issues with Ethernet Pcap-NG
files/packets appended to other Pcap-NG files generated with Wireshark 1.0.7
having an unrecognised link type in later (SVN) versions of Wireshark? At
the same time, it seems that 1.0.7 has issues reading packets in Pcap-NG
files from later versions (i.e. it'll try to recognise a few frames, and if
the link type is Ethernet, show them in the packet pane, but it'll complain
about a decompression error when trying to view them, or it'll just show one
packet with an unknown link type (usally 0 or 113 here), depending on how
packets were combined).

I've attached some samples for reference.

Thanks,
Tyson.

On Fri, May 22, 2009 at 6:35 AM, Ulf Lamping  wrote:

> Aaron Turner schrieb:
> > On Thu, May 21, 2009 at 12:20 PM, Michael Tüxen
> >  wrote:
> >> On May 21, 2009, at 9:15 PM, Aaron Turner wrote:
> >>
> >>> On Thu, May 21, 2009 at 11:55 AM, Michael Tüxen
> >>>  wrote:
>  Hi Aaron,
> 
>  can you check also with the latest svn version?
> >>> This was trunk-1.0 r28436.  Are you working in trunk (wireshark
> >>> 1.1.x)?
> >> Yes, I'm working in 1.1.x...
> >
> >
> > I just looked at the lastest trunk, and it too hard codes only
> > ethernet as supported:
> >
> > from wiretap/pcapng.c pcapng_dump_can_write_encap():
> >
> >   /* XXX - for now we only support Ethernet */
> >   if (encap != WTAP_ENCAP_ETHERNET)
> >   return WTAP_ERR_UNSUPPORTED_ENCAP;
> >
>
> Hi!
>
> This comment is from the time when I started to experimentally implement
> pcapng.
>
> This was only a rough prototype at that time and as I'm personally only
> using Ethernet, I've only implemented the absolutely necessary stuff.
>
> It's very long ago so I can't remember if there are any further problems
> with anything else then Ethernet.
>
> Seems that you're the first one trying to use it in this way ...
>
> Regards, ULFL
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105


Cooked_DC28436-107_Ethernet_Concat.ntar
Description: Binary data


Cooked_Dumpcap_SVN_28436.ntar
Description: Binary data


Ethernet_Dumpcap_SVN_28436.ntar
Description: Binary data


Ethernet_Wireshark_1.0.7.ntar
Description: Binary 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

[Wireshark-dev] Cannot Capture Bluetooth Traffic as of SVN r28436

2009-05-21 Thread Tyson Key
Hi, it seems that as of Wireshark SVN revision 28436 (with libpcap
1.1-PRE-CVS), I am unable to properly capture Bluetooth H4 traffic from a
USB-connected Bluetooth radio. When trying to perform a capture, it appears
that data is not being written to the capture file, and the packet counter
is not incremented. However, if I disconnect the Bluetooth adaptor, 1 packet
is generated and written to disk. I believe that HCIdump and Wireshark 1.0.7
are still able to capture traffic correctly.

If any additional information is required, feel free to ask.

Thanks,
Tyson.

-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] capturing on multiple interfaces

2009-05-21 Thread Tyson Key
Hi Michael, I've sent you some samples off-list. I hope they're of use.

Thanks,
Tyson

On Thu, May 21, 2009 at 7:54 PM, Michael Tüxen <
michael.tue...@lurchi.franken.de> wrote:

> On May 21, 2009, at 8:01 PM, Tyson Key wrote:
>
> > Hi. I'm not sure what the problem was, although changing the
> > directory to the directory that the capture files are to be stored
> > in, and doing "sudo ../wireshark-1.1.4-SVN-28436/dumpcap -n -s 0 -w
> > Wifi3 -i wlan0" did the trick nicely.
> >
> > A great job with the implementation by the way, so far. I managed to
> > create an ersatz multi-link-type file by cat-ing together a file
> > with 802.11 packets, one with USB packets, and one with Linux Cooked
> > packets from a PPP device, and Wireshark handled them perfectly
> > (barring some timestamp strangeness - the appended packets have
> > negative timestamps, although I'd expect that sort of behaviour,
> > given that there are multiple "reference" timestamps, and an issue
> > with the USB dissector (gives "Warn Dissector bug, protocol USB, in
> > packet 104: packet-usb.c:1702: failed assertion
> > "DISSECTOR_ASSERT_NOT_REACHED"" although it's probably a known
> > issue)), if anyone's interested.
> Can you send me the tracefile privately? I would like to have a look
> at the timestamp problem...
> >
> >
> > Thanks,
> > Tyson.
> >
> > On Thu, May 21, 2009 at 6:51 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > wrote:
> > On May 21, 2009, at 7:24 PM, Tyson Key wrote:
> >
> > > Hi again, Michael. Probably a stupid question, and I'm not sure if
> > > it's a bug or not, but any idea why I'd get "The file to which the
> > > capture would be saved ("../pcapng/U1") could not be opened:
> > > Permission denied." when trying to write a pcap-ng file to any
> > > directory other than the default one (/tmp), even as root, and when
> > > a directory has it's permission bits set to 777?
> > Not sure what the problem could be. I can run
> > ./dumpcap -n -w test.pcapng -i lo0 -p
> > without any problem...
> > >
> > >
> > > Thanks in advance,
> > > Tyson.
> > >
> > > On Thu, May 21, 2009 at 5:24 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > > wrote:
> > > On May 21, 2009, at 5:17 PM, Tyson Key wrote:
> > >
> > > > Hi Michael. This is fantastic news to hear!
> > > > Will it eventually support non-Ethernet, and mixed link types in
> > the
> > > > same file (e.g. mmapped Linux USB and Ethernet), out of interest?
> > > Yes, it should be possible to capture from multiple interfaces of
> > link
> > > types
> > > which are supported today (so I do not add new link types). For
> > > supporting
> > > multiple link types, I had to add pcapng support, which is already
> > > there...
> > >
> > > Best regards
> > > Michael
> > >
> > > >
> > > >
> > > > Thanks,
> > > > Tyson.
> > > >
> > > > On Thu, May 21, 2009 at 1:11 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > > > wrote:
> > > > On May 21, 2009, at 12:02 PM, 
> > > wrote:
> > > >
> > > > > Hi Michael,
> > > > >
> > > > > I have downloaded the source code from SVN. Can you please say
> > how
> > > > > to use dumpcap option -n to capture on interfaces x1, x2, x3
> > > from x1
> > > > > to xn.
> > > > Currently you can capture only on one interface, so
> > > > dumpcap -n -i en0
> > > > should work.
> > > > A future version will support
> > > > dumpcap -n -i en0 -s 100 -i en1 -s 1000
> > > > and so one, where you capture on en0 with snaplen 100 and on en1
> > > with
> > > > snaplen 1000.
> > > > You will also be able to set a pe interface capture filter, link
> > > type,
> > > > promiscuous flag.
> > > > I'll send a note to the dev list, when this stuff is working.
> > > >
> > > > Which platform are you using?
> > > >
> > > > Best regards
> > > > Michael
> > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Chandra.
> > > > >
> > > > > -Original Message-
>

Re: [Wireshark-dev] capturing on multiple interfaces

2009-05-21 Thread Tyson Key
Hi. I'm not sure what the problem was, although changing the directory to
the directory that the capture files are to be stored in, and doing "sudo
../wireshark-1.1.4-SVN-28436/dumpcap -n -s 0 -w Wifi3 -i wlan0" did the
trick nicely.

A great job with the implementation by the way, so far. I managed to create
an ersatz multi-link-type file by cat-ing together a file with 802.11
packets, one with USB packets, and one with Linux Cooked packets from a PPP
device, and Wireshark handled them perfectly (barring some timestamp
strangeness - the appended packets have negative timestamps, although I'd
expect that sort of behaviour, given that there are multiple "reference"
timestamps, and an issue with the USB dissector (gives "Warn Dissector bug,
protocol USB, in packet 104: packet-usb.c:1702: failed assertion
"DISSECTOR_ASSERT_NOT_REACHED"" although it's probably a known issue)), if
anyone's interested.

Thanks,
Tyson.

On Thu, May 21, 2009 at 6:51 PM, Michael Tüxen <
michael.tue...@lurchi.franken.de> wrote:

> On May 21, 2009, at 7:24 PM, Tyson Key wrote:
>
> > Hi again, Michael. Probably a stupid question, and I'm not sure if
> > it's a bug or not, but any idea why I'd get "The file to which the
> > capture would be saved ("../pcapng/U1") could not be opened:
> > Permission denied." when trying to write a pcap-ng file to any
> > directory other than the default one (/tmp), even as root, and when
> > a directory has it's permission bits set to 777?
> Not sure what the problem could be. I can run
> ./dumpcap -n -w test.pcapng -i lo0 -p
> without any problem...
> >
> >
> > Thanks in advance,
> > Tyson.
> >
> > On Thu, May 21, 2009 at 5:24 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > wrote:
> > On May 21, 2009, at 5:17 PM, Tyson Key wrote:
> >
> > > Hi Michael. This is fantastic news to hear!
> > > Will it eventually support non-Ethernet, and mixed link types in the
> > > same file (e.g. mmapped Linux USB and Ethernet), out of interest?
> > Yes, it should be possible to capture from multiple interfaces of link
> > types
> > which are supported today (so I do not add new link types). For
> > supporting
> > multiple link types, I had to add pcapng support, which is already
> > there...
> >
> > Best regards
> > Michael
> >
> > >
> > >
> > > Thanks,
> > > Tyson.
> > >
> > > On Thu, May 21, 2009 at 1:11 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > > wrote:
> > > On May 21, 2009, at 12:02 PM, 
> > wrote:
> > >
> > > > Hi Michael,
> > > >
> > > > I have downloaded the source code from SVN. Can you please say how
> > > > to use dumpcap option -n to capture on interfaces x1, x2, x3
> > from x1
> > > > to xn.
> > > Currently you can capture only on one interface, so
> > > dumpcap -n -i en0
> > > should work.
> > > A future version will support
> > > dumpcap -n -i en0 -s 100 -i en1 -s 1000
> > > and so one, where you capture on en0 with snaplen 100 and on en1
> > with
> > > snaplen 1000.
> > > You will also be able to set a pe interface capture filter, link
> > type,
> > > promiscuous flag.
> > > I'll send a note to the dev list, when this stuff is working.
> > >
> > > Which platform are you using?
> > >
> > > Best regards
> > > Michael
> > >
> > > >
> > > >
> > > > Regards,
> > > > Chandra.
> > > >
> > > > -Original Message-
> > > > From: Chandra Sekhar kotikalapudi (WT01 - Telecom Equipment)
> > > > Sent: Thursday, May 21, 2009 3:20 PM
> > > > To: 'Developer support list for Wireshark'
> > > > Subject: RE: [Wireshark-dev] capturing on multiple interfaces
> > > >
> > > > Hi Michael,
> > > >
> > > > It is good to hear you have already working on it. Can you please
> > > > say in which svn version it is available so that I could do the
> > > > testing what ever possible?
> > > >
> > > > Thanks & Regards,
> > > > Chandra.
> > > >
> > > > -Original Message-
> > > > From: wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org
> > > > ] On Behalf Of Michael Tüxen
> > > > Sent: Thursday, May 21, 2009 2:52 PM
> > > > To: Develo

Re: [Wireshark-dev] capturing on multiple interfaces

2009-05-21 Thread Tyson Key
Hi again, Michael. Probably a stupid question, and I'm not sure if it's a
bug or not, but any idea why I'd get "The file to which the capture would be
saved ("../pcapng/U1") could not be opened: Permission denied." when trying
to write a pcap-ng file to any directory other than the default one (/tmp),
even as root, and when a directory has it's permission bits set to 777?

Thanks in advance,
Tyson.

On Thu, May 21, 2009 at 5:24 PM, Michael Tüxen <
michael.tue...@lurchi.franken.de> wrote:

> On May 21, 2009, at 5:17 PM, Tyson Key wrote:
>
> > Hi Michael. This is fantastic news to hear!
> > Will it eventually support non-Ethernet, and mixed link types in the
> > same file (e.g. mmapped Linux USB and Ethernet), out of interest?
> Yes, it should be possible to capture from multiple interfaces of link
> types
> which are supported today (so I do not add new link types). For
> supporting
> multiple link types, I had to add pcapng support, which is already
> there...
>
> Best regards
> Michael
>
> >
> >
> > Thanks,
> > Tyson.
> >
> > On Thu, May 21, 2009 at 1:11 PM, Michael Tüxen <
> michael.tue...@lurchi.franken.de
> > > wrote:
> > On May 21, 2009, at 12:02 PM,  wrote:
> >
> > > Hi Michael,
> > >
> > > I have downloaded the source code from SVN. Can you please say how
> > > to use dumpcap option -n to capture on interfaces x1, x2, x3 from x1
> > > to xn.
> > Currently you can capture only on one interface, so
> > dumpcap -n -i en0
> > should work.
> > A future version will support
> > dumpcap -n -i en0 -s 100 -i en1 -s 1000
> > and so one, where you capture on en0 with snaplen 100 and on en1 with
> > snaplen 1000.
> > You will also be able to set a pe interface capture filter, link type,
> > promiscuous flag.
> > I'll send a note to the dev list, when this stuff is working.
> >
> > Which platform are you using?
> >
> > Best regards
> > Michael
> >
> > >
> > >
> > > Regards,
> > > Chandra.
> > >
> > > -Original Message-
> > > From: Chandra Sekhar kotikalapudi (WT01 - Telecom Equipment)
> > > Sent: Thursday, May 21, 2009 3:20 PM
> > > To: 'Developer support list for Wireshark'
> > > Subject: RE: [Wireshark-dev] capturing on multiple interfaces
> > >
> > > Hi Michael,
> > >
> > > It is good to hear you have already working on it. Can you please
> > > say in which svn version it is available so that I could do the
> > > testing what ever possible?
> > >
> > > Thanks & Regards,
> > > Chandra.
> > >
> > > -Original Message-
> > > From: wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org
> > > ] On Behalf Of Michael Tüxen
> > > Sent: Thursday, May 21, 2009 2:52 PM
> > > To: Developer support list for Wireshark
> > > Subject: Re: [Wireshark-dev] capturing on multiple interfaces
> > >
> > > On May 21, 2009, at 8:59 AM,  <
> chandra.kotikalap...@wipro.com
> > >> wrote:
> > >
> > >> Hi Tyson,
> > >>
> > >> Thank you very much for the response.
> > >> Is it possible to capture on desired 'x' interfaces in 'n'
> > >> interfaces available using "dumpcap".
> > > This is what I'm working on. The capture file will be stored
> > > in .pcapng format...
> > > Saving in .pcapng is already available in the svn version. Use the
> > -n
> > > option.
> > > Testing it is highly appreciated...
> > >
> > > Best regards
> > > Michael
> > >
> > >>
> > >> Regards,
> > >> Chandra.
> > >> From: wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org
> > >> ] On Behalf Of Tyson Key
> > >> Sent: Monday, May 18, 2009 8:53 PM
> > >> To: Developer support list for Wireshark
> > >> Subject: Re: [Wireshark-dev] capturing on multiple interfaces
> > >>
> > >> Hi, Chandra.
> > >> Assuming that all the devices you want to capture on uses the same
> > >> link type, there's an "any" pseudo-device on Linux that you can
> > use.
> > >> Sadly, it doesn't store information about the devices involved, and
> > >> the link type-specific headers are transformed into a "Cooked"
> > >> format.

Re: [Wireshark-dev] capturing on multiple interfaces

2009-05-21 Thread Tyson Key
Hi Michael. This is fantastic news to hear!
Will it eventually support non-Ethernet, and mixed link types in the same
file (e.g. mmapped Linux USB and Ethernet), out of interest?

Thanks,
Tyson.

On Thu, May 21, 2009 at 1:11 PM, Michael Tüxen <
michael.tue...@lurchi.franken.de> wrote:

> On May 21, 2009, at 12:02 PM,  wrote:
>
> > Hi Michael,
> >
> > I have downloaded the source code from SVN. Can you please say how
> > to use dumpcap option -n to capture on interfaces x1, x2, x3 from x1
> > to xn.
> Currently you can capture only on one interface, so
> dumpcap -n -i en0
> should work.
> A future version will support
> dumpcap -n -i en0 -s 100 -i en1 -s 1000
> and so one, where you capture on en0 with snaplen 100 and on en1 with
> snaplen 1000.
> You will also be able to set a pe interface capture filter, link type,
> promiscuous flag.
> I'll send a note to the dev list, when this stuff is working.
>
> Which platform are you using?
>
> Best regards
> Michael
>
> >
> >
> > Regards,
> > Chandra.
> >
> > -Original Message-
> > From: Chandra Sekhar kotikalapudi (WT01 - Telecom Equipment)
> > Sent: Thursday, May 21, 2009 3:20 PM
> > To: 'Developer support list for Wireshark'
> > Subject: RE: [Wireshark-dev] capturing on multiple interfaces
> >
> > Hi Michael,
> >
> > It is good to hear you have already working on it. Can you please
> > say in which svn version it is available so that I could do the
> > testing what ever possible?
> >
> > Thanks & Regards,
> > Chandra.
> >
> > -Original Message-
> > From: wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org
> > ] On Behalf Of Michael Tüxen
> > Sent: Thursday, May 21, 2009 2:52 PM
> > To: Developer support list for Wireshark
> > Subject: Re: [Wireshark-dev] capturing on multiple interfaces
> >
> > On May 21, 2009, at 8:59 AM,  <
> chandra.kotikalap...@wipro.com
> >> wrote:
> >
> >> Hi Tyson,
> >>
> >> Thank you very much for the response.
> >> Is it possible to capture on desired 'x' interfaces in 'n'
> >> interfaces available using "dumpcap".
> > This is what I'm working on. The capture file will be stored
> > in .pcapng format...
> > Saving in .pcapng is already available in the svn version. Use the -n
> > option.
> > Testing it is highly appreciated...
> >
> > Best regards
> > Michael
> >
> >>
> >> Regards,
> >> Chandra.
> >> From: wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org
> >> ] On Behalf Of Tyson Key
> >> Sent: Monday, May 18, 2009 8:53 PM
> >> To: Developer support list for Wireshark
> >> Subject: Re: [Wireshark-dev] capturing on multiple interfaces
> >>
> >> Hi, Chandra.
> >> Assuming that all the devices you want to capture on uses the same
> >> link type, there's an "any" pseudo-device on Linux that you can use.
> >> Sadly, it doesn't store information about the devices involved, and
> >> the link type-specific headers are transformed into a "Cooked"
> >> format. You might want to investigate pcap-ng for that sort of stuff.
> >>
> >> Hope that helps,
> >> Tyson.
> >> On Mon, May 18, 2009 at 10:23 AM, 
> >> wrote:
> >> Hi,
> >>
> >>
> >>
> >> We all know Wireshark can capture on different interfaces, can it be
> >> able to capture on all interfaces at once using Wireshark?
> >>
> >>
> >>
> >> If 'No' is the answer can any one help me in understanding how
> >> capturing is done using Wireshark?
> >>
> >> I could change the implementation accordingly for my needs to
> >> capture on all interfaces.
> >>
> >>
> >>
> >> Thanks in advance.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Chandra.
> >>
> >>
> >>
> >> Please do not print this email unless it is absolutely necessary.
> >>
> >> The information contained in this electronic message and any
> >> attachments to this message are intended for the exclusive use of
> >> the addressee(s) and may contain proprietary, confidential or
> >> privileged information. If you are not the intended recipient, you
> >> should not disseminate, distribute or copy this e-mail. Please
> >> 

Re: [Wireshark-dev] capturing on multiple interfaces

2009-05-18 Thread Tyson Key
Hi, Chandra.
Assuming that all the devices you want to capture on uses the same link
type, there's an "any" pseudo-device on Linux that you can use. Sadly, it
doesn't store information about the devices involved, and the link
type-specific headers are transformed into a "Cooked" format. You might want
to investigate pcap-ng for that sort of stuff.

Hope that helps,
Tyson.

On Mon, May 18, 2009 at 10:23 AM,  wrote:

>  Hi,
>
>
>
> We all know Wireshark can capture on different interfaces, can it be able
> to capture on all interfaces at once using Wireshark?
>
>
>
> If ‘No’ is the answer can any one help me in understanding how capturing is
> done using Wireshark?
>
> I could change the implementation accordingly for my needs to capture on
> all interfaces.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Chandra.
>
>
>
> *Please do not print this email unless it is absolutely necessary. *
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
> ___
> 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
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
+447549728105
___
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] GeoIP support added

2008-10-27 Thread Tyson Key
Hi Gerald, sounds like a very cool and useful feature to have. Any idea
about which SVN revision this is in?
Thanks.

On Mon, Oct 27, 2008 at 4:56 AM, Gerald Combs <[EMAIL PROTECTED]> wrote:

> I've just added initial support for the GeoIP library. Using different
> database files, GeoIP can map IP addresses to Countries, Cities, AS
> numbers, ISPs, etc. The library itself is GPL. Some databases are
> available for free at http://www.maxmind.com/download/geoip/database/,
> but others (such as the ISP and network speed databases) are not.
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> https://wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] WLAN Traffic Statistics

2008-02-12 Thread Tyson Key
Hi Stig. Just tried the new SVN version, and the WLAN Traffic stats option
seems very useful.

Thanks.

On Feb 12, 2008 2:19 PM, Stig Bjørlykke <[EMAIL PROTECTED]> wrote:

> Hi.
>
> I have just added "Statistics->WLAN Traffic..." with some basic
> wireless traffic statistics.  Have a look at revision 24310, and
> please tell me if I have misunderstood something or if you have
> enhancement requests.
>
> Later I will add more detailed statistics for each network, connected
> hosts, amount of data etc.
>
>
> --
> Stig Bjørlykke
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] ethernet over USB

2008-02-01 Thread Tyson Key
Hi, assuming that you're referring to USB Communications Device Class, or
ATM-over-USB devices (e.g. some consumer ADSL routers), everything gets sent
as a generic URB_BULK(?) transmission, if I remember correctly, which
Wireshark can't currently analyze. I'm not sure myself why it constantly
sends a flow of data, even when both computers aren't using the link
(presumably heartbeat traffic?). Assuming that Linux doesn't use some weird
custom header, the USB Forum specifications might be of use.

Hope that helps.

On Jan 31, 2008 10:57 PM, Bill Fassler <[EMAIL PROTECTED]> wrote:

> Hey guys, I have been trying to understand ethernet over USB.  I have
> ethernet over USB working on an embedded development board running a
> blackfin DSP and uClinux.  I have everthing configured and can network with
> either linux or windows.  I am trying to understand the protocol and packet
> headers, wrappers and such.
>
> In an attempt to understand things I installed snoopypro and upgraded my
> Wireshark to 99.7, then I ping the windows box and it responds and I
> capture the traffic using both sniffers (yours and snoopypro).  I can not
> yet however, find a packet for packet correlation.  The sequence numbers are
> different.  I suppose that is because Wireshark sequence numbers are soley
> based on the Ethernet traffic (ARP and PING), when snoopypro picks up the
> higher layer and the sequence numbers reflect that.
>
> I tried to limit the traffic to just one ping.  Figuring that should be
> easy.  It wasn't since apparently the linux ethernet over USB driver sends
> stuff out almost constantly regardless of whether there is ethernet traffic.
>
> Any h... you guys are the experts here.  I imagine I am making a
> simple task difficult.  How can I understand the ethernet over USB packet
> better?  I am thinking about writing a non-linux based version of this..
> and don't understand it enough to even start just yet..
>
> Bill Fassler
>
> --
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] pcap-ng support

2008-01-21 Thread Tyson Key
Hi, sorry to hijack the thread, but does anyone know if there will be a link
type code available for Bluetooth in pcap-ng?

Thanks, Tyson.

On Jan 18, 2008 7:01 AM, Ulf Lamping <[EMAIL PROTECTED]> wrote:

> Gianluca Varenni schrieb:
> > FYI today I tried opening a pcap-ng file with wireshark rev 24118, and
> > it sort of worked.
> >
> > What works:
> > - the first file I opened was a 50+MB file generated with NTAR. Real
> > ethernet packets coming from a custom board. Wireshark opened the
> > trace without any problem, and the decoded packets made perfectly
> > sense. YAY!
> Nice!
> >
> > What doesn't work:
> > - timestamps are wrong. There are two problems here:
> >  1. the IDB option for the timestamp precision is not decoded, and I
> > was generating timestamps with nanosecond precision.
> No wonder, the corresponding line in the code says: /* XXX - convert
> timestamps into nsecs */ ;-)
> >  2. timestamps are not in the libpcap fashion (seconds and
> > microseconds, or seconds and nanoseconds). It's a single 64bit
> > quantity that is split into high and low 32bits.
> >
> The timestamps currently won't work, but shouldn't be too hard to fix.
>
> I'll have a look ...
>
> Regards, ULFL
>
> P.S: The FCS is also not decoded, Wireshark will internally always
> handle pcapng as: "don't know if FCS is there"
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] wimaxintel.dll

2007-10-22 Thread Tyson Key
Hi, as far as I know, CACE Technologies provide commercial support for 
Wireshark. There is no closed-source or commercial license version of 
Wireshark, nor royalties or license fees required for its use, whatsoever.
Hope that helps.


Etay Luz wrote:
>
> (Please ignore my previous post – sorry about that one)
>
> Hi!
>
> I am a developer working for Runcom Ltd – a Wimax technology company.
>
> We are interested in using WireShark to debug our system.
>
> I need to work with the wimaxintel.dll file to interpret MAC messages.
>
> Using this dll, I have noticed the need to insert all sorts of 
> proprietary headers prior to MAC message data in order for it to work 
> correctly.
>
> Does anyone know how and where I can find the format, encapsulations, 
> and fbit sequences for these headers (using wimaxintel.dll)?
>
> Also, we would like to buy a license for commercial use of Wireshark. 
> Does anyone know where I can get support to buy this product (phone 
> number, email)?
>
> Thanks in advance,
>
> Etay Luz
>
> 
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>   

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] SVN Commit With IPMB Support?

2007-08-31 Thread Tyson Key

Hi, the patch is attached, as I originally found it on the mailing list.
Thanks.

Stephen Fisher wrote:

On Fri, Aug 31, 2007 at 12:32:34AM +0100, Tyson Key wrote:

  

Also, does anyone know where the ZigBee/IEEE 802.15.4 dissector is? I
have the patch that was sent to the mailing list, but it doesn't seem
to compile.



Could you point to the message containing the patch in the mailing list
archives or re-send it with the original poster's full name so we can
consider it?  It must have been overlooked the first time.  One of us
could probably get it to compile.


Steve
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
  




ieee802154r3.patch.gz
Description: GNU Zip compressed data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] SVN Commit With IPMB Support?

2007-08-31 Thread Tyson Key
Hi, from looking at the list last night, two different people have 
discussed i2c and IPMB dissectors, so I'm not sure what's happening, but 
thanks anyway.

Anders Broman wrote:
> Hi,
> I think this is related to I2C if you check messages from
> Audet, Jean-Michel. I don't think any code has been submitted.
> Regards
> Anders
>
> -Ursprungligt meddelande-
> Från: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] För Tyson Key
> Skickat: den 31 augusti 2007 01:33
> Till: Developer support list for Wireshark
> Ämne: Re: [Wireshark-dev] SVN Commit With IPMB Support?
>
> Hi, there's a page on the Wireshark Wiki that claims that "The IPMB 
> plugin is fully functional in Wireshark", however I haven't seen any 
> proof of it's existance other than e-mails to the -dev list about the 
> creation of it and a partial screenshot attached to that Wiki page. 
> Also, does anyone know where the ZigBee/IEEE 802.15.4 dissector is? I 
> have the patch that was sent to the mailing list, but it doesn't seem to 
> compile.
>
> Thanks.
>
> Stephen Fisher wrote:
>   
>> On Thu, Aug 30, 2007 at 11:42:37PM +0100, Tyson Key wrote:
>>
>>   
>> 
>>> Hi. I'm not sure if this is the right place to ask, but does anyone
>>> know if the supposed SVN commit/patch for IPMB dissecting support has
>>> been checked in or has been made available somewhere? I've been
>>> checking the SVN commits every few hours, and haven't come across it,
>>> nor can I find the supposed information on it in the Bugzilla.
>>> 
>>>   
>> You are asking the right place.  I do not see any references to "IPMB"
>> in the bug tracker either nor in the recent SVN log entries.  Was this
>> patch submitted through bugs.wireshark.org or to this mailing list or is
>> it a feature someone said would be added?
>>
>>
>> Steve
>>
>> ___
>> Wireshark-dev mailing list
>> Wireshark-dev@wireshark.org
>> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>>   
>> 
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>   

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] SVN Commit With IPMB Support?

2007-08-30 Thread Tyson Key
Hi, there's a page on the Wireshark Wiki that claims that "The IPMB 
plugin is fully functional in Wireshark", however I haven't seen any 
proof of it's existance other than e-mails to the -dev list about the 
creation of it and a partial screenshot attached to that Wiki page. 
Also, does anyone know where the ZigBee/IEEE 802.15.4 dissector is? I 
have the patch that was sent to the mailing list, but it doesn't seem to 
compile.

Thanks.

Stephen Fisher wrote:
> On Thu, Aug 30, 2007 at 11:42:37PM +0100, Tyson Key wrote:
>
>   
>> Hi. I'm not sure if this is the right place to ask, but does anyone
>> know if the supposed SVN commit/patch for IPMB dissecting support has
>> been checked in or has been made available somewhere? I've been
>> checking the SVN commits every few hours, and haven't come across it,
>> nor can I find the supposed information on it in the Bugzilla.
>> 
>
> You are asking the right place.  I do not see any references to "IPMB"
> in the bug tracker either nor in the recent SVN log entries.  Was this
> patch submitted through bugs.wireshark.org or to this mailing list or is
> it a feature someone said would be added?
>
>
> Steve
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>   

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] SVN Commit With IPMB Support?

2007-08-30 Thread Tyson Key
Hi. I'm not sure if this is the right place to ask, but does anyone know 
if the supposed SVN commit/patch for IPMB dissecting support has been 
checked in or has been made available somewhere? I've been checking the 
SVN commits every few hours, and haven't come across it, nor can I find 
the supposed information on it in the Bugzilla.

Thanks, Tyson.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev