Wireshark · Wireshark-dev: Re: [Wireshark-dev] Release (0.99.4) next week

["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

1124 is not really a very big issue at all.  I wouls class it as Enhancement request.
It is fact very rare that this should happen for popular/important protocol decodes.

Most (virtually all) important protocols suchs as SMB/NFS/iSCSI/LDAP and friends that are transaction based
will always put a PSH bit on the tail segment of a higher layer PDU and as such will usually make the next header appear at the start of a segment.
Normally this would only ever happen when the link has been paused for a while or when segments are collapsed due to retransmissions.
As such it is  incredibly rare for important protocols that this would happen.


There are even arguments for not addressing this failure and not even attempt to reassemble a header and just accept that if the header spans across a segment boundary then wireshark will not do reassembly.
One argument is that the header is usually very very small  and is really the only thing we have available for doing heuristics in order to determine IF a packet in fact belongs to the current dissector or not.  As such  when a header spans across a segment boundary it might suddenly not be possible to do any proper heuristics anymore which may lead to false positives and misdissection.


Still, what someone interested could do could be to have the header reassembly specify
#define DESEGMENT_ONE_MORE_SEGMENT 0x0fffffff
to tell wireshark it needs one more full segment   and teach the reassembly code about this magic desegment length indication
just as the code was taught to understand how to desegment the stream until the final FIN using a similar magic constant.

On 10/10/06, Anders Broman <a.broman@xxxxxxxxx> wrote:

Hi,
On the other hand it could be argued that Wireshark has been
Out there with this (possible) bug for months/years.
BR
Anders

-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Brian Vandenberg
Skickat: den 10 oktober 2006 04:24
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] Release (0.99.4) next week

  Blocker, by definition, means it blocks development or testing.  That
bug is likely giving me hell with a dissector I've been writing for
work.  At work we classify bugs as: blocker blocks development, testing,
or use of the feature.  Critical is crash/hang.  Major is loss of
functionality without a reasonable workaround.  Normal is loss of
functionality with a reasonable workaround.  The classification here
seems to be roughly the same.

  I think if you twist the words enough, you could claim (with a
straight face) it's a blocker: it blocks you from testing with certain
types of tcp packets.

-Brian

John R. wrote:
> On 10/9/06, Joerg Mayer < jmayer@xxxxxxxxx> wrote:
>
>> On Mon, Oct 09, 2006 at 04:08:04PM -0700, Gerald Combs wrote:
>>
>>> I'd like to release 0.99.4 next Wednesday (the 18th).  If you're
>>> planning on checking in any major changes, please hold off until the
>>> release branch is created (probably Friday or Monday).
>>>
>> Hmm, there are still some open points on the roadmap:
>>
>> Pending:
>> Version checking.
>> Windows updater.
>> Fix Coverity bugs.
>> Fix blocker bugs:
>> 396 - Saving flow data crashes Wireshark
>> Finish capture privilege separation.
>> Use the "User's Guide" as the online help system for Wireshark releases
>>
>>
>
> So does this mean only blocker bugs are fixed in the short term?
>
> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
>
> Seems pretty important since it means that in circumstances where
> packets are split across tcp segments there are significant issues
> with desegmentation and dissection, probably across all application
> layer protocols on top of TCP where PDU length is judged by header
> rather than trailer data. Is Severity of Major the right thing or not?
>
> I suppose it's not a crash/hang bug so it ain't an emergency but I am
> curious how bugs are prioritized for fix.
>
> Thanks,
>
> -- John.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev


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