LINUX.ORG.RU
ФорумAdmin

veth пропускает повреждённые пакеты

 , , , ,


1

2

Короче, вот информация о баге: https://github.com/kubernetes/kubernetes/issues/18898 Короче, я решил повторить тоже самое, и как удивительно мне это удалось! Если драйвер сетевой платы получает повреждённый пакет, он его должен сбросить. Хотя, veth так не делает. В интернете пишут, сто патч вроде бы введёт в ядро, хотя я этого не замечаю. Вот лог трафика:

.D.X...iGET / HTTP/1.1
Host: 10.243.0.243
User-Agent: Mozilla/5.2 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Mon, 05 Sep 2016 19:11:37 GMT
If-None-Match: "2b60-53bc7730819c4-gzip"
Cache-Control: max-age=0


13:27:54.613469 IP 10.243.0.243.1104 > 10.247.1.46.41532: Flags [R], seq 3611020336, win 0, length 0
E..(.{@.@.&J
...
....P.<.;.0....P...M...
13:27:57.544268 IP 10.243.0.243.80 > 10.247.1.46.41536: Flags [FP.], seq 1713027331:1713027849, ack 839753470, win 939, options [nop,nop,TS val 1517056 ecr 4464825], length 518
E..:..@.@...
...
....P.@f...2........7.....
..&..D .HTTP/1.1 404 Not Found
Date: Sat, 24 Sep 2016 13:26:58 GMT
Server: Apache/2.4.10 (Debian)
Content-Length: 301
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /phpmyadiin/themes/dot.gif was not found on this server.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at 10.243.0.243 Port 80</address>
</body></html>

Вот ядро сервера:

root@router:~# uname -r
4.7.3
root@router:~# 
Как можно в lxc заставить драйвер veth дропать такие пакеты?

★★★★★

А, собственно, с какой целью его фиксить? Он позволяет какую-то уязвимость эксплуатировать, или что?

Prius ()
Ответ на: комментарий от snaf

Подозреваю, ты единственный кто это вообще читал.

Stil ★★★★★ ()
Ответ на: комментарий от ne-vlezay

на приемном конце veth tcpdump ругается на КС ?

vel ★★★★★ ()
Ответ на: комментарий от snaf

А ты что, проверял лог трафика ? :)

Бага с veth древняя. У него в свойствах по-умолчанию стоит, что он умеет аппаратно формировать и проверять все КС и ядро при формировании пакетов эти КС не формирует, а при приеме считает, что с КС все хорошо.

И это все замечательно работает, пока оба конца veth используются внутри одной машины, а вот если второй конец запихнуть в мост, который подключен в реальную сеть, то начинаются появлятся проблемы.

vel ★★★★★ ()

а ты не смотрел счетчики через «netstat -s»

Учти, что tcpdump показывает все пакеты попадающие в систему т.к. он работает до их обработки конкретным протоколом.

vel ★★★★★ ()
Ответ на: комментарий от ne-vlezay

Это если она железная и если умеет. veth этого не умеет - она не железная, а программная, но говорит системе, что все умеет.

vel ★★★★★ ()
Ответ на: комментарий от ne-vlezay

как минимум ethtool -K veth0 tx off && ethtool -K veth1 tx off после создания пары

для параноиков ethtool -K veth0 tx off rx off && ethtool -K veth1 tx off rx off

Либо пропатчить ядро ( для 4.4 )

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 0ef4a5a..e2b2ab8 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -293,8 +293,7 @@ static const struct net_device_ops veth_netdev_ops = {
        .ndo_features_check     = passthru_features_check,
 };
 
-#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |    \
-                      NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA | \
                       NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |           \
                       NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT | NETIF_F_UFO |   \
                       NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \

vel ★★★★★ ()
Ответ на: комментарий от vel

не помогает.
Битые пакеты проходят если сделать на роутере:

tc qdisc add dev eth1 root netem corrupt 100%

ne-vlezay ★★★★★ ()
Последнее исправление: ne-vlezay (всего исправлений: 1)
Ответ на: комментарий от ne-vlezay

по контрольным суммам.

А на счет netem Контейнер с veth/openvswitch - все замечательно работает 10.0.0.1 - реальный хост в сети.

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 htb default 30 r2q 100
tc class add dev eth0 parent 1: classid 1:05 htb rate 100Mbit ceil 100Mbit burst 15k
tc qdisc add dev eth0 parent 1:05 handle 05 netem corrupt 20%
tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.1 classid 1:05

root@intgw3-orig2:/etc/htb# ping -w 0.5 -c 10 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_req=1 ttl=64 time=0.314 ms
64 bytes from 10.0.0.1: icmp_req=2 ttl=64 time=0.149 ms
64 bytes from 10.0.0.1: icmp_req=3 ttl=64 time=0.158 ms
64 bytes from 10.0.0.1: icmp_req=4 ttl=64 time=0.275 ms
64 bytes from 10.0.0.1: icmp_req=5 ttl=64 time=0.160 ms
64 bytes from 10.0.0.1: icmp_req=6 ttl=64 time=0.209 ms
64 bytes from 10.0.0.1: icmp_req=7 ttl=64 time=0.169 ms
64 bytes from 10.0.0.1: icmp_req=10 ttl=64 time=0.136 ms

--- 10.0.0.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.136/0.196/0.314/0.061 ms
на приемной стороне в icmp InCsumErrors +2

vel ★★★★★ ()
Ответ на: комментарий от vel

а попробуй поднять в контейнере сервер и зайти из локалки на него при включенном netem. Ещё можно сделать тест:
test.sh:

#!/bin/bash

DATA=0

while true
do
DATA=$(($DATA+1))
printf "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa $DATA \n";
sleep 1
done
на хосте: cat ./test.sh|nc -l -p 8080
в контейнере: nc 10.0.0.1 8080

Ещё в первом контейнере: cat ./test.sh|nc -l -p 8080
в во втором: nc 10.0.0.1 8080

ne-vlezay ★★★★★ ()
Последнее исправление: ne-vlezay (всего исправлений: 2)
Ответ на: комментарий от ne-vlezay

Я пробовал запускать iperf3 -c 10.0.0.1 && iperf3 -c 10.0.0.1 -R

видно было резкое увеличение числа ошибок КС для tcp на 10.0.0.1

Скорость была никакой даже при 5%, а при 20% не всегда коннектилось.

Если запустить ping из контейнера и запустить на 10.0.0.1 tcpdump, то видны ошибки КС

    10.0.0.96 > 10.0.0.1: ICMP echo request, id 832, seq 9, length 64 (wrong icmp cksum b2d0 (->b2cc)!)
21:38:11.360436 00:15:00:00:48:14 > 68:05:ca:02:51:b3, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 50723, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.96 > 10.0.0.1: ICMP type-#40, length 64 (wrong icmp cksum b3cf (->93cf)!)

У меня все работает так как я ожидал.

vel ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.