Перейти к содержимому
Калькуляторы

xt_TCPMSS: bad length (N bytes) Какова причина появления этих варнингов ядра?

Приветствую.

 

Искал на этом форуме, искал на гугле, там только списки рассылок, в которых сам чёрт ногу сломит.

 

Итак: в kern.log сыпят сообщения от ядра, что мол

xt_TCPMSS: bad length (N bytes)

где N - число, чаще всего в моём случае за сутки попадает (41 bytes), до 1000 записей в логе.

Сообщения ядра начинают появляться соотв. после добавления в iptables след. нужного правила

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

, т.к. сервак является NAS для vpn-щиков.

 

Интересует, откуда ноги растут у данной проблемы, т.с. истинная причина? Есть подозрения на торрент-качальщиков. Видел советы, что надо отключить warn тип сообщений от ядра и тогда логи будут "чистые", но это равносильно закрыть глаза на проблему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приветствую.

 

Искал на этом форуме, искал на гугле, там только списки рассылок, в которых сам чёрт ногу сломит.

 

Итак: в kern.log сыпят сообщения от ядра, что мол

xt_TCPMSS: bad length (N bytes)

где N - число, чаще всего в моём случае за сутки попадает (41 bytes), до 1000 записей в логе.

Сообщения ядра начинают появляться соотв. после добавления в iptables след. нужного правила

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

, т.к. сервак является NAS для vpn-щиков.

 

Интересует, откуда ноги растут у данной проблемы, т.с. истинная причина? Есть подозрения на торрент-качальщиков. Видел советы, что надо отключить warn тип сообщений от ядра и тогда логи будут "чистые", но это равносильно закрыть глаза на проблему.

сталкивался с таким, это проблема mtu, для l2tp mtu составляет 1472, для pptp составляет 1460, при форсаже у нас тоже сыпятся такие логи, дело в том что это зависит от шейпера и от полосы пропускания, чем больше полоса пропускания тем больше mtu, вот от этого ругань и идёт, но пока все сервера работают, и особых проблем с этим нет, попробуйте указать

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, обязательно поэкспериментирую. Шейпер - встроенный в accel-ppp на tbf. Когда-то было всё на скриптах и htb, тогда этих сообщений кстати небыло.

 

PS

В теме про accel-ppp проскакивал точно такой-же вопрос, но я слежу за темой и там этот вопрос остался без ответа xeb-a, возможно шейпер как-то влияет на это.

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, обязательно поэкспериментирую. Шейпер - встроенный в accel-ppp на tbf. Когда-то было всё на скриптах и htb, тогда этих сообщений кстати небыло.

 

PS

В теме про accel-ppp проскакивал точно такой-же вопрос, но я слежу за темой и там этот вопрос остался без ответа xeb-a, возможно шейпер как-то влияет на это.

Кстати мы тоже используем accel-ppp только без встроеного шейпера, а на внешних скриптах, вопрос решили так как я вам написал, хотя интересно, какую версию accel-ppp используете, какой биллинг используете и есть ли у вас форсаж, а вообще значение mtu 1460 используется в Mikrotik для любого типа vpn.

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какую версию accel-ppp используете, какой биллинг используете и есть ли у вас форсаж
1.4.0 release (пока, обычно держу последнюю из git), многострадальный UTM5, а "форсаж" у нас в виде троекратного увеличения скорости с 01:00 до 13:00 опять же средствами accel-ppp. У меня от значения скорости интенсивность появления данных сообщений не зависит.

Да, в accel-ppp.conf:

[ppp]
...
min-mtu=1280
mtu=1400
mru=1400
...

Может это всё как-то привести к общему знаменателю с правилами iptables?

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У нас тоже UTM5, версия accel-ppp 1.3.4 настройки дефолтовые

[ppp]

verbose=1

min-mtu=1000

mtu=1400

mru=1400

ccp=0

 

шейпер на tс, только добавли в iptables настройки которые я вам писал,

как вы делаете настройки встроенного шейпера для форсажа

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

, т.к. сервак является NAS для vpn-щиков.

 

если хотите использовать --clamp-mss-to-pmtu, то вставляйте правило в цепочку POSTROUTING. При прохождении FORWARD система еще не знает через какой интерфейс пакет должен будет уйти, поэтому однозначно определить pmtu не может.

 

либо применяйте --set-mss как это посоветовали выше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472

IMHO, первое правило переопределяется вторым. И в мане в разделе TCPMSS цитирую

This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.
Судя по последнему предложению, правило имеет силу только в таблице mangle

 

taf_321, тогда почему разработчики в своём мане приводят следующий пример:

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

лажанулись?

 

PS

Перенос правила

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

в цепочку POSTROUTING не повлиял на появление сообщений, так и валят в лог... Пробую жёстко задавать 1460.

 

PPS

Сообщения продолжают появляться по 2-3 в минуту при любых вариантах расположения правила. Пробовал и так и сяк. Без данного правила сообщения не появляются, но появляется матюки от некоторых абонентов.

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472

IMHO, первое правило переопределяется вторым. И в мане в разделе TCPMSS цитирую

This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.
Судя по последнему предложению, правило имеет силу только в таблице mangle

 

taf_321, тогда почему разработчики в своём мане приводят следующий пример:

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

лажанулись?

 

PS

Перенос правила

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

в цепочку POSTROUTING не повлиял на появление сообщений, так и валят в лог... Пробую жёстко задавать 1460.

 

PPS

Сообщения продолжают появляться по 2-3 в минуту при любых вариантах расположения правила. Пробовал и так и сяк. Без данного правила сообщения не появляются, но появляется матюки от некоторых абонентов.

это исправиться только полным ребутом сервера, так как правила iptables,sysctrl,tc, жестко задёствуются после полного ребута ядра

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надеюсь, это была шутка с вашей стороны.

 

