none
Несоответствие стека TCP/IP RFC 1624 RRS feed

  • Вопрос

  • Добрый день.

    Имеется приложение работающее под windows 7, оно через TCP/IP взаимодействует с устройством. Все работает хорошо до тех пор пока windows не отправляет устройству TCP-пакет с контрольной суммой 0xFFFF (что не соответствует RFC 1624), после чего устройство неотвечает. Как исправить ситуацию?

    Ниже приводится фрагмент трафика

    Time            Source                Destination           Protocol Info
    17:39:46.390502 192.168.155.31        192.168.155.30        TCP      52699 > 10002 [PSH, ACK] Seq=36987 Ack=6165 Win=63920 Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 3c 40 00 80 06 e2 01 c0 a8 9b 1f c0 a8   .+a<@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f1 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 fd 02 00 00 1b 05 04                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:46.443336 192.168.155.30        192.168.155.31        TCP      10002 > 52699 [ACK] Seq=6165 Ack=36990 Win=5840 Len=0
    
    0000  00 40 f4 5a 21 a3 00 0d e0 d0 f5 15 08 00 45 00   .@.Z!.........E.
    0010  00 28 e5 04 00 00 40 06 de 3c c0 a8 9b 1e c0 a8   .(....@..<......
    0020  9b 1f 27 12 cd db 00 70 51 1f b6 12 e5 f4 50 10   ..'....pQ.....P.
    0030  16 d0 fe f0 00 00 1b 05 04 00 00 00               ............
    
    Time            Source                Destination           Protocol Info
    17:39:46.452963 192.168.155.31        192.168.155.30        TCP      52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 3d 40 00 80 06 e2 00 c0 a8 9b 1f c0 a8   .+a=@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:46.764895 192.168.155.31        192.168.155.30        TCP      [TCP Retransmission] 52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 3f 40 00 80 06 e1 fe c0 a8 9b 1f c0 a8   .+a?@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:47.373292 192.168.155.31        192.168.155.30        TCP      [TCP Retransmission] 52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 40 40 00 80 06 e1 fd c0 a8 9b 1f c0 a8   .+a@@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:48.574461 192.168.155.31        192.168.155.30        TCP      [TCP Retransmission] 52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 44 40 00 80 06 e1 f9 c0 a8 9b 1f c0 a8   .+aD@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:50.976862 192.168.155.31        192.168.155.30        TCP      [TCP Retransmission] 52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 4a 40 00 80 06 e1 f3 c0 a8 9b 1f c0 a8   .+aJ@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:39:55.781601 192.168.155.31        192.168.155.30        TCP      [TCP Retransmission] 52699 > 10002 [PSH, ACK] Seq=36990 Ack=6165 Win=63920 [TCP CHECKSUM 0xFFFF] Len=3
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 2b 61 54 40 00 80 06 e1 e9 c0 a8 9b 1f c0 a8   .+aT@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f4 00 70 51 1f 50 18   ....'......pQ.P.
    0030  f9 b0 ff ff 00 00 1b 05 01                        .........
    
    Time            Source                Destination           Protocol Info
    17:40:05.391090 192.168.155.31        192.168.155.30        TCP      52699 > 10002 [RST, ACK] Seq=36993 Ack=6165 Win=0 Len=0
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 28 61 68 40 00 80 06 e1 d8 c0 a8 9b 1f c0 a8   .(ah@...........
    0020  9b 1e cd db 27 12 b6 12 e5 f7 00 70 51 1f 50 14   ....'......pQ.P.
    0030  00 00 15 ba 00 00                                 ......
    
    Time            Source                Destination           Protocol Info
    17:40:06.080393 192.168.155.31        192.168.155.30        TCP      52711 > 10002 [SYN] Seq=0 Len=0 MSS=1460 WS=2
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 34 61 6d 40 00 80 06 e1 c7 c0 a8 9b 1f c0 a8   .4am@...........
    0020  9b 1e cd e7 27 12 c6 65 7f d8 00 00 00 00 80 02   ....'..e........
    0030  20 00 5c 4f 00 00 02 04 05 b4 01 03 03 02 01 01    .\O............
    0040  04 02                                             ..
    
    Time            Source                Destination           Protocol Info
    17:40:06.084249 192.168.155.30        192.168.155.31        TCP      10002 > 52711 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
    
    0000  00 40 f4 5a 21 a3 00 0d e0 d0 f5 15 08 00 45 00   .@.Z!.........E.
    0010  00 2c e5 23 00 00 40 06 de 19 c0 a8 9b 1e c0 a8   .,.#..@.........
    0020  9b 1f 27 12 cd e7 00 8d d2 27 c6 65 7f d9 60 12   ..'......'.e..`.
    0030  16 d0 bb c9 00 00 02 04 05 b4 01 03               ............
    
    Time            Source                Destination           Protocol Info
    17:40:06.084278 192.168.155.31        192.168.155.30        TCP      52711 > 10002 [ACK] Seq=1 Ack=1 Win=64240 Len=0
    
    0000  00 0d e0 d0 f5 15 00 40 f4 5a 21 a3 08 00 45 00   .......@.Z!...E.
    0010  00 28 61 6e 40 00 80 06 e1 d2 c0 a8 9b 1f c0 a8   .(an@...........
    0020  9b 1e cd e7 27 12 c6 65 7f d9 00 8d d2 28 50 10   ....'..e.....(P.
    0030  fa f0 ef 65 00 00                                 ...e..
    
    Заранее спасибо.
    
    
    

    с форума TechNet

Ответы

  • Так или иначе, но в пакете указано значение 0xFFFF, а ожидалось 0x0000. Это (в моем конкретном случае) является проблемой, т.к. устройство (с которым необходимо взаимодействовать приложению) отбрасывает такие пакеты как недействительные (испорченые) и происходит следующее: не получив ответа (подтверждение о получении) от устройства, компьютер отправляет пакет повторно и опять не получает ответ (и так несколько раз), посче чего происходит сброс подключения и создание нового (для приложения это выглядит как задержка, причем весомая - более 10 сек). Так как все описаное происходит на уровне транспортного протокола, то повлиять программно нет возможности впринципе.

    На текущий момент в качестве единственного выхода вижу использование сетевой карты с поддержкой ChecksumOffload. В этом случае контрольная сумма сумма будет вычислятся сетевой картой и соответственно избавит от проблемы (проверил - это работает).


    с форума TechNet

    • Помечено в качестве ответа SARAFF 17 мая 2012 г. 17:05

Все ответы

  • Речь о контрольной сумме TCP или же о контрольной сумме IP? Для TCP на сколько я знаю 0xFFFF допустима (RFC793).

    И как именно перехватывались пакеты? Если на машине которая их посылала то были ли отключены различные checksum offload в сетевой карте? Если нет то чексуммы скорее всего будут неверными так как сетевая карта вычислит их только при отправке пакета.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Модератор
  • Речь идет о контрольной сумме TCP (собственно из перехваченых пакетов видно). Пакеты перехватывались с машины которая их посылала. checksum offload в сетевой карте не отключали, т.к. сама сетевая карта не позволяет их отключить (в дополнительных свойствах нет такой возможности). так или иначе но в первом (из приведенных сдесь) пакете контрольная сумма вычислена верно. На счет RFC 793, он издан в 1981 году, RFC 1624 в 1994 и говорит о недопустимости использования контрольной суммы 0xffff (вместо ее должна использоваться 0x0000)


    с форума TechNet



    • Изменено SARAFF 15 мая 2012 г. 4:39
  • Не вижу где в 1624 упомянуто что контрольная сумма TCP не может быть 0xffff. Не вижу где упомянуто что 0xffff должна быть заменена на 0x0000. И, если уж на то пошло, то даже упоминаня TCP не вижу. Можете указать на данное требование? Так же почему вы считайте что 1624 вообще имеет отношение к TCP?

    A вот что я вижу: выкладку в п.3 что из за особенностей данных в IP заголовке (всегда есть поле которое не равно нулю) и с учетом того что контрольная сумма в заголовке протокола (TCP/UDP и т.п. - конкретно протокол не упомянут) дополняет сумму всех остальных элементов до нуля, то контрольная сумма в IP заголовке просто не может быть 0хffff. Однако из за ошибки в RFC 1141 возможно получение данного значения при неверном методе обновления контрольной суммы на базе уже расчитанной суммы что и исправляет RFC 1624. При правильно выполненх вычислениях замены 0xffff на 0x0000 в IP заголовке не требуется так как получить значение 0xffff просто невозможно. 

    В пакетах которые вы привели контрольная сумма в IP заголовке явно не 0xffff, так что очевидно ошибка с RFC 1141 не наблюдается. Да и едва ли ее следует ожидать так как обновление контрольной суммы после изменения заголовка в данном случае маловероятен. Скорее данную проблему можно наблюдать на очень старом раутере в отфорварженых пакетах. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Модератор
  • Не надо так нервничать, я не претендую на обсолютную истинности своих предположений.

    Вот фрагмент RFC 1624

    4.  Examples
    
       Consider an IP packet header in which a 16-bit field m = 0x5555
       changes to m' = 0x3285.  Also, the one's complement sum of all other
       header octets is 0xCD7A.
    
       Then the header checksum would be:
    
              HC = ~(0xCD7A + 0x5555)
                 = ~0x22D0
                 =  0xDD2F
    
       The new checksum via recomputation is:
    
              HC' = ~(0xCD7A + 0x3285)
                  = ~0xFFFF
                  =  0x0000
    
       Using [Eqn. 2], as specified in RFC 1141, the new checksum is
       computed as:
    
              HC' = HC + m + ~m'
                  =  0xDD2F + 0x5555 + ~0x3285
                  =  0xFFFF
    
       which does not match that computed from scratch, and moreover can
       never obtain for an IP header.
    
       Applying [Eqn. 3] to the example above, we get the correct result:
    
              HC' = ~(C + (-m) + m')
                  = ~(0x22D0 + ~0x5555 + 0x3285)
                  = ~0xFFFF
                  =  0x0000
    
    в третьем пакете (из приведенных выше) (по смешению 32) стоит не что иное как FFFF. почему я решел что это контрольная сумма TCP? - потому, что она находится в TCP-заголовке, а в не IP-заголовке, хотя при ее вычислении и он участвует.

    с форума TechNet

  • Я не нервничаю (с какой стати?), просто указываю на то что упомянутый RFC а) не имеет отношения к тому что происходит и б) ошибочно интерпретирован. 

    В приведенном вами фрагменте всего лишь пример неверного подсчета обновленной контрольной суммы IP из за ошибки в 1141. Обновили поле, подсчитали контрольную сумму как описано в 1141, получили ерунду. Подсчитали по исправленной формуле - получили верное значение. Ни о какой "замене" 0xFFFF на 0x0000 речь не идет. Как, впрочем, и о контрольной сумме TCP.

    Да, я согласен что контрольная сумма TCP в вашем пакете 0xFFFF и что она по смещению 32. 

    Считая что значение 0хFFFF подсчитано верно (не проверял), является ли это проблемой? Нет - во всяком случае точно не из за 1624 который:

    - Не имеет отношения к TCP вообще и подсчету контрольных сумм TCP в частности.

    - Не ограничивает возможных значений контрольной суммы TCP (да и IP в общем тоже, просто указывает что определенное значение невозможно получить при правильном подсчете). 

    - Не предписывает замены 0xffff на 0x0000.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Модератор
  • Так или иначе, но в пакете указано значение 0xFFFF, а ожидалось 0x0000. Это (в моем конкретном случае) является проблемой, т.к. устройство (с которым необходимо взаимодействовать приложению) отбрасывает такие пакеты как недействительные (испорченые) и происходит следующее: не получив ответа (подтверждение о получении) от устройства, компьютер отправляет пакет повторно и опять не получает ответ (и так несколько раз), посче чего происходит сброс подключения и создание нового (для приложения это выглядит как задержка, причем весомая - более 10 сек). Так как все описаное происходит на уровне транспортного протокола, то повлиять программно нет возможности впринципе.

    На текущий момент в качестве единственного выхода вижу использование сетевой карты с поддержкой ChecksumOffload. В этом случае контрольная сумма сумма будет вычислятся сетевой картой и соответственно избавит от проблемы (проверил - это работает).


    с форума TechNet

    • Помечено в качестве ответа SARAFF 17 мая 2012 г. 17:05
  • Из чего следует что ожидалось 0x0000? Как я уже сказал я не проверял правильность подсчета контрольной суммы TCP. Вы хотите сказать что при подсчете ее по методу приведенному в RFC793 для указаного TCP заголовка и данных должно получится 0x0000? Можете привести вычисления?

    Если ваша карта не из музея, то скорее всего в ней тоже есть ChecksumOffload. Практически все карты выпуска последних ~5 лет имеют данную фичу. В некоторых картах она кстати работает неверно и ее требуется отключать. Вот пример последствий: http://www.symantec.com/business/support/index?page=content&id=TECH52727

    Так же следует перехватить пакеты на другом хосте, иначе нельзя быть увереным что контрольная сумма показана верно.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Модератор
  • Контрольную сумму руками я не считал (уж больно долго) я положился на результаты расчета sniffer-а (которым анализировал трафик - wireshark). Но если есть сомнения можно проверить вручную (для этого есть все данные).

    Насчет карты, из музея она или нет - незнаю. тем не менее, на вкладке "дополнительно" про offload не упаминается и закленание "netsh int tcp set global chimney=enabled" на ее не подействоволо, а вот попробовав использовать другую сетевую карту (современная очевидно) получил требуемый результат (sniffer показывал, что контрольная сумма неверна во всех исходящих пакетах, и предположил, что имеет место ChecksumOffload).


    с форума TechNet


    • Изменено SARAFF 15 мая 2012 г. 19:30
  • Не все параметры карты могут быть доступны на вкладке "дополнительно".

    Теперь на современной карте отключите ChecksumOffload и посмотрите какая будет чексума. 



    This posting is provided "AS IS" with no warranties, and confers no rights.

    Модератор
  • При отключеном ChecksumOffload контрольная сумма равна 0xFFFF (чудес не бывает) (т.е. ситуация вернулась к той, что была в первом посте).


    с форума TechNet


    • Изменено SARAFF 15 мая 2012 г. 20:40