Re: [Wireshark-dev] Ability to dynamically dissect in more detail?

[Sake Blok | SYN-bit]

> On 16 May 2023, at 18:27, jayrturne...@gmail.com wrote:
> 
> I have a dissector. I dissect the content as delimited text. Sometimes the 
> textual content has further meaning, but I only want to dissect it in further 
> detail on a packet by packet basis and only if the user requests it on a 
> specific packet.
>  
> The reason is that the detailed dissection requires extra information to be 
> loaded and extra dissection processing. Is there any mechanism to expand a 
> section only when requested? A trivial example:

One way to achieve this would be to use the C dissector only for the general 
dissection and then use a Lua script to create the detailed dissection. I'm not 
100% sure, but I assume it would be possible to have it register itself under 
tools. I do not think you can add extra fields this way, but it sounds like 
that might not be needed anyways, just a further detailed display of data in 
the packet.

Just an idea...

Cheers,
Sake


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Possible regression in Version 3.3.1 (v3.3.1-0-gd64aca7966e2)

[Sake Blok | SYN-bit]

RIchard,

I just tried “Applying as column” in Wireshark 3.3.1 on my Mac and it works as 
expected. May the problem is only exposed with certain fields? What was the 
field your co-working was trying to apply as a column?

Cheers,
Sake


> On 17 Oct 2020, at 00:54, Richard Sharpe  wrote:
> 
> Hi folks,
> 
> I got a report from a coworker that 'Apply as column' was not working 
> correctly.
> 
> I showed the person how to right-click on a field in the details pane
> and then select Apply as column.
> 
> However, what happened in their case was they got a column with no values in 
> it.
> 
> When we went to Edit->Preferences->Appearance->Columns the column had
> been defined but the type was not Custom and the Fields and Field
> Occurrence values had not been filled in.
> 
> When he manually made them the same as what I have, it all worked.
> 
> I just tried deleting that definition on my 3.2.1 installation and
> then re-adding it all worked correctly.
> 
> My colleague is using a Mac. Not sure if this is relevant.
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-users] Proposed changes to make tcp.ack and tcp.seq relative

[Sake Blok | SYN-bit]

> On 4 May 2020 (Mon), at 22:50, Peter Wu  wrote:
> 
> My proposed change:
> 
> - Change the TCP sequence number-related fields to display the relative
>   numbers when available. Fallback to raw numbers if they are simply
>   not available (for example, when the "Analyze TCP sequence numbers"
>   preference is disabled).
> - Modify the "Relative sequence numbers" preference to affect the
>   displayed value in the Info column only.
> - The raw fields will always be available through the existing
>   tcp.ack_abs and tcp.seq_abs fields. Previously they were only visible
>   when "Relative sequence numbers" was disabled. This field was added
>   in Wireshark 3.2.
> - Document these changes clearly in the release notes and corresponding
>   user guides if needed.
> 
> Are there any objections to this change?

Nope, they sound good to me and will make things more consistent (with the 
small correction that the fields are *_raw instead of *_abs).

A few additions:

- "tcp.nxtseq" will need to have a "tcp.nxtseq_raw" added
- "tcp.options.sack_le" and "tcp.options.sack_re" will also need *_raw versions

Cheers,
Sake

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted

[Sake Blok | SYN-bit]

> On 19 Jun 2019 (Wed), at 14:11, Graham Bloice  
> wrote:
> 
> On Fri, 14 Jun 2019 at 21:27, Roland Knall  > wrote:
> Hi
> 
> There is a patch currently waiting for inclusion. It would allow for 
> dissectors to easily make credentials (username/password) available and 
> present them in a tool window in Wireshark.
> 
> The main concern here is, that this could lead companies, evaluating 
> Wireshark to be used within  the company, to deny the use of the program, due 
> to wrongly identifying Wireshark as a hacking tool.
> 
> 
> I also haven't reviewed the proposed change but in general my view is that 
> it's Wireshark's job to present the information in the capture files in a 
> manner that's useful to the users.  Credentials are one element of this 
> information, and to me, is like any other "object", so I think that adding 
> the dialog that summarizes them is perfectly OK.
> 
> If this causes some companies to "ban" Wireshark, then so be it.  That won't 
> hide the credentials travelling on their networks.
> 
> For more aware companies, they would be able to instruct users to check the 
> "credentials" dialog before sharing the capture to minimise a compromise.

This is a tricky one, as these are just *some* of the credentials in the trace 
file. So if people start using it as a way to verify if there are *no* 
passwords in the trace file they could miss other passwords. I have not looked 
at the proposed change in detail, but I thin it should come with a warning that 
the list of credentials is not a complete list.

Cheers,
Sake

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted

[Sake Blok | SYN-bit]

> On 19 Jun 2019 (Wed), at 14:00, Dario Lombardo  wrote:
> On Mon, Jun 17, 2019 at 1:42 PM Sake Blok | SYN-bit  <mailto:sake.b...@syn-bit.nl>> wrote:
> Hi Dario,
> To me for troubleshooting issues, it is sufficient to see the usernames and 
> sometimes extract a password, but I do not need a list of them
> For security awareness, you do not need the passwords, just the protocol and 
> username and the fact that the password is available in the pcap file
> For hacking you would want to have the full list, but then I would prefer 
> people to use other available tools to keep Wireshark on the friendly side of 
> the line.
> 
> 
> Hi Sake
> I am partially convinced by what you said. Partially because I'm not totally 
> convinced, but I think also that "for troubleshooting it is sufficient to see 
> the usernames" actually _IS_ a point.
> A solution that could kill 2 pigeons with a stone could be to leave the 
> passwords behind, but add a shortcut to "go to the packet" where you can find 
> the actual password. That will raise the credentials to the attention of the 
> analyst, but would require a step, that is pretty similar to the regular 
> wireshark use, to obtain the single password.
> The good part is that adding or removing the presence of the password is very 
> easy, so adding them back, in case we will want them, will not require too 
> much work.
> Would it work?

Sounds like a good compromise to me!

Sake

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building master on Ubuntu 16.04 fails

[Sake Blok | SYN-bit]

> On 17 Jun 2019 (Mon), at 15:06, Anders Broman  
> wrote:
> 
> Hi,
> Building a local relativly new version I get:
> (dpkg-buildpackage -rfakeroot -us -uc )
>  
> ui/qt/simple_dialog.cpp: In member function ‘void SimpleDialog::show()’:
> /ui/qt/simple_dialog.cpp:414:13: error: ‘bind’ is not a member of ‘std’
>  
> std::bind(visible_message_finished,message_box_,std::placeholders::_1));
>  ^
> ui/qt/simple_dialog.cpp:414:66: error: ‘std::placeholders’ has not been 
> declared
>  
> std::bind(visible_message_finished,message_box_,std::placeholders::_1));
>  
> googling 
> https://stackoverflow.com/questions/14261013/bind-is-not-a-member-of-std 
> 
> it looks like flag -std=c++11 is needed. How to add this in CMakeList ?

I ran into the same problem with the development setup that vagrant creates. I 
changed to Ubuntu 18.04 and that solved the issue. From what I have looked at, 
the newer GCC version in Ubuntu 18.04 solved the issue.

Also solving this in Ubuntu 16.04 would be nice though...

Cheers,
Sake

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted

[Sake Blok | SYN-bit]

Hi Dario,

> On 17 Jun 2019 (Mon), at 11:23, Dario Lombardo  wrote:
> 
> Hi Sake
> 
> On Mon, Jun 17, 2019 at 7:01 AM Sake Blok | SYN-bit  <mailto:sake.b...@syn-bit.nl>> wrote:
> Personally I don't like the option to have a central place to add credential 
> information to show to the user. I think this crosses the (very thin) line 
> between "being able to see a password" and "being a tool to extract 
> passwords".
> 
> 
> Personally this is what I like of it :). But indeed this is a discussion 
> about lines crossed, so anybody's opinion and previous experience is welcome. 
> The line between see and extract sounds to me like the Richard's picture of 
> orchids. Wireshark can already extract the credentials: they are dissected 
> and put under the proper proto item with names like "auth", "credential", 
> "password", etc. This is rather different that "follow tcp stream" of an 
> undissected protocol, that contains credentials. The patch doesn't give more 
> "power" to the user: just instead of scripting tshark or jumping between 
> packets it makes easier reading them through a dialog. IMHO Wireshark is 
> already a tool to extract passwords.

I understand your point of view. However, needing a little more knowledge to 
extract passwords than just clicking on the "show me all credentials" is a good 
thing IMHO. If this feature is used to raise security awareness, then having a 
list of usernames with  passwords to show for which users passwords are 
present in the pcap file is enough, no need to show the passwords themselves. 
If an individual password is needed, it can easily be obtained by going to the 
packet that has the password without showing all passwords in a list. 

To me for troubleshooting issues, it is sufficient to see the usernames and 
sometimes extract a password, but I do not need a list of them
For security awareness, you do not need the passwords, just the protocol and 
username and the fact that the password is available in the pcap file
For hacking you would want to have the full list, but then I would prefer 
people to use other available tools to keep Wireshark on the friendly side of 
the line.

What use-case do you see for a list of all passwords (where a list of just the 
usernames is not enough)?

> Just my €0,02
> 
> Taken ;).

Make sure to collect them at a next Sharkfest ;-)

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Proper way to handle changes in the preferences

[Sake Blok | SYN-bit]

Hi,

I'm working on a patch to add the possibility to show times in milli- or 
microsecond units. While working this out, I see a need to change the name of 
certain preferences and/or change the values of other preferences. This will 
however break compatibility with older versions of Wireshark in reading/writing 
the preferences (in my case, settings in the "recent" file).

Is there a way to add backwards compatibility in preference items by converting 
old preference settings into new ones?
And is there a way to add code to the current versions to do the reverse for 
forward compatibility, so at least future minor versions of old major versions 
will be able to handle this correctly?

Things that I might want to change are:

# Timestamp display precision.
# One of: AUTO, SEC, DSEC, CSEC, MSEC, USEC, NSEC
gui.time_precision: MSEC

to:

# Timestamp display precision.
# One of: AUTO, 0DECIMALS, 1DECIMAL, 2DECIMALS, 3DECIMALS, 6DECIMALS, 9DECIMALS
gui.time_precision: AUTO

and

# Seconds display format.
# One of: SECONDS, HOUR_MIN_SEC
gui.seconds_format: SECONDS

to

# Seconds display format.
# One of: SECONDS, MILLISECONDS, MICROSECONDS, HOUR_MIN_SEC
gui.time_units: SECONDS

Are there some guidelines available in handling preferences between wireshark 
versions?

Cheers,
Met vriendelijke groet,


Sake Blok
Relational therapist for computer systems

+31 (0)6 2181 4696
sake.b...@syn-bit.nl

SYN-bit
Deep Traffic Analysis
http://www.SYN-bit.nl

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted

[Sake Blok | SYN-bit]

> On 14 Jun 2019 (Fri), at 22:25, Roland Knall  wrote:
> 
> There is a patch currently waiting for inclusion. It would allow for 
> dissectors to easily make credentials (username/password) available and 
> present them in a tool window in Wireshark.
> The main concern here is, that this could lead companies, evaluating 
> Wireshark to be used within  the company, to deny the use of the program, due 
> to wrongly identifying Wireshark as a hacking tool.

Personally I don't like the option to have a central place to add credential 
information to show to the user. I think this crosses the (very thin) line 
between "being able to see a password" and "being a tool to extract passwords".

Other tools for extracting passwords from pcap files do exist already (just two 
results from a quick google search):

- https://n0where.net/extract-data-from-pcap-files-pcredz 

- https://github.com/DanMcInerney/net-creds 


So personally I do not see a use-case where there is added value to add this to 
Wireshark.

Just my €0,02


Sake


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark hosts file location

[Sake Blok | SYN-bit]

> On 21 Mar 2019 (Thu), at 10:16, Jasper Bongertz  wrote:
> I just saw this: https://ask.wireshark.org/question/8014/hosts-file-manager/
> 
> My first impulse was "put the hosts in a profile directory and switch it via 
> profiles", but when I tested that it didn't work (no names resolved). I'm not 
> sure if the hosts file is even read when it's in a profile directory, or 
> where exactly Wireshark expects a hosts file. Do you know if that's supposed 
> to work?

Strange, in Wireshark -2.6.7 on my Mac, I do get resolved names from the 
"hosts" file in my configuration profile (after turning on Network layer name 
resolution). Which is how I expect it to work, just like you :-)

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Allowing display filters during capture

[Sake Blok]

On 13 mrt 2015, at 19:09, Guy Harris wrote:
 
 On Mar 13, 2015, at 7:22 AM, Jeff Morriss jeff.morriss...@gmail.com wrote:
 
 That will work for your purpose.  The reason the check is there, however, is 
 that most people seem to expect that applying the display filter would 
 affect what messages are sent to the output file (udp_all.pcap).  (They may 
 have that expectation because that's what would have happened in much older 
 versions of Wireshark/Ethereal--before the existence of dumpcap.)
 
 That was a long time ago; might it be possible now to realign those people's 
 expectations to match what would be, and *should* be, reality?  (One might 
 perfectly rationally want to do a capture of, say, all traffic between two 
 given hosts and, while the capture is running, first look at the NFS traffic 
 between them, and then at the HTTP traffic between them, and then go back to 
 looking at all traffic between them, i.e. it makes perfect sense to allow the 
 display of a live capture to be temporarily filtered without actually 
 filtering set of *captured* traffic.)

I guess a warning that the filtering with -Y won't affect which packets are 
saved, and that -f would have to be used for that purpose, would suffice. This 
warning can even be suppressed when there is a combination of -Y and -f filters.


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Conference room before FOSDEM

[Sake Blok]

On 21 jan 2012, at 11:53, Martin Kaiser wrote:

 Hi Gerald,
 
 Thus wrote Gerald Combs (ger...@wireshark.org):
 
 Can any developer who is attending FOSDEM *and* would like to meet at
 the hotel on Friday the 3rd send me an email? I'm working on booking a
 conference room for the day and need to size the room accordingly.
 
 you can count me in, I'll be there on the 3rd.

+1 for me :-)


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Dates for FOSDEM 2012: 4 5 February

[Sake Blok]

On 16 jan 2012, at 14:22, Joerg Mayer wrote:

 On Sat, Jan 14, 2012 at 05:43:22PM +0100, Martin Kaiser wrote:
 Thus wrote Gerald Combs (ger...@wireshark.org):
 
 Are plans to meet around FOSDEM finalized? For me it would be possible to 
 meet up during the day on Friday 3rd (after which we could join the FOSDEM 
 Beer Event :-)). I could either drive up early on Friday or come Thursday 
 in the afternoon. If we plan something like that, I think it would be best 
 to stay in the same hotel with all who are coming. 
 
 I'm still finalizing my travel arrangements but I was planning on being
 in Brussels from the 2nd or 3rd to the 5th.
 
 I've just booked my flights, I'll be in Brussels from the 2nd to the
 5th. 3rd as proposed by Sake would be ideal for me.
 
 OK, I'd like to do the hotel booking soon.
 a) which hotel is recommended

Gerald, I think we will all follow you in your choice of hotel, have you picked 
one yet? I think we should start making reservations to make sure we can all 
stay in the same hotel.

 b) when and where do we meet on Friday?
 I'm trying to decide whether to go on Thursday or Friday and how - it's about 
 a
 4 hour ride by car from Kaiserslautern or a 5.5 hour trip by train.

I think I will arrive on Thursday the 2nd as wel, so that we have all Friday to 
meet up. I'm driving from Amsterdam and it looks like I might be picking Graham 
up from Schiphol.

 Staying until Sunday looks good right now.

