MSS not beinig honored

[CLJBville]

I've got a medical device, a Cat Scan, that is sending images using DICOM to another system. Internally it sends really fast. When we send images over a WAN link to another device it goes incredibly slow. I used Wireshark (formerly Ethereal) to do a capture and I found that when the CT sends to a PC on the internal network a MSS of 1460 is negotiated and the images are transmitted at 1460. However with the other device, let's call it PACS, PACS requests a MSS of 1300. However my CT does seem to honor this, instead of sending the requested 1300, it send 536. I pinged PACS using the -f and -l switches and found it's real MTU appears to be 1386. So there does not appear to be anything in the way causing it to drop to 536.

Anyone have any idea why the MSS would be ignored? I want to be sure this is outside my control before going to the Cat Scan or PACS maker.

Here's a dump of the first four packet headers. 1-3 are the setup and 4 is the first data packet.

No. Time Source Destination Protocol Info
1 0.000000 10.60.1.250 204.16.165.21 TCP 4472 > ariliamulti [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: WwPcbaTe_7b:98:95 (00:0f:1f:7b:98:95), Dst: Dell_98:91:a0 (00:11:43:98:91:a0)
Internet Protocol, Src: 10.60.1.250 (10.60.1.250), Dst: 204.16.165.21 (204.16.165.21)
Transmission Control Protocol, Src Port: 4472 (4472), Dst Port: ariliamulti (3140), Seq: 0, Len: 0
Source port: 4472 (4472)
Destination port: ariliamulti (3140)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x02 (SYN)
Window size: 65535
Checksum: 0x6378 [correct]
Options: (8 bytes)
###
No. Time Source Destination Protocol Info
2 0.052624 204.16.165.21 10.60.1.250 TCP ariliamulti > 4472 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1300

Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Watchgua_3f:fd:64 (00:90:7f:3f:fd:64), Dst: WwPcbaTe_7b:98:95 (00:0f:1f:7b:98:95)
Internet Protocol, Src: 204.16.165.21 (204.16.165.21), Dst: 10.60.1.250 (10.60.1.250)
Transmission Control Protocol, Src Port: ariliamulti (3140), Dst Port: 4472 (4472), Seq: 0, Ack: 1, Len: 0
Source port: ariliamulti (3140)
Destination port: 4472 (4472)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x12 (SYN, ACK)
Window size: 65535
Checksum: 0x3575 [correct]
Options: (8 bytes)
[SEQ/ACK analysis]
###
No. Time Source Destination Protocol Info
3 0.052633 10.60.1.250 204.16.165.21 TCP 4472 > ariliamulti [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 3 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: WwPcbaTe_7b:98:95 (00:0f:1f:7b:98:95), Dst: Dell_98:91:a0 (00:11:43:98:91:a0)
Internet Protocol, Src: 10.60.1.250 (10.60.1.250), Dst: 204.16.165.21 (204.16.165.21)
Transmission Control Protocol, Src Port: 4472 (4472), Dst Port: ariliamulti (3140), Seq: 1, Ack: 1, Len: 0
Source port: 4472 (4472)
Destination port: ariliamulti (3140)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 65535
Checksum: 0x6199 [correct]
[SEQ/ACK analysis]
###
No. Time Source Destination Protocol Info
4 0.052636 10.60.1.250 204.16.165.21 TCP [TCP segment of a reassembled PDU]

Frame 4 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: WwPcbaTe_7b:98:95 (00:0f:1f:7b:98:95), Dst: Dell_98:91:a0 (00:11:43:98:91:a0)
Internet Protocol, Src: 10.60.1.250 (10.60.1.250), Dst: 204.16.165.21 (204.16.165.21)
Transmission Control Protocol, Src Port: 4472 (4472), Dst Port: ariliamulti (3140), Seq: 1, Ack: 1, Len: 536
Source port: 4472 (4472)
Destination port: ariliamulti (3140)
Sequence number: 1 (relative sequence number)
[Next sequence number: 537 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
Window size: 65535
Checksum: 0x277e [correct]
[PDU Size: 4677]
TCP segment data (536 bytes)

 

[burtsbees]

First off, MTU and MSS are two different things. MTU=MSS plus 40 bytes, so MSS of 1460=1500 bytes MTU.
The ethernet standard for MTU is 1500 bytes, but it needs to be adjusted to 1492 (or adjust the mss to 1452, which essentially does the same thing) for ADSL,for example. We need to know what kind of circuit the WAN link is, and what the edge device is. Also, you can tweak MTU in a PC using DrTCP (free), and can usually tweak MTU on the edge router. I would do an extended ping with the df bit set to see where you start dropping packets...

Burt

 

[VinceWhirlwind]

The important thing is that frames either get through or, if they are dropped, that an ICMP message comes back telling the application what size to change to.

http://support.microsoft.com/kb/159211

http://support.microsoft.com/kb/314825/

I've had a similar issue with a WAN provider where frame sizes of 1473-1500 bytes were simply "vanishing" - the WAN provider attempted to deny responsibility, telling our NOC guys that the fault lay with the apps/OS for using too-large frame sizes.

It became apparent that they were filtering out all ICMP, including the important ICMP messages carrying the frame-size information.

The way to demonstrate what is happening is to ping using DNF and size 1500,1473,1472,etc... to show which sizes get a correct response and which ones do not.

Your 536 MTU size sounds vaguely like the normal default MTU size set in Windows XP registry and I don't see why it should be a problem.