PDA

Bekijk de volledige versie : странные проблемы с потерей повторно отправленных пакетов


viogator
11-08-2007, 09:54
День добрый,

Буду очень признателен, если кто-нибудь сможет указать на причину проблемы...

Имеем: 500g Deluxe c 1.9.2.7-7g, к нему подключен ADSL модем, соединение через PPPoE.

Визуально проблема заключается в том, что некоторые сайты "не открываются". Создается впечатление, что какие-то создаваемые самим устройством правила iptables "не пропускают" повторно переданные пакеты. При прямом подключении модема к клиентской машине проблемы нет.

Wireshark показывает примерно следующее:

No. Time Source Destination Protocol Info
3 3.014632 192.168.1.21 212.154.164.73 TCP 2085 > http [SYN] Seq=0 Len=0 MSS=1460
4 3.144745 212.154.164.73 192.168.1.21 TCP http > 2085 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1452
5 3.144804 192.168.1.21 212.154.164.73 TCP 2085 > http [ACK] Seq=1 Ack=1 Win=17424 Len=0
6 3.145049 192.168.1.21 212.154.164.73 HTTP GET / HTTP/1.0
7 3.328652 212.154.164.73 192.168.1.21 HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic
8 3.328711 192.168.1.21 212.154.164.73 TCP [TCP Dup ACK 6#1] 2085 > http [ACK] Seq=258 Ack=1 Win=17424 Len=0 SLE=1453 SRE=1461
9 18.308108 212.154.164.73 192.168.1.21 TCP http > 2085 [FIN, ACK] Seq=1461 Ack=258 Win=32768 Len=0
10 18.308158 192.168.1.21 212.154.164.73 TCP [TCP Dup ACK 6#2] 2085 > http [ACK] Seq=258 Ack=1 Win=17424 Len=0 SLE=1453 SRE=1462


При прямом подключении модема к компьютеру через PPPoE потери пакетов есть, но успешно принимаются повторно переданные:

No. Time Source Destination Protocol Info
3 0.145507 xx.xxx.xxx.xxx 212.154.164.73 TCP 2970 > http [SYN] Seq=0 Len=0 MSS=1360
4 0.278320 212.154.164.73 xx.xxx.xxx.xxx TCP http > 2970 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1360
5 0.278320 xx.xxx.xxx.xxx 212.154.164.73 TCP 2970 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
6 0.278320 xx.xxx.xxx.xxx 212.154.164.73 HTTP GET / HTTP/1.0
7 0.542968 212.154.164.73 xx.xxx.xxx.xxx TCP [TCP segment of a reassembled PDU]
8 0.554687 212.154.164.73 xx.xxx.xxx.xxx HTTP HTTP/1.1 200 OK (text/html)
9 0.554687 xx.xxx.xxx.xxx 212.154.164.73 TCP 2970 > http [ACK] Seq=258 Ack=1461 Win=65535 Len=0
10 0.630859 xx.xxx.xxx.xxx 212.154.164.73 HTTP GET /styles.css HTTP/1.0
11 0.875000 212.154.164.73 xx.xxx.xxx.xxx TCP [TCP segment of a reassembled PDU]
12 0.974609 212.154.164.73 xx.xxx.xxx.xxx TCP [TCP segment of a reassembled PDU]
13 0.974609 xx.xxx.xxx.xxx 212.154.164.73 TCP 2970 > http [ACK] Seq=472 Ack=4181 Win=65535 Len=0
14 0.990234 212.154.164.73 xx.xxx.xxx.xxx TCP [TCP Previous segment lost] [TCP segment of a reassembled PDU]

Frame 14 (200 bytes on wire, 200 bytes captured)
Ethernet II, Src: a4:de:20:00:03:00 (a4:de:20:00:03:00), Dst: Xerox_00:00:00 (00:00:01:00:00:00)
Internet Protocol, Src: 212.154.164.73 (212.154.164.73), Dst: xx.xxx.xxx.xxx (xx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: http (80), Dst Port: 2970 (2970), Seq: 5541, Ack: 472, Len: 146
Source port: http (80)
Destination port: 2970 (2970)
Sequence number: 5541 (relative sequence number)
[Next sequence number: 5687 (relative sequence number)]
Acknowledgement number: 472 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 32768
Checksum: 0xbb34 [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 13]
[The RTT to ACK the segment was: 0.015625000 seconds]
[TCP Analysis Flags]
[A segment before this frame was lost]
[Reassembled PDU in frame: 16]
TCP segment data (146 bytes)

15 0.990234 xx.xxx.xxx.xxx 212.154.164.73 TCP [TCP Dup ACK 13#1] 2970 > http [ACK] Seq=472 Ack=4181 Win=65535 Len=0 SLE=5541 SRE=5687
16 1.090820 212.154.164.73 xx.xxx.xxx.xxx HTTP [TCP Retransmission] HTTP/1.1 200 OK (text/css)

Frame 16 (1414 bytes on wire, 1414 bytes captured)
Ethernet II, Src: a4:de:20:00:03:00 (a4:de:20:00:03:00), Dst: Xerox_00:00:00 (00:00:01:00:00:00)
Internet Protocol, Src: 212.154.164.73 (212.154.164.73), Dst: xx.xxx.xxx.xxx (xx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: http (80), Dst Port: 2970 (2970), Seq: 4181, Ack: 472, Len: 1360
Source port: http (80)
Destination port: 2970 (2970)
Sequence number: 4181 (relative sequence number)
[Next sequence number: 5541 (relative sequence number)]
Acknowledgement number: 472 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 32768
Checksum: 0xe29b [correct]
[Good Checksum: True]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 15]
[The RTT to ACK the segment was: 0.100586000 seconds]
[TCP Analysis Flags]
[This frame is a (suspected) retransmission]
[The RTO for this segment was: 0.100586000 seconds]
[RTO based on delta from frame: 14]
TCP segment data (1360 bytes)
[Reassembled TCP Segments (4226 bytes): #11(1360), #12(1360), #16(1360), #14(146)]
[Frame: 11, payload: 0-1359 (1360 bytes)]
[Frame: 12, payload: 1360-2719 (1360 bytes)]
[Frame: 16, payload: 2720-4079 (1360 bytes)]
[Frame: 14, payload: 4080-4225 (146 bytes)]
Hypertext Transfer Protocol
Line-based text data: text/css

17 1.090820 xx.xxx.xxx.xxx 212.154.164.73 TCP 2970 > http [ACK] Seq=472 Ack=5687 Win=65535 Len=0


Какие-то объективные проблемы, вызывающие потерю пакетов, однозначно есть, но вот почему устройство "режет" повторно переданные?.. В любом случае, очень прошу меня наставить на путь истинный или указать, если я где-то неправ.
vsu
12-08-2007, 16:52
В прошивке от Олега есть tcpdump - можно посмотреть на самом роутере, что приходит снаружи (интерфейс vlan1 - порт WAN, ppp0 - то, что приходит по PPPoE/PPTP), и сравнить с тем, что доходит до машины внутри сети.

В приведённых дампах видны разные значения MSS - возможно, кто-то по дороге сломал PMTU discovery, а Windows XP при использовании туннелей выставляет заведомо заниженное значение MTU (1400), с которым пакеты могут проходить нормально. Попробуйте в настройках роутера (IP Config - WAN & LAN) добавить в Additional pppd options параметр mtu 1400 (для PPTP это точно работает, с PPPoE не проверял).
viogator
13-08-2007, 04:45
Спасибо огромное! Похоже, проблема именно в этом... Буду пробовать... Кстати, небольшой поиск дал интересный совет, мол, есть такая опция для iptables, которая включает автоматическое вычисление размера mtu:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Не знаю, правда, насколько это поможет для конкретного случая, но поэкспериментировать повод есть.
vsu
13-08-2007, 15:42
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Это уже есть в прошивке:

$ iptables -L -vxn | grep TCPMSS
1405 72824 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 TCPMSS clamp to PMTU
Но на самом деле это правило сработает только в том случае, если сам роутер может определить PMTU (т.е., до него нормально доходят пакеты ICMP с типом Fragmentation Needed), но до машины, инициировавшей соединение, пакеты ICMP не доходят. В данном же случае настоящая проблема, скорее всего, где-то между роутером и сервером 212.154.164.73, и роутер точно так же не сможет определить правильное значение PMTU. Поэтому в любом случае придётся манипулировать параметром mtu у pppd.

Основная функция --clamp-mss-to-pmtu - устранение лишних согласований MTU между машинами из внутренней сети и роутером (что полезно, но не решает проблему, если MTU на внешнем интерфейсе роутера больше, чем на каком-то из последующих каналов, а пакеты ICMP Fragmentation Needed оттуда не доходят).