The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Сеть. проблемы, диагностика / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 03:44 
Недавно поставил последнюю stable версию FreeBSD и столкнулся со странной проблемой. При соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные со стороны FreeBSD. Пинги ходят. Причем в тоже время, если активировать pf со включенным nat'ом, то c других машин, подключенных к FreeBSD, все отлично работает!

Выглядит это так:

1) Пакеты на ng0 при вызове из FreeBSD команды ftp ftp.yandex.ru:


01:24:15.376780 IP (tos 0x0, ttl 64, id 9182, offset 0, flags [DF], proto TCP (6), length 60)
    X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x30ab (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51127810 ecr 0], lX.X.X.Xength 0
01:24:15.389104 IP (tos 0x0, ttl 57, id 20534, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x078d (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496809586 ecr 51127810,nop,wscale 12], length 0
01:24:16.788631 IP (tos 0x0, ttl 57, id 20535, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x062f (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496809936 ecr 51127810,nop,wscale 12], length 0
01:24:18.425590 IP (tos 0x0, ttl 64, id 9189, offset 0, flags [DF], proto TCP (6), length 60)
    X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x24c1 (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51130860 ecr 0], length 0
01:24:18.437909 IP (tos 0x0, ttl 57, id 20536, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x0493 (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496810348 ecr 51127810,nop,wscale 12], length 0
01:24:18.988711 IP (tos 0x0, ttl 57, id 20537, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x0409 (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496810486 ecr 51127810,nop,wscale 12], length 0
01:24:21.644590 IP (tos 0x0, ttl 64, id 9199, offset 0, flags [DF], proto TCP (6), length 60)
    X.X.X.X.18211 > mirror.yandex.ru.ftp: Flags [S], cksum 0x182e (correct), seq 1575215393, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 51134079 ecr 0], length 0
01:24:21.656910 IP (tos 0x0, ttl 57, id 20538, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.18211: Flags [S.], cksum 0x016e (correct), seq 2746157114, ack 1575215394, win 43338, options [mss 1300,sackOK,TS val 496811153 ecr 51127810,nop,wscale 12], length 0

---> Соединение не устанавливается

1) Пакеты на ng0 при выполнении команды ftp ftp.yandex.ru с другого компа локальной сети (через nat на FreeBSD средствами PF): 


01:26:16.261639 IP (tos 0x0, ttl 63, id 27695, offset 0, flags [DF], proto TCP (6), length 64)
    X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [S], cksum 0xd148 (correct), seq 3205284718, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 416052165 ecr 0,sackOK,eol], length 0
01:26:16.271587 IP (tos 0x0, ttl 57, id 20539, offset 0, flags [none], proto TCP (6), length 60)
    mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [S.], cksum 0x87a2 (correct), seq 3487406062, ack 3205284719, win 43338, options [mss 1300,sackOK,TS val 496839805 ecr 416052165,nop,wscale 12], length 0
01:26:16.272025 IP (tos 0x0, ttl 63, id 29979, offset 0, flags [DF], proto TCP (6), length 52)
    X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [.], cksum 0x1eee (correct), seq 1, ack 1, win 16422, options [nop,nop,TS val 416052175 ecr 496839805], length 0
01:26:16.285674 IP (tos 0x0, ttl 57, id 20540, offset 0, flags [none], proto TCP (6), length 137)
    mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [P.], cksum 0x8423 (correct), seq 1:86, ack 1, win 11, options [nop,nop,TS val 496839809 ecr 416052175], length 85
01:26:16.285732 IP (tos 0x0, ttl 57, id 20541, offset 0, flags [none], proto TCP (6), length 58)
    mirror.yandex.ru.ftp > X.X.X.X.60965: Flags [P.], cksum 0xef45 (correct), seq 86:92, ack 1, win 11, options [nop,nop,TS val 496839809 ecr 416052175], length 6
01:26:16.286120 IP (tos 0x10, ttl 63, id 11591, offset 0, flags [DF], proto TCP (6), length 52)
    X.X.X.X.60965 > mirror.yandex.ru.ftp: Flags [.], cksum 0x1e92 (correct), seq 1, ack 86, win 16411, options [nop,nop,TS val 416052189 ecr 496839809], length 0

---> Все отлично работает!

Такое впечатление, что FreeBSD просто "не видит" пакеты  [S.], приходящие на ng0. Не подскажете, куда копать?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от universite email(ok) on 20-Фев-15, 04:08 
> Недавно поставил последнюю stable версию FreeBSD и столкнулся со странной проблемой. При
> соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные
> со стороны FreeBSD. Пинги ходят. Причем в тоже время, если активировать
> pf со включенным nat'ом, то c других машин, подключенных к FreeBSD,
> все отлично работает!

Смотреть в сторону MTU и MSS

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 11:52 
> Смотреть в сторону MTU и MSS

Сейчас стоит 1400/1400. Пробовал все возможное уже, но не помогает :( Попробую сегодня еще раз, по порядку.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 14:24 
Сводные результаты тестов MTU / MRU
Тестировал изменяя параметры mpd.conf

set link mtu <value>
set link mru <value>

и исполняя команду

ftp ftp.yandex.ru

Результат снимался с интерфейса ng0 командой

tcpdump -vvv -i ng0 host 213.180.204.183

Отчет

MTU/MRU        mss-fix?        Iface MTU        send_mss        rec_mss
1400            NO             1400            1360            1300
1400            YES            1400            1360            1360
1300            NO             1300            1260            1300
1300            YES            1300            1260            1260
1460            NO             1456            1416            1410
1460            YES            1456            1416            1410
1500            NO             1456            1416            1410
DEFAULT         NO             1456            1416            1410
1380            NO             1380            1340            1410
1380            YES            1380            1340            1340

Соединение ни разу не прошло :(

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "UPDATE"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 15:03 
Похоже, UDP тоже не работает:


root: # ntpdate -v 78.129.190.21
20 Feb 15:43:55 ntpdate[4772]: ntpdate 4.2.4p5-a (1)
20 Feb 15:44:00 ntpdate[4772]: no server suitable for synchronization found

Пакеты на ng0:

root: # tcpdump -i ng0 host 78.129.190.21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 65535 bytes
15:52:38.866559 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:38.926591 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:39.864257 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:39.924283 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:40.872079 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:40.932122 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48
15:52:41.872067 IP X.X.X.X.ntp > 78.129.190.21.ntp: NTPv4, Client, length 48
15:52:41.932113 IP 78.129.190.21.ntp > X.X.X.X.ntp: NTPv4, Server, length 48

Пинги однако ходят как и раньше без проблем, в том числе и c DF:


root: # ping -D -s 1372 78.129.190.21
PING 78.129.190.21 (78.129.190.21): 1372 data bytes
1380 bytes from 78.129.190.21: icmp_seq=0 ttl=56 time=62.339 ms
1380 bytes from 78.129.190.21: icmp_seq=1 ttl=56 time=62.567 ms
1380 bytes from 78.129.190.21: icmp_seq=2 ttl=56 time=62.380 ms

Соединения через туже сетевуху, но мимо туннеля (например, с ftp провайдера) также отлично работают.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "UPDATE #2"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 16:21 
DNS через l2tp туннель тоже не работает:

root: # nslookup google.com 8.8.8.8
;; connection timed out; no servers could be reached

В это время на ng0:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 65535 bytes
17:17:52.575879 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:17:52.606329 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)
17:17:57.577442 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:17:57.589621 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)
17:18:02.594181 IP X.X.X.X.10513 > google-public-dns-a.google.com.domain: 12677+ A? google.com. (28)
17:18:02.606505 IP google-public-dns-a.google.com.domain > X.X.X.X.10513: 12677 15/0/0 A 195.98.65.185, A 195.98.65.157, A 195.98.65.155, A 195.98.65.147, A 195.98.65.181, A 195.98.65.143, A 195.98.65.170, A 195.98.65.151, A 195.98.65.173, A 195.98.65.166, A 195.98.65.162, A 195.98.65.187, A 195.98.65.177, A 195.98.65.158, A 195.98.65.172 (268)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "UPDATE #3"  +/–
Сообщение от P_Dmitrij (ok) on 20-Фев-15, 21:48 
Сейчас проверил в обратную сторону, те открыл на FreeBSD tcp порт 45678 с помощью программы nc:
nc -l 45678

и попробовал подключиться снаружи телнетом:
telnet X.X.X.X 45678

Соединиться не удалось.

Пакеты на ng0:


22:38:13.834419 IP (tos 0x0, ttl 53, id 36160, offset 0, flags [DF], proto TCP (6), length 64)
    55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x18b5 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289199718 ecr 0,sackOK,eol], length 0
22:38:14.522044 IP (tos 0x0, ttl 53, id 21391, offset 0, flags [DF], proto TCP (6), length 64)
    55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x14c7 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289200724 ecr 0,sackOK,eol], length 0
