Re: [Wireshark-dev] Capturing 10GbE on a Linux laptop?

[Jasper Bongertz]

Hi Richard,

I know there are some USB-C 10G network adapters (and the ProfiShark 10G, of
course), but I haven't tested any of them. Writing that much data to disk is
something I do with small portable servers (about the size of a small shoe box)
with a FPGA based capture card.

Cheers,
Jasper

Sunday, August 2, 2020, 7:03:05 PM, you wrote:

> Hi folks,

> Last year using my Cubro EX2+ I managed to capture around 600MB/s on
> my Lenovo P51 laptop.

> My P51 has a Thunderbolt 3 interface and has two 1TB NVMe storage
> devices that are capable of 2+GBps write speeds.

> I was aggregating multiple 1GbE interfaces into one of the 10GbE
> interfaces and then using a 10GbE to Thunderbolt 3 adapter.

> I had two Windows laptops and two OSX 10 laptops driving the load and
> interestingly the Apple laptops were generating more load than the
> Windows laptops via SMB2.

> My question is: Is there a Linux laptop out there that can handle that
> load. I have looked at System 76 and Librem but it does not seem they
> are capable of handling the load.




___
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] Proposed changes to make tcp.ack and tcp.seq relative

[Jasper Bongertz]

Hello Peter,

Tuesday, May 5, 2020, 1:46:13 AM, you wrote:

>> To avoid cluttering the TCP tree with redundant fields: can we only show the
>> absolutes if the relatives are also displayed? I don't think it's useful to
>> show the absolutes twice.

> Sure! The fields will be hidden in the view, but you will still be able
> to use them in filter expressions.

Good, I like it.

> On a related note, to address one of the use cases that prompted for the
> new field, I added expert info to mark connections where the server
> accepted TCP Fast Open (TFO) data. Is that useful to have?

Yes, that's useful to have, absolutely.

Would it be possible to mark TFO connections when they were NOT accepted as
well? That could be helpful, because right now I am not sure how I would find
failed TFO connections (except looking for SYN/ACK packets that fail). Or is
there an expert info that tells me that a connection used TFO and I can use the
field existence of the "accepted" TFO to check for it's absence to find failed
connections?
Unfortunately I have no example pcap for that scenario, so maybe this
functionality has to come as a later patch?

Cheers,
Jasper


___
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] Proposed changes to make tcp.ack and tcp.seq relative

[Jasper Bongertz]

Hello Peter,

> A request was filed earlier to add a new "tcp.ack_rel" field to ensure
> that color filters can be created that always work on the relative
> sequence numbers independent of the "Relative sequence numbers" option.
> Instead of adding a new field, I propose to change the existing ones.

> 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).

To avoid cluttering the TCP tree with redundant fields: can we only show the
absolutes if the relatives are also displayed? I don't think it's useful to
show the absolutes twice.

>  - Modify the "Relative sequence numbers" preference to affect the
>displayed value in the Info column only.

Good.

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

I guess you mean "were only visible when "Relative sequence numbers" was 
**enabled**?
At least that's what my Wireshark does, unless I'm not thinking straight right
now (at 1:30am, it's quite possible...) :-)

>  - Document these changes clearly in the release notes and corresponding
>user guides if needed.
>
> Are there any objections to this change?

No, sounds like a good solution (the "document clearly" is indeed critical here,
I guess). And I hadn't even noticed the new way of displaying
the relative sequence numbers in 3.2 yet :-)

Cheers,
Jasper


___
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] Brotli decompression

[Jasper Bongertz]

Hi Peter,

thanks for asking - I just checked (after having to abort looking into it) and
now it seems to be working, at least in the packet decode and the "Decompressed
Header hex view". Using "Follow HTTP2" still gives me gibberish though, but 
maybe
I'm using it wrong or haven't really understood what it's supposed to be doing 
:-)

Cheers,
Jasper

Friday, January 3, 2020, 10:31:30 PM, you wrote:

> Hi Jasper,

> Do you still have an issue? If so, can you check whether TCP reassembly
> is enabled?

> Kind regards,
> Peter

> On Thu, Dec 19, 2019 at 01:51:14PM +0100, Jasper Bongertz wrote:
>> Hi Anders,
>> 
>> you're right, it shows it's included... that means I have a different 
>> problem,
>> but good to know!
>> 
>> Thanks!
>> Jasper
>> 
>> Thursday, December 19, 2019, 1:42:54 PM, you wrote:
>> 
>> > Hi,
>> > On Windows it should be included, check About Wireshark
>> > Regards
>> > Anders
>> 
>> > -Original Message-
>> > From: Wireshark-dev  On Behalf Of 
>> > Jasper 
>> > Bongertz
>> > Sent: den 19 december 2019 13:30
>> > To: wireshark-dev@wireshark.org
>> > Subject: [Wireshark-dev] Brotli decompression
>> 
>> > Hello all,
>> 
>> >   I found this in the release notes of Wireshark 3.2:   "Brotli 
>> > decompression 
>> > support in HTTP/HTTP2 (requires the brotli library)"
>> 
>> >   Sounds great, but I can't seem to find any instructions how to add the 
>> > "brotli
>> >   library" to my Wireshark installation. I guess I need some DLL, but all I
>> >   could find are the Github pages with the source code. Does anyone have a 
>> > good
>> >   instruction set for Wireshark on Windows to enable Brotli?
>> 
>> >   I did a "Follow HTTP2 stream" and got unreadable stuff (decrypted first 
>> > with
>> >   SSLKEYLOG file), so I guess Brotli is  what I need to see the actual 
>> > page 
>> > contents...
>> 
>> > Thanks & cheers,
>> > Jasper
> ___
> 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



jas...@packet-foo.com


___
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] Brotli decompression

[Jasper Bongertz]

Hi Anders,

you're right, it shows it's included... that means I have a different problem,
but good to know!