Yep, that sounds like a plan too :-)

Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Fwd: [FOSDEM] Dates for FOSDEM 2012: 4 5 February

[Sake Blok]

On 29 dec 2011, at 21:00, Martin Kaiser wrote:

 Hello Gerald and all,
 
 Thus wrote Gerald Combs (ger...@wireshark.org):
 
 Sorry for taking so long to get back to you on this. We don't have a
 devroom, but we might be able to find a spot in one of the existing
 rooms. Alternatively I might be able to reserve a conference room at a
 nearby hotel.
 
 I realize it's now short notice, but can anyone interested in meeting
 at FOSDEM send an email to -dev or to me directly with the dates you can
 attend? The main event is February 4 and 5 in Brussels, but we could
 also meet on the 3rd or 6th if that's more convenient.
 http://fosdem.org/2012/
 
 I'm still interested in meeting at or around Fosdem. Any of 3rd-6th
 would be ok. When we fix a date, I can organize my trip.
 
 I'll try to prepare some questions and ideas before the meeting.

Gerald,

Are plans to meet around FOSDEM finalized? For me it would be possible to meet 
up during the day on Friday 3rd (after which we could join the FOSDEM Beer 
Event :-)). I could either drive up early on Friday or come Thursday in the 
afternoon. If we plan something like that, I think it would be best to stay in 
the same hotel with all who are coming. 

So far I have the following attendee list, should we actively try to get more 
European developers interested?

Gerald Combs
Martin Kaiser
Graham Bloice
Martin Mathieson
Joerg Mayer
Sake Blok

Should I block my agenda for this?

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Fwd: [FOSDEM] Dates for FOSDEM 2012: 4 5 February

[Sake Blok]

On 6 jan 2012, at 02:19, Gerald Combs wrote:

 On 1/5/12 5:17 PM, Gerald Combs wrote:
 On 1/5/12 3:19 AM, Sake Blok wrote:
 Gerald,
 
 Are plans to meet around FOSDEM finalized? For me it would be possible to 
 meet up during the day on Friday 3rd (after which we could join the FOSDEM 
 Beer Event :-)). I could either drive up early on Friday or come Thursday 
 in the afternoon. If we plan something like that, I think it would be best 
 to stay in the same hotel with all who are coming. 
 
 I'm still finalizing my travel arrangements but I was planning on being
 in Brussels from the 2nd or 3rd to the 5th.
 
 BTW, does anyone have a preferred hotel?

Well, not preferred, but I stayed in Hotel Beau Site 
(http://www.beausitebrussels.com/home.htm) before and quite liked it.

It seems to be nicely in between the FOSDEM venue:

http://maps.google.com/maps?saddr=Rue+de+la+Longue+Haie+76,+1000+City+of+Brussels,+Belgium+(BEAU+SITE)daddr=Avenue+Paul+H%C3%A9ger,+Bruxelles,+Belgiquehl=enie=UTF8sll=50.82112,4.37207sspn=0.020144,0.033731geocode=FZOaBwMdMZZCACHAbP1_1k8hYg%3BFedXBwMdvtpCACnnmwFW3MTDRzFbLHXyZ_TC4Avpsrc=0dirflg=wmra=lst=mz=15


and the Grote Markt which is the center of town:

http://maps.google.com/maps?saddr=Rue+de+la+Longue+Haie+76,+1000+City+of+Brussels,+Belgium+(BEAU+SITE)daddr=Grote+Markt,+Brussel,+Belgi%C3%ABhl=enie=UTF8ll=50.838386,4.358611spn=0.020136,0.033731sll=50.82112,4.37207sspn=0.020144,0.033731geocode=FZOaBwMdMZZCACHAbP1_1k8hYg%3BFSDbBwMd9GpCACGXhL1NSUEImQvpsrc=0dirflg=wmra=lst=mz=15

... and to the Friday Night beer Event:

http://maps.google.com/maps?saddr=Rue+de+la+Longue+Haie+76,+1000+City+of+Brussels,+Belgium+(BEAU+SITE)daddr=Impasse+de+la+Fid%C3%A9lit%C3%A9,+4A+-+1000+Bruxelleshl=enie=UTF8ll=50.839145,4.358997spn=0.020136,0.033731sll=50.838386,4.358611sspn=0.020136,0.033731geocode=FZOaBwMdMZZCACHAbP1_1k8hYg%3BFaTiBwMdV29CACmpauyigMPDRzHumIetO8Kf_wvpsrc=0dirflg=wmra=lst=mz=15


I don't know it the hotel has a conference room or a room that could function 
as one. Also the site says wifi is available in *selected* rooms.

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 40108: / /trunk/epan/dissectors/: Makefile.common packet-eth.c packet-vssmonitoring.c /trunk/: AUTHORS

[Sake Blok]

On 10 dec 2011, at 07:10, Guy Harris wrote:

 On Dec 6, 2011, at 3:07 PM, s...@wireshark.org wrote:
 
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40108
 
 User: sake
 Date: 2011/12/06 03:07 PM
 
 Log:
 - Make a distinction between ethernet padding and an ethernet trailer
 - ... and make that distinction configurable for capture files that do not 
 have padding in small frames, but do have trailers
 
 How would you have small frames without padding, unless you're capturing 
 packets before they're put onto the wire (e.g., capturing packets being sent 
 by your machine, in which case you're not going to have a trailer added by 
 any monitoring hardware)?

I know F5 makes a dissector for trailing data, where the capturing is done on 
the box. I did check on my virtual F5 box and it does seem to add padding first 
before adding their trailer.  But theoretically it is possible that the 
capturing mechanism of a device is handed a small frame and then adds a 
trailer. I wanted to keep this possibility open as before my change an 
ethernet-trailer-dissector would be handed that data. If we think we can skip 
this and always assume there is padding on small frames, then it is safe to 
skip this preference.


 - Add VSS-Monitoring dissector to show by the TAP inserted time- and 
 portstamps
 
 That dissector won't actually dissect anything if the trailer length is  8 
 and is 0 modulo 3.  However, it does not reject trailers with a length of 0 
 or 4; this keeps frames with an FCS from being handled correctly.  I've 
 checked in a changed to reject packets with a length  8 and that's 0 mod 3.
 
 I've also checked in a changed to packet-eth.c not to even try calling *any* 
 of the heuristic trailer dissectors if the real trailer length is 0.
 
 These changes fix the dissection of some captures

Thanks!


 If the FCS is known to be present (fcs_len = 4), we should probably make sure 
 the FCS is *not* part of the tvbuff we hand to the heuristic trailer 
 dissectors; we definitely should make sure it's dissected as an FCS.

I agree, checked in SVN 40146


 If it's not known to be present, and the real trailer is exactly 4 bytes 
 long, is there any way to determine whether it's a trailer or an FCS?  Short 
 of the 4-byte trailer failing all the heuristics, that's about it.
 
 We also currently have no way for the trailer dissector to say OK, there's a 
 trailer, followed by an FCS.

At first I thought that dissector_try_heuristic() would return the amount of 
bytes that were handled by the trailer-dissector. That would make it possible 
to check whether there are still 4 bytes left and assume those must be the FCS. 
But it returns true of false only.

Cheers,
Sake



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] N in 1 packets

[Sake Blok]

On 10 dec 2011, at 00:11, Akos Vandra wrote:

 The target want to send these packet, in timely order:
 
 Exception 15 occured - 5 bytes
 Exception 3 occured - 5 bytes
 Memory address written - 6 bytes
 Exception 3 handling done - 5 bytes
 Exception 15 handling done - 5 bytes
 All exceptions handled, returning to user application - 3 bytes.
 
 On the wire I can see two 16-byte frames. The first one contains the
 first 3 interesting packets, the second one the last 3.
 
 My question is this:
 
 Should the pcap code doing the packet capturing present the incoming
 datastream as two 16-byte frames, or split the dissection of the
 packets, and the libpcap code - upon receipt of a 16-byte frame -
 dissect the frame, and present the 3 packets as different packets to
 wireshark?

The task of libpcap is to capture frames and hand each frame to wireshark, no 
dissection is done by libpcap, that is wiresharks job.
 
 Is it possible for a wireshark dissector to say hey, this packet
 isn't really a packet, actually there are 3 packets here!

Yes, this is how wireshark works if you implement your dissector to do that. 
Many dissectors work like that. For example, visit an https site and capture 
the traffic. You will most probably see multiple SSL records and/or multiple 
HandShake messages in one frame (sometimes after reassembly if a PDU was split 
across two or more packets).

 For this project to be useful I need to present the packets in the
 wireshark window as seen above. Seeing 2 packets, and then seeing the
 inner packets in the subtree is not a good idea.

You're out of luck here with the combination libpcap / wireshark. You will need 
to make substantial changes to either one of them to make that possible. 

 Also, sometimes these
 sub-packets are not within a single 16-byte frame, sometimes they
 are split, if the remaining space in the 16-byte frame is too small
 for the packet to fit.

This is possible, as can be seen in the SSL example I mentioned earlier. There 
are two ways of doing this in wireshark. More details on reassembly can be 
found in README.developer (in the source tree).

Cheers,
Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Managing pcapng files

[Sake Blok]

Hi all,

When I use my version(s) of tshark, I have a problem using tshark to save 
pcapng files back to file:

sake@macsake-wifi:~$ capinfos -t in.cap 
File name:   in.cap
File type:   Wireshark - pcapng
Packet size limit:   inferred: 96 bytes
sake@macsake-wifi:~$ tshark -r in.cap -w out.cap -R arp
dlsym(0x7fff5fc43ed0, py_create_dissector_handle): symbol not found
tshark: The capture file being read can't be written as a libpcap file.
sake@macsake-wifi:~$ tshark -F pcapng -r in.cap -w out.cap -R arp
dlsym(0x7fff5fc43ed0, py_create_dissector_handle): symbol not found
tshark: The capture file being read can't be written as a pcapng file.
sake@macsake-wifi:~$ tshark -v
dlsym(0x7fff5fc43ed0, py_create_dissector_handle): symbol not found
TShark 1.7.1 (SVN Rev 40111 from /trunk)

Copyright 1998-2011 Gerald Combs ger...@wireshark.org 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.28.8, with libpcap 1.1.1, with libz 1.2.5, without
POSIX capabilities, without SMI, with c-ares 1.7.4, without Lua, with Python
2.7.2, with GnuTLS 2.8.6, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP.

Running on Mac OS 10.6.8 (Darwin 10.8.0), with locale nl_NL.UTF-8, with libpcap
version 1.1.1, with libz 1.2.5.

Built using gcc 4.2.1 (Apple Inc. build 5666) (dot 3).
sake@macsake-wifi:~$


Trying with version 1.6.1 also does not work:

sake@macsake-wifi:~$ 
/Applications/Wireshark-other/Wireshark-1.6.1.app/Contents/Resources/bin/tshark 
-r in.cap -w out.cap -F pcapng -R arp
tshark: The capture file being read can't be written in that format.
sake@macsake-wifi:~$ 
/Applications/Wireshark-other/Wireshark-1.6.1.app/Contents/Resources/bin/tshark 
-v
TShark 1.6.1 (SVN Rev Unknown from unknown)

Copyright 1998-2011 Gerald Combs ger...@wireshark.org 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.28.8, with libpcap 1.1.1, with libz 1.2.5, without
POSIX capabilities, without libpcre, without SMI, with c-ares 1.7.4, without
Lua, without Python, with GnuTLS 2.8.6, with Gcrypt 1.5.0, with MIT Kerberos,
with GeoIP.

Running on Mac OS 10.6.8 (Darwin 10.8.0), with libpcap version 1.1.1, with libz
1.2.5.

Built using gcc 4.2.1 (Apple Inc. build 5666) (dot 3).
sake@macsake-wifi:~$

Is it just me and my version(s) of tshark or is this a general problem at the 
moment with handling pcapng files?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Managing pcapng files

[Sake Blok]

On 7 dec 2011, at 18:04, Jose Pedro Oliveira wrote:

 On 2011-12-07 16:06, Sake Blok wrote:
 Is it just me and my version(s) of tshark or is this a general problem at 
 the moment with handling pcapng files?
 
 The problem appears to be on your side. No problem on this
 side with wireshark-1.7.1-SVN-40068 on a Mac OS X 10.6.8:

Thank you for clearing that up and providing your version info, I'll dive in my 
version then...

Cheers,
Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 38038: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-icmp.c

[Sake Blok]

On 15 jul 2011, at 04:39, cmayn...@wireshark.org wrote:

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=38038
 
 User: cmaynard
 Date: 2011/07/14 07:39 PM
 
 Log:
 Be sure there's enough bytes in the ICMP payload before trying to access it in
 order to try to determine if it contains a timestamp.

Ah... Thanks for that :-)


 Added some FIXME notes.

Fixed the endianness FIXME part in SVN 38041 :-)


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 38028: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-icmp.c

[Sake Blok]

On 15 jul 2011, at 02:34, Maynard, Chris wrote:

 Log:
 If the first 8 bytes of the icmp echo/echo-reply data look like a
 timestamp, dissect it as a timestmap and calculate the time since the icmp
 packet was created.
 
 
 Sake, now that you've dug into timestamps for ICMP echo/echo-reply data, 
 maybe you might have some thoughts about how to improve the last patch I 
 submitted to bug 5770 
 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5770)?  I'm sure the 
 patch will no longer apply cleanly now, but hopefully you can get a feel for 
 what I was trying to do.  If you really want, I can resubmit a patch that 
 will apply cleanly to the trunk.

Nice idea, but that won't really work well, see my response in the bug-report...

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 37859: /trunk/ /trunk/gtk/: color_dlg.c /trunk/: color_filters.c color_filters.h

[Sake Blok]

On 4 jul 2011, at 21:09, Stig Bjørlykke wrote:

 On Mon, Jul 4, 2011 at 5:49 PM, Sake Blok s...@euronet.nl wrote:
 Where do you need that info, in the frame section of the packet details we 
 list the following:
 
 Coloring Rule Name: ___tmp_color_filter___01
 
 If a user wants to know which coloring rule is used for a selected
 package, the Coloring Rule Name is the one to look at.
 I think that tmp_color_filter don't tell the user which coloring
 rule is used (the user may not know that tmp is used for
 conversation or filter coloring rules), or which function that created
 this rule.  That's why I want a more descriptive name here :)

As these color filters are only active during one Wireshark session, I would 
have assumed a user would know he created a colorfilter from a conversation or 
field and that the filterstring right under the filter name would be 
descriptive enough. But maybe that's just me...

If you really look for a new name, how about ___session_color_filter___XX?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 reach www.wireshark.org

[Sake Blok]

On 7 jul 2011, at 00:41, Tony Trinh wrote:

 I also occasionally get connection problems to ask.wireshark.org (and I 
 recall it happening before the 30th). Sometimes, the connection is painfully 
 slow, where I'm waiting more than a minute for the main page to even open. I 
 don't think this intermittent lag is related to my connection because I've 
 experienced it from home and from work.

The hostname ask.wireshark.org has had a  record a while longer (I think 
even from the beginning when it was set up). If your browser favors IPv6 over 
IPv4 (which most browsers do by default AFAIK), they will try to get to a site 
over IPv6 before trying IPv4. Which in turn means that if you have IPv6 
enabled, but don't have IPv6 access to the Internet (either native or tunneled 
over IPv4), then you will see these delays. 

[You might want to use Wireshark to look at this problem ;-)]

Disabling the IPv6 protocol on your PC if you don't have IPv6 access to the 
Internet might speed up things again!

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 reach www.wireshark.org

[Sake Blok]

On 7 jul 2011, at 01:48, Tony Trinh wrote:

 That's an interesting theory. My browser (Firefox) indeed has IPv6 enabled by 
 default while my network is IPv4 only. If that's really the problem, why 
 doesn't the awful delay *always* occur for any site I go to?