22:38:15.242215 IP (tos 0x0, ttl 53, id 50075, offset 0, flags [DF], proto TCP (6), length 64)
    55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x10d9 (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289201730 ecr 0,sackOK,eol], length 0
22:38:16.218003 IP (tos 0x0, ttl 53, id 23417, offset 0, flags [DF], proto TCP (6), length 64)
    55.gprs.mts.ru.39909 > X.X.X.X.45678: Flags [S], cksum 0x0ced (correct), seq 3936149955, win 65535, options [mss 1300,nop,wscale 4,nop,nop,TS val 289202734 ecr 0,sackOK,eol], length 0
22:38:17.258127 IP (tos 0x0, ttl 53, id 38220, offset 0, flags [DF], proto TCP (6), length 64)

Может быть такое, что пакеты не выходят из Netgraph, или еще каким-то образом не доходят до сокета? Самое странное, что система совершенно новая, никакие конфиги я особо не трогал. Из сторонних программ стоят только BIND, DHCPD и MPD.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от universite email(ok) on 21-Фев-15, 00:33 
Провайдер Билайн?

На каком участке NAT находится?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij (ok) on 21-Фев-15, 02:14 
> Провайдер Билайн?
> На каком участке NAT находится?

Нет, провайдер Freedom, Воронеж. Насчет участка не понял вопрос, что имеется в виду? Мне домой заведен кабель от провайдера. Кабель воткнут в сервер. Таким образом доступна городская сеть. Подключение к интернету осуществляется через L2TP.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от universite email(ok) on 21-Фев-15, 03:29 
>> Провайдер Билайн?
>> На каком участке NAT находится?
> Нет, провайдер Freedom, Воронеж. Насчет участка не понял вопрос, что имеется в
> виду? Мне домой заведен кабель от провайдера. Кабель воткнут в сервер.
> Таким образом доступна городская сеть. Подключение к интернету осуществляется через L2TP.

