Wireshark-bugs: [Wireshark-bugs] [Bug 10289] DNP3 dissector bug in multi-fragmented messages wit
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 18 Jul 2014 09:08:56 +0000

changed bug 10289

What Removed Added
Status UNCONFIRMED CONFIRMED
CC   graham.bloice@trihedral.com
Ever confirmed   1

Comment # 1 on bug 10289 from 
Confirmed this is an issue.

The issue comes about because the DNP3 dissector does not check for tcp
analysis flags when adding Transport Segments (TS)to the conversation for
reassembly, nor does it check that the Transport Layer (TL) sequence number is
in the expected sequence.  The retransmitted packet thus breaks the reassembled
Application Layer (AL) message by including one block twice.

Should dissectors be checking for retranmissions?  Are there any other
dissectors that reassemble their protocol from multiple tcp segments that do
this?  I believe this is also an issue for http amongst other protocols.

One way to do this for DNP3 without relying on tcp analysis flags is to ensure
that any TS with a given TL sequence number is only added to a conversation
once.  This works as long as the sequence number doesn't wrap round during a
conversation, i.e. more than 64 TS carrying a single AL message.  I'm not aware
of anything in the protocol spec that prevents more than 64 TS though so it is
possible.  The dissector can't simply do the normal DNP3 device receive
handling by discarding out of order Transport segments as it is receiving the
TCP segments as captured which may be out of order, but would be presented in
order by a DNP3 devices tcp stack.

You are receiving this mail because:
  • You are watching all bug changes.