Most sites still don't have  records , only A records :-)

Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 37859: /trunk/ /trunk/gtk/: color_dlg.c /trunk/: color_filters.c color_filters.h

[Sake Blok]

On 1 jul 2011, at 23:13, s...@wireshark.org wrote:

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=37859
 
 User: stig
 Date: 2011/07/01 02:13 PM
 
 Log:
 Renamed ___tmp_color_filter___ to ___conversation_color_filter___
 in the coloring rule name to better describe where it comes from.

Conversation coloring is just one of the sources of these temporary coloring 
filters. Rightclicking on any field can also create a temporary coloring rule. 
IMHO it is the fact that these coloring rules don't get saved to the 
colorfilters file that makes them distinctive :-)

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 37859: /trunk/ /trunk/gtk/: color_dlg.c /trunk/: color_filters.c color_filters.h

[Sake Blok]

On 4 jul 2011, at 17:22, Stig Bjørlykke wrote:

 2011/7/4 Sake Blok s...@euronet.nl:
 Conversation coloring is just one of the sources of these temporary coloring 
 filters. Rightclicking on any field can also create a temporary coloring 
 rule. IMHO it is the fact that these coloring rules don't get saved to the 
 colorfilters file that makes them distinctive :-)
 
 Hmm, ok.  Maybe I should find a smarter name then.  I think it should
 be possible to see why the packet i colorized, and tmp does not tell
 me anything :)

Where do you need that info, in the frame section of the packet details we list 
the following:

Coloring Rule Name: ___tmp_color_filter___01
Coloring Rule String: (ip.addr eq 192.168.0.104 and ip.addr eq 208.117.232.170) 
and (tcp.port eq 50388 and tcp.port eq 80)

Or (when using a field to create the temporary coloring filter):

Coloring Rule Name: ___tmp_color_filter___01
Coloring Rule String: ip.id == 0x59fe

(I do see a little problem that this information is not updated for the current 
packet after doing the coloring, you need to select another packet first and 
them come back to the original one at the moment)

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 37859: /trunk/ /trunk/gtk/: color_dlg.c /trunk/: color_filters.c color_filters.h

[Sake Blok]

On 4 jul 2011, at 17:57, Guy Harris wrote:

 
 On Jul 4, 2011, at 8:49 AM, Sake Blok wrote:
 
 Where do you need that info, in the frame section of the packet details we 
 list the following:
 
 Coloring Rule Name: ___tmp_color_filter___01
 Coloring Rule String: (ip.addr eq 192.168.0.104 and ip.addr eq 
 208.117.232.170) and (tcp.port eq 50388 and tcp.port eq 80)
 
 If the rule isn't saved in the colorfilters file, does the rule's name serve 
 any purpose other than to identify the rule in places such as the Frame 
 section of the packet details?  

The rule is saved in the list of colorfilters in memory, but based on the 
filter-name-prefix it is not saved to the colorfilters file. The name of the 
temporary coloring rule is used to overwrite the filter with a new filter if 
another conversation/field is chosen for the particular temporary color. That's 
why it has a fixed name prefix and a trailing index number. The fixed name is 
also used when clearing the temporary coloring rules (CTRL+SPACE).

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] IPv6 longest representation vs INET6_ADDRSTRLEN

[Sake Blok]

On 5 mei 2011, at 19:41, Gerald Combs wrote:
 On 5/5/11 6:01 AM, Jakub Zawadzki wrote:
 On Thu, May 05, 2011 at 02:01:06PM +0200, Jakub Zawadzki wrote:
 IMHO when IPv4-mapping is used the longest address is:
 :::255.255.255.255 (22B)
 
 Anyone knows inet_ntop(AF_INET6, ..) implementation which can actually use 
 46 bytes?
 
 Maybe some inet_ntop() implementation don't generate short addresses? ( 
 instead of ::)
 so ipv4 mapped address would be: 
 ::::::255.255.255.255
 
 I think I'll just copy inet_ntop6() from wsutil/inet_ntop.c to 
 address_to_str.c...
 
 RFC 2553 section 6.6 and MSDN's InetNtop documentation both specify 46
 characters, but you'd think that if an implementation was smart enough
 to check for v4-mapped addresses it would be smart enough to compress
 zeroes.

There is also the IPv6 mixed notation (or Trailing dotted decimal notation 
as Microsoft calls it) which displays the last 32 bits of a (general) IPv6 
address in dotted decimal. This could indeed lead to 45 byte strings:

IE   2001:db8:1234:5678:9abc:def0:192.168.123.234

(OK, this is 44 bytes, but I wanted to stick to the 2001:db8::/32 example 
prefix)

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Handling TCP packets reordering

[Sake Blok]

On 4 mei 2011, at 22:11, Jeff Morriss wrote:

 Max Dmitrichenko wrote:
 Hi!
 I'm continue to write dissector for an encrypted protocol. Everything
 works fine until I receive an out-of-order TCP segment, i.e. previous
 was lost.
 Since I'm trying to decrypt it, I fail with it and break the whole
 decryption context. Is there any way to:
 1) Detect that this packet is out of order in given conversation?
 2) Ask the TCP dissector to feed this packet later again when all
 previous segments will be retransmitted?
 
 I would think desegment_tcp() should be able to handle this by not calling 
 your dissector for an out-of-order segment: it should be able to only call 
 your dissector once it has a completely reassembled (desegmented) PDU.  
 Looking through the code, it's not immediately obvious to me what the problem 
 is.

One case that can cause a problem is when the first segment of a PDU is 
received out-of-order. Or did your recent work also handle this exception, Jeff?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Handling TCP packets reordering

[Sake Blok]

On 4 mei 2011, at 22:48, Jeff Morriss wrote:
 Sake Blok wrote:
 On 4 mei 2011, at 22:11, Jeff Morriss wrote:
 Max Dmitrichenko wrote:
 Hi!
 I'm continue to write dissector for an encrypted protocol. Everything
 works fine until I receive an out-of-order TCP segment, i.e. previous
 was lost.
 Since I'm trying to decrypt it, I fail with it and break the whole
 decryption context. Is there any way to:
 1) Detect that this packet is out of order in given conversation?
 2) Ask the TCP dissector to feed this packet later again when all
 previous segments will be retransmitted?
 I would think desegment_tcp() should be able to handle this by not calling 
 your dissector for an out-of-order segment: it should be able to only call 
 your dissector once it has a completely reassembled (desegmented) PDU.  
 Looking through the code, it's not immediately obvious to me what the 
 problem is.
 One case that can cause a problem is when the first segment of a PDU is 
 received out-of-order. Or did your recent work also handle this exception, 
 Jeff?
 
 Yep, that's the case rev 36304 fixed.

Unfortunately not, I just constructed a file in which the first segment of the 
HTTP-response PDU comes after the second segment of that PDU. And dissection 
still fails as there is not yet a segment in tcpd-fwd-multisegment_pdus for 
that seq. 

This could be fixed by adding a segment that comes after a gap to the 
multisegment list by default, but that would break dissection of single segment 
PDU's that come out-of-order. I don't know of a good way to solve this dilemma.

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Handling TCP packets reordering

[Sake Blok]

On 4 mei 2011, at 23:33, Jeff Morriss wrote:

 Sake Blok wrote:
 On 4 mei 2011, at 22:48, Jeff Morriss wrote:
 Sake Blok wrote:
 One case that can cause a problem is when the first segment of a PDU is 
 received out-of-order. Or did your recent work also handle this exception, 
 Jeff?
 Yep, that's the case rev 36304 fixed.
 Unfortunately not, I just constructed a file in which the first segment of 
 the HTTP-response PDU comes after the second segment of that PDU. And 
 dissection still fails as there is not yet a segment in 
 tcpd-fwd-multisegment_pdus for that seq. 
 
 Doh! You're right.  In fact what I fixed was when you actually *see* the 
 first packet more than once.

I remembered a bug report on this (but could not find it earlier tonight): 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4727
And here is my fabricated file as well...

Sake


first-segment-ooo.cap
Description: Binary data
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] HTTP header truncated

[Sake Blok]

On 16 apr 2011, at 09:40, Anders Broman wrote:
 First time I saw it - [Truncated] i found it a bit ambiguous perhaps it 
 should say
 [Display Truncated] even if that's a bit longish.

Or we should put the [truncated] at the end instead of the beginning? Than it 
is also not to bad to make it longer, so we could even make it [truncated to 
240 bytes].

Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] HTTP header truncated

[Sake Blok]

On 14 apr 2011, at 22:46, Chris Maynard wrote:

 Alexander Koeppe format_c@... writes:
 
 If I click on the field, the complete data is being selected in the
 bytes view. But in the detail view (where I clicked on) the word
 [truncated] is prepended.
 
 Question: Can I increase that limit over the GUI or ony withing the
 source code?
 I already had a look but didn't found the position where this truncation
 is being performed.
 
 So would be great if you guys could give me a short hint.
 
 The limitation is imposed by ITEM_LABEL_LENGTH, currently defined in
 epan/proto.h as 240.  
 
 
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] HTTP header truncated

[Sake Blok]

On 14 apr 2011, at 22:46, Chris Maynard wrote:

 Alexander Koeppe format_c@... writes:
 
 If I click on the field, the complete data is being selected in the
 bytes view. But in the detail view (where I clicked on) the word
 [truncated] is prepended.
 
 Question: Can I increase that limit over the GUI or ony withing the
 source code?
 I already had a look but didn't found the position where this truncation
 is being performed.
 
 So would be great if you guys could give me a short hint.
 
 The limitation is imposed by ITEM_LABEL_LENGTH, currently defined in
 epan/proto.h as 240.  

(and now without premature sending)

A workaround without having to recompile Wireshark might be one of these 
options:

- Use follow TCP stream to get the full Authentication header
- Use rightclick - copy - value and then paste in a separate text file

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] HTTP header truncated

[Sake Blok]

On 16 apr 2011, at 02:10, Alexander Koeppe wrote:
 
 But you maybe also know vendor's support people.
 If they see a truncated they even don't believe anything.
 If they see nothing, they believe everything.
 
 I'll go the recompile way and increase the value of ITEM_LABEL_LENGTH
 (thanks to Chris). it's not so costy for me.

If you need to recompile Wireshark to get the Vendor to believe the data in the 
trace file, I think it's about way over time to call their escalation manager 
:-)

Good luck!


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 loopback traffic on Windows

[Sake Blok]

On 24 mrt 2011, at 17:40, Chris Maynard wrote:

 While certainly not as good/easy as capturing loopback traffic on a *NIX
 platform, so far this has been by far the best way for me to obtain loopback
 traffic on Windows.  Maybe others will find this tool useful as well.

That's great, could you update the wiki page on Loopback interfaces an update 
with your findings too?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark -z vs. tshark -z

[Sake Blok]

On 21 mrt 2011, at 20:40, Stephen Fisher wrote:

 On Mon, Mar 21, 2011 at 06:37:03PM +, Chris Maynard wrote:
 
 Any concerns about backward-compatibility?  Are folks accustomed to 
 using rtt with tshark instead of srt?  Should we support either one 
 going forward, or is it OK to abandon rtt?
 
 (without thinking it through very much...) I would say to change it and 
 mention the change in the release notes.

And of course in the Usage, manpage, user manual etc ;-)

(and yes... I think it's a joy to make the occasional superfluous remark ;-))
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Using a tap to make a dissector work?

[Sake Blok]

Hi,

The buildbots are failing on the test.sh script because:

sake@macsake-wifi:~/Wireshark/trunk/test$ ../tshark -r dhcp.pcap -w -  tmp.cap
tshark: Taps aren't supported when saving to a pipe.
sake@macsake-wifi:~/Wireshark/trunk/test$

I tracked this down to 
http://anonsvn.wireshark.org/viewvc?view=revisionrevision=35323 in which the 
tap functionality is used to track mappings that determine how packets should 
be dissected.

This basically makes writing to a pipe in tshark impossible unless the protocol 
would be dissabled. What would be the proper way to go?

1) From a quick view of the code, the tap has been used as the conversation 
tracking wireshark provides does not provide the proper hooks for this kind of 
traffic. Should we change the conversation tracking to a more general 
framework? Or maybe map the indices that are available to the variables that 
are available (if this is at all possible). But then we need to make sure there 
will be no overlapping (which kinda calls for a general framework again).

2) Allow taps to be used in dissectors and remove the check in tshark? Tshark 
does not know whether the tap is producing output or not, so maybe we need to 
have a flag with each tap to state whether it will produce output or not.

3)  Just leave things as they are and disable this protocol by default (as has 
been done to PRP)?

Any ideas?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Using a tap to make a dissector work?

[Sake Blok]

On 8 mrt 2011, at 15:55, Jeff Morriss wrote:

 Sake Blok wrote:
 Hi,
 The buildbots are failing on the test.sh script because:
 sake@macsake-wifi:~/Wireshark/trunk/test$ ../tshark -r dhcp.pcap -w -  
 tmp.cap
 tshark: Taps aren't supported when saving to a pipe.
 sake@macsake-wifi:~/Wireshark/trunk/test$
 I tracked this down to 
 http://anonsvn.wireshark.org/viewvc?view=revisionrevision=35323 in which 
 the tap functionality is used to track mappings that determine how packets 
 should be dissected.
 This basically makes writing to a pipe in tshark impossible unless the 
 protocol would be dissabled. What would be the proper way to go?
 1) From a quick view of the code, the tap has been used as the conversation 
 tracking wireshark provides does not provide the proper hooks for this kind 
 of traffic. Should we change the conversation tracking to a more general 
 framework? Or maybe map the indices that are available to the variables that 
 are available (if this is at all possible). But then we need to make sure 
 there will be no overlapping (which kinda calls for a general framework 
 again).
 2) Allow taps to be used in dissectors and remove the check in tshark? 
 Tshark does not know whether the tap is producing output or not, so maybe we 
 need to have a flag with each tap to state whether it will produce output or 
 not.
 3)  Just leave things as they are and disable this protocol by default (as 
 has been done to PRP)?
 Any ideas?
 
 Just for cross-referencing purposes:
 
 This issue is tracked in 
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5445 .  There, Guy 
 suggested:
 
 The trick might be to have multiple types of taps, such as ones that produce 
 no
 output, and are allowed to be unconditionally run, and ones that produce
 output, which are not allowed to be unconditionally run.  Dissection will be
 forced on in TShark if one of the latter type of taps is listening, but will
 not be forced on if only the former type of taps is listening.
 
 That sounds similar to (2) above.

It does indeed. 

I checked the bug report. As long as it's kept open until there is a solution, 
we can skip the discussion here :-)

In the mean time, should we disable these protocols by default until it has 
been sorted out? It's a shame to have the buildbots unavailable because of this.

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Using a tap to make a dissector work?

[Sake Blok]

On 8 mrt 2011, at 16:53, Jeff Morriss wrote:

 Sake Blok wrote:
 On 8 mrt 2011, at 15:55, Jeff Morriss wrote:
 This issue is tracked in 
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5445 .  There, Guy 
 suggested:
 
 The trick might be to have multiple types of taps, such as ones that 
 produce no
 output, and are allowed to be unconditionally run, and ones that produce
 output, which are not allowed to be unconditionally run.  Dissection will 
 be
 forced on in TShark if one of the latter type of taps is listening, but 
 will
 not be forced on if only the former type of taps is listening.
 That sounds similar to (2) above.
 It does indeed. I checked the bug report. As long as it's kept open until 
 there is a solution, we can skip the discussion here :-)
 
 Well, except that no progress has been made--discussion out here might change 
 that. :-)

