xt_TCPMSS: bad length (N bytes)

lan-viper · January 8, 2012

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

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

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

alexaaa · January 8, 2012

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

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

Итак: в 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 January 8, 2012 by alexaaa

lan-viper · January 8, 2012

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

PS

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

Edited January 8, 2012 by lan-viper

alexaaa · January 8, 2012

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

PS

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

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

Edited January 8, 2012 by alexaaa

lan-viper · January 8, 2012

какую версию 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 January 8, 2012 by lan-viper

alexaaa · January 8, 2012

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

[ppp]

verbose=1

min-mtu=1000

mtu=1400

mru=1400

ccp=0

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

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

Edited January 8, 2012 by alexaaa

taf_321 · January 8, 2012

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

lan-viper · January 8, 2012

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 January 8, 2012 by lan-viper

alexaaa · January 8, 2012

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 January 8, 2012 by alexaaa

lan-viper · January 8, 2012

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

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

Edited January 8, 2012 by lan-viper

alexaaa · January 8, 2012

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

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

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

[ppp]

ccp=0

Edited January 8, 2012 by alexaaa

mmv980 · January 8, 2012

[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???

lan-viper · January 8, 2012

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 January 8, 2012 by lan-viper

lan-viper · January 9, 2012

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

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

mmv980 · January 9, 2012

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

alexaaa · January 9, 2012

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

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 January 9, 2012 by alexaaa

lan-viper · January 9, 2012

стандартный mtu=1500

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

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

mmv980 · January 9, 2012

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

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

lan-viper · January 9, 2012

# 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 January 9, 2012 by lan-viper

mmv980 · January 9, 2012

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

lan-viper · January 10, 2012

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

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

alexaaa · January 10, 2012

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

Edited January 10, 2012 by alexaaa

Ivan_83 · January 10, 2012

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

Длинны чего?

- с ethernet

- с IP

- данных в TCP

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

lan-viper · January 11, 2012

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

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

bos9 · March 30, 2012

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

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

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

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

Sign In

xt_TCPMSS: bad length (N bytes)

Recommended Posts

lan-viper

alexaaa

lan-viper

alexaaa

lan-viper

alexaaa

taf_321

lan-viper

alexaaa

lan-viper

alexaaa

mmv980

lan-viper

lan-viper

mmv980

alexaaa

lan-viper

mmv980

lan-viper

mmv980

lan-viper

alexaaa

Ivan_83

lan-viper

bos9

Join the conversation