Thanks!
Jasper

Thursday, December 19, 2019, 1:42:54 PM, you wrote:

> Hi,
> On Windows it should be included, check About Wireshark
> Regards
> Anders

> -Original Message-
> From: Wireshark-dev  On Behalf Of Jasper 
> Bongertz
> Sent: den 19 december 2019 13:30
> To: wireshark-dev@wireshark.org
> Subject: [Wireshark-dev] Brotli decompression

> Hello all,

>   I found this in the release notes of Wireshark 3.2:   "Brotli decompression 
> support in HTTP/HTTP2 (requires the brotli library)"

>   Sounds great, but I can't seem to find any instructions how to add the 
> "brotli
>   library" to my Wireshark installation. I guess I need some DLL, but all I
>   could find are the Github pages with the source code. Does anyone have a 
> good
>   instruction set for Wireshark on Windows to enable Brotli?

>   I did a "Follow HTTP2 stream" and got unreadable stuff (decrypted first with
>   SSLKEYLOG file), so I guess Brotli is  what I need to see the actual page 
> contents...

> Thanks & cheers,
> Jasper


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



jas...@packet-foo.com


___
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] Brotli decompression

[Jasper Bongertz]

Hello all,

  I found this in the release notes of Wireshark 3.2:   "Brotli decompression 
support in HTTP/HTTP2 (requires the brotli library)"

  Sounds great, but I can't seem to find any instructions how to add the "brotli
  library" to my Wireshark installation. I guess I need some DLL, but all I
  could find are the Github pages with the source code. Does anyone have a good
  instruction set for Wireshark on Windows to enable Brotli?

  I did a "Follow HTTP2 stream" and got unreadable stuff (decrypted first with
  SSLKEYLOG file), so I guess Brotli is  what I need to see the actual page 
contents...

Thanks & cheers,
Jasper


___
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] Visual studio 2019 from choco

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Visual studio 2019 from choco












Oh.  A very old and unsupported (by MS) version of Win 10. See here for lifecycle info: https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet



Indeed. It was a fresh install with no updates (due to network issues). I'm updating the system now: let's see if it suffices.
I'd add something in the docbook about using a supported version of windows, referencing your link.



In my experience it is significantly faster to download & install from scratch again from a recent ISO instead of going through all the update cycles to reach 1909... Those often take hours per cycle, and starting from 1511 probably means 1 or 2 days of patching to get there :-)



___
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] “bytes on wire” vs. “bytes captured”

[Jasper Bongertz]

Hi,

so if I get this right you expect to end up with a frame where length of the 
original
content is less than what ends up in the pcap because meta data is added? This
usually happens by adding a trailer to the Ethernet frame, e.g. some TAPs do
that to add high precision timestamps and other info. Which of course increases
the total length, because it's now part of the frame. And Wireshark can parse
that info if it knows/assumes that its attached.

If you have a capture device that wants to write additional detail about a frame
to the capture file you should choose pcapng instead. pcapng allows storing a
lot of additional information for each frame in the frame headers. This is a
much cleaner way, instead of merging frame and non-frame bytes together -
especially since other tools that can process pcap won't be able to distinguish
between the two.

If using frame headers like the ones in pcapng is not possible - why not? :-)

Cheers,
Jasper

Friday, July 19, 2019, 2:52:57 PM, you wrote:

> Hi,

> I was wondering about a fact regarding the reported frame lengths in 
> Wireshark.

> The frame dissector states “bytes on wire” and “bytes captured” values.
> I understand that these values where initially generated by the values caplen
> and len in the pcap packet header as follows:
> struct pcap_pkthdr {
> struct timeval ts;  /* time stamp */
> bpf_u_int32 caplen;   /* length of portion present */
> bpf_u_int32 len;  /* length this packet (off 
> wire) */
> };

> This is useful if the capture device cuts off data but wants to report the
> original length and thus tvbuff also provides the values length and 
> reported_length.
> struct tvbuff
> …
> /** Amount of data that's available from the capture
> * file.  This is the length of virtual buffer (and/or
> * real_data).  It may be less than the reported
> * length if this is from a packet that was cut short
> * by the capture process.
> *
> * This must never be > reported_length or contained_length. */
> guint length;

> /** Amount of data that was reported as being in
> * the packet or other data that this represents.
> * As indicated above, it may be greater than the
> * amount of data that's available. */
> guint reported_length;
> ….
> };

> Thus, as stated in the comment above length never must be larger than
> reported_length, which is true if the capture device drops data.

> Now my question: I would be very useful to use pcap’s caplen and len values
> to report original packet length while a capture device adds additional data
> to a frame, for example a header containing some more details about the frame 
> itself.
> In such a case, I would expect that pcap’s len would be set to the original’s
> frames length, while caplen would be frame length plus header length. That a
> header is present and how it can be decoded is detectable by the link layer 
> type.

> Unfortunately, when I tested this, Wireshark truncates reported_length,
> cutting of the data buffer which container the additional header information.

> Is there any reason for that type of implementation?
> It would be really great if Wireshark would report a “bytes on wire” value
> which actually shows the original frames length on wire, while “bytes
> captured” would show the larger value including the header part.

> BR,
> Holger


> Hilscher Gesellschaft für Systemautomation mbH   |  Rheinstrasse 15  |  65795
> Hattersheim  |  Germany  |  www.hilscher.com
> Sitz der Gesellschaft / place of business: Hattersheim  |  Geschäftsführer /
> managing director: Dipl.-Ing. Hans-Jürgen Hilscher
> Handelsregister / commercial register: Frankfurt B 26873  |  Ust. Idnr. / VAT 
> No.: DE113852715
> Registergericht / register court: Amtsgericht Frankfurt/Main