True!

 In the mean time, should we disable these protocols by default until it has 
 been sorted out? It's a shame to have the buildbots unavailable because of 
 this.
 
 Except that having the buildbots red might eventually annoy someone enough to 
 fix the underlying problem ;-).  (More seriously: I think test.sh is the last 
 step so they're only missing the other tests in the test suites. Or is 
 something else being missed/lost?)

True again. I thought it also has an effect on the automated builds, but I see 
that the windows bots have a whole different issue... 
@Gerald, what's with the win-bots?

Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] SCCP reassembly broken for duplicateded SCTP messages.

[Sake Blok]

On 3 mrt 2011, at 15:00, Anders Broman wrote:

 SCCP reassembly will add both segments from duplicated packets thus producing 
 garbage in the reassembled packet.
 An easy fix could perhaps bee to add a flag in pinfo duplicate or 
 suspected duplicate and ignore such frames in reassembly, possibly the
 Dissector doing reassembly could have a preference wether to use the flag or 
 not - thoughts?
  
 There is a similar bug in the TCP reassembly causing it to not show the 
 reassembled packet.
 1 0.00 10.80.79.132 10.62.180.97 TCP [TCP segment of a reassembled PDU]
 2 0.04 10.80.79.132 10.62.180.97 TCP [TCP segment of a reassembled PDU]
 3 0.238283 10.80.79.132 10.62.180.97 TCP [TCP Retransmission] [TCP segment of 
 a reassembled PDU]
 4 0.716280 10.80.79.132 10.62.180.97 TCP [TCP Retransmission] [TCP segment of 
 a reassembled PDU]

SSL reassembly and decryption also does not like duplicates. Instead of solving 
it in each and every upper layer protocol, I think it could be solved by having 
an option to Auto-ignore duplicate packets, preferably referencing the frame 
of which it is a duplicate in the INFO column.

How does that sound?

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark filter list

[Sake Blok]

On 1 mrt 2011, at 23:52, Gilsinn, James D. wrote:

 I’m trying to find out if there’s a file somewhere that lists all of the 
 available Wireshark filters?  I’m developing an application that uses TShark 
 to filter capture files based on certain criteria and returns with PSML files 
 that can be read and used for additional analysis.  Since I’m using TShark in 
 a hands-off approach on Windows, I’d like to be able to do some syntax 
 checking of the filter before I start the TShark process to make sure that it 
 doesn’t come back with an error simply because someone typed “fraem” instead 
 of “frame”.  Is there a list of all the protocol filters available for use?
  
 I’ve found the “wireshark-filter.html” file which lists all the protocols, 
 but that would require some pretty complicated processing to parse the HTML.  
 What I’d like to see is a text or XML file that lists all of the 
 capture/display filters in one file by themselves.  XML would probably be 
 easier to parse, since some additional fields could be added without really 
 affecting the ease of importing the data.

You can use tshark -G for this purpose:

sake@MacSake:~$ tshark -G fields | cut -f 3 | head
ieee1722
ieee1722.cdfield
ieee1722.subtype
ieee1722.svfield
ieee1722.verfield
ieee1722.mrfield
ieee1722.gvfield
ieee1722.tvfield
ieee1722.seqnum
ieee1722.tufield
sake@MacSake:~$ 

Hope this helps,
Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] reassembling tcp streams to dissect netstrings

[Sake Blok]

On 14 feb 2011, at 11:59, Toni Ruottu wrote:

 I am writing a plugin to dissect a TCP stream of netstrings. Examples
 of netstrings would include 5:hello, and 0:, See
 http://cr.yp.to/proto/netstrings.txt for details. Method
 tcp_dissect_pdus takes length of the data as a parameter, which is not
 a problem for the payload part, but how do I reassemble the stream up
 to the first :, so I can read the length information?

That's also done by tcp_dissect_pdus:

(from epan/dissectors/packet-tcp.h)
/*
 * Loop for dissecting PDUs within a TCP stream; assumes that a PDU
 * consists of a fixed-length chunk of data that contains enough information
 * to determine the length of the PDU, followed by rest of the PDU.
 *
 * The first three arguments are the arguments passed to the dissector
 * that calls this routine.
 *
 * proto_desegment is the dissector's flag controlling whether it should
 * desegment PDUs that cross TCP segment boundaries.
 *
 * fixed_len is the length of the fixed-length part of the PDU.
 *
 * get_pdu_len() is a routine called to get the length of the PDU from
 * the fixed-length part of the PDU; it's passed pinfo, tvb and offset.
 *
 * dissect_pdu() is the routine to dissect a PDU.
 */
extern void
tcp_dissect_pdus(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
 gboolean proto_desegment, guint fixed_len,
 guint (*get_pdu_len)(packet_info *, tvbuff_t *, int),
 dissector_t dissect_pdu);

In short, you need to tell tcp_dissect_pdus the minimum amount of bytes that 
are always available and will contain enough information to determine the 
length of a PDU.

In your case the length is in itself of variable length, which makes using 
tcp_dissect_pdus impossible. Unless you can make sure all lengths are noted 
with a fixed length string, like 5:Hello and 0: for PDU's with a 
maximum size of 9. If this is not possible, then you will need to use pinfo 
struct as can be read in paragraph 2.7.2 of doc/README.developer

Hope this helps,
Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Bug 5653 - Display Day of Year for January 1 as 1, not 0

[Sake Blok]

On 7 feb 2011, at 19:46, Guy Harris wrote:

 Unless the NASA guys who contributed the packet-ccsds.c and packet-vcdu.c 
 dissectors would like to argue that, in their dissection, a 0-origin 
 day-of-year works better, in which case we should support both 0-origin and 
 1-origin display formats, I would suggest switching to a 1-origin display 
 format and see whether we get a complaint from any space data people (in 
 which case we should add a separate 0-origin format).

I like the practical trial-and-complaint approach. If we do get a complaint, I 
would suggest a preference for choosing 1-origin or 0-origin instead of 
displaying both.

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Question about tcp window scaling value

[Sake Blok]

On 8 jan 2011, at 15:12, Douglas Wood wrote:

 I have tried the options that you have stated.  It doesn't appear to make
 any difference.  For what it's worth, tshark seems to generate the correct
 values for TCP Window Size.  PDML output is different for tshark than
 Wireshark.

I just updated the code for TCP window scaling (as per bug 5541), could you try 
an automated build from http://www.wireshark.org/download/automated/ (use an 
installer number that is 35425 or higher, available in a couple of hours) to 
see whether this also fixed your output issues?

If it didn't, could you please file a bug report at 
https://bugzilla.wireshark.org. Please provide the capture file, tshark pdml 
output and wireshark pdml output so we can find out why you see a difference.

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] UDP desegmentation - how to?

[Sake Blok]

On 22 dec 2010, at 09:58, Kaul wrote:

 Can I use something like tcp_dissect_pdus() for UDP packets? Specifically, 
 Kerberos over UDP - I think we can get the PDU length from the packet and get 
 a complete PDU.

As the UDP header is missing a sequence number, it is not possible to do UDP 
reassembly at the UDP layer. It needs to be done at a higher layer where the 
order of fragments can be determined.

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] editcap -B

[Sake Blok]

On 12 nov 2010, at 18:08, Stephen Fisher wrote:

 On Fri, Nov 12, 2010 at 03:03:17PM +0100, Sake Blok wrote:
 
 I would expect '-A 2010-11-08 20:00:00 -B 2010-11-09 00:00:00' to 
 mean: All packets with a timestamp starting at 2010-11-08 20:00:00 
 and *before* 2010-11-09 00:00:00.
 
 Does anyone object to me changing (correcting) the current behavior of 
 -B to what I would have expected?
 
 This matches what the help output (editcap -h) explains on the right 
 side, although the term stop time is ambigious:
 
  -A start timedon't output packets whose timestamp is before the
 given time (format as -MM-DD hh:mm:ss).
  -B stop time don't output packets whose timestamp is after the
 given time (format as -MM-DD hh:mm:ss).
 
 Thinking of it as letting Wireshark run while you're watching the time, 
 when you see it reach the stop time, then you would stop the capture 
 part way through that section, depending on your reaction time.  So 
 correcting it as you describe sounds fine to me, just make sure to 
 update the help text.

fixed in SVN 34913

New editcap -h:

  -A start timeonly output packets whose timestamp is after (or equal
 to) the given time (format as -MM-DD hh:mm:ss).
  -B stop time only output packets whose timestamp is before the
 given time (format as -MM-DD hh:mm:ss).

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] TCP reassembly when packet capture size limited

[Sake Blok]

On 16 nov 2010, at 19:17, Guy Harris wrote:

 On Nov 16, 2010, at 9:58 AM, Stephen Fisher wrote:
 
 Should TCP reassembly be done when the packet size was limited during 
 capture?
 
 Not unless we can do reassembly with holes in the result, which we 
 currently can't do.  At least some other dissectors check to make sure, when 
 adding data to the reassembled packet, that all the data they're adding is 
 present.

IMHO reassembly is not very useful when packets have been truncated. So I would 
prevent TCP reassembly at the TCP level (actually I was under the impression 
the TCP dissector was doing that already, but I could be mistaken).


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] editcap -B

[Sake Blok]

Hello,

I ran into some unexpected behavior of editcap. The -A and -B options can be 
used to select e certain timerange from a capture file. I would have expected 
-B to *not* include packets that were seen in that particular second. Here is 
what I got:

s...@macsake:/tmp$ editcap -A 2010-11-08 20:00:00 -B 2010-11-09 00:00:00 
tmp.cap tmp2.cap
s...@macsake:/tmp$ capinfos -Teca tmp*
File name   Number of packets   Start time  End time
tmp.cap 450 Mon Nov  8 19:52:42 2010Tue Nov  9 00:00:37 2010
tmp2.cap4364047 Mon Nov  8 20:00:00 2010Tue Nov  9 00:00:00 2010
s...@macsake:/tmp$ tshark -ta -r tmp2.cap | tail
4364038 23:59:56.440017  10.94.206.2 - 224.0.0.2HSRP Hello (state Active)
4364039 23:59:56.994172 00:19:2f:57:49:ea - 01:00:0c:cc:cc:cd STP RST. Root = 
4096/638/00:19:07:f5:24:00  Cost = 0  Port = 0x83a3
4364040 23:59:57.112757  10.94.206.3 - 224.0.0.2HSRP Hello (state Standby)
4364041 23:59:58.994450 00:19:2f:57:49:ea - 01:00:0c:cc:cc:cd STP RST. Root = 
4096/638/00:19:07:f5:24:00  Cost = 0  Port = 0x83a3
4364042 23:59:59.228845  10.94.206.3 - 224.0.0.2HSRP Advertise (state 
Passive)
4364043 23:59:59.372142  10.94.206.2 - 224.0.0.2HSRP Hello (state Active)
4364044 00:00:00.020821  10.94.206.3 - 224.0.0.2HSRP Hello (state Standby)
4364045 00:00:00.675857 78:e7:d1:f9:35:38 - 00:1b:78:e2:cd:3a ARP Who has 
10.94.206.170?  Tell 10.94.206.161
4364046 00:00:00.676047 00:1b:78:e2:cd:3a - 78:e7:d1:f9:35:38 ARP 
10.94.206.170 is at 00:1b:78:e2:cd:3a
4364047 00:00:00.995831 00:19:2f:57:49:ea - 01:00:0c:cc:cc:cd STP RST. Root = 
4096/638/00:19:07:f5:24:00  Cost = 0  Port = 0x83a3
s...@macsake:/tmp$ 

To me, it's illogical to include packet 4364044 to 4364047, as they would also 
be included when 'editcap -A 2010-11-09 00:00:00 -B 2010-11-09 04:00:00' 
would be used to generate the next interval (yes I know, intervals can be done 
with -i).

I would expect '-A 2010-11-08 20:00:00 -B 2010-11-09 00:00:00' to mean: All 
packets with a timestamp starting at 2010-11-08 20:00:00 and *before* 
2010-11-09 00:00:00.

Does anyone object to me changing (correcting) the current behavior of -B to 
what I would have expected?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34186: /trunk/ /trunk/epan/: column-utils.c column.c column.h column_info.h epan.c epan.h prefs.c proto.c proto.h /trunk/gtk/: main.c main_packet_list.c new

[Sake Blok]

On 5 okt 2010, at 21:06, Stig Bjørlykke wrote:

 On Wed, Sep 22, 2010 at 10:56 PM,  s...@wireshark.org wrote:
  When using a custom column, make it possible to select which occurrence to 
 show if the field has multiple occurrences.
 
 Did this change also change the output from tshark -Tfields -e ip.addr?
 Do we have to add support for -e ip.addr[1]?

Nope, tshark -T fields and wireshark are now not totally in sync. In tshark you 
can select the first, last or all occurrences, but only for all fields at once. 
Of course one can use the normal column output for specific references. 
However, it would be better to have the -T fields option take something like 
ip.addr[1] indeed.

There is always stuff to work on more than there is time to work on the stuff 
;-)

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34339: /trunk/gtk/ /trunk/gtk/: capture_dlg.c

[Sake Blok]

On 3 okt 2010, at 01:08, Guy Harris wrote:

 On Oct 2, 2010, at 3:32 PM, Sake Blok wrote:
 
 Ah... thank you for pointing me to capture-wpcap.c, I was not aware of the 
 intermediate layer to WinPcap.
 
 Yes - we load WinPcap at run time; that dates back to before we bundled it 
 with Wireshark, so we could ship a single binary that worked, without capture 
 support, if you didn't have WinPcap installed and that worked, with capture 
 support, if you did.  capture-wpcap.c is a bunch of wrappers that call 
 through pointers fetched from the run-time-loaded WinPcap.

I was able to make things work for pcap_open_dead, but when trying to do the 
same for bpf_image, I still run into problems at the linking stage where 
bpf_image can not be found. I checked the WinPcap header files and bpf_image 
is there.

Am I missing a link here?


 Note, BTW, that older versions of libpcap have neither pcap_compile_nopcap() 
 nor pcap_open_dead().  I can dig up the full history (I have the impression 
 that some versions of NetBSD have a pcap_compile_nopcap() with an extra 
 argument, for example) at some point.

Hmmm... do we need to define HAVE_PCAP_COMPILE_NOPCAP and check for it? Or 
can we safely assume it's there in all supported platforms?

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] passing argument 4 of 'pcap_compile_nopcap' discards qualifiers from pointer target typ

[Sake Blok]

Hi,

The OSX-PPC buildbot is complaining:

capture_dlg.c:266: warning: passing argument 4 of 'pcap_compile_nopcap' 
discards qualifiers from pointer target type

Indeed the pointer given to pcap_compile_nopcap is declared as a const gchar 
* and the 4th argument of pcap_compile_nopcap is declared as a char *.

How can this be fixed?

Do I have to copy the string first before giving it to pcap_compile_nopcap? Or 
can I just use a (char *) cast? That however would still defeat the purpose 
of the const declaration in the first place would it not?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] passing argument 4 of 'pcap_compile_nopcap' discards qualifiers from pointer target typ

[Sake Blok]

On 3 okt 2010, at 20:02, Guy Harris wrote:
 On Oct 3, 2010, at 5:16 AM, Sake Blok wrote:
 
 Or can I just use a (char *) cast? That however would still defeat the 
 purpose of the const declaration in the first place would it not?
 
 Yes, but, in this particular case, you can, as indicated, trust 
 pcap_compile()/pcap_compile_nopcap() not to try to modify the string.  You 
 should probably put a comment in about that.

Done in SVN 34353

Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34339: /trunk/gtk/ /trunk/gtk/: capture_dlg.c

[Sake Blok]

