UDP: bad checksum, UDP: short packet

[srg555]

Помогите пожалуйста избавиться от сообщения "UDP: bad checksum" и "UDP: short packet" в dmesg:

 

root@host:/var/log# tail kern.log
May 17 00:31:19 host kernel: [1062554.100448] UDP: bad checksum. From 201.141.191.142:61720 to x.y.z.v:1113 ulen 111
May 17 12:12:30 host kernel: [1104518.848629] UDP: short packet: From 98.102.165.3:45776 25649/111 to x.y.z.v:29205
May 17 18:33:26 host kernel: [1127317.889095] UDP: bad checksum. From 187.126.236.4:4662 to x.y.z.v:29205 ulen 111
May 17 20:42:43 host kernel: [1135055.006305] UDP: bad checksum. From 84.43.177.151:28916 to x.y.z.v:20047 ulen 38
May 18 00:30:26 host kernel: [1148683.919826] UDP: bad checksum. From 201.141.225.144:19547 to x.y.z.v:16211 ulen 111
May 18 03:23:26 host kernel: [1159037.170204] UDP: short packet: From 50.129.87.230:12358 38596/145 to x.y.z.v:39587
May 18 08:21:23 host kernel: [1176869.162084] UDP: bad checksum. From 88.242.219.199:9573 to x.y.z.v:55491 ulen 106
May 18 16:25:13 host kernel: [1205826.745835] UDP: bad checksum. From 124.168.59.7:10403 to x.y.z.v:61885 ulen 111
May 18 18:01:41 host kernel: [1211600.491922] UDP: bad checksum. From 109.61.86.64:44892 to x.y.z.v:15082 ulen 111
May 18 19:42:24 host kernel: [1217627.816602] UDP: short packet: From 189.165.2.120:55554 64658/73 to x.y.z.v:23650

 

Выполнял:

sysctl net.netfilter.nf_conntrack_checksum=0
sysctl net.ipv4.netfilter.ip_conntrack_checksum=0

 

вроде бы этих сообщений стало поменьше, но всё равно хочется от них избавиться полностью

 

На сервере работает SNAT(обычный iptables), linux 3.2, x86_64

[martini]

они после 3.0 ядра появились вроде, до сих пор внятно никто не может ответить что это.. причем сыпет даже там где нет НАТа

[Pinkbyte]

Насколько я знаю, подобные сообщения были и раньше, до 3.0, только про TCP. В основном это обычно битые пакеты от p2p-трафика...

[Ivan_83]

вроде бы этих сообщений стало поменьше, но всё равно хочется от них избавиться полностью

Отключите сеть и они исчезнут полностью.

Или из ядра выпилите то чем он жалуется.

 

x.y.z.v - это скорее всего адрес этого несчастного линукса, который вынужден терпеть такие издевательства в виде битых юдп пакетов, на что и жалуется.

[nuclearcat]

Попробуйте

sysctl -w net.core.warnings=0

[bos9]

Как последнее, но действенное средство используйте rsyslog или syslog-ng вместо стандартного syslog, в них есть возможность фильтрации сообщений.

[lan-viper]

Такая же фигня была и у меня с TCPMSS bad length. Избавился с помощью игнорирования в rsyslog-е.

[srg555]

Отключите сеть и они исчезнут полностью.

Если нечего сказать по существу, проходите мимо, не задерживайтесь.

 

nuclearcat

Спасибо, попробовал, буду наблюдать за сообщениями в dmesg.

 

lan-viper

Зафильтровать сислогом конечно можно, но всё же это самообман, т.к. генерация событий в userspace-е из-за вшивенького транзитного пакета это прямой путь к dos-у софтроутера.

[lan-viper]

Зафильтровать сислогом конечно можно, но всё же это самообман, т.к. генерация событий в userspace-е из-за вшивенького транзитного пакета это прямой путь к dos-у софтроутера.

Я тоже так считал, пока не увидел, что разработчики ядра сами своими руками выкосили код, генерирующий сообщения в kern.log. Но это касается только проблемы с bad length.

[bos9]

Зафильтровать сислогом конечно можно, но всё же это самообман, т.к. генерация событий в userspace-е из-за вшивенького транзитного пакета это прямой путь к dos-у софтроутера.

Я тоже так считал, пока не увидел, что разработчики ядра сами своими руками выкосили код, генерирующий сообщения в kern.log. Но это касается только проблемы с bad length.

 

Ну тут ТС прав конечно... Одно дело выпилить код из сорцов ядра, другое гонять мессаджи в юзерспейс и фильтровать уже там. Если это "штатный" трафик, то разница не ощутима, а если осознанная атака - может выйти боком.

[srg555]

Попробуйте

sysctl -w net.core.warnings=0

 

проблема решена, спасибо!

[Megas]

проблема решена, спасибо!

она не решена, она скрыта.

[srg555]

Megas

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