> Important Information:
> This e-mail message including its attachments contains confidential and
> legally protected information solely intended for the addressee. If you are
> not the intended addressee of this message, please contact the addresser
> immediately and delete this message including its attachments. The
> unauthorized dissemination, copying and change of this e-mail are strictly
> forbidden. The addresser shall not be liable for the content of such changed 
> e-mails.

> Wichtiger Hinweis:
> Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich
> geschützte Informationen, die nur für den Adressaten bestimmt sind. Sollten
> Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender
> umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte
> Weitergabe, das Anfertigen von Kopien und jede 

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

[Jasper Bongertz]

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






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.

We would like your feedback on that topic

kind regards
Roland



Hi,

I have seen at least three occasions where the fact that credentials were that easily accessed with a network analysis tool has resulted in a ban of that exact tool by upper management. In one case this affected a freshly bought license of Clearsight, which immediately after receiving the product ended up in a safe under lock and key, never again to see the light of day.

It may sound weird but this is one case of the typcail "what they don't know doesn't bother them". If this function is added some people will suddenly realize the potential that they are currently unaware of, so it's quite possible that Wireshark will be banned when it is currently fine to use it (in enterprise network that usually means admins only, anyway).

Cheers,
Jasper


___
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

[Jasper Bongertz]

>> 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 :-)

Yes, I tried it again after Chris Maynard said the same thing, and it worked. 
So it must have been one of those "I did something wrong even though I was sure 
I didn't" situations :-)

But the good thing is that Roland is now aware of all this for his planned 
rewrite of the profile handling code.

Cheers,
Jasper


___
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

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Wireshark hosts file location


Thanks, Chris, good point - I forgot the NRB as a source for name resolutions in my prio list. So it should be host > NRB > Answer records -> reverse lookup.

Thursday, March 21, 2019, 2:20:06 PM, you wrote:





See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11470
 
- Chris
 
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jasper Bongertz
Sent: Thursday, March 21, 2019 6:38 AM
To: Roland Knall ; Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Wireshark hosts file location
 
Hi Roland,

When network name resolution is enabled, Wireshark tries to resolve names via hosts file, DNS reverse lookup and by using DNS answer records it found in the pcap. There might be more mechanisms, but these are the ones I am currently aware of.

I would expect it to work like this: there should be a priority of the lookup where the hosts file has the highest priority because that's the one a user can influence and override values she/he doesn't like, e.g. things like DNS resolutions found in the pcap. Second are the DNS answers found in the pcap, and finally an active reverse lookup (unless disabled in the preferences)

For the hosts file, there should be a prioritized list of where to look: current profile folder, Wireshark install folder (because some people put theirs there in the past, like me), and finally the system hosts file. That would allow creating different profiles with alternative hosts files a user can switch.

Cheers,
Jasper




No, currently Wireshark does not switch hosts files with the profiles (to be quite honest, wasn't even aware, that we support something like using non-system hosts files at all).

Currently I am in the middle of rewriting the profile system and can put this on the todo list. Could you describe the behavior a little bit?

kind regards
Roland

Am Do., 21. März 2019 um 10:17 Uhr schrieb Jasper Bongertz <jas...@packet-foo.com>:




Hi Graham,

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?

Cheers,
Jasper


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








jas...@packet-foo.com
CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. 





jas...@packet-foo.com


___
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

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Wireshark hosts file location


Hi Roland,

When network name resolution is enabled, Wireshark tries to resolve names via hosts file, DNS reverse lookup and by using DNS answer records it found in the pcap. There might be more mechanisms, but these are the ones I am currently aware of.

I would expect it to work like this: there should be a priority of the lookup where the hosts file has the highest priority because that's the one a user can influence and override values she/he doesn't like, e.g. things like DNS resolutions found in the pcap. Second are the DNS answers found in the pcap, and finally an active reverse lookup (unless disabled in the preferences)

For the hosts file, there should be a prioritized list of where to look: current profile folder, Wireshark install folder (because some people put theirs there in the past, like me), and finally the system hosts file. That would allow creating different profiles with alternative hosts files a user can switch.

Cheers,
Jasper





No, currently Wireshark does not switch hosts files with the profiles (to be quite honest, wasn't even aware, that we support something like using non-system hosts files at all).

Currently I am in the middle of rewriting the profile system and can put this on the todo list. Could you describe the behavior a little bit?

kind regards
Roland

Am Do., 21. März 2019 um 10:17 Uhr schrieb Jasper Bongertz <jas...@packet-foo.com>:




Hi Graham,

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?

Cheers,
Jasper


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








jas...@packet-foo.com


___
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] Wireshark hosts file location

[Jasper Bongertz]

Hi Graham,

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?
  
Cheers,
Jasper


___
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] Npcap 0.9-r9 causing WiFi disconnect?

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Npcap 0.9-r9 causing WiFi disconnect?


Hi,

same here - I had strange WiFi disconnects in the past (and didn't connect it to Npcap, so that finally explains them), but not with the current version of npcap.

But I guess rolling out Wireshark 3.0 with Npcap now extremely increases the user installs of Npcap, so it's possible we see things now that didn't happen in a smaller install base :-)

Cheers,
Jasper

Wednesday, March 6, 2019, 10:08:10 AM, you wrote:





Hi Anders,

I do not face such issue with my Windows 10 1809 x64 build 17763, but had similar symptoms a few years back when testing development builds of Npcap on Windows 7 x64. Starting Wireshark was workarounding the issue.
Those users should go to https://github.com/nmap/nmap/issues to report their issue.

Regards,
Pascal.

Le mer. 6 mars 2019 à 10:02, Anders Broman  a écrit :




Hi,
I have had reports from users saying that they lost WiFi connections when installing Wireshark 3.0 (internal) and that uninstalling
Npcap 0.9-r9 solved the problem – anyone else seeing this? This is on Windows 10
(presumably something like Windows 10 (1709), build 16299 )
Regards
Anders
___
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 on Kali linux

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Wireshark on Kali linux








On Wed, 6 Feb 2019 at 17:32, Guy Harris  wrote:







So the question is whether we should print/pop up a message if TShark/Wireshark is running as root - and, if we do, whether we should have a compile or configuration option to disable that, so it can be disabled on Kali Linux or other OSes where you don't have much of a choice about whether to run them as root.




+1 for this.  I haven't entirely followed the preceding technical discussion as it's mostly about platforms I have little knowledge about, but this in general seems to be a fair approach.  Of course there will be those who have no need to run as "root", who will ignore the advice and disable the warning and continue to run as "root" on the way to ruin.  So be it, we will have tried.
 
--
Graham Bloice



+1 from me for this as well. The warning should be there for anyone not realizing that this is dangerous, but having the option to mute that warning for people who know (or think they do) what they're doing makes sense.


___
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] [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block

[Jasper Bongertz]

Michael Richardson wrote:
> Peter Wu  wrote:
> > Requirements for block placement:
> > - No requirement. Producers are allowed to write the block anywhere.
> > Disadvantages for consumers: requires a two-pass scan to collect
> > secrets before they are used.

> I prefer this, but I would support having a flag in the block that says that 
> no other blocks exist in the file until at least X-bytes.
> So, a producer (or something downstream of it), could scan for the blocks, 
> move them to the front, and indicate how far into the file it cover. 
> Naturally, if X >= file size, then the work is done.

I agree that this would be nice but I see technical difficulties with this. When
writing a block you have to assume that you don't know what's going to be
written next, so you don't know how far it is to the next block. pcap-ng files
are usually written by the producer as a stream of blocks, so you can't go back
to update a previous block when you write the next one.

Also, moving blocks around while writing a live capture is not an option when
it comes to heavy loads. Or did I misunderstand your idea?




___
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] Gerrit

[Jasper Bongertz]

Hello Peter,

I think calling it as "assigned to me" was a misinterpretation on my behalf.
Dario only wanted me to be cc'd in, as you assumed.

Thanks!
Jasper

Thursday, September 13, 2018, 11:26:07 AM, you wrote:

> Hi Jasper,

> On Tue, Sep 11, 2018 at 12:36:10PM +0200, Jasper Bongertz wrote:
>> Hi Dario,
>> 
>>   I saw you assigned a Gerrit change/ticket/thingy to me - I have to admit 
>> that
>>   I'm not really sure what to do there. I have no build environment for
>>   Wireshark at the moment, and I don't know what I'm supposed to do? Are 
>> those
>>   changes ending up in the automatic builds?

> The change (https://code.wireshark.org/review/29549) does not have
> downloadable builds. Not sure why Dario "assigned" you, it was probably
> an attempt to copy ("cc") you on the change to make you aware of it. I
> have not seen this assign function being used before.



___
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] Gerrit

[Jasper Bongertz]

Hi Dario,

  I saw you assigned a Gerrit change/ticket/thingy to me - I have to admit that
  I'm not really sure what to do there. I have no build environment for
  Wireshark at the moment, and I don't know what I'm supposed to do? Are those
  changes ending up in the automatic builds?

Cheers,
Jasper


___
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] New syntax for range support in membership operator: tcp.port in {1662-1664}

[Jasper Bongertz]

Hi,

+1 for the double dot syntax.

Cheers,
Jasper

Sunday, April 15, 2018, 3:03:53 PM, you wrote:

> Hi,

> In fact I would suggest to consider double dot (‘..’) in this case.
> Reasons:
> * It is a sufficiently unique operator
> * The minus causes too many conflicts, as you have stated
> * triple dot (‘...’, i.e. Ellipsis) is too prone to
> ‘autocorrection’ to the ellipsis symbol, causing copy-paste problems.

> Regards,
> Jaap



>> On 15 Apr 2018, at 13:24, Peter Wu  wrote:

>> Hi,

>> Laura requested support for ranges for the "in" display filter operator
>> in bug 1480 which seems like a reasonable idea. I have a prototype patch
>> working here: https://code.wireshark.org/review/26945

>> The initial implementation converted "f in {a-b}" to "f >= a && f <= b",
>> but this turned out to be problematic when a field has multiple
>> occurrences. To solve this, I added a new ANY_IN_RANGE DVFM instruction
>> that checks each field against the range.

>> One remaining issue is the syntax. The proposed syntax looks a bit ugly
>> with negative numbers, and is also not implemented for things other than
>> numbers. It can also be ambiguous.

>> Example: find SMB server timezone within UTC-0700 and UTC-0400):

>>smb.server_timezone in {-420--240}

>> Example: find all hosts in range 10.0.0.10-10.0.0.60. The CIDR notation
>> cannot be used to match this, instead you need something verbose like:

>>(ip.src >= 10.0.0.10 and ip.src <= 10.0.0.60) or
>>(ip.dst >= 10.0.0.10 and ip.dst <= 10.0.0.60)

>> A potential shorter version (not supported at the moment):

>>ip.addr in {10.0.0.10-10.0.0.60}

