On 13.04.2017 20:48, Irina Liakh wrote:
> On Thu, Apr 13, 2017 at 07:00:02PM +0300, Andrey V. Elsukov wrote:
>> Спасибо. Подозрение было на то, что флаги проверки контрольной
>> суммы полученные от сетевой карты и подсчитанные для внешнего IP и
>> UDP заголовков используются и на передоваемые
Hi!
On Thu, Apr 13, 2017 at 11:19:32PM +0300, Vladislav V. Prodan writes:
> 13 апреля 2017 г., 21:01 пользователь Yuriy B. Borysov <
> yokod...@yokodzun.kiev.ua> написал:
>>
> Очень похоже на видоизмененный virtio
> Попробуйте в /boot/loader.conf вставить:
> # решает проблемы с битыми
13 апреля 2017 г., 21:01 пользователь Yuriy B. Borysov <
yokod...@yokodzun.kiev.ua> написал:
> Hi!
>
> On Thu, Apr 13, 2017 at 08:32:11PM +0300, Vladislav V. Prodan writes:
>
> >> Вероятно, не только в таких случаях. На нескольких FreeBSD, работающих
> >> на хостах hyper-v проблема проявлялась
14.04.2017 1:01, Irina Liakh пишет:
>> 13.04.2017 21:55, Irina Liakh пишет:
>>> Может, дело в том, что tcpdump и netstat проверяют разные чексуммы?
>>> iiuc, tcpdump проверяет IP checksum, а netstat - TCP/UDP checksum.
>>
>> tcpdump без ключа -K проверяет и TCP/UDP тоже, он умный.
>
>
Hi!
On Thu, Apr 13, 2017 at 08:32:11PM +0300, Vladislav V. Prodan writes:
>> Вероятно, не только в таких случаях. На нескольких FreeBSD, работающих
>> на хостах hyper-v проблема проявлялась при включении NAT.
>>
> Драйвера сетевых virtio ?
Драйвер про себя пишет:
hn5: on vmbus0
при
On Thu, Apr 13, 2017 at 11:17:01PM +0700, Eugene Grosbein wrote:
> 13.04.2017 21:55, Irina Liakh пишет:
> > Может, дело в том, что tcpdump и netstat проверяют разные чексуммы?
> > iiuc, tcpdump проверяет IP checksum, а netstat - TCP/UDP checksum.
>
> tcpdump без ключа -K проверяет и TCP/UDP тоже,
On Thu, Apr 13, 2017 at 07:00:02PM +0300, Andrey V. Elsukov wrote:
> Спасибо. Подозрение было на то, что флаги проверки контрольной суммы
> полученные от сетевой карты и подсчитанные для внешнего IP и UDP
> заголовков используются и на передоваемые внутри туннеля данные.
Ясно, спасибо!
> Судя по
On Thu, Apr 13, 2017 at 06:07:02PM +0300, Irina Liakh wrote:
> On Thu, Apr 13, 2017 at 06:02:37PM +0300, Oleg V. Nauman wrote:
> > On Thursday 13 April 2017 16:59:10 Irina Liakh wrote:
> > > On Thu, Apr 13, 2017 at 12:50:43PM +0300, Andrey V. Elsukov wrote:
> > > > Добрый день,
> > > >
> > > >
13 апреля 2017 г., 20:08 пользователь Yuriy B. Borysov <
yokod...@yokodzun.kiev.ua> написал:
> Вероятно, не только в таких случаях. На нескольких FreeBSD, работающих
> на хостах hyper-v проблема проявлялась при включении NAT.
>
Драйвера сетевых virtio ?
--
Vladislav V. Prodan
System &
On Thursday 13 April 2017 20:08:14 Yuriy B. Borysov wrote:
> Hi!
>
> On Thu, Apr 13, 2017 at 11:41:30PM +0700, Eugene Grosbein writes:
> > Это не проблема сетевой карты, она тут вообще ни в чём не виновата, и её
> > драйвер тоже. Проблема в сетевом стеке FreeBSD, а -rxcsum это просто
> >
On 13.04.2017 20:08, Yuriy B. Borysov wrote:
> Вероятно, не только в таких случаях. На нескольких FreeBSD, работающих
> на хостах hyper-v проблема проявлялась при включении NAT.
>
> Картина такая, включаем NAT (проверял ipfw и pf) - доступ по SSH
> снаружи пропадает, ftp работает только active.
On 13.04.2017 19:31, Vladislav V. Prodan wrote:
>
>
> 13 апреля 2017 г., 19:00 пользователь Andrey V. Elsukov
> > написал:
>
> On 13.04.2017 18:07, Irina Liakh wrote:
> раз уж мы говорим о решении, сможете протестировать патч?
>
13.04.2017 23:31, Vladislav V. Prodan пишет:
> Теперь вопрос.
> Как детектить сетевые карты с подобными проблемами? Или сразу вырубать
> -rxcsum -txcsum ?
Это не проблема сетевой карты, она тут вообще ни в чём не виновата, и её
драйвер тоже.
Проблема в сетевом стеке FreeBSD, а -rxcsum это
13 апреля 2017 г., 19:00 пользователь Andrey V. Elsukov
написал:
> On 13.04.2017 18:07, Irina Liakh wrote:
> раз уж мы говорим о решении, сможете протестировать патч?
> https://people.freebsd.org/~ae/udp_csum_flags.diff
>
> Нужно пересобрать ядро.
> >>>
>
13.04.2017 21:55, Irina Liakh пишет:
>> Ядро может пропускать самостоятельный подсчет контрольных сумм,
>> если в метаданных пакета уже есть посчитанная оборудованием сумма (checksum
>> offload).
>> Для netgraph такого быть не должно, но не исключены баги.
>
> Может, дело в том, что tcpdump и
On 13.04.2017 18:07, Irina Liakh wrote:
раз уж мы говорим о решении, сможете протестировать патч?
https://people.freebsd.org/~ae/udp_csum_flags.diff
Нужно пересобрать ядро.
>>>
>>> Все работает с этим патчем. Проверяла только IPv4.
>>
>> Для однозначности - и TCP работает?
>
On Thu, Apr 13, 2017 at 06:02:37PM +0300, Oleg V. Nauman wrote:
> On Thursday 13 April 2017 16:59:10 Irina Liakh wrote:
> > On Thu, Apr 13, 2017 at 12:50:43PM +0300, Andrey V. Elsukov wrote:
> > > Добрый день,
> > >
> > > раз уж мы говорим о решении, сможете протестировать патч?
> > >
On Thursday 13 April 2017 16:59:10 Irina Liakh wrote:
> On Thu, Apr 13, 2017 at 12:50:43PM +0300, Andrey V. Elsukov wrote:
> > Добрый день,
> >
> > раз уж мы говорим о решении, сможете протестировать патч?
> > https://people.freebsd.org/~ae/udp_csum_flags.diff
> >
> > Нужно пересобрать ядро.
>
On Thu, Apr 13, 2017 at 01:54:56PM +0700, Eugene Grosbein wrote:
> 13.04.2017 13:49, Irina Liakh пишет:
>
> >> С другой стороны, tcpdump -s0 про входящие TCP-пакеты на ng0 говорит cksum
> >> 0x8bd2 (correct),
> >> а это значит, что контрольная сумма у него сходится. Я склонен верить
> >>
On Thu, Apr 13, 2017 at 12:50:43PM +0300, Andrey V. Elsukov wrote:
> Добрый день,
>
> раз уж мы говорим о решении, сможете протестировать патч?
> https://people.freebsd.org/~ae/udp_csum_flags.diff
>
> Нужно пересобрать ядро.
Все работает с этим патчем. Проверяла только IPv4.
On 13.04.2017 11:04, Irina Liakh wrote:
> On Thu, Apr 13, 2017 at 02:24:28PM +0700, Eugene Grosbein wrote:
>> Баг в ядре, значит. Пока пропишите в /etc/rc.conf:
>>
>> ifconfig_fxp0="inet 192.168.12.2/24 -rxcum"
>>
>> Ну и желательно сделать PR, да, со всей этой диагностикой.
>
> Благодарю Вас за
On Thu, Apr 13, 2017 at 03:08:05PM +0700, Eugene Grosbein wrote:
> Тут конечно -rxcsum, опечатка.
sure)
> А можно ссылку на жалобу того ещё одного человека?
https://www.opennet.ru/openforum/vsluhforumID1/96009.html
___
freebsd mailing list
13.04.2017 15:04, Irina Liakh пишет:
> On Thu, Apr 13, 2017 at 02:24:28PM +0700, Eugene Grosbein wrote:
>> Баг в ядре, значит. Пока пропишите в /etc/rc.conf:
>>
>> ifconfig_fxp0="inet 192.168.12.2/24 -rxcum"
Тут конечно -rxcsum, опечатка.
>> Ну и желательно сделать PR, да, со всей этой
On Thu, Apr 13, 2017 at 02:24:28PM +0700, Eugene Grosbein wrote:
> Баг в ядре, значит. Пока пропишите в /etc/rc.conf:
>
> ifconfig_fxp0="inet 192.168.12.2/24 -rxcum"
>
> Ну и желательно сделать PR, да, со всей этой диагностикой.
Благодарю Вас за помощь!
И вообще всех кто помогал.
Здорово, что
13.04.2017 14:06, Irina Liakh пишет:
> On Thu, Apr 13, 2017 at 01:54:56PM +0700, Eugene Grosbein wrote:
>> 13.04.2017 13:49, Irina Liakh пишет:
>>> # ifconfig fxp0
>>> fxp0: flags=8843 metric 0 mtu 1500
>>> options=2009
>>>
On Thu, Apr 13, 2017 at 01:54:56PM +0700, Eugene Grosbein wrote:
> 13.04.2017 13:49, Irina Liakh пишет:
> > # ifconfig fxp0
> > fxp0: flags=8843 metric 0 mtu 1500
> > options=2009
> > ether X:X:X:X:X:X
> >
On Thu, Apr 13, 2017 at 01:52:26AM +0300, Alexander Sheiko wrote:
> ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
> сети
Ставить ради этого винду так не хочется
> и, потом, ещё и с другого провайдера.
Попытаюсь..
___
freebsd
13.04.2017 13:49, Irina Liakh пишет:
>> С другой стороны, tcpdump -s0 про входящие TCP-пакеты на ng0 говорит cksum
>> 0x8bd2 (correct),
>> а это значит, что контрольная сумма у него сходится. Я склонен верить
>> tcpdump-у в этом вопросе,
> Кстати да, как так получается, что tcpdump говорит
On Thu, Apr 13, 2017 at 01:06:30AM +0300, Vladislav V. Prodan wrote:
> 2017-04-13 0:31 GMT+03:00 Irina Liakh :
>
> > Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp"
> > и "netstat -sp udp".
> >
>
> Заменить сетевую карту и патч-корд есть возможность?
Но
On Thu, Apr 13, 2017 at 10:07:07AM +0700, Eugene Grosbein wrote:
> 12.04.2017 23:32, Eugene Grosbein пишет:
>
> 65 discarded for bad checksums
> >>>
> >>> Этот счетчик растёт в то время, когда выполняются попытки установить
> >>> TCP-соедиение
> >>> через туннель?
> >>
> >> Да. Синхронно
12.04.2017 23:32, Eugene Grosbein пишет:
65 discarded for bad checksums
>>>
>>> Этот счетчик растёт в то время, когда выполняются попытки установить
>>> TCP-соедиение
>>> через туннель?
>>
>> Да. Синхронно с приходящими SYN ACK пакетами.
>> Аналогично растет вот это:
>>
>> # netstat -sp
Каким образом можно провести механическую и электрическую диагностику
разъема 8P8C, а также патч-корда UTP программным способом из PC ? :)
Причем одна из сторон патч-корда нам не подконтрольна.
13 апреля 2017 г., 1:43 пользователь Anton Sayetsky
написал:
> 13 апр. 2017 г.
В письме от Чтв, 13 Апр 2017, 00:01 Irina Liakh пишет:
> Ничего не поменялось.
> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp" и
> "netstat -sp udp".
ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
сети и, потом, ещё и с другого провайдера.
13 апр. 2017 г. 1:30 пользователь "Vladislav V. Prodan"
написал:
Сетевые карты vr никогда стабильностью и безупречной работой не отличались.
Да и всегда существует проблема статики и КЗ у "медных" сетевых плат.
А кто-то говорил, что сетевухи на чипе VIA Rhine хорошие? Тем
13 апреля 2017 г., 1:09 пользователь Anton Sayetsky
написал:
>
>
> 13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan" <
> ad...@support.od.ua> написал
>
> Заменить сетевую карту и патч-корд есть возможность?
>
> А ещё шамана позвать в бубен постучать.
>
У вас необычные
13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan"
написал
Заменить сетевую карту и патч-корд есть возможность?
А ещё шамана позвать в бубен постучать.
___
freebsd mailing list
freebsd@uafug.org.ua
2017-04-13 0:31 GMT+03:00 Irina Liakh :
> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp"
> и "netstat -sp udp".
>
Заменить сетевую карту и патч-корд есть возможность?
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
On Thu, Apr 13, 2017 at 12:16:32AM +0700, Eugene Grosbein wrote:
> выгрузить pf и ещё раз попробовать c ipfw nat - всё должно работать.
# kldstat
Id Refs AddressSize Name
1 19 0x8020 1fa7c38 kernel
21 0x82221000 1fe5a3 zfs.ko
31
On Wed, Apr 12, 2017 at 11:17:04PM +0300, Alexander Sheiko wrote:
>
> Покажите pfctl -s states в момент установленного туннеля.
all udp :57871 (192.168.12.2:54002) -> :1701
MULTIPLE:MULTIPLE
> Попробуйте поменять:
>
> nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
>
> на
>
>
В письме от Чтв, 13 Апр 2017, 00:15 Irina Liakh пишет:
> # pfctl -s nat
Покажите pfctl -s states в момент установленного туннеля.
Попробуйте поменять:
nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
на
nat pass on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
--
WBR, Alexander
On Wed, Apr 12, 2017 at 09:39:26PM +0300, Alexander Sheiko wrote:
> Покажите, как именно НАТите.
>
> Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
> часы. Может проблема с правилами, а может специфика фри.
# pfctl -s nat
nat on vr0 inet from 192.168.12.0/24 to any ->
В письме от Срд, 12 Апр 2017, 22:35 Irina Liakh пишет:
> # pfctl -s rules
Покажите, как именно НАТите.
Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
часы. Может проблема с правилами, а может специфика фри.
--
WBR, Alexander Sheiko
13.04.2017 2:35, Irina Liakh пишет:
>> Если ядро GENERIC, то есть вывод kldstat на роутере в то время,
>> когда туннель через него установлен.
> # kldstat
> Id Refs AddressSize Name
> 1 15 0x8020 1fa7c38 kernel
> 21 0x82221000 1fe5a3 zfs.ko
> 31
On Wed, Apr 12, 2017 at 07:59:38PM +0300, Oleg V. Nauman wrote:
> И wifi роутер с NAT ?
У меня роутером FreeBSD с внутренним и внешним эзернетами.
Это когда через NAT подключаюсь.
Когда напрямую - через wifi роутер, мне неподвластный.
___
freebsd
On Wed, Apr 12, 2017 at 11:52:19PM +0700, Eugene Grosbein wrote:
> Теперь насчет него, всё те же вопросы: ядро GENERIC?
Да.
Система FreeBSD 11.0-RELEASE-p2
> Что в loader.conf и в sysctl.conf?
В loader.conf пусто, в sysctl.conf только про acpi.
> Какая внешняя сетевая (имя драйвера)?
vr0
>
On Wednesday 12 April 2017 21:00:21 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> > 13.04.2017 0:43, Irina Liakh пишет:
> > > tcpdump вдогонку показывала,
> >
> > Но без командной строки (без аргументов), а это важно.
> > Нужна полная команда и её вывод
13.04.2017 2:07, Irina Liakh пишет:
> Пробовались ipfw и pf - результат одинаковый (только на счетчики bad checksum
> не смотрела
> во время эксперимента с ipfw).
> Портит не по причине моих рук? Значит, send-pr?
Рано, роутер с NAT тоже легко неправильно настроить.
Теперь насчет него, всё те
On Wed, Apr 12, 2017 at 07:39:25PM +0300, Vladislav V. Prodan wrote:
> Или сетевая карта (в виртуалке).
не виртуальная машина, обычная)
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
On Wed, Apr 12, 2017 at 11:32:10PM +0700, Eugene Grosbein wrote:
> 13.04.2017 1:48, Irina Liakh пишет:
> > On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> >>> 65 discarded for bad checksums
> >>
> >> Этот счетчик растёт в то время, когда выполняются попытки установить
> >>
12 апреля 2017 г., 19:32 пользователь Eugene Grosbein
написал:
> Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.
>
Или сетевая карта (в виртуалке).
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
13.04.2017 1:48, Irina Liakh пишет:
> On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
>>> 65 discarded for bad checksums
>>
>> Этот счетчик растёт в то время, когда выполняются попытки установить
>> TCP-соедиение
>> через туннель?
>
> Да. Синхронно с приходящими SYN ACK
On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> > 65 discarded for bad checksums
>
> Этот счетчик растёт в то время, когда выполняются попытки установить
> TCP-соедиение
> через туннель?
Да. Синхронно с приходящими SYN ACK пакетами.
Аналогично растет вот это:
# netstat -sp
13.04.2017 1:30, Irina Liakh пишет:
> 65 discarded for bad checksums
Этот счетчик растёт в то время, когда выполняются попытки установить
TCP-соедиение
через туннель?
___
freebsd mailing list
freebsd@uafug.org.ua
On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже нет?
Перепробовала несколько разных сервисов (по TCP) на разных серверах -
все ведут себя аналогично.
То же самое с разными DNS-серверами (по UDP).
On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> В студию вывод команд uptime и netstat -sp tcp
# uptime
7:05PM up 8:26, 7 users, load averages: 0.40, 0.36, 0.29
# netstat -sp tcp
tcp:
47279 packets sent
21066 data packets (4318440 bytes)
12 апреля 2017 г., 3:38 пользователь Irina Liakh написал:
> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
> к VPN-серверу.
>
Машина в виртуалке? Какой драйвер сетевухи?
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
13.04.2017 1:00, Irina Liakh пишет:
> "-p" же не принципиально?
В данном случае не должно быть, но tcpdump лучше всегда запускать с -p, за
исключением
тех случаев, когда есть особая причина использовать promiscuous mode.
TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже
Может, это окажется полезным: если в настройках изменить исключительно
тип линка (в mpd.conf вместо l2tp поставить pptp), то все работает.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> 13.04.2017 0:43, Irina Liakh пишет:
>
> > tcpdump вдогонку показывала,
>
> Но без командной строки (без аргументов), а это важно.
> Нужна полная команда и её вывод подряд. Не забыть ключи tcpdump -vnps0 и -i.
# tcpdump -i ng0
13.04.2017 0:43, Irina Liakh пишет:
>> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми
>> аргументами,
>> даже если кажется, что это не нужно - на самом деле, нужно.
> На клиенте ipfw, pf и ipfilter не загружены, на сервере с NAT'ом
> загружен только pf с nat rules, фильтрующих
On Wed, Apr 12, 2017 at 09:37:37PM +0700, Eugene Grosbein wrote:
> Стандартная ошибка - художественное изложение своими словами проделанной
> диагностики и полное отсутствие по-настоящему необходимых деталей.
> Не надо так.
угу.
> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми
12.04.2017 7:38, Irina Liakh пишет:
> Добрый день всем!
>
> Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> известно)
>
> Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
On Wed, Apr 12, 2017 at 04:04:35PM +0300, Oleg V. Nauman wrote:
> SYN+ACK похож на правду, значит еще один вариант - смотреть а не уходит ли
> ACK мимо туннеля или вообще через "левый" интерфейс.
Посмотрела "для очистки совести" - не уходит.
Видимо, дело не в "левом" интерфейсе, т.к. в случае
On Wednesday 12 April 2017 16:17:52 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
> > Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это
> > момент.
> Серверная сторона туннеля мне не доступна. Доступны только клиентская
> и
On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
>
> Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это момент.
Серверная сторона туннеля мне не доступна. Доступны только клиентская
и сервер-роутер, который маскарадит клиентскую машину и роутит ее к
On Wednesday 12 April 2017 15:00:43 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> > Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
> > отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?
>
> Не растут. Кстати, UDP sum ok:
>
>
On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
> отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?
Не растут. Кстати, UDP sum ok:
12:35:11.991026 IP (tos 0x0, ttl 64, id 13540, offset 0, flags [none], proto
On 12.04.17 11:01, skeletor wrote:
12.04.17 03:38, Irina Liakh пишет:
Добрый день всем!
Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)
Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом -
On Wed, Apr 12, 2017 at 11:38:20AM +0300, Oleg V. Nauman wrote:
> Часы убежали вперед.
Спасибо :) Спрошу почему так.
> > On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > > линии присутствуют).
On Wednesday 12 April 2017 13:27:42 Irina Liakh wrote:
Часы убежали вперед.
> On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > линии присутствуют). Я бы пересмотрел все правила ещё раз или
On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
>
> Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> линии присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост
> полностью на время эксперимента...
Это при отключенном файерволе
12.04.17 03:38, Irina Liakh пишет:
Добрый день всем!
Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)
Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
к
Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в линии
присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост
полностью на время эксперимента...
--
Отправлено из Mail.Ru для Android среда, 12 апреля 2017г., 10:49 +03:00 от
Irina Liakh sp...@itl.ua :
On Wed, Apr 12, 2017 at 06:29:29AM +0300, Vladislav V. Prodan wrote:
> 12 апреля 2017 г., 3:38 пользователь Irina Liakh написал:
>
> > Добрый день всем!
> >
> > Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> > известно)
> >
>
> Смотреть с каким MTU
12 апреля 2017 г., 3:38 пользователь Irina Liakh написал:
> Добрый день всем!
>
> Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> известно)
>
Смотреть с каким MTU поднялся туннель на обоих концах.
Подбирая пингом размер пакетов, вычисляем MTU.
На клиенте
Добрый день всем!
Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)
Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
к VPN-серверу.
Туннель поднимается, в логах все
76 matches
Mail list logo