On 3 okt 2010, at 20:18, Guy Harris wrote:

 On Oct 3, 2010, at 5:08 AM, Sake Blok wrote:
 
 I was able to make things work for pcap_open_dead, but when trying to do 
 the same for bpf_image, I still run into problems at the linking stage 
 where bpf_image can not be found. I checked the WinPcap header files and 
 bpf_image is there.
 
 ...and, at least for WinPcap 4.1.1, bpf_image is in the .def file.

Which .def file are you referring too?

 Where is it failing?

It was failing in both capture_filter_compile_cb and dumpcap.c, the only 
places where bpf_image is used. As long as HAVE_BPF_IMAGE is not defined, all 
is fine (except, the compile BPF button is not available and neither is dumpcap 
-d). But if I add support for bpf_image in the same way as I added support 
for pcap_open_dead, the linker complains that bpf_image can not be found.

  The buildbot seems to be doing OK.

That's because I did not want to break it yet another time, I have been 
pestering everyone enough this weekend ;-)
So when it did not work on my WinXP dev VM, I decided to ask here first!

 Hmmm... do we need to define HAVE_PCAP_COMPILE_NOPCAP and check for it? Or 
 can we safely assume it's there in all supported platforms?
 
 If we don't support any platforms that use libpcap before libpcap 0.5, we can 
 safely assume it's there, although I think there might be some older versions 
 of NetBSD where pcap_compile_nopcap() took an additional argument (a char * 
 pointing to a buffer into which it put an error message if it failed - 
 pcap_compile_nopcap() as implemented in tcpdump.org libpcap can't give you an 
 error message for the failure, but pcap_open_dead()/pcap_compile() can).
 
 libpcap 0.4 had neither pcap_open_dead() nor pcap_compile_nopcap() - you 
 *had* to have a live capture device or a savefile open in order to compile a 
 filter into BPF code.

So, that sounds to me like we should just use these functions without adding 
complexity by using HAVE_PCAP_COMPILE_NOPCAP until someone knocks at our door 
telling us that (s)he has a problem with these functions on their platform.

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34339: /trunk/gtk/ /trunk/gtk/: capture_dlg.c

[Sake Blok]

On 3 okt 2010, at 23:48, Guy Harris wrote:

 On Oct 3, 2010, at 12:44 PM, Sake Blok wrote:
 
 On 3 okt 2010, at 20:18, Guy Harris wrote:
 
 Where is it failing?
 
 It was failing in both capture_filter_compile_cb and dumpcap.c, the only 
 places where bpf_image is used. As long as HAVE_BPF_IMAGE is not defined, 
 all is fine (except, the compile BPF button is not available and neither is 
 dumpcap -d). But if I add support for bpf_image in the same way as I added 
 support for pcap_open_dead, the linker complains that bpf_image can not be 
 found.
 
 That's because, at least in the current top of tree, the bpf_image() wrapper 
 in capture-wpcap.c is static.  None of the other wrappers are.

Oops!  Thanks for spotting that. 
It now works on my WinXP-dev-VM... checking it in...

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34339: /trunk/gtk/ /trunk/gtk/: capture_dlg.c

[Sake Blok]

On 3 okt 2010, at 00:06, Bill Meier wrote:

 Bill Meier wrote:
 s...@wireshark.org wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=34339
 
 User: sake
 Date: 2010/10/02 02:15 PM
 
 Log:
 Reverting SVN 34338, looks like libpcap and winpcap are more different than 
 I thought. I might have to set up a local windows build system again :(
 
 libui.lib(capture_dlg.obj) : error LNK2019: unresolved external symbol 
 _bpf_image referenced in function _capture_filter_compile_cb
 
 libui.lib(capture_dlg.obj) : error LNK2019: unresolved external symbol 
 _pcap_open_dead referenced in function _capture_compile_cb
 
 
 I'm not sure about bpf_image but for pcap_open_dead() I expect you'll 
 need to add stuff to capture-wpcap.c the same way I just added stuff for 
 pcap_compile_nopcap() in SVN #34336.

Ah... thank you for pointing me to capture-wpcap.c, I was not aware of the 
intermediate layer to WinPcap.


 PS: If you don't want to set up a Windows Build system, I can have a 
 look-see on Monday... (since I build on both Windows and Linux).

I will try to solve it myself, I think I still have a dusty Win-dev VM lying 
around. If it takes too long for me to brush it clean and do the fixing myself, 
I'd be happy to accept your offer ;-)

(I seem to have been spending to much time on this already ;-))

Have a nice weekend,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] TCP data PDU decoding fails depending on TCP options field?

[Sake Blok]

On 1 okt 2010, at 20:35, Fulko Hew wrote:

 On Fri, Oct 1, 2010 at 2:18 PM, Sake Blok s...@euronet.nl wrote:
 Could you please open a bug report at http://bugs.wireshark.org and attach 
 the two tracefiles so that we don't lose track of it?
 
 Done, bugzilla entry #5269 submitted.
 
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5269

Thanks, this will prevent it from being forgotten.

I just checked in a partial fix. Now the packets in your trace are indeed 
decoded, however, there are still some problems with the dissection, so I will 
leave the bug open until that is fixed too.

You can download a version including this fix from 
http://www.wireshark.org/download/automated/ , just make sure you pick a 
version with a number higher than or equal to 34316, it will be available in a 
couple of hours.

Cheers,



Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] GTK question

[Sake Blok]

Hi Guys,

I'm implementing something new for which I would to use ctrl+[ and 
ctrl+] as accelerator keys. But I can't figure out what to put in 
gtk/menus.c.

I tried:

control[
controlLeft_Bracket

And there are not it (no accelerator key shown in the menu and of course also 
no action when pressed).

I tried to google for it, but was unsuccessful so maybe one of you might be 
able to help me out here?

Cheers,


Sake
 
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] GTK question

[Sake Blok]

On 30 sep 2010, at 23:03, Stephen Fisher wrote:
 On Thu, Sep 30, 2010 at 10:39:46PM +0200, Sake Blok wrote:
 
 I'm implementing something new for which I would to use ctrl+[ and 
 ctrl+] as accelerator keys. But I can't figure out what to put in 
 gtk/menus.c.
 
 After digging through the GTK documentation, it looks like the character 
 name needs to be used and not the character itself.  The include file 
 gdk/gdkkeysyms.h is generated from the X.org distribution and it's 
 called bracketleft in there, so you would use bracketleft 
 presumabily.

Great! That did the trick, I will enlist myself for the Google Advanced 
Searching class now ;-)

Thanks,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34186: /trunk/ /trunk/epan/: column-utils.c column.c column.h column_info.h epan.c epan.h prefs.c proto.c proto.h /trunk/gtk/: main.c main_packet_list.c new

[Sake Blok]

On 23 sep 2010, at 17:55, Sake Blok wrote:

 On 23 sep 2010, at 09:37, Stig Bjørlykke wrote:
 
 I have some small issues:
 
 1.  When showing all occurrences and turning off Show Resolved (on
 an entry which is resolved) nothing is displayed (e.g. ip.proto on an
 icmp package).  The correct would be to display all values.
 
 I will look into this...

Fixed in revision 34247


 2. When entering a big number in Field occurrence we get an
 overflow.  Maybe we should limit this value to a decent maximum?
 
 No problem, how does 250 sound as a limit?

Also fixed in revision 34247 by limiting the input field to 4 characters, which 
limits the value for occurrence to -999 and . I doubt there are tracefiles 
with this many occurrences of a particular field :-)

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34247: /trunk/ /trunk/epan/: proto.c /trunk/gtk/: main.c prefs_column.c

[Sake Blok]

On 25 sep 2010, at 12:19, Stig Bjørlykke wrote:

 On Sat, Sep 25, 2010 at 11:33 AM,  s...@wireshark.org wrote:
  Make sure ... as filter does not result in an invalid filter string if 
 all occurrences are displayed.
 
 I really like the comment about filter on multiple occurrences.
 This is added feature which will not interfere with other functionality.

I'm not sure, but do you mean you would like to see the filtering on *all* 
occurrences of a field to be implemented? Or do you like the fact that it is 
restricted now to prevent invalid filters?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 34186: /trunk/ /trunk/epan/: column-utils.c column.c column.h column_info.h epan.c epan.h prefs.c proto.c proto.h /trunk/gtk/: main.c main_packet_list.c new

[Sake Blok]

On 23 sep 2010, at 09:37, Stig Bjørlykke wrote:

 On Wed, Sep 22, 2010 at 10:56 PM,  s...@wireshark.org wrote:
 Log:
  When using a custom column, make it possible to select which occurrence to 
 show if the field has multiple occurrences.
 
 Very nice feature Sake!

Thanks!  I thought so too :-)


 I have some small issues:
 
 1.  When showing all occurrences and turning off Show Resolved (on
 an entry which is resolved) nothing is displayed (e.g. ip.proto on an
 icmp package).  The correct would be to display all values.

I will look into this...

 2. When entering a big number in Field occurrence we get an
 overflow.  Maybe we should limit this value to a decent maximum?

No problem, how does 250 sound as a limit?

  I want to be able to set this value from the heading popup menu.

That would be great indeed. Maybe you should wait a bit. I have the idea to add 
the option to chose the character to aggregate values with (it now uses a 
comma, which does not look nice when showing all ip.addr for instance). Do you 
think that's useful too?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Virtual WireShark appliance

[Sake Blok]

On 20 sep 2010, at 06:58, john s wolter wrote:

 WireShark needs to have software virtual appliances.  This for the Cloud 
 computing services and for the virtual environments like Xen.  A minimal 
 virtual WireShark appliance could be added as an observer as part of a cloud 
 array or Xen environment.  It's a perfect complement to the physical 
 appliances for the in the Cloud crowd.  I can imagine many variations on this 
 theme.

That would indeed be great. However, the problem is not so much the software 
virtual appliance (we could whip up a linux VM with wireshark installed, ready 
to deploy). The problem is how to get packets to the virtual appliance. Most 
virtual switches that come with the virtualization environment just don't do 
port mirroring and such (please correct me if I'm wrong here nowadays).

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Changing PostScript(R) font

[Sake Blok]

On 11 aug 2010, at 13:09, Jaap Keuter wrote:

 Anyone a problem with changing the font used in PostScript(R) print output 
 from Courier into Monaco?
 It's also a monospaced font, is/was a Mac 'favorite' and just renders a bit 
 more readable under adverse conditions (crappy display, printer almost out of 
 toner, that kind of thing).
 
 If there's no objection I like to put the change up for 1.4.0 as well.

No objection here!


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] capture filter issue

[Sake Blok]

On 19 jul 2010, at 13:19, upendra.a...@wipro.com upendra.a...@wipro.com 
wrote:

 When I am doing live capture with Wireshark using the “Capture filter” option 
 (host 172.16.59.240), my expectation is that I can able to see both the to 
 and from (source  dest) traffic with that ip address. But I can see only 
 incoming traffic (i.e. destination ip address only), it is not showing any 
 outgoing traffic from that ip address.
   
 If I remove that filter and start capturing, then I can see both incoming and 
 outgoing traffic with that ip address.
 I am doubting some setup problem in my Wireshark, but not sure where to 
 change.
 Can you please help me on this issue.

It could be that incoming traffic is not 802.1Q tagged, while outgoing traffic 
is  802.1Q tagged, that all depends on where you are doing the capture and what 
the L2 design is of that infrastructure.

The capture filter host 172.16.59.240 will only match untagged traffic. If 
you would also like to see the 802.1Q tagged traffic for 172.16.59.240, you 
need to specify a capture filter like this:

host 172.16.59.240 or (vlan and host 172.16.59.240)

Please note that the order in that filter is important. See also: 
http://wiki.wireshark.org/CaptureSetup/VLAN#Capture_filters

Hope this helps,
Cheers,


Sake

PS  This can also happen on PPPoE networks or any other situation where L2 
tagging/encapsulation is done in one direction, but the most common case is 
802.1Q vlan-tagging



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Output of 'tshark -T fields' with multiple occurrences of a field

[Sake Blok]

On 19 jul 2010, at 17:03, Martin Visser wrote:

 Not saying that this isn't a good idea (being able to output repeated 
 fields), but I suspect when it gets to stable you might get some complaints. 
 If people use -T fields like they do a CSV file, they might be expecting a 
 fixed number of columns. (Currently whether there are 0, 1 or  more 
 instances, I think there are always the same number of commas).

Well, the fields are still separated with tabs (by default), but within a 
field, multiple occurrences are now separated by commas (by default). I added 
another option to be able to select the value of the first occurrence of the 
field, the last occurrence (as it was before my change) and all occurrences 
(the new default):

  -T pdml|ps|psml|text|fields
   format of text output (def: text)
  -e field   field to print if -Tfields selected (e.g. tcp.port);
   this option can be repeated to print multiple fields
  -Efieldsoption=value set options for output when -Tfields selected:
 header=y|nswitch headers on and off
 separator=/t|/s|char select tab, space, printable character as separator
 occurrence=f|l|a  print first, last or all occurrences of each field
 aggregator=,|/s|char select comma, space, printable character as 
aggregator
 quote=d|s|n   select double, single, no quotes for values

I think that will give everyone the granularity of control they might need. 

 You might want to think about adding this new feature only by adding a new 
 switch (say the -E aggregator switch)

Would showing the value of the last occurrence of the field (-E occurrence=l) 
be a better default? That way the behavior does not change unless you 
specifically ask for it.

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 How to add fieldname for certain IEs

[Sake Blok]

On 14 jul 2010, at 04:59, Leon Liu wrote:

 Now what I want to do is extract certain IEs(which involve MS capability) 
 from pcap files via tshark.
 In my plan, I can achieve it using command 'tshark -r filename.dump -R 
 filter(filter out 'attach request') -T field -e fieldname'.
 But when I check the fieldname of IEs which I want to extract, I found that 
 the fieldname is null.
  
 So my question is how to add fieldname in source code?
 The picture below shows the stacks of protocols and the IEs within the red 
 ellipse are what I want.
  
 Could someone help me to locate which source file I need to modify? And give 
 me an simple example of how to achieve a new field name?

The reason is that the dissectors that generate the protocol tree for these 
protocols use proto_tree_add_text(...) for the values you would like to 
extract. This function is easy to implement, because it does not need all the 
work of setting up fieldnames. Please read the file README.developer in the 
source tree to get an idea on how to add fields in Wireshark. It also gives a 
broader perspective on development for Wireshark. Of course the Developers 
Guide on the Wireshark website is a good starting point on getting a build 
environment up and running.

Then, which files to edit, you can search the source repository for the 
specific items you are after. I use a little alias for that:

alias srcfgrep='fgrep -Ril --include *.[ch] --exclude *svn* '

which can be used like this:

s...@macsake:~/Wireshark/trunk$ srcfgrep EGPRS multislot class *
epan/dissectors/packet-bssgp.c
epan/dissectors/packet-gsm_a_gm.c
s...@macsake:~/Wireshark/trunk$

So these two files contain the code that adds the EGPRS multislot class items.

I hope this gets you on your way :-)
Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Output of 'tshark -T fields' with multiple occurrences of a field

[Sake Blok]

Hi,

Recently a lot of questions have been asked on this list (and also at 
Sharkfest) about the output of 'tshark -T fields -e field' when field had 
multiple occurrences in one packet. Only the last occurrence was printed by 
tshark. I submitted a fix that now prints all occurrences, aggregated by commas 
(which can be overwritten with -E aggregator=char).

The fix will be included in version 1.6.x as well as in the next development 
release (1.5.x). For the impatient, please use an automated build from 
http://www.wireshark.org/download/automated/ (look for a version 33504 or 
higher).

Enjoy!
Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] MacOS/X builds

[Sake Blok]

Hi,

