Graham Bloice
changed
bug 10289
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
CONFIRMED
|
| CC |
|
[email protected]
|
| Ever confirmed |
|
1
|
Comment # 1
on bug 10289
from Graham Bloice
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.