На физическим интерфейсе, который смотрит в сеть ISP, из какой сети выдан IP адрес?
На виртуальном интерфейсе туннеля, который поднят на провайдера, из какой сети выдан IP адрес?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij (ok) on 21-Фев-15, 14:32 
> На физическим интерфейсе, который смотрит в сеть ISP, из какой сети выдан
> IP адрес?
> На виртуальном интерфейсе туннеля, который поднят на провайдера, из какой сети выдан
> IP адрес?


root: # ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=4019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 2c:27:d7:14:f1:ec
    inet 172.17.3.1 netmask 0xffff0000 broadcast 172.17.255.255 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
    ether a0:b3:cc:e9:51:76
    inet 10.7.13.140 netmask 0xffffffc0 broadcast 10.7.13.191 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
    inet 127.0.0.1 netmask 0xff000000 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1400
    inet X.X.X.X --> 195.98.64.216 netmask 0xffffffff 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Интерфейсы:
  em0:  домашняя локальная сеть
  bge0: cеть ISP
  ng0:   туннель l2tp в интернет, адрес X.X.X.X белый    

Маршрутизация до поднятия туннеля:


root: # /usr/home/da # netstat -4rn
Routing tables
Internet:
Destination        Gateway            Flags      Netif Expire
default            10.7.13.129        UGS        bge0
10.0.0.0/8         10.7.13.129        UGS        bge0
10.7.13.128/26     link#2             U          bge0
10.7.13.140        link#2             UHS         lo0
127.0.0.1          link#3             UH          lo0
172.17.0.0/16      link#1             U           em0
172.17.3.1         link#1             UHS         lo0
195.98.64.65/32    10.7.13.129        UGS        bge0
195.98.64.66/32    10.7.13.129        UGS        bge0
195.98.65.128/26   10.7.13.129        UGS        bge0

Маршруты с поднятым туннелем:


root@home-da:/usr/home/da # netstat -4rn
Routing tables
Internet:
Destination        Gateway            Flags      Netif Expire
default            195.98.64.216      UGS         ng0
10.0.0.0/8         10.7.13.129        UGS        bge0
10.7.13.128/26     link#2             U          bge0
10.7.13.140        link#2             UHS         lo0
127.0.0.1          link#3             UH          lo0
172.17.0.0/16      link#1             U           em0
172.17.3.1         link#1             UHS         lo0
192.168.149.0/24   10.7.13.129        UGS        bge0
195.98.64.65/32    10.7.13.129        UGS        bge0
195.98.64.66/32    10.7.13.129        UGS        bge0
195.98.64.216      link#5             UH          ng0
195.98.65.128/26   10.7.13.129        UGS        bge0
X.X.X.X     link#5             UHS         lo0