I'm starting to build Wireshark on my MacBook. It all compiles well, but when I 
do 'make osx-install' the created Wireshark.app does not execute. It says it's 
damaged or incomplete. If I compare the contents of the App to an official 
release, I see that Contents/MacOS/Wireshark is missing. This file is also 
missing in the automated builds for MacOS/X-intel.

As I'm new to building Wireshark for MacOS/X I'm not sure where to look to be 
able to fix this. Any help is welcome :-)

Cheers,


Sake


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] MacOS/X builds

[Sake Blok]

On 6 jul 2010, at 12:07, Stig Bjørlykke wrote:

 On Tue, Jul 6, 2010 at 12:01 PM, Sake Blok s...@euronet.nl wrote:
 I'm starting to build Wireshark on my MacBook. It all compiles well, but 
 when I do 'make osx-install' the created Wireshark.app does not execute.
 
 I'm using the attached patch to build on my system (OSX 10.6.4).

Great, that did the trick. I think we need to make SDKROOT determined at 
compile time so that the automated builds don't show the same problem...

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] MacOS/X builds

[Sake Blok]

On 6 jul 2010, at 13:13, Sake Blok wrote:

 On 6 jul 2010, at 12:07, Stig Bjørlykke wrote:
 
 On Tue, Jul 6, 2010 at 12:01 PM, Sake Blok s...@euronet.nl wrote:
 I'm starting to build Wireshark on my MacBook. It all compiles well, but 
 when I do 'make osx-install' the created Wireshark.app does not execute.
 
 I'm using the attached patch to build on my system (OSX 10.6.4).
 
 Great, that did the trick. I think we need to make SDKROOT determined at 
 compile time so that the automated builds don't show the same problem...

I can add a line determining which SDK to use in packaging/macosx/osx-app.sh 
(there is already some version dependent stuff in there), but I have no idea 
which OSX versions need which SDK dir. Does anybody have an idea?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] MacOS/X builds

[Sake Blok]

On 6 jul 2010, at 22:35, Guy Harris wrote:

 
 On Jul 6, 2010, at 12:38 PM, Guy Harris wrote:
 
 
 On Jul 6, 2010, at 11:38 AM, Guy Harris wrote:
 
 ...although the *first* thing I'd try is just removing the setting of 
 SDKROOT from 
 packaging/macosx/ScriptExec/ScriptExec.xcodeproj/project.pbxproj and see 
 whether the resulting .app bundle, when built (32-bit) on Leopard, works on 
 Leopard and on Snow Leopard, and, when built (64-bit) on Snow Leopard, 
 works on Snow Leopard.
 
 I've checked into the trunk a change to do that; I'll check whether the 
 resulting .app bundles work.  If not, I'll revert the change and we can look 
 further; if so, we might want to propagate that change to the 1.4 branch.
 
 The app bundle in the 64-bit .dmg's, as built by the buildbot, works on my 
 Snow Leopard machine.
 
 There doesn't yet appear to be a 32-bit Intel .dmg for that build yet; the 
 PPC build is still in progress - I'll check again after that finishes.  (I 
 don't have Leopard at home, so I'll have to test it later at work anyway.)

Great!

 I did check building without the SDKROOT definition too, but
... I had to run off to watch the soccer game with friends. Woohoo... we... 
uhm... Holland :-) made it to the finals of the Worldcup!

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-users] tshark or dumpcap ring buffer limitations

[Sake Blok]

On 20 mei 2010, at 23:24, Jaap Keuter wrote:
 On Thu, 20 May 2010 12:05:09 -0400, Jeff Morriss
 jeff.morriss...@gmail.com wrote:
 [Redirecting to -dev for this question.]
 
 Jaap Keuter wrote:
 On 05/19/2010 07:38 PM, Joseph Laibach wrote:
 All,
 
 I’m running a continuous capture of data. I’m trying to use a ring
 buffer of 25000 files with an 8mb file size. The problem is that the
 ring buffer starts overwriting after 1 files. I’ve tried it with
 dumpcap and tshark. The command is using the –b files:25000 –b
 filesize:8192. Is there a limitation to the size of the ring buffer for
 dumpcap and/or tshark?
 
 [...]
 
 That's a fixed limit:
 
 j...@host:~/src/wireshark/trunk$ grep RINGBUFFER_MAX_NUM_FILES *.h
 ringbuffer.h:#define RINGBUFFER_MAX_NUM_FILES 1
 
 Hmmm, actually, it's not: if you specify a value of 0 you get 
 unlimited files.  (I just tried it and killed dumpcap after it created
 26,492 files.)
 
 Why have an upper limit at all if we also allow unlimited files?
 
 Ehm, when specifying 0 it's not a circular buffer anymore.
 
 This appeared in rev 7912 and it appears that the max # of files limit 
 was there originally because *ethereal kept the old files open so we 
 would (prior to that commit) run out of fds.
 
 Any reason not to just take this constant out and let users specify any 
 number?
 
 Any number would mean an array of keeping names of that size as well. And
 it's some sort of self protection, since not all file systems handle a
 kazillion files well. But what an appropriate limit would be, who knows?

Well, since the filesnames in the fileset have a 5 digit counter, the upper 
limit would be 9 (not 10 as it has to be able to create the next file 
before deleting the oldest one). Why not give the user the rope to hang 
themselves with if they really need/want to? It's not that the files are 
accessed repeatedly, so I wonder if the performance hit of having a kazillion 
files in one directory is really a problem here...

Just my $0,02


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 31343: /trunk/gtk/ /trunk/gtk/: main_packet_list.c main_packet_list.h menus.c new_packet_list.c new_packet_list.h

[Sake Blok]

On Tue, Dec 22, 2009 at 01:37:18PM +0100, Stig Bjørlykke wrote:
 On 22. des. 2009, at 00.07, s...@wireshark.org wrote:
 
  Add Ignore all packets, just like Mark all packets
 
 Should we rename the menu items to Mark all displayed packets and 
 Ignore all displayed packets?
 This would clearify the usage.

Yes, but.. yada yada... oh... it's already been done ;-)

(I was wondering the same thing myself, I think it's indeed better this
way)

Cheers,


Sake

PS  Thanks for fixing the sensitivity too...
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Marking all frames with new packet list

[Sake Blok]

Hi All,

I'm implementing Ignore all packets by mimicking the mark all packets
functions. However, I encounter a difference in behavior between the
mark all packets in the old packet list and the mark all packets in the
new packet list.

In the ol'days, mark all packets would only mark the displayed frames,
which is useful. Now'days it marks *all* frames, which is not quite
useful ;-)

My question, as I have not really dug into the new packetlist, is there
an easy function I can use to determine if a frame in the list is
displayed or not?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Marking all frames with new packet list

[Sake Blok]

On Mon, Dec 21, 2009 at 03:24:12PM -0800, Guy Harris wrote:
 
 On Dec 21, 2009, at 2:43 PM, Sake Blok wrote:
 
  My question, as I have not really dug into the new packetlist, is there
  an easy function I can use to determine if a frame in the list is
  displayed or not?
 
 Are you looking at the model (ultimately backed by the frame_data structures) 
 or the view?
 
 If the model, does fd-flags.passed_dfilter indicate what you want?

Yes, this is exactly what I wanted :-)

Thx Guy!

(marking/ignoring all packets is fixed in SVN 31345)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Optimization - accumulative filters?

[Sake Blok]

Optimization - accumulative filters?Would it also be easily possible with the 
new packet list to freeze the displayed packets in a view. One could then have 
multiple views in a dropdown list (with whole file as a default view). Then 
the next display filter entered will work on the view, instead of the whole 
file. That would be really reallu useful :-) But... I haven't digged into the 
new packet list yet to know whether I'm now opening up cool posibilities or 
just wishing for myracles ;-)

Cheers,


Sake

  - Original Message - 
  From: Anders Broman 
  To: Developer support list for Wireshark 
  Sent: Tuesday, November 03, 2009 5:48 PM
  Subject: [Wireshark-dev] Optimization - accumulative filters?


  Hi, 
  Would it bebeneficial to have a second filter option box in the main filter 
toolbar that only filters on the displayed packets?

  With the new packet list it may not be so difficult to implement as it has a 
record of displayed packets and a new filter could be applied

  To only those packets. 
  Regards 
  Anders 



--


  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  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 wireshark-dev@wireshark.org
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] regarding the output of Follow TCP Stream command

[Sake Blok]

On Thu, Sep 03, 2009 at 09:17:26AM +0300, Selçuk Cevher wrote:
 
Is the output of Follow TCP Stream command, with the Entire
Conversation option in drop-down list selected, strictly ordered ?

Yes, it is strictly ordered... but... only in the order in which they
were received by the system that captured the packets. There is no way
for the capturing system to know when the packets were sent by each
sender...

One way to analyze the *strict* order of both flows is to create
capture files at both ends of the connection and see how the
transmission delay is having an influence on the order of the packets.

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 29523: /trunk/ /trunk/epan/dissectors/: packet-tcp.c /trunk/epan/: column-utils.c column-utils.h column.c column_info.h prefs.c /trunk/gtk/: new_packet_list

[Sake Blok]

On Sun, Aug 23, 2009 at 05:25:38PM +0200, Kovarththanan Rajaratnam wrote:
 Stig Bjørlykke wrote:
  On 23. aug.. 2009, at 14.24, k...@wireshark.org wrote:
  
  Log:
  Custom columnfication:
 
  * Deprecate COL_REL_CONV_TIME (Relative time (conversation)). Use  
  tcp.time_relative
  
  What about conversations other than tcp?
 
 COL_REL_CONV_TIME and COL_DELTA_CONV_TIME are pretty generic but they 
 were only used within the TCP dissector, so I didn't think that 
 converting them would be controversial. So far I've only converted 
 columns that were restricted to one dissector.

When I wrote the Conversation Timestamps functionality, I had in mind
to make it open enough for other protocols to also generate conversation
timestamps (I only implemented the tcp version so far). The column would
be a container that just shows the conversation timestamps for the
highest layer. Dropping support for the specific column values will
result in having to add multiple columns, one for each protocol that has
conversation timestamps. However, the same functionality can be achieved
with adding a frame.conv_time.relative and frame.conv_time.delta field
that gets updated by all protocols that support conversation timestamps.
Then that field can be used in a custom column.

Does anyone think this functionality is needed? Or are we analysing one
or two layers of conversations at a time and be fine with having to add
the specific protocol timestamps manually?

One other concern with transforming fixed columns to custom columns,
what is the impact on performance? I can imagine custom columns to be
much slower, so maybe some widely used fixed columns should stay fixed
for performance sake. Did anyone test this?

Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] ip6_to_str equivalent/alternative with variable length for ipv6 address

[Sake Blok]

On Mon, Aug 10, 2009 at 07:03:09PM -0700, ivan jr sy wrote:
 Hi all:
 
 I need some advise on getting an IPv6 address to str with variable number of 
 bytes.
 
 Example:
 
 /* the hex part is */
 20 01 db 08 ff ff 00 02 20 86 20 03 de ad be ef
 
 addr_len = 6; /* variable */
 
 /* if I do this: */
 addr = tvb_get_ptr(tvb, cur_offset, addr_len);

This just gives you a ptr (addr) to the start of some data portion but
it ensures that at least addr_len bytes are present.

   ip6_to_str((const struct e_in6_addr *)addr);
 
 this will result to:
 2001:db8::2:2086:2003:dead:beef

Which is as it is designed.

 but what i wanted was:
 /* the hex part is */
 20 01 db 08 ff ff
 
 so it will result to 2001:db8: (the network portion) coz 
 the 00 02 20 86 20 03 de ad be ef is for a different purpose.. 
 then I also need to append :: to the last part of the str to 
 make it 2001:db8:::

If *that* is what you want, you need to copy the first addr_len bytes
into a new variable, add 16-addr_len zeroes to that variable and then
call ip6_to_str on the new variable.

The copying can be done with:

/** Returns target for convenience. Does not suffer from possible
 * expense of tvb_get_ptr(), since this routine is smart enough
 * to copy data in chunks if the request range actually exists in
 * different TVBUFF_REAL_DATA tvbuffs. This function assumes that the
 * target memory is already allocated; it does not allocate or free the
 * target memory. */
extern void* tvb_memcpy(tvbuff_t*, void* target, gint offset, size_t
length);

(see epan/tvbuff.h)

Hope this helps,
Cheers,
Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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

[Sake Blok]

Kevin,

Yes, this is definitely worthy of a feature request. In fact, the developers 
have discussed this option at Sharkfest in great depth. Please feel comfortable 
to add it to the list.

In general, there are many caveats in implementing anonimization. It should be 
handled per protocol, taken into account that certain data can be segmented 
across multiple frames. It can be compressed or encapsulated. Certain lower 
layer data can be present in higher layer protocols. So in the end, if it is 
implemented, it should be used with great caution. A false sense of security is 
worse than having no security at all (which of course can be disputed ;-)).

As for masking IP addresses. Of course it is easy to alter the src and dst ip 
addresses of packets, but what to do with the icmp unreachable messages. And 
the port command of an FTP session? Or the X-Forwarded-For header in HTTP? And 
should IP addresses be changed the same way on all protocol levels?

We really need this feature IMHO, but it is pretty complex to implement it 
properly unfortunately.

Cheers,


Sake

PS   Have a look at the bittwist suite, it contains bittwiste which could 
alter mac-addresses, ip-addresses, ports etc of packets, so that might suit 
your needs, but be aware of the higher layers that might still contain the 
things you were trying to mask (http://bittwist.sourceforge.net/).

  - Original Message - 
  From: Kevin Jones 
  To: wireshark-dev@wireshark.org 
  Sent: Thursday, July 23, 2009 2:22 PM
  Subject: [Wireshark-dev] Feature Request


  I'd like to add a feature request to the list in the wiki. As per the rules 
listed there, I'd like to know from the devs if this idea is something worthy 
of a feature request.

  A lot of times, Wireshark captures get uploaded to the internet for others to 
view/compare/analyze. However, there are many times when a log of IP addresses 
and MAC addresses could be detrimental. Therefore, I'm suggesting an easy way 
(one click perhaps?) to anonymize the data. Unique IPs and MACs would have to 
be replaced with something such as 1.1.1.1 and 1.1.1.2, etc... and maintained 
throughout the results. 

  Granted, this would not be useful for every occasion or user but I think that 
it would be a welcome addition that would benefit a great number of users.

  Thanks,
  Kevin



--


  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  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 wireshark-dev@wireshark.org
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] tab-width considered less effective than some might think

[Sake Blok]

On Thu, Jul 23, 2009 at 09:56:02PM -0400, Bill Meier wrote:
 
 I've been thinking for quite some time about suggesting that the use 
 non 8 space tabs (eg: tab stops every 4 spaces) be deprecated;
 
 So: what do others think ?  :)

I would go one step further, as tabs will be displayed differently
depending on what program is displaying the code, why not deprecate tabs
alltogether and stick to using spaces for indentation only?

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] tab-width considered less effective than some might think

[Sake Blok]

On Fri, Jul 24, 2009 at 07:35:49AM +0200, Sake Blok wrote:
 On Thu, Jul 23, 2009 at 09:56:02PM -0400, Bill Meier wrote:
  
  I've been thinking for quite some time about suggesting that the use 
  non 8 space tabs (eg: tab stops every 4 spaces) be deprecated;
  
  So: what do others think ?  :)
 
 I would go one step further, as tabs will be displayed differently
 depending on what program is displaying the code, why not deprecate tabs
 alltogether and stick to using spaces for indentation only?

Which is what the majority of dissectors already do :-)

s...@brutus:/wireshark/trunk/epan/dissectors$ fgrep -l TAB *.c | wc -l
758
s...@brutus:/wireshark/trunk/epan/dissectors$ fgrep -v -l TAB *.c | wc -l
855
s...@brutus:/wireshark/trunk/epan/dissectors$ 

Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Tshark XML conversion

