headers
Chris Maynard | 1 Jul 2011 16:34

Bugzilla not sending e-mails?

I am no longer receiving any e-mail updates from bugzilla.  Just checking if
this is isolated to me or if there might be something wrong with bugzilla.  
Thanks.

- Chris

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 2 comments |
headers
Gerald Combs | 1 Jul 2011 17:38
Favicon
Gravatar

Re: Bugzilla not sending e-mails?

On 7/1/11 7:34 AM, Chris Maynard wrote:
> I am no longer receiving any e-mail updates from bugzilla.  Just checking if
> this is isolated to me or if there might be something wrong with bugzilla.  
> Thanks.

Mailman was having issues. It should be fixed now.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 0 comments |
headers
Chris Maynard | 1 Jul 2011 17:51

Re: Bugzilla not sending e-mails?

Chris Maynard <Chris.Maynard <at> ...> writes:

> I am no longer receiving any e-mail updates from bugzilla.  Just checking if
> this is isolated to me or if there might be something wrong with bugzilla.  

OK, I guess they are being sent, but for some reason there seems to be a really
long delay before I receive them.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 0 comments |
headers
John x | 1 Jul 2011 18:50
Picon
Favicon

anyone can give me a sample pcap of "roofnet" ?

Hi,

.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Tahoma;}
who has a sample pcap of roofnet protocol ? I wanna one to test

thanks
John
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 0 comments |
headers
Randy Buck | 1 Jul 2011 18:53
Picon

Duplicating TCP dissector

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 <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 1 comment |
headers
Guy Harris | 1 Jul 2011 19:03
Picon
Favicon

Re: Duplicating TCP dissector


On Jul 1, 2011, at 9:53 AM, Randy Buck wrote:

> 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?

The ways discussed in the responses to the previous instance of this mail message sent to the list.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 0 comments |
headers
Guy Harris | 1 Jul 2011 20:41
Picon
Favicon

Re: [Wireshark-commits] rev 37846: /trunk/ /trunk/: dumpcap.c


On Jun 30, 2011, at 1:18 PM, gerald@... wrote:

> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=37846
> 
> User: gerald
> Date: 2011/06/30 01:18 PM
> 
> Log:
> Log the success or failure of pcap_open/pcap_create/pcap_open_live.

So, err, umm, is WinPcap's pcap_open_live() - well, you probably have a recent version of WinPcap, so it
might be pcap_activate() inside pcap_open_live() - hanging, crashing, or *what* when you hand it "-" as
an argument?  It *should* just quickly fail, so that dumpcap can fall back on "I guess that's a pipe".
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 3 comments |
headers
Michael Tüxen | 1 Jul 2011 21:05
Picon

Re: [Wireshark-commits] rev 37846: /trunk/ /trunk/: dumpcap.c

On Jul 1, 2011, at 8:41 PM, Guy Harris wrote:

> 
> On Jun 30, 2011, at 1:18 PM, gerald@... wrote:
> 
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=37846
>> 
>> User: gerald
>> Date: 2011/06/30 01:18 PM
>> 
>> Log:
>> Log the success or failure of pcap_open/pcap_create/pcap_open_live.
> 
> So, err, umm, is WinPcap's pcap_open_live() - well, you probably have a recent version of WinPcap, so it
might be pcap_activate() inside pcap_open_live() - hanging, crashing, or *what* when you hand it "-" as
an argument?  It *should* just quickly fail, so that dumpcap can fall back on "I guess that's a pipe".
Actually I guess that WinPcap's pcap_open_live() somehow calls exit(127)... Not
that I expect WinPcap to call exit() at all, I have no clue why this behavior
now shows up and not earlier... All parameters provided to the pcap_open_live()
call make sense (to me)...

Best regards
Michael
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@...?subject=unsubscribe
> 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 2 comments |
headers
Guy Harris | 1 Jul 2011 21:34
Picon
Favicon

Re: [Wireshark-commits] rev 37846: /trunk/ /trunk/: dumpcap.c


On Jul 1, 2011, at 12:05 PM, Michael Tüxen wrote:

> Actually I guess that WinPcap's pcap_open_live() somehow calls exit(127)... Not
> that I expect WinPcap to call exit() at all

The only exit calls I see in the WinPcap source are inherited from libpcap, and they're in

	1) the DOS libpcap support;

	2) some code that is called "pcap-enet.c" but was never actually a pcap module for anything (perhaps it was
taken from a really old pre-libpcap tcpdump or something with the intent that it turn into a pcap module for
"Stanford Enetfilter")

so they're not used by WinPcap.  Perhaps something WinPcap calls in turn calls exit.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Permalink | Reply | 1 comment |
headers
Gerald Combs | 1 Jul 2011 22:56
Favicon
Gravatar

Re: [Wireshark-commits] rev 37846: /trunk/ /trunk/: dumpcap.c

On 7/1/11 12:34 PM, Guy Harris wrote:
> 
> On Jul 1, 2011, at 12:05 PM, Michael Tüxen wrote:
> 
>> Actually I guess that WinPcap's pcap_open_live() somehow calls exit(127)... Not
>> that I expect WinPcap to call exit() at all
> 
> The only exit calls I see in the WinPcap source are inherited from libpcap, and they're in
> 
> 	1) the DOS libpcap support;
> 
> 	2) some code that is called "pcap-enet.c" but was never actually a pcap module for anything (perhaps it
was taken from a really old pre-libpcap tcpdump or something with the intent that it turn into a pcap module
for "Stanford Enetfilter")
> 
> so they're not used by WinPcap.  Perhaps something WinPcap calls in turn calls exit.

So far the problem has only shown up inside Buildbot. I can't duplicate
it interactively on the same machine running as the same user.

After adding

  export CYGWIN="$CYGWIN error_start=c:\cygwin\bin\dumper.exe -d %1 %2"

to test/config.sh dumpcap no longer exits prematurely. Dumper doesn't
create a core file, either. Could it be a Cygwin issue?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request <at> wireshark.org?subject=unsubscribe
Permalink | Reply | 0 comments |

Gmane