Opened 4 months ago
Closed 3 months ago
#697 closed баг (не воспроизводится)
Watchdog reset при подключении браузером к блоку
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: |
Description
Пользователь наблюдал на нескольких платах SW-01 перезагрузку по ватчдогу при подключении к веб-интерфейсу некоторыми браузерами. Проблема воспроизводилась постоянно. Позднее выяснилось, что через сеть пользователя не проходили большие пакеты. После того как пользователь установил MTU = 1200 в SW-01 проблема перестала воспроизводиться.
r2400
Прилагаю лог с одной из плат SW-01, последние несколько перезагрузок по ватчдогу и есть воспроизведение проблемы.
Attachments (1)
Change History (30)
by , 4 months ago
| Attachment: | logs-sw01-10.88.167.72.tar.gz added |
|---|
comment:2 by , 4 months ago
Replying to san:
Позднее выяснилось, что через сеть пользователя не проходили большие пакеты.
Хотелось бы уточнения этого момента: что подразумевается под "большими пакетами"?
follow-up: 5 comment:3 by , 4 months ago
Replying to san:
Также пользователь выслал пару дампов трафика,
А почему в логе один адрес платы, а в дампе - другой?
comment:4 by , 4 months ago
Replying to san:
Пользователь наблюдал ... перезагрузку по ватчдогу при подключении к веб-интерфейсу некоторыми браузерами.
Хотелось бы уточнения этого момента: какими именно "некоторыми браузерами"?
follow-ups: 8 18 comment:5 by , 4 months ago
Replying to alx:
А почему в логе один адрес платы, а в дампе - другой?
Я так понял, что лог и дамп от разных плат, на которых воспроизводилась проблема.
Replying to alx:
Хотелось бы уточнения этого момента: что подразумевается под "большими пакетами"?
С MTU от 1200 до 1500. Изначально MTU был 1500, некоторые пакеты не проходили через сеть пользователя и баг проявлялся. А после установки на SW-01 MTU 1200 все пакеты стали иметь возможность проходить через сеть и баг перестал проявляться.
Replying to alx:
Хотелось бы уточнения этого момента: какими именно "некоторыми браузерами"?
Firefox 78.0.2, Firefox 115.12, Chrome (версия не известна)
comment:6 by , 4 months ago
Replying to san:
Дамп при котором плата зависла:
08:52:03.263053 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [SEW], seq 4260185274, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0Дамп после установки MTU 1200 - всё работает штатно:
08:46:50.241192 IP 10.88.167.75.49823 > 10.88.167.73.http: Flags [S], seq 899520915, win 8192, options [nop,wscale 8,nop,nop,sackOK], length 0
Как странно... Изменили параметр в плате SW-01, но после этого изменился первый пакет, отправляемый из браузера в плату (другой набор флагов TCP)... Почему так?
comment:7 by , 4 months ago
Как странно... Изменили параметр в плате SW-01, но после этого изменился первый пакет, отправляемый из браузера в плату (другой набор флагов TCP)... Почему так?
Я не знаю, возможно и со стороны браузера MTU меняли, но пользователь об этом умолчал.
follow-up: 10 comment:8 by , 4 months ago
Replying to san:
Хотелось бы уточнения этого момента: что подразумевается под "большими пакетами"?
С MTU от 1200 до 1500.
Что-то здесь не сходится... Как можно видеть в первом из приведенных дампов, до компьютера успешно доходят сегменты данных с размерами 1460 и 1408 байт. Если добавить размеры заголовков TCP (20 байт) и IP (20 байт) размеры этих пакетов получается 1500 и 1448 байт соответственно, то есть они попадают в названный тобой диапазон...
follow-up: 12 comment:9 by , 4 months ago
Что-то здесь не сходится...
Согласен.
Можно попросить пользователя воспроизвести WD reset, с логом в режиме Debug или в какой-нибудь специальной отладочной прошивке...
follow-up: 13 comment:10 by , 4 months ago
Replying to alx:
Что-то здесь не сходится... Как можно видеть в первом из приведенных дампов, до компьютера успешно доходят сегменты данных с размерами 1460 и 1408 байт. Если добавить размеры заголовков TCP (20 байт) и IP (20 байт) размеры этих пакетов получается 1500 и 1448 байт соответственно, то есть они попадают в названный тобой диапазон...
А, кстати, дамп был захвачен на MC-03, т.е. со стороны SW-01, а не компьютера, относительно сети.
comment:11 by , 4 months ago
А, кстати, дамп был захвачен на MC-03, т.е. со стороны SW-01, а не компьютера, относительно сети.
Теперь я запутался, уточню у пользователя схему включения при захвате трафика.
comment:12 by , 4 months ago
Replying to san:
Можно попросить пользователя воспроизвести WD reset, с логом в режиме Debug или в какой-нибудь специальной отладочной прошивке...
Попросить, конечно, можно. Непонятно, как это поможет выявить причину проблемы...
comment:13 by , 4 months ago
Replying to san:
А, кстати, дамп был захвачен на MC-03,
Подожди... При чем здесь MC-03? В описании тикета никакая MC-03 не упоминается...
Правильно ли я понимаю, что имелось в виду, что плата SW-01 перезагружалась при подключении некоторыми браузерами к веб-интерфейсу платы MC-03?
т.е. со стороны SW-01, а не компьютера, относительно сети.
Этот фрагмент я вообще не понял. Похоже, я окончательно запутался... :(
Уточни, пожалуйста, что конкретно к чему конкретно подключалось, и что конкретно при этом перезагружалось.
comment:14 by , 4 months ago
И уточни, пожалуйста, откуда конкретно и куда конкретно какие конкретно пакеты не проходили.
follow-up: 16 comment:15 by , 4 months ago
Правильно ли я понимаю, что имелось в виду, что плата SW-01 перезагружалась при подключении некоторыми браузерами к веб-интерфейсу платы MC-03?
Нет, подключение было к веб-интерфейсу SW-01.
MC-03 как-то участвовала в захвате трафика.
comment:16 by , 4 months ago
Replying to san:
Правильно ли я понимаю, что имелось в виду, что плата SW-01 перезагружалась при подключении некоторыми браузерами к веб-интерфейсу платы MC-03?
Нет, подключение было к веб-интерфейсу SW-01.
MC-03 как-то участвовала в захвате трафика.
В таком случае, хотелось бы получить всю организованную схему прохождения трафика (дополнительно к упоминавшимся выше уточнениям)...
И, главное, непонятно, зачем захватывать трафик на плате MC-03, а не на компьютере, где запущен браузер (как, казалось бы, проще и логичнее) или самой SW-01... Но это, наверное, риторический вопрос... :)
comment:17 by , 4 months ago
Цитирую ответ пользователя
Дамп нужно было захватить удаленно (на стороне SW-01) а после «Проблемного» обращения к web-интерфейсу платы SW-01 она сразу перезапускалась, так что на ней захват tcpdump-ом приемлемого результата не дал.
Была реализована такая схема:
На плате МС-03, установленной в той-же корзине был настроен NAT Port-Forwarding. При обращении из браузера на удаленном ПК по адресу платы МС-03 (10.88.167.75) на порт 8080, запрос переадресовывался на плату SW-01 10.88.167.73 на порт 80.
На плате МС-03 был запущен tcpdump c фильтром на захват пакетов содержащих IP-адрес платы SW-01 (10.88.167.73).
После этого сделали обращение из web-браузера на 10.88.167.75:8080.
МС-03 переадресовала запросы на SW-01.
Поскольку плата МС-03 в процессе сбоя продолжала работать, в tcpdump-е отобразился весь трафик к плате SW-01 и обратно от начала обращения к ее http-серверу до сбоя.
Сравнивая этот трафик в различных ситуациях (разные браузеры / разные ОС) мы пришли к выводу, что сбой происходит только тогда, когда обмен происходит пакетами максимальной длины.
Позже, экспериментальным путем установили, что если выставить mtu на плате SW-01 не более 1476, то с платой работать можно с любого браузера и с любой ОС. А если выставить более 1476, то срабатывает watch-dog reset после первых 3х-4х TCP-сообщений.
comment:18 by , 4 months ago
Replying to san:
Хотелось бы уточнения этого момента: что подразумевается под "большими пакетами"?
С MTU от 1200 до 1500.
Replying to san:
сли выставить mtu на плате SW-01 не более 1476, то с платой работать можно с любого браузера и с любой ОС
Верно ли я понял, что если в SW-01 выставить MTU 1476, то она перестает перезагружаться несмотря на то, что пакеты размером от 1200 до 1476 по-прежнему теряются в сети?
comment:19 by , 4 months ago
Попроси, пожалуйста, пользователя воспроизвести описанную в тикете проблему с моим "Нижним самураем" - http://samurai.kolez.com/ (именно HTTP, не HTTPS). Потерю ответных пакетов длиннее 1200 байт я уже организовал. Запущен tcpdump, благодаря которому, я надеюсь, удастся увидеть, что же браузер присылает блоку.
comment:20 by , 4 months ago
Верно ли я понял, что если в SW-01 выставить MTU 1476, то она перестает перезагружаться несмотря на то, что пакеты размером от 1200 до 1476 по-прежнему теряются в сети?
Да. Видимо цифра 1200 была примерной, до 1200 точно всё работало, а сейчас они экспериментально подобрали более точную границу 1476. При MTU больше 1476 что-то теряется в сети и баг проявляется.
comment:21 by , 4 months ago
Оказалось, что пользователь почему-то не может использовать протокол IPv6, поэтому была организована более "хитрая" схема подключения к плате по протоколу IPv4, подобная описанной в comment:17.
follow-up: 24 comment:22 by , 4 months ago
Уточняю.
При установке на SW-01 MTU 1476 пакеты в сети не теряются, а при установке большего значения часть пакетов теряется(т.е. теряются пакеты более 1476 байт на уровне IP). Пользователь затем проверил это ещё и с помощью пинга. Причём, пользователь утверждает что в их сети пакеты теряются только в направлении SW->браузер, и MTU изменяли только на SW-01.
comment:23 by , 4 months ago
Эксперимент проведен, но результат отрицательный - пользователь не смог воспроизвести проблему. Вот пример одного из сеансов:
16:17:00.477787 IP 2.63.150.110.40563 > 192.168.0.60.80: Flags [S], seq 1596983104, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 16:17:00.478119 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [S.], seq 262660872, ack 1596983105, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 3], length 0 16:17:00.533101 IP 2.63.150.110.40563 > 192.168.0.60.80: Flags [.], ack 1, win 33033, length 0 16:17:00.533970 IP 2.63.150.110.40563 > 192.168.0.60.80: Flags [P.], seq 1:440, ack 1, win 33033, length 439: HTTP: GET / HTTP/1.1 16:17:00.534343 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], ack 440, win 1959, length 0 16:17:00.540876 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:00.540996 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1453:2905, ack 440, win 1959, length 1452: HTTP 16:17:00.541115 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [P.], seq 2905:4306, ack 440, win 1959, length 1401: HTTP 16:17:00.541275 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 4306:5758, ack 440, win 1959, length 1452: HTTP 16:17:00.541382 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 5758:7210, ack 440, win 1959, length 1452: HTTP 16:17:00.541479 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [P.], seq 7210:8402, ack 440, win 1959, length 1192: HTTP 16:17:00.541606 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 8402:9854, ack 440, win 1959, length 1452: HTTP 16:17:00.541691 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 9854:11306, ack 440, win 1959, length 1452: HTTP 16:17:00.541786 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [P.], seq 11306:12498, ack 440, win 1959, length 1192: HTTP 16:17:00.541918 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 12498:13950, ack 440, win 1959, length 1452: HTTP 16:17:00.797261 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:01.311899 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:02.342111 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:04.400615 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:08.521585 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:16.755447 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:17:33.223224 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:18:06.158725 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:19:12.096243 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [.], seq 1:1453, ack 440, win 1959, length 1452: HTTP: HTTP/1.1 200 OK 16:20:00.868638 IP 192.168.0.60.80 > 2.63.150.110.40563: Flags [F.], seq 13950, ack 440, win 1959, length 0 16:20:00.923715 IP 2.63.150.110.40563 > 192.168.0.60.80: Flags [.], ack 1, win 33033, length 0
Здесь видно, что клиент подключился к серверу, передал запрос, сервер подтвердил запрос и начал передавать ответ, но пакеты теряются в сети, и подтверждений серверу не приходит. Наконец, ровно через 3 минуты после соединения (очевидно, по таймауту) клиент присылает FIN. Картина соответствует ожидаемому поведению клиента и сервера при потере пакетов в сети. Также она в целом соответствует картине успешного воспроизведения проблемы, присланной пользователем.
Единственное отличие, которое я вижу, это отличие флагов SYN/SYN+ACK. При успешном воспроизведении проблемы браузер пользователя выставлял в первом пакете флаги [SEW] (то есть был активирован tcp_ecn). В эксперименте с моей платой первый пакет от клиента имел только флаг SYN (tcp_ecn не активирован).
comment:24 by , 4 months ago
Replying to san:
При установке на SW-01 MTU 1476 пакеты в сети не теряются, а при установке большего значения часть пакетов теряется(т.е. теряются пакеты более 1476 байт на уровне IP).
В связи с вновь открывшимися обстоятельствами я изменил параметры фильтра, и теперь он уничтожает пакеты размером больше 1476 байт. Предлагаю повторить эксперимент.
comment:25 by , 4 months ago
Только что заметил еще одно странное различие в поведении браузера.
Replying to san:
Дамп при котором плата зависла:
08:52:03.263053 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [SEW], seq 4260185274, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 ...... 08:52:03.271206 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 1:1461, ack 360, win 1959, length 1460: HTTP: HTTP/1.1 200 OK 08:52:03.271347 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 1461:2921, ack 360, win 1959, length 1460: HTTP 08:52:03.271482 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [P.], seq 2921:4329, ack 360, win 1959, length 1408: HTTP
В первом пакете присутствует опция mss 1460, и сервер передает ответ сегментами именно по 1460 байт (что с учетом заголовка TCP 20 байт и заголовка IPv4 20 байт дает MTU 1500 байт).
Дамп после установки MTU 1200 - всё работает штатно:
08:46:50.241192 IP 10.88.167.75.49823 > 10.88.167.73.http: Flags [S], seq 899520915, win 8192, options [nop,wscale 8,nop,nop,sackOK], length 0 ...... 08:46:50.256121 IP 10.88.167.73.http > 10.88.167.75.49823: Flags [.], seq 1:537, ack 388, win 1959, length 536: HTTP: HTTP/1.1 200 OK 08:46:50.256200 IP 10.88.167.73.http > 10.88.167.75.49823: Flags [.], seq 537:1073, ack 388, win 1959, length 536: HTTP 08:46:50.256263 IP 10.88.167.73.http > 10.88.167.75.49823: Flags [.], seq 1073:1609, ack 388, win 1959, length 536: HTTP
MTU на сервере уменьшили до 1200 байт, а на стороне клиента ничего не трогали, однако теперь в первом пакете клиента нет опции mss, и сервер посылает ответ сегментами по 536 байт, то есть размеры пакетов IP всего 576 байт...
comment:26 by , 4 months ago
Так как вторая попытка эксперимента также закончилась неудачей (плата не перезагрузилась), я делаю вывод о том, что в сети пользователя имеется какой-то еще фактор, необходимый для воспроизведения проблемы, о котором мы пока не знаем и не догадываемся.
В приведенном изначально дампе клиент обращается к серверу по протоколу HTTP. Прошу поинтересоваться у пользователя, воспроизводится ли проблема также при обращении по протоколу HTTPS.
follow-up: 28 comment:27 by , 4 months ago
Прошу поинтересоваться у пользователя, воспроизводится ли проблема также при обращении по протоколу HTTPS.
Пользователь не работает с блоком по https, сертификат ssl в блок не загружен, так-что неизвестно воспроизводится ли проблема в https
comment:28 by , 4 months ago
Replying to san:
неизвестно воспроизводится ли проблема в https
Именно поэтому я прошу попросить пользователя выяснить этот момент.
comment:29 by , 3 months ago
| Resolution: | → не воспроизводится |
|---|---|
| Status: | new → closed |
Также пользователь выслал пару дампов трафика, до установки MTU и после, не уверен что они полезны, но раз есть - прилагаю.
Тестируемая SW-01 10.88.167.73
Дамп при котором плата зависла:
root@localhost:~/DEBS-11# tcpdump host 10.88.167.73 and port 80 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 08:52:03.263053 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [SEW], seq 4260185274, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 08:52:03.263455 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [S.], seq 1382486397, ack 4260185275, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 3], length 0 08:52:03.266816 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [.], ack 1, win 1026, length 0 08:52:03.267225 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [P.], seq 1:360, ack 1, win 1026, length 359: HTTP: GET / HTTP/1.1 08:52:03.267429 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], ack 360, win 1959, length 0 08:52:03.271206 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 1:1461, ack 360, win 1959, length 1460: HTTP: HTTP/1.1 200 OK 08:52:03.271347 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 1461:2921, ack 360, win 1959, length 1460: HTTP 08:52:03.271482 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [P.], seq 2921:4329, ack 360, win 1959, length 1408: HTTP 08:52:03.271576 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 4329:5789, ack 360, win 1959, length 1460: HTTP 08:52:03.271713 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [.], seq 5789:7249, ack 360, win 1959, length 1460: HTTP 08:52:03.271811 IP 10.88.167.73.http > 10.88.167.75.63723: Flags [P.], seq 7249:8425, ack 360, win 1959, length 1176: HTTP 08:52:03.275137 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [.], ack 1, win 1026, options [nop,nop,sack 1 {2921:4329}], length 0 08:52:03.275286 IP 10.88.167.75.63723 > 10.88.167.73.http: Flags [.], ack 1, win 1026, options [nop,nop,sack 2 {7249:8425}{2921:4329}], length 0 ^CДамп после установки MTU 1200 - всё работает штатно: