Jump to content
Калькуляторы

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 тип сообщений от ядра и тогда логи будут "чистые", но это равносильно закрыть глаза на проблему.

Share this post


Link to post
Share on other sites

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

 

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

 

Итак: в 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

Edited by alexaaa

Share this post


Link to post
Share on other sites

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

 

PS

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

Edited by lan-viper

Share this post


Link to post
Share on other sites

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

 

PS

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

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

Edited by alexaaa

Share this post


Link to post
Share on other sites
какую версию 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?

Edited by lan-viper

Share this post


Link to post
Share on other sites

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

[ppp]

verbose=1

min-mtu=1000

mtu=1400

mru=1400

ccp=0

 

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

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

Edited by alexaaa

Share this post


Link to post
Share on other sites

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 как это посоветовали выше.

Share this post


Link to post
Share on other sites

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 в минуту при любых вариантах расположения правила. Пробовал и так и сяк. Без данного правила сообщения не появляются, но появляется матюки от некоторых абонентов.

Edited by lan-viper

Share this post


Link to post
Share on other sites

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, жестко задёствуются после полного ребута ядра

Edited by alexaaa

Share this post


Link to post
Share on other sites

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

 

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

Edited by lan-viper

Share this post


Link to post
Share on other sites

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

 

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

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

[ppp]

ccp=0

Edited by alexaaa

Share this post


Link to post
Share on other sites
[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???

Share this post


Link to post
Share on other sites

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)

Edited by lan-viper

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Может перед правилом с 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:"

Share this post


Link to post
Share on other sites

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

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 значений для разных типов соединений, сайт правда уже не помню.

Edited by alexaaa

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

debian squeeze

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

Edited by lan-viper

Share this post


Link to post
Share on other sites

В коде ядра версии 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. забить и оставить как есть :)

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by alexaaa

Share this post


Link to post
Share on other sites
К сожалению логгирование пакетов длины 41 не дало результата.

 

Длинны чего?

 

- с ethernet

 

- с IP

 

- данных в TCP

 

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

 

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this