["Martin Regner" <martin.regner@xxxxxxxxx>]

Steven Backus wrote:


>   Apologies in advance if this is not a good place to ask about
> this.  I am using a disk backup program called Retrospect from
> Dantz.  The application is failing and the Dantz people say it is
> hardware or network related.  Every other application works fine on
> this machine, a Windows 2000 box.  Here's ethereal's output, does
> anyone know what hardware problem could cause this?  TIA.
>

> 453.768783 155.100.176.25 -> 155.100.158.57 TDS [TCP Retransmission] Login Packet (Not last buffer) (Not last
buffer)[Unreassembled Packet]

> 453.772026 155.100.176.25 -> 155.100.158.57 TDS [TCP Retransmission] Unknown Packet Type: 249[Malformed Packet]

> 453.773598 155.100.176.25 -> 155.100.158.57 TDS [TCP Retransmission] Query Packet (Not last buffer) (Not last buffer)


Hi,

I think that the reason why you get [Malformed Packet] (and similar) is due to that Ethereal
thinks that one of the packets is a Netlib/TDS/MS-SQL
packet and then assumes that the TCP connection is used
for Netlib/TDS, but it is really another protocol.

I guess that Dantz Retrospect  uses some proprietary protocol
(and they have reserved an IANA port number for it, port 497).

The Netlib/TDS dissector has probably started a "conversation"
to decode the packets on this specific TCP "conversation" with the Netlib/TDS dissector
due to that at least one packet looked like a Netlib/TDS packet.

There is a risk that other protocols may have some packets that
 matches the pattern that the heuristic Netlib/TDS dissector is looking for.

I assume that that is what is happening in your case. You could disable
TDS protocol and then Ethereal will probably show the packets as TCP
packets (You can disable protocols by using the menu item Analyze/Enabled protocols...)

I don't know what can be the cause for the problem you are having with Retrospect
and I don't really know if the sample you provided gives enough information
to see what the problem is, but maybe someone else on the list can find
some interesting information in the extract you sent.

There is a lot of packets with 1448 bytes TCP payload
sent in the direction 155.100.176.25-->155.100.158.57.

All the TCP ACKs in the other direction acknowledges a packet
that has been sent about 0.3 seconds before the extract begins.
Ethereal shows these ACKs as "[TCP Dup ACK".

Below is an extract modified based on the assumption that
the TDS packets are TCP packets with 1448 bytes TCP payload
(which seeems to be a correct assumption when looking
on the Seq-numbers on the packets in direction
155.100.176.25-->155.100.158.57 that are
not displayed as TDS packets).



453.765578 155.100.176.25 -> 155.100.158.57 TCP port 497>port49166 [ACK] Seq=90548355 Ack=1124814 Win=49152 Len=12
TSV=698715 TSER=2045316676

#####  (155.100.176.25 -> 155.100.158.57  : SeqNum=90548355    Len=12 ====>  NextSeqNum=90548355+12 = 90548367)

453.765759 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#13] port49166>port497 [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571



453.767222 155.100.176.25 -> 155.100.158.57 TCP port497>port49166 [ACK] Seq=90548367 Ack=1124814 Win=49152 Len=1448
TSV=698715 TSER=2045316704

#####  ( 155.100.176.25 -> 155.100.158.57  : SeqNum=90548367    Len=1448 ====>  NextSeqNum=90548367+1448 = 90549815)


453.767338 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#14] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571


453.768783 155.100.176.25 -> 155.100.158.57 TCP port497>port49166 [ACK] Seq=90548367+1448=90549815 Ack=1124814 Win=49152
Len=1448 TSV=698715 TSER=2045316676

#####  ( 155.100.176.25 -> 155.100.158.57  : SeqNum=90549815    Len=1448 ====>  NextSeqNum=90549815+1448 = 90551263)

453.768897 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#15] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571

453.770381 155.100.176.25 -> 155.100.158.57 TCP dantz > 49166 [ACK] Seq=90548367+2896=90551263 Ack=1124814 Win=49152
Len=1448 TSV=698715 TSER=2045316704

:

(and so on ...)

:


453.812013 155.100.176.25 -> 155.100.158.57 TCP dantz > 49166 [ACK] Seq=90588911 Ack=1124814 Win=49152 Len=1448
TSV=698715 TSER=2045316704

453.812202 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#42] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571

453.813692 155.100.176.25 -> 155.100.158.57 TCP dantz > 49166 [ACK] Seq=90588911+1448=90590359 Ack=1124814 Win=49152
Len=1448

453.813858 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#43] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571

453.815326 155.100.176.25 -> 155.100.158.57 TCP dantz > 49166 [ACK] Seq=90548367+1448+1448=90591807 Ack=1124814
Win=49152 Len=1448

453.815498 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#44] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571

453.815546 155.100.158.57 -> 155.100.176.25 TCP [TCP Dup ACK 144364#45] 49166 > dantz [ACK] Seq=1124814 Ack=90546907
Win=66608 Len=0 TSV=2045316704 TSER=698571