Хосты 195.98.64.65 и 195.98.64.66 - это DNS сервера провайдера

В подсети 192.168.149.0/24 лежат l2tp сервера провайдера. Маршрут в эту подсеть я прописываю скриптом после поднятия туннеля, перед изменением default gateway.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "UPDATE #4"  +/–
Сообщение от P_Dmitrij (ok) on 22-Фев-15, 19:46 
Сегодня оставил в /etc/pf.conf только 3 строки:

set debug loud
pass in log (all) all allow-opts
pass out log (all) all allow-opts

При попытке подключиться по ftp к ftp.yandex.ru (213.180.204.183) в консоли появились следующие сообщения:

root: # tail /var/log/messages
Feb 22 20:37:52 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=2834186493 (2834186493) ack=1665393824 len=0 ackskew=0 pkts=5:5 dir=in,rev
Feb 22 20:37:52 fw kernel: pf: State failure on: 1       | 5  
Feb 22 20:37:56 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=2834186493 (2834186493) ack=1665393824 len=0 ackskew=0 pkts=6:5 dir=in,rev
Feb 22 20:37:56 fw kernel: pf: State failure on: 1       | 5  
Feb 22 20:38:02 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:02 fw kernel: pf: State failure on: 1       | 5  
Feb 22 20:38:03 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:03 fw kernel: pf: State failure on: 1       | 5  
Feb 22 20:38:05 fw kernel: pf: BAD state: TCP out wire: 213.180.204.183:21 X.X.X.X:45497 stack: - [lo=1665393824 high=1665438880 win=65535 modulator=0 wscale=6] [lo=2686160170 high=2686225706 win=43338 modulator=0 wscale=12] 4:2 SA seq=3031502001 (3031502001) ack=1665393824 len=0 ackskew=0 pkts=7:5 dir=in,rev
Feb 22 20:38:05 fw kernel: pf: State failure on: 1       | 5  

Мб кто-то знает, что это обозначает? Не может ли это быть как-то связано с моей проблемой?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "UPDATE #5"  +/–
Сообщение от P_Dmitrij (ok) on 02-Мрт-15, 19:20 
Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду на freebsd.org
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "UPDATE #5"  +/–
Сообщение от Hammer (ok) on 19-Мрт-15, 16:23 
> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
> на freebsd.org

Попробуйте
ifconfig em0 -tso
ifconfig bge0 -tso

В течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump в студию.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "UPDATE #5"  +/–
Сообщение от full on 21-Мрт-15, 13:36 
>> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
>> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
>> на freebsd.org
> Попробуйте
> ifconfig em0 -tso
> ifconfig bge0 -tso
> В течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump
> в студию.

Видимо заработало

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "UPDATE #5"  +/–
Сообщение от P_Dmitrij (ok) on 21-Мрт-15, 22:50 
>>> Все, я сдаюсь. Снес все, поставил FreeBSD 10.1 RELEASE с нуля, поставил
>>> порт MPD5. Запустил - таже фигня. Больше никаких идей нет, пойду
>>> на freebsd.org
>> Попробуйте
>> ifconfig em0 -tso
>> ifconfig bge0 -tso
>> В течении секунд 15 будет перестройка сетевой подсистемы. Потом ifconfig и dump
>> в студию.
> Видимо заработало

Ну на самом деле я еще не успел проверить, тк сейчас в командировке. Как только вернусь, сразу попробую, спасибо за совет!

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "UPDATE #5"  +/–
Сообщение от sudiv on 03-Фев-17, 00:01 
Примерно такая же фигня и у Билайна на 10 и 11. Бился с этим еще года 3 назад, понять не смог в чем беда.
На фре 9 версии работает все нормально.