[Sake Blok]

On Wed, Jul 22, 2009 at 03:03:49PM +0200, Wasim Bari wrote:
 
I just converted 1.5 Gbyte file to XML and it took about 13 minutes. And
the size of output xml file was 72 Gbyte which is very strange for me. Am
I doing something wrong or is it normal behaviour ?

Yes it is. Well, at least the increase in filesize is. Imagine the ip
source address. It takes up 4 bytes in the actual packet, but in text it
is already 7-15 bytes long (1.1.1.1 and 111.111.111.111). Add to that
the XML tags and you can imagine that the file blows up quite quickly...


Secondly can  get output in text mode with full details ?  (I saw text
option but it only gives me summary)

Try 'tshark -V'

('tshark -h' and 'man tshark' are your friends :-))


Cheers,


Sake

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Time for 1.2.1?

[Sake Blok]

On Fri, Jul 10, 2009 at 09:40:00AM -0700, Gerald Combs wrote:

   - Bug 3672, which appears to be an off-by-one error in the reassembly
 code.

This bug seems to be fixed already by:

r28875 | jake | 2009-06-28 18:39:31 +0200 (Sun, 28 Jun 2009) | 1 line

Make dissector handle unexpected data better.


Strange thing is that my windows WS SVN 28821 does not have a problem
with the file. My linux wireshark 28836 did have a problem with packet
40780. Updating to SVN 29055 did solve the issue with frame 40780.

I assume this bug has been fixed in latest SVN.


Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Using find_conversation with multiple conversations conducted over the same UDP address / port pairs

[Sake Blok]

Hi Kelvin,

The radius dissectors uses a hash table to store multiple sessions per 
conversation. You might want to have a look at it 
(epan/dissectors/packet-radius.c). If you need a tracefile to work with, 
showing multiple requests/responses in the same conversation, I could create 
one for you...

Hope this helps,
Cheers,
 Sake
  - Original Message - 
  From: kelvin.proc...@au.schneider-electric.com 
  To: wireshark-dev@wireshark.org 
  Sent: Friday, June 26, 2009 7:19 AM
  Subject: [Wireshark-dev] Using find_conversation with multiple conversations 
conducted over the same UDP address / port pairs



  Hi Wireshark Dev List, 

  We have a network with DNP3.0 that is using UDP.  We have a gateway device 
that communicates to a collections of RTUs (RTU = Remote Terminal Unit, a 
device on the DNP3.0 network) over a serial radio-modem network and we talk to 
the gateway using UDP / IP. 

  The DNP3.0 dissector uses the standard calls to find_conversation etc... and 
fragment_add_seq_next etc... to do application layer frame re-assembly as 
follows: 

if (! (tr_fir  tr_fin)) 
{ 
  /* A fragmented packet */ 
  pinfo-fragmented = TRUE; 

  /* Look up the conversation to get the fragment reassembly id */ 
  conversation = find_conversation(pinfo-fd-num, pinfo-src, 
pinfo-dst, 
pinfo-ptype, pinfo-srcport, pinfo-destport, 0); 

  if (conversation == NULL) { 
/* No conversation yet, so make one */ 
conversation = conversation_new(pinfo-fd-num,  pinfo-src, 
pinfo-dst, pinfo-ptype, 
  pinfo-srcport, pinfo-destport, 0); 
  } 

  conv_data_ptr = 
(dnp3_conv_t*)conversation_get_proto_data(conversation, proto_dnp3); 

  if (conv_data_ptr == NULL) { 
/* New data structure required */ 
conv_data_ptr = se_alloc(sizeof(dnp3_conv_t)); 

/*** Increment static global fragment reassembly id ***/ 
conv_data_ptr-conv_seq_number = seq_number++; 

conversation_add_proto_data(conversation, proto_dnp3, (void 
*)conv_data_ptr); 
  } 
  conv_seq_number = conv_data_ptr-conv_seq_number; 

  /* 
  * Add the frame to 
  * whatever reassembly is in progress, if any, and see 
  * if it's done. 
  */ 

  frag_msg = fragment_add_seq_next(al_tvb, 0, pinfo, conv_seq_number, 
  al_fragment_table, 
  al_reassembled_table, 
  tvb_reported_length(al_tvb), /* As this is a constructed tvb, all 
of it is ok */ 
  !tr_fin); 

  next_tvb = process_reassembled_data(al_tvb, 0, pinfo, 
  Reassembled DNP 3.0 Application Layer message, frag_msg, 
dnp3_frag_items, 
  update_col_info, tr_tree); 

  Unfortunately this does not take into account the fact that over the same IP 
address / port number pairs we may receive messages from many different source 
RTUs that should be treated as separate conversations.  The problem we have at 
the moment is that we are getting fragment re-assembly occurring for fragments 
from difference RTUs. 

  Is there a standard way to handle situations like this?  If so can someone 
point me to the correct dissector to look at? 

  We can provide packet captures that demonstrate the issue if desired.   It is 
considered acceptable to attach a .pcap file to a posting to this mailing list? 

  Thanks in advance, 

  Kelvin Proctor 



--


  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  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 wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 28794: /trunk/gtk/ /trunk/gtk/: Makefile.common capture_dlg.c capture_file_dlg.c drag_and_drop.c file_dlg_win32.c fileset_dlg.c main.c main.h main_filter_to

[Sake Blok]

On Mon, Jun 22, 2009 at 09:03:14PM +0200, Ulf Lamping wrote:
 Guy Harris schrieb:
  On Jun 22, 2009, at 1:41 AM, Ulf Lamping wrote:
  
  Now you're telling me that file name in question is not 100% correct  
  so
  you're changing it back into the chaos we once had - ignoring the
  benefits we could get from the name prefixes.f
  
  I'm unconvinced that, for that *particular* file, there's any benefit  
  whatsoever to having main_ in the name at all.  It should be pretty  
  obvious that a file with menus in its name would contain the  
  implementation of menus.
 
 Reading this, I'm unconvinced that you even understand the problem I 
 tried to solve.

Ah, I'm glad you two are now both unconvinced of each others
understanding ;-)

That means we can now move forward towards the goal that you both have 
with the filename changes you made: Improving the navigation
through the gtk source code.

Lets define categories of code first and then make a team effort to 
split up the source files and consolidate the code belonging to one
category into new files, either in subdirectories or files with a 
category prefix.

Does that sound like a (mutual) plan?

Cheers,


Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] On Copy as Filter

[Sake Blok]

On Fri, Jun 05, 2009 at 11:55:02PM +0200, didier wrote:
 Le dimanche 31 mai 2009 à 11:56 +0200, Sake Blok a écrit :
  Hi Jaap ( list),
  
  As the father of the copy as filter functionality, I would vote for it 
  to be present all the time in the packet details pane (where I use it 
  most). 
  Keeping track of all possible filters for the packet list pane seems like 
  an 
  overkill to me and could be made optional to save memory. Or it should be 
  implemented in a way where it will dynamically be generated. For 1.2.0 I 
  would suggest to just revert the implemented memory-consuming patch and 
  disable the functionality in the packet-list. Then we can decide later to 
  make it either optional of write code that dynamically generate the filter 
  string on use (if that is at all possible).
 
 Anyone remember why it was changed from dynamically generate?
 The SVN log msg doesn't make sense to me.

IIRC, the filter strings were not generated dynamically, they were
generated while building the packet-list, resulting in having the
filters for the last row to be the filters for all rows. But my memory
might not be totally accurate ;-)

Cheers,
 Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] On Copy as Filter

[Sake Blok]

Hi Jaap ( list),

As the father of the copy as filter functionality, I would vote for it 
to be present all the time in the packet details pane (where I use it most). 
Keeping track of all possible filters for the packet list pane seems like an 
overkill to me and could be made optional to save memory. Or it should be 
implemented in a way where it will dynamically be generated. For 1.2.0 I 
would suggest to just revert the implemented memory-consuming patch and 
disable the functionality in the packet-list. Then we can decide later to 
make it either optional of write code that dynamically generate the filter 
string on use (if that is at all possible).

How does that sound?

Sake

- Original Message - 
From: Jaap Keuter jaap.keu...@xs4all.nl
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Sunday, May 31, 2009 11:02 AM
Subject: [Wireshark-dev] On Copy as Filter


 Hi list,

 Looking at bug 3489 (which need to be solved in 1.0.9) and the history of 
 the
 Copy as Filter feature, with complaints on memory usage, I wonder if we 
 need
 to make this an optional feature. Optional in that it can be selected in 
 the
 user preferences if this features is to be available, hence increase the 
 memory
 footprint. Should this be done in time for 1.2.0?

 Thanx,
 Jaap


 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Win32 buildbot failing

[Sake Blok]

Gerald,

Could you have a look at the Win32 buildbot? It seems to be failing for a few 
days. There have not been an automated build for Win32 since last friday. Build 
6193 was the first to fail with the following errors in it:

xsltproc --stringparam base.dir wsug_html_chunked/ --stringparam  
use.id.as.filename 1 --stringparam admon.graphics 1 --stringparam 
admon.graphics.path wsug_graphics/ --stringparam section.autolabel 1 
--stringparam  section.label.includes.component.label 1 --stringparam 
html.stylesheet ws.css --nonet 
http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl user-guide.xml
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
user-guide.xml:321: warning: failed to load external entity 
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
]
  ^

(http://buildbot.wireshark.org/trunk/builders/Windows-XP-x86/builds/6193/steps/nmake%20docs/logs/stdio)

All builds after that fail with:

starting svn operation

remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most 
recent call last):
  File C:\Python24\lib\site-packages\twisted\internet\defer.py, line 107, in 
maybeDeferred
result = f(*args, **kw)
  File C:\Python24\lib\site-packages\buildbot\slave\commands.py, line 846, in 
start
d.addCallback(self.doClobber, self.workdir)
  File C:\Python24\lib\site-packages\twisted\internet\defer.py, line 191, in 
addCallback
callbackKeywords=kw)
  File C:\Python24\lib\site-packages\twisted\internet\defer.py, line 182, in 
addCallbacks
self._runCallbacks()
--- exception caught here ---
  File C:\Python24\lib\site-packages\twisted\internet\defer.py, line 307, in 
_runCallbacks
self.result = callback(self.result, *args, **kw)
  File C:\Python24\lib\site-packages\buildbot\slave\commands.py, line 1004, 
in doClobber
rmdirRecursive(d)
  File C:\Python24\lib\site-packages\buildbot\slave\commands.py, line 74, in 
rmdirRecursive
rmdirRecursive(full_name)
  File C:\Python24\lib\site-packages\buildbot\slave\commands.py, line 74, in 
rmdirRecursive
rmdirRecursive(full_name)
  File C:\Python24\lib\site-packages\buildbot\slave\commands.py, line 77, in 
rmdirRecursive
os.remove(full_name)
exceptions.OSError: [Errno 13] Permission denied: 
'C:\\buildbot\\wireshark\\trunk32\\winxpx86\\build\\docbook\\wsdg_graphics\\ws-function-blocks.png'
]
(http://buildbot.wireshark.org/trunk/builders/Windows-XP-x86/builds/6194/steps/svn/logs/stdio)

Maybe some file permissions got stuck?

Thanks,
Cheers,
 Sake___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Prefs GUI handling: Apply followed by Cancel gives incorrect results ?

[Sake Blok]

Bill,

My intuitive use of the OK, Apply and Cancel buttons would be as 
follows:

- Starting point would be that the preferences used in the current instance 
of WS are the same as the preferences on disk
- When the preferences window is opened, a backup copy of these preferences 
are made in memory
- The user can make changes and revert them to the backup copy *before* 
applying them to the current WS instance
- The user can make changes to the preferences and apply them to the current 
WS instance to see the effect, only the preferences in memory are affected
- When the user clicks on cancel, the backup copy of the preferences will 
again be loaded into memory and applied, so that the preferences are the 
same as when the preferences display was opened, also the preferences on 
disk are still unchanged.
- When the user makes changes and likes the result after applying the 
changes, they will be saved to disk when the OK button is clicked.

This means that the current behavior of saving the preferences to disk on 
apply need to be replaced by saving the preferences to disk on OK only. 
Your solution would mean that there is no way of returning to the 
preferences that were active when the preferences window was opened and the 
Apply button has been pressed. So there is no way of trying out the effect 
of new settings with an easy bail-out.

But that's just *my* intuitive use, not sure how others would intuitively 
use the OK, Apply and Cancel buttons.

Cheers,
Sake

- Original Message - 
From: Bill Meier wme...@newsguy.com
To: wireshark-dev@wireshark.org
Sent: Sunday, May 03, 2009 6:45 PM
Subject: [Wireshark-dev] Prefs GUI handling: Apply followed by Cancel gives 
incorrect results ?


 Summary
 ---

 While working on fixing various issues with Preferences!Columns
 I found the that Preferences!Apply followed by Preferences!Cancel
 reverts the preferences not to the preferences settings last saved
 state but to the preferences settings state when the preferences window
 was opened.

 (I'm describing the case for the normal default Wireshark configuration
 when the Preferences Buttons are OK/Apply/Cancel w/o a Save button).


 Both the Wireshark Wiki and the Wireshark User's Guide indicate that
 Preferences ! Cancel should restore the preferences to the last saved
 state.

 If there's no objection (and assuming that I'm not missing something),
 I plan to check in a fix tomorrow (Monday) to update the in-memory saved
 preferences state when/if the preferences are written to disk for
 the Preferences!Apply and Preferences!Save buttons.



 Details
 ---

 In the current Wireshark development SVN (and presumably in the various
 1.0 releases) [For show a save button set to False]:

 Preferences ! Apply followed by Preferences ! Cancel does the following

 1. Apply writes the preferences to disk (with any changes made since
 the preferences window was opened);

(The next time Wireshark is started these preferences will be used).

 2. Cancel reverts the in-memory preferences to the state of the
 preferences when the Preferences window was opened (before any changes
 were made) and *not* to the most recently saved state.

This is true for the general preferences as well as for the the
protocol preferences.


 The fix looks reasonably simple:

 For Prefs!Apply and Prefs!Save if/when the prefs are written to disk:

 1. (Re)save the prefs structure (in memory).

 2. (Re)save all the module preferences (in memory).


 Bill
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] [Full-disclosure] SniffJoke 0.3 release and requestfor feedback (forw)

[Sake Blok]

As the purpose of Wireshark is to display network traffic to analyse 
problems, I see no use in competing in a race to cloak and uncloak traffic 
with Sniffjoke. That would put Wireshark in the list of cracking tools which 
might have a negative effect on the places where it is allowed to be used. 
So I would not consider this a bug and I would *not* consider being able to 
reassemble Sniffloke traffic a feature to implement.

Just my $0.02


Sake