>> Another issue: the filter "data.data==1-3" is interpreted as matching
>> bytes "0103" (because data.data is of type FT_BYTES). The display filter
>> "data.data in {1-3}" is currently ambiguous (previously it matched the
>> previous "==" filter, after my patch it becomes "a single byte in range
>> 01 to 03"). One way to address this is to treat only "01:02:03" as byte
>> patterns and forbid "01-02-03".


>> With these cases, do you think that using "-" is a good range operator
>> for the set membership operator? An alternative range syntax suggestion
>> was proposed in doc/README.display_filter as:

>>(x in {a ... z})

>> Some possible ideas (I don't really like them to be honest):

>>tcp.srcport in { 80 1662 ... 1664 }
>>tcp.srcport in { 80 1662 .. 1664 }
>>tcp.srcport in { 80 [1662, 1664] }
>>tcp.srcport in { 80 range(1662, 1664) }

>> Feedback is welcome!
>> -- 
>> Kind regards,
>> Peter Wu
>> https://lekensteyn.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

smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Tools to anonymize pcaps with cellular/3gpp traffic

[Jasper Bongertz]

Hi Ivan,

> Only one note: AFAIK 3gpp/cellular protocols are not usually on top of
> TCP/UDP (with the main exception of GTP_U/C) but on top of SCTP (or
> even some SS7 stuff)

Thanks, I wasn't aware, but it doesn't surprise me - and it probably
makes things even more complex...

Cheers,
Jasper


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Tools to anonymize pcaps with cellular/3gpp traffic

[Jasper Bongertz]

Hi,

I learned that there is a tool that is supposed to be supporting lots
and lots of protocols (including Cellular stuff apparently), called
"SafePCAP". It's not free though, and I haven't tried it, so I have no
idea what it can or cannot do correctly.

https://omnipacket.com/safepcap.html

Cheers,
Jasper

Thursday, June 8, 2017, 3:09:25 PM, you wrote:

> Hi Ivan
> I went through a similar topic some time ago. The answer is:
> generally speaking, no. The tools you mentione target specific
> protocols, which are a few (ip/tcp/udp ecc), but the cover the
> majority of traffic. To go to upper layers you should know the
> semantic of the protocols you want to anonymize. Moreover, not all
> fields are straightforward to change. A 4 bytes integer can be, a
> string, whatever its format is, is not straightforward (you could go
> to a change in packet len, then lengths have to be changed, etc.).
> And that's not all: the fields you're changing could require changes
> in other fields. A stupid example: a protocol with an IP + a flag
> that indicates whether the IP is from net 10. would require to change both.
> If you want to target a specific procol, you should write a
> software that knows that protocol and that does the dirty work for you.
> Tracewrangler is the most advanced I know, but falls in the aforementioned 
> category.
> Bye.
> Dario.

> On Wed, Jun 7, 2017 at 8:54 PM, Ivan Nardi  wrote:

> Hi

> There are a few public available tools that anonymize pcap files,
> but they usually target L2-L4 layers and "standard" protocols (i.e. dns, 
> icmp,...)

> Is there any tool which sanitizes information carried on "3gpp"
> protocols (ranap, bssap, gsm_a dtap, gsm_map, sgsap...) or, at least, on some 
> of them?


> I am not looking for something particularly advanced: zeroing mcc
> and mnc (both in imsi and in cell/location information) should be
> enough, even without checksum updating.

> The goal is to easily share some pcaps without changing them with an 
> hex-editor by hand



> I know that I am asking for a very specific tool, but it's worth giving it a 
> try...


> Thanks in advance

> Ivan

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





jas...@packet-foo.com


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Tools to anonymize pcaps with cellular/3gpp traffic

[Jasper Bongertz]

Hi Ivan,

> There are a few public available tools that anonymize pcap files,
> but they usually target L2-L4 layers and "standard" protocols (i.e.
> dns, icmp,...)

There is a good reason for this: the complexity to anonymize anything
on top of L4 is a nightmare. UDP only haunts you with IP fragment
reassembly, which is not as easy as it may sound, but sanitizing TCP
based applications is like an instant migraine when I think about
segmented payloads.

The main reason why sanitization looks simple enough to most people is
that they assume that sanitization means "patching some zeros over
sensitive stuff at some offset, and you're done." - and it's something
else entirely if it is done correctly.

Real sanitization needs to parse/dissect the whole packet, extract all
information bottom up, and rebuild all layers with sanitized
values (where required) from the top protocol down. For that a
protocol parser/dissector needs to be written, and a protocol assembly
counterpart needs to be coded as well. This is exactly what I'm doing
in TraceWrangler.

> Is there any tool which sanitizes information carried on "3gpp"
> protocols (ranap, bssap, gsm_a dtap, gsm_map, sgsap...) or, at least,
> on some of them?

Not that I know of - mostly because few care about real sanitization
(most tools are "patching" tools), and nobody so far touches
applications on L5 and higher in a useful way (meaning, not simply
zeroing or randomizing everything). Well, TraceWrangler does, for
DHCPv4 and RTPS (both mostly because UDP is single packet stuff most
of the time), but that's it. DNS is still missing because it's hard to
do right, since it has that pesky pointer FQDN assembly mechanism
(sort of a compression algorithm) that is complicating things when
rebuilding the protocol layer.

The main point for me to implement protocols on top of L4 is if I can
get sample PCAPs and documentation on how to parse and rebuild them.
With those telecommunication protocols it seems to be one of the
classic deadlock situations: I need a PCAP to see how to sanitize it,
but nobody can share it without some sanitization first - and no, just
coding stuff based on protocol specs isn't working (probably because I'm
not a coder. I'm a network analyst that can write some sort of strange
code) :-)

> I am not looking for something particularly advanced: zeroing mcc
> and mnc (both in imsi and in cell/location information) should be
> enough, even without checksum updating.

Let me tell you, it may not sound advanced, but it is ;-)

Anyway, if you can get me PCAPs and Specs for the stuff on top of
TCP/UDP I can see what I can do. That's basically what happened for
RTPS (I thought it was simple, because it's on top of UDP... and then
IP reassembly was like 16tons coming down on me just when I thought I
was done) :-)

> The goal is to easily share some pcaps without changing them with an 
> hex-editor by hand

That's the main reason why I started writing TraceWrangler ;-)

Cheers,
Jasper


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Writing NoOp PCAP-NG Records

[Jasper Bongertz]

Hi Paul,

I see the problem, but isn't it possible to read the .etl file first to
extract the interface information, write the IDBs and then reread the
file to convert the blocks? Maybe this can even be done in a way
skipping having to read all of the .etl file first, reading from the
back instead (I have no idea how .etl is formatted at this time, so
maybe that's not possible - with pcapng it is easy as you can read
from the back).