Кто нибудь победил ? Или хотя бы может жать божественный пинок в нужном направлении ?


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "UPDATE #5"  +/–
Сообщение от P_Dmitrij email(ok) on 03-Фев-17, 00:25 
Я к сожалению разобраться так и не смог. Пришлось отказаться от mpd :( Очень жаль, тк на нем у меня был еще и VPN сервер поднят. Если найдете причину, напишите обязательно пожалуйста.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "UPDATE #5"  +/–
Сообщение от sudiv email on 10-Фев-17, 15:01 
> Я к сожалению разобраться так и не смог. Пришлось отказаться от mpd
> :( Очень жаль, тк на нем у меня был еще и
> VPN сервер поднят. Если найдете причину, напишите обязательно пожалуйста.

тестирую шлюз на 11.0-RELEASE-p7 amd64 с акутальным на текущий момент в портах mpd5-5.8
в первом приближении выяснилось следующее:
mpd5.8 на l2tp и реализация ipv6 в 10, 11 и пожалуй начиная где-то с 9.2 категорически не дружат. при наличии в ядре ipv6 + sctp mpd ведет себя по разному:
поднимает ng интерфейс и ...
1. практически тут же разрывает соединение
2. соединение разрывается не сразу (может пройти 1,2 ... 5 минут), при этом через ng ничего не пропускается.
3. наблюдается ситуация, описаная автором ветки
4. соединение активно, трафик ходит, но через непредсказуемые интервалы времени mpd просто зависает наглухо (иногда помогает kill -9, а иногда только перезагрузка помогает)
5. дополнительно к наблюдению №4, предположительно если не предпринимать никаких активных действий по завершению чёртика mpd5, отваливается ssh, потом консоль (информация в консоль сыпется, на действия пользователя консоль не отвечает), потом машина уходит в ребут сама по себе. Тут как мне кажется просто чем-то кем-то (возможно mpd5) выжираются ресурсы и наступает кома ).
Но.
Отключил ipv6 в ядре. Ушли пункты 5, 4, 3, 2. Проблема 1 пока имеет место, но если раньше я раз 10 перезапускал mpd чтобы получить еще какие то наблюдения, то теперь №1 выскакивает крайне редко и, опять таки, имхо и скорее всего, по кривой реализации l2tp у билайна.

Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6 оно вменяемо работать отказывается.

Наблюдаю дальше, если что появится еще - напишу.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "UPDATE #5"  +/–
Сообщение от P_Dmitrij email(ok) on 10-Фев-17, 15:43 
> Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6
> оно вменяемо работать отказывается.

Мб. надо что-то дополнительно настроить в IPv6? Спасибо за идею, на выходных пересоберу ядро без options INET6, посмотрю что получится.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "UPDATE #5"  +/–
Сообщение от sudiv email on 10-Фев-17, 19:11 
>> Большой минус всего этого, теперь не получится пользоваться ipnat. Без поддержки ipv6
>> оно вменяемо работать отказывается.
> Мб. надо что-то дополнительно настроить в IPv6? Спасибо за идею, на выходных
> пересоберу ядро без options INET6, посмотрю что получится.

Может быть. Читал где-то что ipv6 даже в 11 до сих пор нестабильна, особенно при частых up/down интерфейсов, и похоже очень особенно на виртуальных. Удивительно, что например, nmap последних версий, "насильно" втюхивает поддержку ipv6 пользователям.
Но, в принципе, ipfw nat справляется аналогично с задачами ipnat. Жаль что статистика у ipfw nat крайне скудная.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "UPDATE #5"  +/–
Сообщение от violin (??) on 31-Мрт-17, 00:43 
> Отключил ipv6 в ядре. Ушли пункты 5, 4, 3, 2.

Собрала ядро без IPv6. Пункт 3 (заявленный в стартпосте) не ушел.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от violin (??) on 31-Мрт-17, 00:36 
> При
> соединении с провайдером по протоколу l2tp, не работают tcp-соединения, инициированные
> со стороны FreeBSD. Пинги ходят.
> Такое впечатление, что FreeBSD просто "не видит" пакеты  [S.], приходящие на
> ng0. Не подскажете, куда копать?

Столкнулась тоже с этой проблемой. Все точно так же, уходит SYN, возвращается SYN-ACK, но ACK после этого не уходит. UDP запросы уходят, UDP ответы приходят (tcpdump показывает расшифровку DNS-ответов), но до пользовательской программы (host) эти ответы не доходят. Пинги работают.

Если в mpd.conf заменить l2tp на pptp, все работает.

Проблема проявляется только за NAT'ом (настроенном на шлюзе, являющимся defaultroute для моей машины). Если связаться с VPN-сервером напрямую, без NAT, тогда все работает.
NAT пробовался на pf и на ipfw - результат одинаковый.
Система 10.3-RELEASE-p11.

А в Вашей конфигурации был ли NAT по дороге к VPN-серверу?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij email(ok) on 31-Мрт-17, 00:53 
>[оверквотинг удален]
> SYN-ACK, но ACK после этого не уходит. UDP запросы уходят, UDP
> ответы приходят (tcpdump показывает расшифровку DNS-ответов), но до пользовательской
> программы (host) эти ответы не доходят. Пинги работают.
> Если в mpd.conf заменить l2tp на pptp, все работает.
> Проблема проявляется только за NAT'ом (настроенном на шлюзе, являющимся defaultroute для
> моей машины). Если связаться с VPN-сервером напрямую, без NAT, тогда все
> работает.
> NAT пробовался на pf и на ipfw - результат одинаковый.
> Система 10.3-RELEASE-p11.
> А в Вашей конфигурации был ли NAT по дороге к VPN-серверу?