- Original Message - 
From: Joerg Mayer jma...@loplof.de
To: wireshark-dev@wireshark.org
Sent: Monday, April 27, 2009 3:53 PM
Subject: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 release and 
requestfor feedback (forw)


 Should it be considered a bug if WS can be fooled by a tool like Sniffjoke
 to incorrectly reassemble a TCP stream?
 The webpage has two sample traces that seem to be handeled incorrectly by
 HEAD indeed.

 Ciao
   Joerg
 - Forwarded message from vecna ve...@s0ftpj.org -

 Delivered-To: jma...@thot.informatik.uni-kl.de
 Delivered-To: full-disclos...@lists.grok.org.uk
 Date: Wed, 15 Apr 2009 09:27:39 +0200
 From: vecna ve...@s0ftpj.org
 Organization: SALVIA  MENTA, azione TOTALE, aiuta a prevenire placca, 
 carie
 e disturbi gengivali.
 To: full-disclos...@lists.grok.org.uk
 Subject: [Full-disclosure] SniffJoke 0.3 release and request for feedback
 Errors-To: full-disclosure-boun...@lists.grok.org.uk

 Some days ago I've relased this:

 SniffJoke is a connection scrambler for Linux with the purpose of
 preventing packet sniffers from reassemble network sessions of the user.
 The sniffer evasion technology is well known since almost 10 years.
 SniffJoke implements the most efficents techniques. Using a local fake
 tunnel it is able to manage outgoing and ingoing packets without
 disturbing the kernel. With the local web interface the user can easily
 start/stop and configure SniffJoke. At the moment, Wireshark, the most
 famous packet analyzer, is unable to correctly reconstruct TCP flow
 mangled by SniffJoke. I would like to update the list of victim
 sniffers, so please send me a report if you test SniffJoke with other
 network protocol analyzers.

 http://www.delirandom.net/20090402/sniffjoke-03/
 http://www.delirandom.net/sniffjoke/


 Any comments appreciate

 Regards,
 vecna




 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/

 - End forwarded message -

 -- 
 Joerg Mayer   jma...@loplof.de
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] [Full-disclosure] SniffJoke 0.3 releaseandrequestfor feedback (forw)

[Sake Blok]

Hi Sebastien,

Unfortunately SniffJoke does a lot more (sending RST with bogus seq numbers, 
sending SYN/FIN/RST frames, etc, I have not looked at all the frames yet). It 
would take quite some effort and code to analyse the frames and consider the 
context to disregard them when doing a follow TCP stream. Even if we succeed 
in doing so, the sole purpose of SniffJoke is to be evasive, so they will 
definitely come up with new tricks and we end up in a battle writing code. 

Then think of the gain for wireshark users? If they are running SniffJoke 
themselves? Well then they know what data they did send, so no use in trying to 
extract it for them. If they sniffed the packets in between source and 
destination, let's keep the SniffJoke purpose intact and let the user have some 
form of privacy, people in between networks have no use looking into the 
payload IMHO, so lets not give them extra tools to do so ;-) Of course  and 
experienced WS user will be able to extract the data anyhow, just not easily. 
And if the WS user is at the server end analysing a problem of some client that 
is using SniffJoke, they see al the bogus traffic coming from the client and 
will tell them to clean up their act. So who is to benefit from code that tries 
to reassemble the SniffJoke traffic? Apart from the nice exercise to do so of 
course ;-)  But time is limited and there are more important things to be fixed!

Regarding the Expert Info, since there are packets with all kinds of TTL's and 
it would take a broader look at all frames to discover the right TTL, I would 
say it would be a bit tricky to create such an expert info item. Also, 
filtering on TTL alone won't do it, as you would need to save these frames to a 
new file first, otherise the bogus frames will still be used for reassembly.

Cheers,
 Sake
  - Original Message - 
  From: Sébastien Tandel 
  To: Developer support list for Wireshark 
  Sent: Monday, April 27, 2009 9:46 PM
  Subject: Re: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 
releaseandrequestfor feedback (forw)


  Hi Sake,




  ok, a (TTL-1) trick. Then if *every* tricks are based on this scheme, it 
could be verified with an expert item. This way, people knowing about SniffJoke 
could check this expert item and create a tcp filter based on the good ttl 
and re-assemble the TCP stream.


  What do you think?




  Regards,
  Sebastien Tandel


  On Mon, Apr 27, 2009 at 15:54, Sake Blok s...@euronet.nl wrote:

Sebastien,

One of the tricks SniffJoke uses is to first determine how many hops there 
are to the destination and then it sends bogus traffic with a TTL that is 
just 1 lower. This means the receiving OS never gets to see that traffic, while 
wireshark does (when it's in between the sender and the receiving end).

If the trace is made at the receiving end and wireshark is not able to 
reassemble the stream, then that might be considered a bug. Does anyone use 
SniffJoke? If so, could you please make a capture at the sending and the 
receiving end?

Since WS does not know which of the packets will not arrive at the 
receiving end, I'm no fan of incorporating code to handle those bogus frames.

Cheers,
Sake
  - Original Message - 
  From: Sébastien Tandel 
  To: Developer support list for Wireshark 
  Sent: Monday, April 27, 2009 7:28 PM
  Subject: Re: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 release 
andrequestfor feedback (forw)


 SniffJoke has a nice/interesting characteristic : It is *only* used by 
the sender *not* by the receiver. 


 SniffJoke, thanks to some tricks - which *does not* have impact on the 
receiver's TCP/IP stack (for all OSes?) -, is able fool sniffers and some 
others network tools.


 I would expect wireshark seeing the traffic as the OS is able to see 
it ... IOW, if receiver's OS is able to re-assemble correctly the traffic, 
wireshark should be able to do so too. Therefore, I would consider this as a 
bug in wireshark since OSes (all?) would be able to reassemble the traffic 
without any problem. (Although the next question would be : who will spend time 
to analyze SniffJoke tricks and fixes the TCP dissector?)


 Also, I'm not convinced people will think that wireshark would 
consider it as a cracking tool since the receiver's OS is considering this 
SniffJoke's traffic as valid ...




  Regards,
  Sebastien


  On Mon, Apr 27, 2009 at 11:45, Sake Blok s...@euronet.nl wrote:

As the purpose of Wireshark is to display network traffic to analyse
problems, I see no use in competing in a race to cloak and uncloak 
traffic
with Sniffjoke. That would put Wireshark in the list of cracking tools 
which
might have a negative effect on the places where it is allowed to be 
used.
So I would not consider this a bug and I would *not* consider being 
able to
reassemble Sniffloke traffic a feature

Re: [Wireshark-dev] Is 'mark all packets' functionality widely used(or is it useful?)?

[Sake Blok]

When you have filtered frames using a display filter, Mark All will mark all 
the displayed items. You can then use a different diplay filter to match some 
other packets, mark them and so on. Then you can save all the marked frames 
without having to use a super-complex display filter to match all the frames 
you want. 

So, yes... it is used :-)

However, when the focus is on the input widget for entering a filter, it might 
be nicer to have it bound to the same text editing function as you have in 
emacs. You could file an enhancement request for having the text editing 
options available in the filter input widget.

Cheers,
Sake
  - Original Message - 
  From: yami 
  To: Developer support list for Wireshark 
  Sent: Sunday, March 22, 2009 10:16 AM
  Subject: Re: [Wireshark-dev] Is 'mark all packets' functionality widely 
used(or is it useful?)?


  I see. Thanks!

  Of course we can mark the excluded ones and save 'unmarked packets' for this 
scenario, however I feel 'saving unmarked' is not intuitive for end users.


  On Sun, Mar 22, 2009 at 3:51 PM, Stephen Fisher st...@stephen-fisher.com 
wrote:

On Sun, Mar 22, 2009 at 03:08:05PM +0800, yami wrote:

 I can not figure out why marking all packets is a useful
 functionality. Could anyone kindly give some use cases?


You can mark all packets, then unmark certain ones before saving.


Steve

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 wireshark-dev@wireshark.org
  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 wireshark-dev@wireshark.org
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] Migration from Ethereal to Wireshark - differences

[Sake Blok]

On Thu, Jan 22, 2009 at 10:23:02AM -0800, Malaviya, Keyur wrote:
 
We are concerned about the sequence number differences and want to confirm
with you the reason for the difference.
 
From Wireshark Wiki, I found relative sequence number settings and as
per this Ethereal always starts with sequence number 0. But Wireshark
starts with sequence number 1 and it has one number higher for every
sequence number and ACK packets compared to ethereal. Why this difference?
Does Wireshark require some settings or parameter to be set?

Have a look at bug 1542
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1542)

the code that calculates sequence numbers has been corrected to behave
in a more predictable way when comparing tracefiles. Is it true that in
your capture file, the SYN or the SYN/ACK are missing?

Could you compare output of ethereal and wireshark on a capture file
that includes the whole TCP session (3way-handshake, data, FIN/FIN)?
Any differences now? If so, please provide full version information on
both ethereal and wireshark, the capture file and the relative sequence
numbers that ethereal produces on the first 5 packets (SYN, SYN/ACK,
ACK, data from client, ACK from server).

Cheers,
 Sake

PS  It's better to use the wireshark-users list for this type of question,
as it does not involve development, as it is more of a usage question.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Parsing SMB Packet

[Sake Blok]

Hi Mahendran,

I can reproduce your issue when I disable Allow subdissector to reassemble TCP 
streams. When I have that setting enabled, packet 47,51 and 55 show up fine.

Can you check that setting in the TCP protocol preferences and enable it if it 
was disabled (as I would expect, based on your findings).

Cheers,
 Sake
  - Original Message - 
  From: Mahendran 
  To: wireshark-dev@wireshark.org 
  Sent: Tuesday, December 23, 2008 7:51 PM
  Subject: [Wireshark-dev] Parsing SMB Packet


  Hi,

  I am using Wire Shark 1.0.5. 

  I am trying to capture the SMB packets using Wire Shark. It parses the SMB 
Request correctly but unable to parse the SBM Response that is sent from our 
device. The content are shown under Continuation Data. If it parses properly 
that will help me in analyzing the packets. Could you please help me?

  I have attached the capture for your analysis. Look at the packet no 47, 51 
and 55.

  Best Regards,
  Mahendran 


--


  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  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 wireshark-dev@wireshark.org
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] Utility to split pcap files?

[Sake Blok]

On Thu, Dec 18, 2008 at 05:44:26PM -0500, Nasif Ekiz wrote:
 Does anybody now an utility app running on FreeBSD to split large sized 
 pcap files into multiple smaller sized pcap files?

Have a look at 'editcap' which is included in the Wireshark
distribution :-)

Cheers,
 Sake
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Problem in wireshark pcap

[Sake Blok]

Well, as the IP length field is 0 instead of the proper length of the IP
datagram, I think the whole dissection of the IP payload is not done.
This makes the whole TCP segment look like a ethernet trailer, including
a FCS. Which of course will be incorrect... 

So the question is: Why is the IP length field set to 0?

Cheers,
 Sake


On Mon, Dec 01, 2008 at 11:16:35AM +1100, Martin Visser wrote:
It definitely looks a little crazy. What is interesting as well, is that
the captured frame has an incorrect frame check sequence - Frame check
sequence: 0x0d0a0d0a [incorrect, should be 0xde70a86f]. I don't know
whether this is coincidence, but the given FCS value  0x0d0a0d0a can be
represented in ASCII as CR LF CR LF. This maybe just a fluke but it is
curious, and It would steer to thinking you have some corruption. Is this
traffic passing through some HTTP application proxy before you capture it
by any chance?
 
Regards, Martin
 
[EMAIL PROTECTED]
 
On Sat, Nov 29, 2008 at 3:36 AM, prashanth s [EMAIL PROTECTED] wrote:
 
  Hi Harris,
   
  thanks for the reply.
  I am attaching here  a packet that has the bogus IP as the field.
  It has the HTTP POST within the bogus IP field.
  If you could you tell me what problem is there it would be very helpful
  for me.
  Regards,
  Prashanth
  On Thu, Nov 27, 2008 at 6:13 AM, Guy Harris [EMAIL PROTECTED] wrote:
 
On Nov 26, 2008, at 1:11 PM, prashanth s wrote:
 
 I am capturing the HTTP traffice on wireshark. However for HTTP POST
 messages I get in the Protocol Column of wireshark display, IP as
 the protocol name. And Info column of wireshark reads as Bogus IP
 length (0, less than header length 20).
 
That looks as if the packet data is somehow corrupted.  The IP header
has a total length field, giving the length of the IP datagram (not
including any link-layer headers); in the packet in the capture file,
that field has a value of 0, which is not valid - the length includes
the length of the IP header, so it must be = the length of the IP
header, and the header length appears to be the default minimum length
of 20 bytes.
 
Could you extract one of those packets into a capture file and send it
to us, so we can try to figure out what might have happened?
 
 Destination reads like Sonicwal_**:**:** 
 
That's presumably the link-layer destination, which is presumably some
device from SonicWALL:
 
   http://www.sonicwall.com/
 And HTTP POST is actually seen under the tree node Trailer under
 the subtree Ethernet II 
 
Ethernet frames have a minimum length of 60 bytes (64 bytes if you
include the FCS at the end of the frame).  This means that a short
packet might have to be padded out to that minimum length.
 
The Ethernet dissector tries to figure out what part of an Ethernet
packet is data and what part is the padding; the padding is called a
trailer.  It can only determine that if the protocol running on top
of Ethernet has a length field of some sort; IPv4 has such a length
field.
 
Unfortunately, in your packet, the length field has a bogus value, so
the Ethernet dissector thinks the entire IP packet is just padding.
 It should actually be decoding as TCP and under TCP it should be
HTTP.
 
That would happen only if there were a valid length field, so that
Wireshark knows how much of the data after the Ethernet header is the
IP packet and how much is padding.  That isn't the case, so the IP
dissector just gives up and doesn't call the TCP dissector, and the
TCP dissector then can't call the HTTP dissector.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
 
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  https://wireshark.org/mailman/listinfo/wireshark-dev

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

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

Re: [Wireshark-dev] regarding memory failure in wireshark

[Sake Blok]

On Fri, Nov 14, 2008 at 02:21:06PM +0100, Speck, Michael wrote:
 Hi Prashanth,
 
 AFAIK, Wireshark uses as much memory as it could allocate by your
 systems. 
 The longer Wireshark runs the more memory is used. 
 
 There are several solutions:
 First, you could install more RAM to your PC and/or increase the size of
 virtual (swap) memory.

This will not scale ;-)

 A second option is to use more then one capture
 files in a ring buffer fashion limiting each file's size to a reasonable
 (for your system) length. This could be easily configured in Wiresharks
 capture start dialog.

Unfortunately wireshark will not flush state information when starting
to write to a new file. This means that you will still run out-of-memory
in the end.

 A third option would be to capture only some bytes
 of each packet, but that is often not a good idea, especially if you are
 interested in the packet data.

This will also not scale ;-)


A fourth option would be to use dumpcap with a ringbuffer to do the
capturing and use wireshark to analyse the files you are interested in.
See: http://www.lovemytool.com/blog/2008/07/ostu_dumpcap.html

In this setup your disk space is the only limiter to the amount of trace
data you can keep, but you can let it run forever (I have used it for
months in several occasions).

Hope this helps,
Cheers,
Sake
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol dissector

[Sake Blok]

On Thu, Aug 07, 2008 at 03:57:46PM +0200, Luis EG Ontanon wrote:
 My vote goes for 2) :
 
 Wireshark is a troubleshooting tool and a vulnerable key can be source
 of trouble. It would be plainly wrong not to notify of a potential
 source of trouble if we can.
 
 I wonder whether we actually need to decrypt? I think we just need to
 build a hash of broken keypairs indexed by PubKeys and check the
 PubKey during the setup exchange, if the key is one of the well-known
 64k we just mark it.
 
 It would be also interesting to check for CA certs whose PrivKey is
 one of the well known 64k. Is that feasable?

OK, it's been a while, but no decission has been made for enhancing
Wireshark with Weak-Key detection and decryption.

I re-read all the mails in this discussion and it can be summarized as
follows:

- Most of us like the functionality of detecting weak keys

- Most of us dislike the cpu-load it would take, so there should
  be a preference for it which default to disable.

- Most of us dislike the idea that WS can be used as a cracking
  tool, so there should only be detection of the weak key and as
  little as possible information to the user on how to decrypt
  the traffic.

Is this something we can all (oh well, most of us) agree on? 

If so, I think the option of using hashes of the weak keys instead of
the keys themselves will address both the performance as the security
issue.

Cheers,


Sake
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev