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 & Networ
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
> mailto:bu7c...@yandex.ru>> написал:
>
> On 13.04.2017 18:07, Irina Liakh wrote:
> раз уж мы говорим о решении, сможете протестировать патч?
> https://people.freeb
Hi!
On Thu, Apr 13, 2017 at 11:41:30PM +0700, Eugene Grosbein writes:
> Это не проблема сетевой карты, она тут вообще ни в чём не виновата, и её
> драйвер тоже.
> Проблема в сетевом стеке FreeBSD, а -rxcsum это просто быстрый workaround.
> Вообще для того, чтобы напороться на проблему, нужно
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 и ne
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:
> > > Добрый день,
> > >
> > > раз уж мы говорим о решении, сможете протестировать патч?
> > > https://peop
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),
> >> а это значит, что контрольная сумма у него сходится. Я склонен верить
> >> tcpdump
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
freebsd@uafug.
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
>>> ether X:X:X:X:X:X
>>> inet 192.168.12.2 netmask 0xf
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
> > inet 192.168.12.2 netmask 0xff00 broadcast 192.168.12.255
> >
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 говорит "cksu
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 ud
Каким образом можно провести механическую и электрическую диагностику
разъема 8P8C, а также патч-корда UTP программным способом из PC ? :)
Причем одна из сторон патч-корда нам не подконтрольна.
13 апреля 2017 г., 1:43 пользователь Anton Sayetsky
написал:
> 13 апр. 2017 г. 1:30 пользователь "Vlad
В письме от Чтв, 13 Апр 2017, 00:01 Irina Liakh пишет:
> Ничего не поменялось.
> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp" и
> "netstat -sp udp".
ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
сети и, потом, ещё и с другого провайдера. Ips
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> написал
>
> Заменить сетевую карту и патч-корд есть возможность?
>
> А ещё шамана позвать в бубен постучать.
>
У вас необычные фантазии, с LOR'a наб
13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan"
написал
Заменить сетевую карту и патч-корд есть возможность?
А ещё шамана позвать в бубен постучать.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/free
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 0x8242000
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)
>
> на
>
> na
В письме от Чтв, 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 She
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 -> (vr
В письме от Срд, 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 mailin
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
> >>
> >> Этот счетчик растёт в то время, когда выполняются попытки установить
> >> TCP
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
http://mailman.uafug.org.ua/mailman/
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 -nv
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 мимо туннеля или вообще через "левый" интерфейс.
Посмотрела "для очистки совести" - не уходит.
Видимо, дело не в "левом" интерфейсе, т.к. в случае DN
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 на обоих сторонах туннеля в это момент.
Серверная сторона туннеля мне не доступна. Доступны только клиентская
и сервер-роутер, который маскарадит клиентскую машину и роутит ее к VPN-серверу.
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:
>
> 12:35:11.99
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
U
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'ится ближайшим хопом - сервером, имеющим выход
к VPN-сервер
Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в линии
присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост
полностью на время эксперимента...
--
Отправлено из Mail.Ru для Android среда, 12 апреля 2017г., 10:49 +03:00 от
Irina Liakh sp...@itl.ua :
>O
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-серверу.
Туннель поднимается, в логах все ок
77 matches
Mail list logo