Упустил важную деталь, в сети разрешено mppe по требованию клиента.

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надеюсь, это была шутка с вашей стороны.

 

Упустил важную деталь, в сети разрешено mppe по требованию клиента. Так что mss у таких клиентов будет меньше заявленных 1460

с шифрование у нас тоже работало. но мы его отключили чтобы снизить нагрузку на сервера, отключить его можно функцией

[ppp]

ccp=0

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

[ppp]

verbose=1

min-mtu=1000

mtu=1400

mru=1400

 

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472

 

Не кажется ли Вам что выделенные циферки конфликтуют друг с другом и в правилах iptables надобы написать 1360???

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

mmv980, всё верно. На домашнем роутере когда поднимается тунель, то MTU у него именно 1400 (исходя из настроек accel-ppp), на сервере туннель так же с MTU 1400. Для l2tp значением mss будет 1372, а для pptp - 1360. Подтверждается хотя-бы пингом с клиентского ПК: ping -f -l 1373 ya.ru у меня уже требует фрагментации, а 1372 проходит нормально.

Но отошли от темы - сообщение в логах всё равно присутствует!?

# cat /var/log/kern.log | tail
Jan  8 19:29:18 nas kernel: [885279.117250] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:29:32 nas kernel: [885293.031603] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:30:28 nas kernel: [885349.331528] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:30:42 nas kernel: [885363.630631] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:44:02 nas kernel: [886162.846974] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:53:56 nas kernel: [886757.149446] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:57:19 nas kernel: [886960.027561] xt_TCPMSS: bad length (41 bytes)
Jan  8 19:58:25 nas kernel: [887026.164193] xt_TCPMSS: bad length (41 bytes)
Jan  8 20:00:31 nas kernel: [887152.751347] xt_TCPMSS: bad length (41 bytes)
Jan  8 20:01:22 nas kernel: [887203.126974] xt_TCPMSS: bad length (41 bytes)

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При прохождении FORWARD система еще не знает через какой интерфейс пакет должен будет уйти, поэтому однозначно определить pmtu не может.

Решение о маршрутизации пакета принимается до таблицы FORWARD, так что интерфейс уже известен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может перед правилом с TCPMSS поставить правило логирования пакетов с размером в 41 байт?

что нибудь типа:

iptables -t mangle -A FORWARD -p tcp -m limit --limit=1/minute --limit-burst=10 -m length --length 41 -j LOG --log-prefix="TCPMSS 41 log:"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не знаю как у Вас, но у нас пропала эта проблема и решилась прописанием правила

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

а как это расчитывается, стандартный mtu=1500 -40 для pptp(l2tp)тунеля получается 1460, посмотрите например даже в описание Mikrotik значение mtu и mru, http://www.mikrotik.com/documentation/manual_2.7/Interface/L2TP.html

есть даже на иностранном сайте таблица стандартных mtu значений для разных типов соединений, сайт правда уже не помню.

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

стандартный mtu=1500
"стандартный" в прикладном случае (моём, Вашем и любом другом) - это такой mtu, который задан на интерфейсе => на туннелях у меня MTU=1400.

Проблему так и не локализовал, буду отслеживать, как советовал mmv980, иначе никак. Логи ядра не информативны, но по ним ясно, что гадит один или пару абонентов, т.к. бывают промежутки времени и даже дни, когда этих сообщений в логе нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а какая версия ядра?

и может логировать не только пакеты в 41 байт а весь диаппазон от 1 до 40?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

# uname -a
Linux nas 2.6.32-custom #1 SMP Wed Apr 20 08:56:37 MSD 2011 i686 GNU/Linux

debian squeeze

К сожалению логгирование пакетов длины 41 не дало результата.

Изменено пользователем lan-viper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В коде ядра версии 2.6.32 в файле xt_TCPMSS.c есть такие строчки:

       /* Since it passed flags test in tcp match, we know it is is
          not a fragment, and has data >= tcp header length.  SYN
          packets should not contain data: if they did, then we risk
          running over MTU, sending Frag Needed and breaking things
          badly. --RR */
       if (tcplen != tcph->doff*4) {
               if (net_ratelimit())
                       printk(KERN_ERR "xt_TCPMSS: bad length (%u bytes)\n",
                              skb->len);
               return -1;
       }

 

а в версии например 2.6.37 проверка все еще есть а вывода в лог уже нет.

       /* Header cannot be larger than the packet */
       if (tcplen < tcph->doff*4)
               return -1;

 

так что предлагаю варианты:

1. обновить ядро

2. забить и оставить как есть :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а в версии например 2.6.37 проверка все еще есть а вывода в лог уже нет.

Вот за эту информацию спасибо (для моей версии в сети есть патч, который делает тоже самое).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня тоже debian sqeeze 2.6.32 и accel-ppp, и решилась эта проблема, и даже ядро менять не пришлось.

Изменено пользователем alexaaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К сожалению логгирование пакетов длины 41 не дало результата.

 

Длинны чего?

 

- с ethernet

 

- с IP

 

- данных в TCP

 

Потому, скорее всего, и не дало.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы вообщето говорим в контексте netfilter, где ниже IP ничего нет, а сама проблема касается только TCP протокола => всё это мной учитывалось при составлении правила логгирования на интерфейсах туннелей. Неполучилось по другим причинам.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Была таже проблема, в rsyslogd решается одной строкой в конфиге:

:msg, contains, "xt_TCPMSS: bad length" ~

 

Можно накатить syslog-ng там тоже есть фильтрация сообщений.

 

Ковырять из-за этого сорцы ядра на рабочей машине как-то лениво, тем более, что суть одна - не писать в лог эти сообщения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.