If you want to go with your idea of keeping a null segment please
don't add a custom block (I think you mean "custom option", not
"custom block", which would be the equivalent of SHB, IDB, EPB etc.) if
it can be avoided. You could use the opt_endofopt code instead (which
has option code 0 anyway), meaning if you zero the rest of the block
it shouldn't hurt at all.

Cheers,
Jasper

Tuesday, July 5, 2016, 1:08:34 PM, you wrote:

> Hi,
>  
>  
>  
> I am writing a small utility that converts .etl network trace files
> produced by netsh trace into pcapng format.  The interface
> information is right at the end of the ETL file, but I need to
> create  IDBs near the start of the pcapng file.  I don’t want to
> hold a whole converted trace file in memory and I’d prefer not to
> shuffle the data around in the pcapng file.  My plan is:
>  
>  
>  
> ·Write an “IDB segment” of null bytes where the IDB will go
> – enough to accomodate the maximum anticipated IDB blocks, say 2 KB
>  
> ·Once I get to the interface data in the ETL, seek back to the “IDB 
> Segment”
>  
> ·Write the IDBs
>  
> ·Pad the “IDB segment” with the equivalent of NoOps
>  
>  
>  
> There is no NoOp block type and so I’m thinking of using a Custom Block
>  
>  
>  
> ·Would using a Custom Block in this way cause problems?
>  
> ·What value should I use for the Private Enterprise Number (PEN)?
>  
> ·Is there a better way of doing this?
>  
>  
>  
> Thanks and regards…Paul
>   
> 
> __
>  
>  This message contains confidential information and is intended
> only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>  
>  Any views or opinions expressed are solely those of the author and
> do not necessarily represent those of Advance Seven Ltd. E-mail
> transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses. The sender therefore does
> not accept liability for any errors or omissions in the contents of
> this message, which arise as a result of e-mail transmission.
>  
>  Advance Seven Ltd. Registered in England & Wales numbered 2373877
> at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
>  
> 
> __
>  This email has been scanned by the Symantec Email Security.cloud service.
>  For more information please visit http://www.symanteccloud.com
> 
> __
>   


smime.p7s
Description: S/MIME Cryptographic Signature
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Dumpcap 2.x trouble

[Jasper Bongertz]

Hi all,

  I noticed that captures taken with Wireshark 2.x (meaning, with
  dumpcap coming with those versions) showing unexpected results (see
  Glossary below for the abbreviations).

  With 1.12, the dumpcap version is written to the application option
  field in the SHB, and the OS build in the OS option field. Both
  values are omitted in 2.0.2 and later. As far as I can tell the OS
  is now written as option code 12 to the IDB instead, but the capture
  application is not found anywhere. And Wireshark does not show the
  IDB OS option anymore anywhere (yet?). I think losing the capture
  application is not a good idea, especially when we change behaviour
  of dumpcap all of a sudden:

  In the latest 2.1.x dev builds the start/end timestamp options
  (called isb_starttime and isb_endtime) for the ISB are written in
  the wrong order, as lo-hi values instead of hi-lo (like it is
  specified in the PCAPng specs) - in 2.0.2 they are written
  correctly (from my point of view, at least).

  I have to admit that the latest PCAPng specs are a confusing in this
  point though - they state "format as for the EHB" (which is Hi-Lo,
  clearly), but the examples for the options mentions "Little Endian"
  and is given in Lo-Hi order (which contradicts the EHB order).

  Frankly I don't see the point why we should do Lo-Hi now all of a
  sudden, as it makes it more complex to read PCAPng files from now
  on. There is no good way to tell how to read the timestamp values,
  especially with the capture application being unknown. Having to
  try-catch the values (meh!) to find the right order when dealing
  with PCAPng files after 2.1.x is released is a workaround at best.
  And we can't really depend on the capture application value even if
  it is present for this anymore.

  But maybe there's a good reason for that kind of change to the
  timestamp order I can't see right now?

  Short Glossary:
  SHB = Section Header Block
  IDB = Interface Description Block
  ISB = Interface Statistics Block

Cheers,
Jasper


smime.p7s
Description: S/MIME Cryptographic Signature
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] MPLS dissection fail

[Jasper Bongertz]

Hi all,

I just added a bug report, as agreed with Alexis, regarding the
dissection failure in 1.99 when a frame contains MPLS shims. This is
the bug report URL:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271

and I also attached a screen shot comparing 1.12.5 and 1.99 to this
email (I hope it doesn't get stripped off by the list)

Cheers,
Jasper

smime.p7s
Description: S/MIME Cryptographic Signature
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Translation tools

[Jasper Bongertz]

Hi all,

FYI, for the fun of it I started working on the German translation for
the QT UI. Just in case someone else gets the same idea.

Cheers,
Jasper


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] How WIRESHARK confirm the TCP OUT-OF-ORDER packet!

[Jasper Bongertz]

Hello Jeff,

Out-of-order is basically a packet that arrives just a little too late
to be in-sequence, but is not a retransmission. It's the original
packet, which somehow got rearranged on the way to the destination so
that it arrives after a packet following it in sequence. WAN
optimizers sometimes do this, squeezing in smaller packets that arrive
earlier at the destination than the larger predecessors.

It makes sense to call those packets out-of-order because they are not
retransmissions (which would mean packet loss) to avoid
misinterpretation.

To get to the original question: I have seen another case where a
retransmission was labeled out-of-order. It has probably to do with
the recent change of including iRTT to determine out-of-order vs.
retransmission (new in 1.12), and that may need some fine tuning. I'm
investigating already to see if there really is a problem and how we
can improve the algorithm if there is.

Cheers,
Jasper

Monday, September 15, 2014, 7:19:34 PM, you wrote:

 On 09/15/14 03:10, 李凌 wrote:
 Hello,everyone!
 It is my pleasure to write here for you.
 I've got some problems with the wireshark that how the software confirm
 if the tcp packet is out-of-order or not.
 I captured a pcap file named 'example.pcap',in this file No.507, No.508
 ,No.509 make me confused：
 （because the pcap file is too large ，it is more than 7MB，so I have to
 export  the right packets as plain text named No507-No509.txt ）
 507IP_ID:15689TCP_SEQ:727452
  508IP_ID:15690TCP_SEQ:669373--out of order
  509IP_ID:15691TCP_SEQ:670825--TCP retransmission
 No.508 Packet has a IP header ID that is 15690 which is bigger than
 No.507.This means the server sended No.508 packet after No.507
 packet,and wireshark captured them the same way .So,as I known ,No.508
 may be a retransmission instead of out-of-order packet.However,
 wireshark tags a out-of-order flag on No.508 which makes me confused,Is
 there any rule I don't get? I got nothing on the Internet about this
 question ，could you please help me？

 Yeah, I have never really understood what out of order really means.
 In my mind a packet would either be a retransmission (something which 
 should have come before the last packet we've seen) or it's ahead of the
 last packet we've seen (indicating we've missed one or more packets).

 The idea behind out of order is, I believe, to indicate when something
 is too far out of order to be a retransmission or a simple  hole in 
 the sequence (i.e., a couple of missed packets).  Here's the logic 
 Wireshark uses to determine if a TCP segment is out of order:

 /* If the segment came relativly close since the segment with the 
 highest
  * seen sequence number and it doesn't look like a retransmission
  * then it is an OUT-OF-ORDER segment.
  */
 t=(pinfo-fd-abs_ts.secs-tcpd-fwd-nextseqtime.secs)*10;
 t=t+(pinfo-fd-abs_ts.nsecs)-tcpd-fwd-nextseqtime.nsecs;
 if( t  ooo_thres
  tcpd-fwd-nextseq != seq + seglen ) {
 if(!tcpd-ta) {
 tcp_analyze_get_acked_struct(pinfo-fd-num, seq, ack, TRUE, 
 tcpd);
 }
 tcpd-ta-flags|=TCP_A_OUT_OF_ORDER;
 goto finished_checking_retransmission_type;
 }

 ___
 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



jas...@packet-foo.com


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Initial RTT

[Jasper Bongertz]

 2014-07-02 20:59 GMT+02:00 Jasper Bongertz jas...@packet-foo.com:

 Hello,
  
    as promised during Sharkfest, I checked the latest developer builds
    for the accuracy of the calculation of initial RTT for TCP
    connections. So far I have only seen correct results, even in cases
    with heavy packet loss during the three way handshake. So I think
    the code is good.
  
    I also checked traces where the TCP expert was incorrectly assuming
    a retransmission when it was in fact an out-of-order packet. Those
    are now correctly identified, at least when we have the handshake
    and thus initial RTT. Thumbs up for that.
  
    Regarding the way to handle missing handshakes - I would go with the
    old 3ms arbitrary value in that case, because most Wireshark
    captures are taken in local network environments. Higher values are
    problematic because retransmissions are not flagged anymore and
    called out-of-order instead, which could lead to a lot of confusion
    out there. I prefer false positives for retransmissions over
    out-of-orders.
  
    Again, thanks for the effort!
  
  Cheers,
  Jasper

 Hi,

 if it is working great (Evan changed the timer back to its old 3ms
 arbitrary value in case we do not have the handshake) would it make
 sense to backport this change from the development branch to the
 1.12 one (before Wireshark 1.12 gets released)?
   

 Regards,
 Pascal.

yes, it would definitely be nice to have it in 1.12 if possible.

Cheers,
Jasper

jas...@packet-foo.com


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Initial RTT

[Jasper Bongertz]

Hello,

  as promised during Sharkfest, I checked the latest developer builds
  for the accuracy of the calculation of initial RTT for TCP
  connections. So far I have only seen correct results, even in cases
  with heavy packet loss during the three way handshake. So I think
  the code is good.

  I also checked traces where the TCP expert was incorrectly assuming
  a retransmission when it was in fact an out-of-order packet. Those
  are now correctly identified, at least when we have the handshake
  and thus initial RTT. Thumbs up for that.

  Regarding the way to handle missing handshakes - I would go with the
  old 3ms arbitrary value in that case, because most Wireshark
  captures are taken in local network environments. Higher values are
  problematic because retransmissions are not flagged anymore and
  called out-of-order instead, which could lead to a lot of confusion
  out there. I prefer false positives for retransmissions over
  out-of-orders.

  Again, thanks for the effort!

Cheers,
Jasper


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] master 104a6ed: Disable IPv4 checksum verfification to match TCP and UDP.

[Jasper Bongertz]

 On Sat, Mar 01, 2014 at 01:49:58PM +, Wireshark code review wrote:
 URL: 
 https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=104a6edd1fb703c5c2319c893720df86f8c9a9e7
 ...
 104a6ed by Gerald Combs (ger...@wireshark.org):
 
 Disable IPv4 checksum verfification to match TCP and UDP.
 
 Offloading seems to be very common nowadays and having this option
 enabled by default generates a lot of false positives. Suggested by
 Laura Chappell.
 
 Change-Id: I285f218efb3c9f164d8ad7a6d6de8270e442

 While this is currently the right thing to do, it might make more sense
 to disable all this checksum verification stuff only for outgoing traffic.
 Unfortunately our current captures don't support that distinction. What
 would be required where to make this possible?
 My guess:
 - Add a metadata element direction to the capture information provided
   by the network driver and
 - add direction element to libpcap packet header and fill it with the
   information from above.
 How much work would that amount to?

The pcap-ng file format has packet blog flags in the EPB block type,
which has two bits to indicate direction (00 = information not
available, 01 = inbound, 10 = outbound). I don't think those flags are
being  set by dumpcap as of now, but it would be the way to go from my
point of view.

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

Cheers,
Jasper



___
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] What is the history and status of PCAP Next Generation?

[Jasper Bongertz]

Sorry to answer this late; I saw this email a week ago but didn't
manage to reply - the todo got swapped out but never swapped in again.
Graham gave me a heads up (that I didn't see until now, either,
*sigh*), so here I go.

  Q2: What is the status of pcap-ng?
 
  * it works fine, everyone's using it, it just isn't an RFC
   or * it's an abandoned effort, plain pcap is good enough
   or * all development has moved to X, take a look at X

 It works fine, some software's using it, and there's no RFC for
 pcap format, either, although there probably should be informative
 RFCs for both of them at some point.

At Sharkfest 2013 we (me, plus the Wireshark devs that were in
range) had a impromptu meeting regarding the status of the PCAP-ng
specifications.

I offered to see if we can go in the direction of an RFC, but got a
bit sidetracked. I had checked how the procedures work in July/August, but
at the time the RFC submission process was closed for new submissions.
It should be open again by now, so I'll try to go forward asap.

Oh, and regarding the status of PCAP-ng I'd say it is more like a
couple of tools are using it, but most are still stuck on pcap for
whatever  reason.

Cheers,
Jasper


___
Sent via:Wireshark-dev mailing list 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] Start and stop capture toolbar buttons?

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Start and stop capture toolbar buttons?


 Either way, we aren't going to have any hard data for the expected release of 1.10 unless that gets bumped back a *lot*. The best we can do is probably a quick poll, so I've created  just that:

https://docs.google.com/forms/d/1VFyNGmHtbdl827XziWGIHX5KfoxuF4MIaigzQAJph00/viewform

 Hopefully the results will be illuminating.

 Maybe the poll should be sent to the users list as well?

I could forward the poll to the quite large Wireshark group in the german XING community (sort of a european LinkedIn site), but I think the poll isn't explaining itself enough for anyone who hasn't read the discussions in this mailing list. Maybe we can have an additional intro text on the poll page to make sure people unterstand what the poll is for?

Cheers,
Jasper

jas...@packet-foo.com




___
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] PCAPng Name Resolution Blocks

[Jasper Bongertz]

Hi all,

can anyone tell me when Wireshark/Dumpcap will actually write a Name
Resolution Block to a pcapng file? I have a file written with an older
dumpcap version (I guess it was pre 1.8) that contains a NRB but the
latest 1.9 build doesn't seem to do that at all.

I tried with DNS queries enabled, and even edited a hosts file to see
under which circumstances the resulting pcapng file would contain a
NRB. It didn't work, no matter what I tried. Is it possible that the
code writing this kind of block is not being called anymore?

I'd expect Wireshark to write a NRB containing all records whenever a
name resolution is not coming from DNS packets contained in a file
(which would make it reproducable when opening the file, even without
the NRB).

Thanks,
Jasper

___
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] pcapng options

[Jasper Bongertz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02.11.2012 04:23, Guy Harris wrote:

 Is it legal to have a pcap-ng file that contains a block with
 options that does not contain an opt_endofopt option?
 
 My inclination would be to say yes, to indicate that option
 processing must stop when you reach the end of the block even if no
 opt_endofopt option is seen, but also indicate that option
 processing should stop when an opt_endofopt block is seen, even if
 there is more data remaining in the block.  So my inclination would
 be to say:
 
 option processing MUST stop when you run out of data in the block;
 
 option processing MUST stop when you see an opt_endofopt block;
 
 option lists that contain at least one non-opt_endofopt option
 SHOULD also have an opt_endofopt option at the end;
 
 and possibly change the last SHOULD to MUST in order not to upset
 code that *doesn't* check for the end of the block, even if that
 code is insecure.

I agree. The opt_endofopt is a nice-to-have in my eyes, because - as
Guy said - you need to check that your code is not running past the
end of a block anyway, and that requires keeping track of where you are.

I think we can go for a MUST on the last one as well; code that
reads pcap-ng still has to expect that there is no opt_endofopt
because of the first rule.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQk8fgAAoJELMLD8F06bDgD7MH/AsYbtcrMRGuk6rtG8uCcgjd
8sMzkCYuDQGuiBDCciCxCri/FFPdAx8Vm1U3R7Eu8ANfgcQRRDh2bhcWwTUMM/i/
QJ1BCtF1I3cfgg2+Lt0n1gotkQ8NUg9T+Tv5zYxESR8CvjvCHj1m5CFnZzDOiVex
7kZgbv2sP3rnZVWpBxhEPyPx5dbNzZgIfIQD4DzBo30+tspIBUmWUqLT4fKXWl/G
I+Gldeoepyv/tYbXkRk6vqmoF2uUX1Nhd5vBuD1R3f+hLMF6l7gT3H+NYFkmtdH/
38p/udIsZHXFC5H2txvsUBSJGi1Wxs/XznrATwRIwusPLGmz81VFLpsqiegMMWc=
=bkYP
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Random feature and enhancements ideas (topics for Sharkfests developers room?)

[Jasper Bongertz]

Title: Re: [Wireshark-dev] Random feature and enhancements ideas (topics for Sharkfests developers room?)


Hi Anders,





- The defined blocks are capture oriented should we define some analysis re-saving oriented ones.
 - UDP/TCP/SCTP... port map similar to the NRB (think decode as)
 - Read filter used ( save filtered trace)
 - File history ( saved file A as B (using read filter X) ...) 



The port map could be a little problematic unless you have a "well known port list" to map ports to. Maybe the official IANA list could be used for that though, but I guess there are application ports that have no official port in that list that could not be mapped then... Anyway, I guess a new optional blocktype would make sense for this kind of thing.

The read filter and the file history could be added as text option fields to the SHB, so that should be simple enough.

By the way, I just asked for some additional options added to the specs on the pcap-ng development mailing list, too :-)

Best regards,
Jasper




___
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