PACE Wiki Cannot be Updated from FIRST Conference in Singapore

Abstract

On 27 June 2005, WilfriedWoeber complained that he cannot update PACE Wiki pages while logged in from the FIRST Meeting in Singapore. He can visit the "Edit" form, but when he tries to submit it to the Wiki Web server using the Preview or Save buttons, the connection hangs until eventually an error message is displayed.

Packet Trace at the Wiki server

We found Wilfried's accesses in the logs of the TWiki server, started a packet trace program (tcpdump) to record all packets from and to that address range, and asked Wilfried to try again.

The packet trace consists of several separate TCP connections. The one that seems to present problems looks like this:

: leinen@diotima[leinen]; tethereal -r /tmp/singtel-http.pcap tcp.port == 54803
 58 158.065654 165.21.154.114 -> 130.59.35.130 TCP 54803 > 80 [SYN] Seq=0 Ack=0 Win=8190 Len=0 MSS=1460
 59 158.065701 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [SYN, ACK] Seq=0 Ack=1 Win=17920 Len=0 MSS=8960
 60 158.631496 165.21.154.114 -> 130.59.35.130 TCP 54803 > 80 [ACK] Seq=1 Ack=1 Win=8190 Len=0
 61 161.086946 165.21.154.114 -> 130.59.35.130 HTTP Continuation
 62 161.086972 130.59.35.130 -> 165.21.154.114 TCP [TCP Dup ACK 59#1] 80 > 54803 [ACK] Seq=1 Ack=1 Win=17920 Len=0
 63 161.087058 165.21.154.114 -> 130.59.35.130 HTTP POST /cgi-bin/twiki/save/PACE/NrenSmeList HTTP/1.1
 64 161.087069 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [ACK] Seq=1 Ack=640 Win=18760 Len=0
 65 161.087160 165.21.154.114 -> 130.59.35.130 HTTP Continuation
 66 161.087168 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [ACK] Seq=1 Ack=2019 Win=32767 Len=0
 67 161.123489 165.21.154.114 -> 130.59.35.130 HTTP Continuation
 68 161.123517 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [ACK] Seq=1 Ack=3471 Win=32767 Len=0
 69 161.128604 165.21.154.114 -> 130.59.35.130 HTTP Continuation
 70 161.128610 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [ACK] Seq=1 Ack=3761 Win=32767 Len=0
 71 161.379691 130.59.35.130 -> 165.21.154.114 HTTP HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 72 161.379717 130.59.35.130 -> 165.21.154.114 HTTP Continuation
 73 164.379592 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 74 170.379213 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 75 176.383877 130.59.35.130 -> 165.21.154.114 HTTP Continuation
 78 176.784382 165.21.154.114 -> 130.59.35.130 TCP [TCP Dup ACK 60#1] 54803 > 80 [ACK] Seq=3761 Ack=1 Win=17520 Len=0
 80 182.377462 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 84 206.373962 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 85 254.367954 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 86 350.355959 130.59.35.130 -> 165.21.154.114 HTTP [TCP Retransmission] HTTP/1.1 401 Authorization Required[Unreassembled Packet (incorrect TCP checksum)]
 87 382.480208 165.21.154.114 -> 130.59.35.130 TCP 54803 > 80 [FIN, ACK] Seq=3761 Ack=3537 Win=17520 Len=0
 88 382.480245 130.59.35.130 -> 165.21.154.114 TCP 80 > 54803 [ACK] Seq=3537 Ack=3762 Win=32767 Len=0
 89 382.480261 165.21.154.114 -> 130.59.35.130 TCP 54803 > 80 [RST] Seq=3762 Ack=3537 Win=9300 Len=0
 90 382.854441 165.21.154.114 -> 130.59.35.130 TCP 54803 > 80 [RST] Seq=3762 Ack=3537 Win=8201 Len=0

Apparently, our server sends packets with wrong TCP checksums, which are correctly discarded by the remote proxy. However, the wrong checksums might be an artifact of the measurement method, because the Ethernet interfaces on this server provide a TCP checksum offload feature. So it might be that the checksum is only actually filled in by the controller.

Resolution

While we haven't found the root cause of the problem, Wilfried was able to update the pages from his hotel room. So it can be assumed that the problem is related to the specific NAT/Proxy combination that was used at the FIRST meeting.

-- SimonLeinen - 27 Jun 2005