На машине был поднят NAT на pf, т.к. она же является роутером для локалки. Однако интерфейс, который смотрел на VPN сервер провайдера, был соединен с ним напрямую (разве что у провайдера NAT какой поднят, но для меня он прозрачен). У вас заработало по PPTP? И как, стабильно работает?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

24. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от violin (??) on 31-Мрт-17, 01:24 
> На машине был поднят NAT на pf, т.к. она же является роутером
> для локалки. Однако интерфейс, который смотрел на VPN сервер провайдера, был
> соединен с ним напрямую (разве что у провайдера NAT какой поднят,
> но для меня он прозрачен).

У Вас был белый или серый IP?
По возможности проверю с NAT'ом для локалки.
> У вас заработало по PPTP? И как, стабильно работает?

Да, PPTP работает. Вроде стабильно, но надо еще смотреть (вчера первый день полета был).

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

25. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij email(ok) on 31-Мрт-17, 01:45 
>У Вас был белый или серый IP?

Структура сети такая:
LAN -> FreeBSD pf NAT -> WAN провайдера
На этом этапе IP что-то вроде 192.168.110.25
Далее через mpd5 машина FreeBSD соединялась с VPN сервером провайдера и получала белый статический IP:
LAN -> FreeBSD pf NAT <-- (WAN) --> VPN -> Internet

Причем, если с самой машины FreeBSD идти в инет после соединения с VPN, пакеты идут мимо NAT, напрямую на интерфейс ng0. NAT служит для маскарада моего LAN.

> По возможности проверю с NAT'ом для локалки.

Спасибо, было бы интересно.

> Да, PPTP работает. Вроде стабильно, но надо еще смотреть (вчера первый день
> полета был).

У меня иногда до 3 дней работал стабильно. А бывало и нескольких секунд не держалось соединение :(

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от violin (??) on 31-Мрт-17, 10:51 
> Структура сети такая:
> LAN -> FreeBSD pf NAT -> WAN провайдера
> На этом этапе IP что-то вроде 192.168.110.25
> Далее через mpd5 машина FreeBSD соединялась с VPN сервером провайдера и получала
> белый статический IP:
> LAN -> FreeBSD pf NAT <-- (WAN) --> VPN -> Internet

Погодите. В N10 Вы писали, что адрес на bge0 (интерфейс на провайдера) такой: 10.7.13.140.
А в подсети 192.168.149.0/24 лежат l2tp сервера провайдера.
Значит, где-то там по пути есть NAT.
Или что-то изменилось?


Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от P_Dmitrij email(ok) on 31-Мрт-17, 11:17 
> Погодите. В N10 Вы писали, что адрес на bge0 (интерфейс на провайдера)
> такой: 10.7.13.140.
> А в подсети 192.168.149.0/24 лежат l2tp сервера провайдера.
> Значит, где-то там по пути есть NAT.
> Или что-то изменилось?

Прошу прощения, это я не тот ip адрес в предыдущем сообщении скопировал (192.168.110.25). Правильный адрес на bge0, как вы верно заметили, 10.7.13.140. Между 10.7.0.0. и 192.168.149.0/24 вероятно настроена маршрутизация у провайдера. Есть ли у него при этом там NAT или нет, я не могу сказать.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от violin (??) on 13-Апр-17, 21:19 
Тут уже советовали отключить tso, как-то осталось без внимания.
Из той же серии: попробуйте сделать ifconfig bge0 -rxcsum
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "FreeBSD10.1 + MPD5.7 l2tp client: Проблема с tcp"  +/–
Сообщение от violin (??) on 23-Апр-17, 17:22 
> Тут уже советовали отключить tso, как-то осталось без внимания.
> Из той же серии: попробуйте сделать ifconfig bge0 -rxcsum

Если помогло, то, скорей всего, дело в баге, который пофиксили уже.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру