[Wireshark-dev] Dissector submitted
Hello, I'm new to this so I want to make sure that I submitted my ged125 dissector properly. It is bug # 2692. Also, I will probably make changes to this dissector in the near future as Cisco uses this. I did fuzz test but there are a few parts that couldn't be well tested at this moment. Is there an easy way I can quickly modify the sources I submitted without going through reporting a bug since I'm the only original author of the dissector? Thanks, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] assigning bugs
Hi, There's no real assignment process. The default assignee (wireshark-bugs) is the mailinglist everyone can subscribe to to track bug changes. It's usually best to leave it that way so everyone stays informed. That doesn't mean you're not invited to submit patches ;) Thanx, Jaap Edward J. Paradise wrote: > How are bugs normally assigned? I just opened up 2690 > (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2690 > ) which has an easy fix for packet-pppoe.c. I wouldn't mind fixing it > myself as I would like to enhance the current support for rfc4938 and > rfc4938bis to include filtering and inband credit grant decoding in > this dissector. -ed ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] assigning bugs
How are bugs normally assigned? I just opened up 2690 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2690 ) which has an easy fix for packet-pppoe.c. I wouldn't mind fixing it myself as I would like to enhance the current support for rfc4938 and rfc4938bis to include filtering and inband credit grant decoding in this dissector. -ed ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build-in
Hi, If your dissector is a single dissector file, possibly with include file, it might be better to include in libwireshask. Therefore you'll need to move your dissector to epan/dissectors and add it's name to epan/dissectors/Makefile.common. Just like README.developers tells you. The extra stuff described in README.plugins can be omitted. Thanx, Jaap Basically Martin Corraine (mcorrain) wrote: > Hello, > > I'm nearly ready to submit my first dissector. Currently, I have the > dissector set up as a plug-in. However, after reading I've found out > that the community usually prefers a build-in dissector. How do I go > about making this change? > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Build-in
Hello, I'm nearly ready to submit my first dissector. Currently, I have the dissector set up as a plug-in. However, after reading I've found out that the community usually prefers a build-in dissector. How do I go about making this change? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH]: enhanced "what's past last mpls label?" heuristic
Hi,
Please read http://www.wireshark.org/docs/wsdg_html/#ChSrcSend about
submitting patches for Wireshark. Just to make sure it doesn't get lost.
Thanx,
Jaap
Francesco Fondelli wrote:
> Hi all,
>
> Attached is a patch for:
>
> - PW Associated Channel Header dissection as per RFC 4385
> - PW MPLS Control Word dissection as per RFC 4385
> - mpls subdissector table indexed by label value
> - enhanced "what's past last mpls label?" heuristic
> - Ethernet PW (w/o CW) support as per RFC 4448
>
> The new logic to dissect data after last mpls label is:
>
> if (!dissector_try_label(mpls_subdissector_table, label, ...)) {
>if (nibble == 6) {
>call_dissector(ipv6_handle, ...);
>} else if (nibble == 4) {
>call_dissector(ipv4_handle, ...);
>} else if (nibble == 1) {
>dissect_pw_ach(next_tvb, ...);
>} else if (nibble == 0) {
> if (looks_like_plain_eth(next_tvb)) {
> call_dissector(eth_withoutfcs_handle, next_tvb, ...);
> } else {
> dissect_pw_mcw(next_tvb, ...);
> }
>} else {
> call_dissector(eth_withoutfcs_handle, ...);
>}
> }
>
> The mpls protocol dissector has now a subdissector table indexed by label.
> If the user specifies a binding (through "Decode as...") label N <--> proto X
> wireshark will pass data past last mpls label to dissector X. If there is
> no label2proto binding the legacy "first nibble based" algorithm (corrected
> and
> enhanced) is used.
>
> the original code was:
>
> if (ipvers == 6) {
>call_dissector(ipv6_handle, next_tvb, pinfo, tree);
> } else if (ipvers == 4) {
>call_dissector(ipv4_handle, next_tvb, pinfo, tree);
> } else if (ipvers == 1) {
>dissect_mpls_control(next_tvb, pinfo, tree);
> } else {
>call_dissector(eth_withoutfcs_handle, next_tvb, pinfo, tree);
> }
>
> dissect_mpls_control() is now called dissect_pw_ach() (ach stands for
> Associated Channel Header) as per RFC 4385 terminology.
> dissect_pw_mcw() (mcw stands for MPLS Generic/Preferred Control Word)
> is called only if the first nibble is 0 (as per RFC 4385) and if the
> first 12 bytes of data look like two mac addresses.
>
> Ethernet PWs are common nowadays with and without CW (control word:
> 4 bytes between last mpls label and the encapsulated ethernet header)
> in service provider networks. I have been told few times that
> "wireshark doesn't work" because of the CW presence. This patch
> "automagically" provides a valid dissection in most common "eth
> PWs with/without CW" cases.
>
> Moreover, this patch allows wireshark users to manually provide info
> in case the heuristic fails.
>
> If you accept this changes new dissectors, one for each type of PW
> encapsulated traffic, can be easily implemented (packet-pw-eth.c is
> provided as a starting point).
>
> - Structure-Agnostic Time Division Multiplexing (TDM) over Packet
> (SAToP) (RFC 4553)
>
> - Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service
> over Packet Switched Network
> (CESoPSN) (RFC 5086)
>
> are at the top of my to-do list.
>
> I have used and fuzz-tested this code. Please check it in.
>
> Ciao
> FF
>
> ps
> patch is against svn #25387 but unfortunately is a "diff -ru dir1 dir2"
> because I cannot "svn diff" anymore due to bad bad proxy settings,
> sorry, it should work fine anyway.
>
> pps
> bug report is #2689
>
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LLRP dissector support
I've rewritten the guts of this dissector to remove all of the buffer portability abstraction. A new patch has been added to the bugzilla case. Please let me know if it's acceptable. Thanks, Matt Poduska -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter Sent: Tuesday, April 08, 2008 10:59 AM To: [EMAIL PROTECTED]; Developer support list for Wireshark Subject: Re: [Wireshark-dev] LLRP dissector support Hi, I have to refer back to my earlier statement: "the code is very hard to read. I can't really comment beyond that.". What John and you are asking is that we actually read it, understand it and see how this could be accepted. That is the whole point. If you would give it another go we are willing to give it a shot, just like any other dissector. Thanx, Jaap Matt Poduska wrote: > Is there anything other than the use of the portability wrappers that > are preventing this dissector from being accepted (making the code > very hard to read and maintain)? > > Please let me know what needs to change in the dissector in order to > be accepted. > > - Matt Poduska > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter > Sent: Tuesday, April 08, 2008 1:17 AM > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] LLRP dissector support > > Hi, > > Well, as the general comment states "the code is very hard to read". I > can't really comment beyond that. > If the code is reasonably written and understandable and adheres to > the coding guidelines found in README.developer it shouldn't be a big > problem getting it in. > > Thanx, > Jaap > > John R. Hogerhuis wrote: >> Jaap Keuter <[EMAIL PROTECTED]> writes: >> >>> Hi John, >>> >>> I've been looking at this submission from the start, and frankly I >>> don't like it. It is like Ronnie says in >>> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1957#c4, this >>> code is very hard to read, let alone maintain. >>> I don't want to sign off on that and burden myself and other with >>> the maintenance chores. So I left it alone for another core >>> developer to eventually pick it up. It seems none is confident enough to commit it. >>> >> Well that's a clear statement of the problem, thanks for the reply. >> >> It appears Matt is responding favorably to requests to make specific >> improvements. General criticisms about hard to read/maintain and how >> he has abstracted the message parsing are obviously harder to address. >> My understanding is that parts of the code are generated based on XML >> descriptors of the binary protocol available from >> http://sourceforge.net/projects/llrp-toolkit (I am a developer for >> this > project but not the LLRP dissector). >> If the code could be simplified to avoid wrappers are there other >> issues for you or Ronnie that would stand in the way of commit? >> >> Thanks, >> >> -- John. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Teamspeak2 Dissector
Just a friendly reminder that I have addressed the comments you made on the bug (2373) with a new patch and am waiting for more feedback. Thank you Brooss Jaap Keuter wrote: > Hi, > > You caught us in a busy time, working towards 1.0.0. I've looked at it and > added some comments. Lets keep working on it in bugzilla. > > Thanx, > Jaap > > Brooss wrote: > >> Hi wireshark-dev, >> >> A few months ago I completed work on a TeamSpeak2 dissector and posted >> it on the bug tracker (2373). >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2373 >> No one seems to have had a chance to review it yet but I would >> appreciate some feedback on the chances of it getting checked in. >> >> Thank you >> Brooss >> > > ___ > 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] buildbot failure in Wireshark (release) on OSX-10.5-x86
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark (release). Full details are available at: http://buildbot.wireshark.org/release/builders/OSX-10.5-x86/builds/16 Buildbot URL: http://buildbot.wireshark.org/release/ Buildslave for this Build: osx-10.5-x86 Build Reason: Build Source Stamp: HEAD Blamelist: gerald BUILD FAILED: failed shell_3 sincerely, -The Buildbot ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] malformed packet
Martin Corraine (mcorrain) wrote: > Hello, > > If I check a packet's header and size and return 0 because it wasn't my > protocol (GED125), should I get the following message: "Malformed > Packet: GED125"? Probably not. Are you sure it's actually returning 0 for that packet? It sounds like your dissector generated an exception (normally because it read beyond the end of a TVB). Maybe you need to check tvb_length() before the rest of your heuristic checks? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] col_set_str not working from plugin ?? bug 1967
Gilles Dufour (gdufour) wrote: > Hi, > > I used to do this a few years ago, but I might be a bit rusty :) > > I have a plugin/dll dissector that I created and it works fine except I > never get the column text to be modified. > Whatever the column. > I tried many different commands (you will see it in the code below). > Even tried to create my own col_set_str - called mcol_set_str [...] > I found a bug that is an exact match of my problem > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1967 Did you, as mentioned in the bug, recompile your plugin against the source for the version of Wireshark you are running? (That is, plugins generally cannot be compiled against version X and run in version Y.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] malformed packet
Hello, If I check a packet's header and size and return 0 because it wasn't my protocol (GED125), should I get the following message: "Malformed Packet: GED125"? Thanks, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] col_set_str not working from plugin ?? bug 1967
Hi,
I used to do this a few years ago, but I might be a bit rusty :)
I have a plugin/dll dissector that I created and it works fine except I
never get the column text to be modified.
Whatever the column.
I tried many different commands (you will see it in the code below).
Even tried to create my own col_set_str - called mcol_set_str
I'm just clueless and would appreciate some help.
The protocol runs on top of UDP. Again everything else works so I know
the dissector is correctly called.
gboolean dissect_ace_hb (tvbuff_t *tvb, packet_info *pinfo, proto_tree
*tree)
{
proto_item *ti;
proto_tree *ace_tree;
int offset;
// col_set_writable(pinfo->cinfo, TRUE);
if (check_col(pinfo->cinfo, COL_PROTOCOL)){
col_clear(pinfo->cinfo, COL_PROTOCOL);
col_set_str(pinfo->cinfo, COL_PROTOCOL, "ACE-HB");
//mcol_set_str(pinfo->cinfo, COL_PROTOCOL, "ACE-HB");
//col_add_fstr(pinfo->cinfo, COL_INFO,"%s","ACE-HB");
}
/* Clear out the Info column. */
if (check_col(pinfo->cinfo, COL_INFO))
col_clear(pinfo->cinfo, COL_INFO);
I found a bug that is an exact match of my problem
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1967
Thanks,
Gilles.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH]: enhanced "what's past last mpls label?" heuristic
Hi all,
Attached is a patch for:
- PW Associated Channel Header dissection as per RFC 4385
- PW MPLS Control Word dissection as per RFC 4385
- mpls subdissector table indexed by label value
- enhanced "what's past last mpls label?" heuristic
- Ethernet PW (w/o CW) support as per RFC 4448
The new logic to dissect data after last mpls label is:
if (!dissector_try_label(mpls_subdissector_table, label, ...)) {
if (nibble == 6) {
call_dissector(ipv6_handle, ...);
} else if (nibble == 4) {
call_dissector(ipv4_handle, ...);
} else if (nibble == 1) {
dissect_pw_ach(next_tvb, ...);
} else if (nibble == 0) {
if (looks_like_plain_eth(next_tvb)) {
call_dissector(eth_withoutfcs_handle, next_tvb, ...);
} else {
dissect_pw_mcw(next_tvb, ...);
}
} else {
call_dissector(eth_withoutfcs_handle, ...);
}
}
The mpls protocol dissector has now a subdissector table indexed by label.
If the user specifies a binding (through "Decode as...") label N <--> proto X
wireshark will pass data past last mpls label to dissector X. If there is
no label2proto binding the legacy "first nibble based" algorithm (corrected and
enhanced) is used.
the original code was:
if (ipvers == 6) {
call_dissector(ipv6_handle, next_tvb, pinfo, tree);
} else if (ipvers == 4) {
call_dissector(ipv4_handle, next_tvb, pinfo, tree);
} else if (ipvers == 1) {
dissect_mpls_control(next_tvb, pinfo, tree);
} else {
call_dissector(eth_withoutfcs_handle, next_tvb, pinfo, tree);
}
dissect_mpls_control() is now called dissect_pw_ach() (ach stands for
Associated Channel Header) as per RFC 4385 terminology.
dissect_pw_mcw() (mcw stands for MPLS Generic/Preferred Control Word)
is called only if the first nibble is 0 (as per RFC 4385) and if the
first 12 bytes of data look like two mac addresses.
Ethernet PWs are common nowadays with and without CW (control word:
4 bytes between last mpls label and the encapsulated ethernet header)
in service provider networks. I have been told few times that
"wireshark doesn't work" because of the CW presence. This patch
"automagically" provides a valid dissection in most common "eth
PWs with/without CW" cases.
Moreover, this patch allows wireshark users to manually provide info
in case the heuristic fails.
If you accept this changes new dissectors, one for each type of PW
encapsulated traffic, can be easily implemented (packet-pw-eth.c is
provided as a starting point).
- Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP) (RFC 4553)
- Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service
over Packet Switched Network
(CESoPSN) (RFC 5086)
are at the top of my to-do list.
I have used and fuzz-tested this code. Please check it in.
Ciao
FF
ps
patch is against svn #25387 but unfortunately is a "diff -ru dir1 dir2"
because I cannot "svn diff" anymore due to bad bad proxy settings,
sorry, it should work fine anyway.
pps
bug report is #2689
new_mpls_heuristic.patch
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
No problems... thanks for the update, Sake! On Mon, Jul 7, 2008 at 5:20 PM, Sake Blok <[EMAIL PROTECTED]> wrote: > Abhik, > > I did take a look at it, but have not found the time yet to create > a proper fix. > > Cheers, > Sake > > > On Mon, Jul 07, 2008 at 04:03:28PM +0400, Abhik Sarkar wrote: >> Hi Sake, >> >> I was curious to know - Are you working on this? I just wanted to know >> because some work I am doing depends (slightly) on this and I will put >> comments in the code accordingly. >> >> Thanks! >> Abhik. >> >> On Thu, May 29, 2008 at 9:38 PM, Sake Blok <[EMAIL PROTECTED]> wrote: >> > On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: >> >> >>> > >> >> >>> > - Make the TCP dissector not forward retransmitted segments to >> >> >>> > higher >> >> >>> > layer protocols, just like the normal TCP stack will do on the >> >> >>> > receiving host. This will have a major impact on the way >> >> >>> > retransmitted >> >> >>> > frames are displayed. Then again, the fully dissected segment is >> >> >>> > already available. >> >> >> >> 1. Given that TCP is a streaming protocol, ISTR that a "retransmitted >> >> frame" >> >> can actually consist partially of bytes previously sent and partially of >> >> additional bytes not previously sent. >> >> >> >> If this is the case (and I'm not missing something), then presumably the >> >> tcp >> >> dissector would need to forward any "new" bytes of a frame. >> > >> > Yes indeed. When tcp reassembly is enabled, this will be taken care of >> > unless the extra data is actually the start of a new upper layer PDU. I >> > will either try to incorporate this case in my fix, or put some notes in >> > the code that it should be fixed in the future. I think there will not be >> > many cases where this happens... >> > >> > >> >> 2. How does re-assembly play into this discussion ? >> >> >> >> I haven't looked at the SSL dissector so I don't know how it works. Is >> >> re-assembly being used ? >> >> >> >> Doesn't re-assembly in effect take care of retransmissions (at least in >> >> some >> >> cases) ? >> > >> > It does, unless the retransmitted segment is the last part of the upper >> > layer >> > PDU (which of course includes the case where the PDU consists of only one >> > tcp >> > segment). >> > >> > Cheers, >> > Sake >> > ___ >> > Wireshark-dev mailing list >> > Wireshark-dev@wireshark.org >> > http://www.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] SSL decryption breaks after retransmission
Abhik, I did take a look at it, but have not found the time yet to create a proper fix. Cheers, Sake On Mon, Jul 07, 2008 at 04:03:28PM +0400, Abhik Sarkar wrote: > Hi Sake, > > I was curious to know - Are you working on this? I just wanted to know > because some work I am doing depends (slightly) on this and I will put > comments in the code accordingly. > > Thanks! > Abhik. > > On Thu, May 29, 2008 at 9:38 PM, Sake Blok <[EMAIL PROTECTED]> wrote: > > On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: > >> >>> > > >> >>> > - Make the TCP dissector not forward retransmitted segments to higher > >> >>> > layer protocols, just like the normal TCP stack will do on the > >> >>> > receiving host. This will have a major impact on the way > >> >>> > retransmitted > >> >>> > frames are displayed. Then again, the fully dissected segment is > >> >>> > already available. > >> > >> 1. Given that TCP is a streaming protocol, ISTR that a "retransmitted > >> frame" > >> can actually consist partially of bytes previously sent and partially of > >> additional bytes not previously sent. > >> > >> If this is the case (and I'm not missing something), then presumably the > >> tcp > >> dissector would need to forward any "new" bytes of a frame. > > > > Yes indeed. When tcp reassembly is enabled, this will be taken care of > > unless the extra data is actually the start of a new upper layer PDU. I > > will either try to incorporate this case in my fix, or put some notes in > > the code that it should be fixed in the future. I think there will not be > > many cases where this happens... > > > > > >> 2. How does re-assembly play into this discussion ? > >> > >> I haven't looked at the SSL dissector so I don't know how it works. Is > >> re-assembly being used ? > >> > >> Doesn't re-assembly in effect take care of retransmissions (at least in > >> some > >> cases) ? > > > > It does, unless the retransmitted segment is the last part of the upper > > layer > > PDU (which of course includes the case where the PDU consists of only one > > tcp > > segment). > > > > Cheers, > > Sake > > ___ > > Wireshark-dev mailing list > > Wireshark-dev@wireshark.org > > http://www.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] SSL decryption breaks after retransmission
Hi Sake, I was curious to know - Are you working on this? I just wanted to know because some work I am doing depends (slightly) on this and I will put comments in the code accordingly. Thanks! Abhik. On Thu, May 29, 2008 at 9:38 PM, Sake Blok <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: >> >>> > >> >>> > - Make the TCP dissector not forward retransmitted segments to higher >> >>> > layer protocols, just like the normal TCP stack will do on the >> >>> > receiving host. This will have a major impact on the way retransmitted >> >>> > frames are displayed. Then again, the fully dissected segment is >> >>> > already available. >> >> 1. Given that TCP is a streaming protocol, ISTR that a "retransmitted frame" >> can actually consist partially of bytes previously sent and partially of >> additional bytes not previously sent. >> >> If this is the case (and I'm not missing something), then presumably the tcp >> dissector would need to forward any "new" bytes of a frame. > > Yes indeed. When tcp reassembly is enabled, this will be taken care of > unless the extra data is actually the start of a new upper layer PDU. I > will either try to incorporate this case in my fix, or put some notes in > the code that it should be fixed in the future. I think there will not be > many cases where this happens... > > >> 2. How does re-assembly play into this discussion ? >> >> I haven't looked at the SSL dissector so I don't know how it works. Is >> re-assembly being used ? >> >> Doesn't re-assembly in effect take care of retransmissions (at least in some >> cases) ? > > It does, unless the retransmitted segment is the last part of the upper layer > PDU (which of course includes the case where the PDU consists of only one tcp > segment). > > Cheers, > Sake > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
