from:"Yaroslav Shvets"


Hello Eugene Grosbein.

On Thu, 2 Dec 2021, 08:09, you wrote:


02.12.2021 6:41, Yaroslav Shvets пишет:


FreeBSD 12.2-releng
Почтовый сервер: sendmail, dovecot
Все работало без приключений. ipfw довольно сложный.

При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
поведение:


[skip]


Посмотрю. Сервер постоянно используется.
Времени на эксперименты особо нет.


Не стоит ставить dot-zero (13.0) на рабочие серверы.
Рекомендую откат на stable/12 хотя бы до выпуска 13.1

На тестовые машины ставить можно.


Обычно, так и происходит.
А тут черт дёрнул.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

Hello.

On Thu, 2 Dec 2021, 01:31, you wrote:

Hello Taras Heichenko.

On Wed, 1 Dec 2021, 21:10, you wrote:

On 1 Dec 2021, at 21:01, Yaroslav Shvets wrote:

Hello All.

Не могу гарантировать, более того, не могу сказать, почему это могло
произойти при переходе
на 13, но выглядит как странности работы DNS. У вас резолвер где живет?
Когда запускается?

FreeBSD 12.2-releng
Почтовый сервер: sendmail, dovecot
Все работало без приключений. ipfw довольно сложный.

При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
поведение:

При перезагрузке сервера успешно стартуют и sendmail, и dovecot.
`netstat -an` показывают, что нужные порты успешно слушаются.
При этом, подключится telnet'ом то получается, то не получается.
То получается на localhost, но не получается на другие сетевые интерфейсы.
То можно подключиться к одному порту, но не получается к другому,
то после перезагрузки к другому уже нельзя, а к ранее неработавшему -
уже можно. Такое чувство, что после перезагрузки слушающие
порты работают/не работают в рэндомном порядке.

Рестарт сервисов уже после загрузки, как правило лечит.
И оба сервиса начинают нормально работать.
Вобщем, какая-то магия.
Sendmail - штатный,
dovecot-2.3.17_1

(ssh при этом работает нормально)

На <= 12.2-releng до этого много лет на тех же конфигах
все работало без странностей: если порт слушается и фаервол не
препятствует - то подключиться можно.

Кто-нибудь знает, что и где могло поломаться?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Нет. Дело не в резолвинге.
И не в правилах ipfw.
Одно из первых правил разрешает все via lo

Все попытки законнектиться telnet'ом выполнялись
только применительно к ip-адресам интерфейсов.
А вообще на машине bind крутится.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

Hello Eugene.

On Wed, 1 Dec 2021, 23:31, you wrote:

02.12.2021 2:01, Yaroslav Shvets пишет:

Hello All.

FreeBSD 12.2-releng
Почтовый сервер: sendmail, dovecot
Все работало без приключений. ipfw довольно сложный.

При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
поведение:

(ssh при этом работает нормально)

Кто-нибудь знает, что и где могло поломаться?

Что угодно могло поломаться. Что значит "не получается" - connection refused?
таймаут?

telnet 127.0.0.1 110
идут попытки - таймаут

Или, при следующей перезагрузке:
110 как положено открывается, но
перестает 995, или 143.
Закономерности не нашел.

Что показывает tcpdump -npi lo0 ?

Посмотрю. Сервер постоянно используется.
Времени на эксперименты особо нет.

"Рестарт сервисов лечит" - это включает в себя загрузку правил ipfw по новой?

Нет, только `service dovecot restart`
или `cd /etc/mail && make stop start`

Если да, то уходит ли проблема, если вместо рестарта временно сделать
sysctl net.inet.ip.fw.enable=0 ?

пробовал первым правилом все разрешать, но не помогает

В багзилле делал поиск по похожим проблемам для 13.0-RELEASE или 13.0-STABLE?

Нет. Надеялся, что проблема известная и стандартная.

Почему думаю, что проблема в операционке или в моих руках -
потому что наблюдается одновременно на sendmail и dovecot.

Не упомянул: это виртуалка под ESXi какой-то не очень
старый. Сходу не скажу, но кажется 6.7

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

Hello Taras Heichenko.

On Wed, 1 Dec 2021, 21:10, you wrote:

On 1 Dec 2021, at 21:01, Yaroslav Shvets wrote:

Hello All.

Не могу гарантировать, более того, не могу сказать, почему это могло произойти
при переходе
на 13, но выглядит как странности работы DNS. У вас резолвер где живет? Когда
запускается?

FreeBSD 12.2-releng
Почтовый сервер: sendmail, dovecot
Все работало без приключений. ipfw довольно сложный.

При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
поведение:

(ssh при этом работает нормально)

Кто-нибудь знает, что и где могло поломаться?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Нет. Дело не в резолвинге.
И не в правилах ipfw.
Одно из первых правил разрешает все via lo

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] странности с сетью при переходе на 13-ую версию

Hello All.

FreeBSD 12.2-releng
Почтовый сервер: sendmail, dovecot
Все работало без приключений. ipfw довольно сложный.

При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
поведение:

(ssh при этом работает нормально)

Кто-нибудь знает, что и где могло поломаться?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] PPPoE и PPTP, GRE, IPSEC

2021-11-12 Пенетрантность Yaroslav Shvets

Hello.

On Thu, 11 Nov 2021, 18:09, you wrote:

11.11.2021 14:25, Yaroslav Shvets пишет:

Hello All.

Провайдер предоставляет интернет через pppoe.
Данный сервер должен также выступать как множественным
pptp-клиентом, так и pptp-сервером (mpd5).
Предполагается также подключение по IPSEC.
Не исключены в будущем другие туннели.
Конфигурация давно отлажена и успешно работает
через классический сетевой интерфейс.

Будет ли это все нормально работать через PPPoE?
Есть ли смысл связываться или стоит выбрать
классическое подключение к провайдеру?

С одной стороны, работать через PPPoE оно может и будет, при условии что
провайдер ничего не фильтрует
и ты аккуратно будешь обращаться с MTU на туннелях.

С другой стороны, с практической точки зрения КРАЙНЕ желательно иметь MTU=1500
на интерфейсе подключения к публичному интернету, так как это избавит от
большого числа проблем.

Иметь MTU=1500 на PPPoE теоретически возможно, а практически это зависит от
провайдера.
Так что классическое статическое подключение с MTU=1500 гораздо более
беспроблемно на практике
и нужно всеми силами стараться получить именно его.

Спасибо за советы. Потенциальные проблемы не нужны.
Нужно, чтобы просто работало и каши не просило.
Предпочту тогда классическое сетевое соединение.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] PPPoE и PPTP, GRE, IPSEC

2021-11-10 Пенетрантность Yaroslav Shvets


Hello All.

Провайдер предоставляет интернет через pppoe.
Данный сервер должен также выступать как множественным
pptp-клиентом, так и pptp-сервером (mpd5).
Предполагается также подключение по IPSEC.
Не исключены в будущем другие туннели.
Конфигурация давно отлажена и успешно работает
через классический сетевой интерфейс.

Будет ли это все нормально работать через PPPoE?
Есть ли смысл связываться или стоит выбрать
классическое подключение к провайдеру?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для проц��сса

2021-07-01 Пенетрантность Yaroslav Shvets


Hello Oleg V. Nauman.

On Wed, 30 Jun 2021, 18:59, you wrote:


On 2021 M06 30, Wed 18:40:45 EEST Yaroslav Shvets wrote:

Hello Oleg V. Nauman.

On Wed, 30 Jun 2021, 18:01, you wrote:

On 2021 M06 30, Wed 08:23:42 EEST Yaroslav Shvets wrote:

Hello.

В /usr/local/etc/rc.d есть скрипт, который запускает некий процесс.
При получении сигнала SIGHUP и скрипт, и процесс отдельно умеют
этот сигнал обрабатывать.
Т.е. выполняют отвественную за это логику.


А какую реакцию на SIGHUP Вы ожидаете?


Записи в логи, манипуляции с фаерволом, переконнекты на удаленные системы.


Ну, если такой функционал есть. А то (не)многие по SIGHUP перечитывают
конфиги.
 Кстати, а сеть/файервол уже подняты к моменту попытки их использования?
Файловая система с логами уже смонтирована?


Да. В стартовом скрипте так:
# REQUIRE: LOGIN FILESYSTEMS ipfw syslogd.

Eugene Grosbein хорошо объяснил суть проблемы.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

2021-07-01 Пенетрантность Yaroslav Shvets

Hello Eugene.

On Wed, 30 Jun 2021, 22:32, you wrote:

30.06.2021 12:23, Yaroslav Shvets пишет:

Hello.

В /usr/local/etc/rc.d есть скрипт, который запускает некий процесс.
При получении сигнала SIGHUP и скрипт, и процесс отдельно умеют
этот сигнал обрабатывать.
Т.е. выполняют отвественную за это логику.

Если запуск скрипта, а соотвественно и последующий запуск процесса произошел
во время загрузки системы, то и скрипт, и процесс на SIGHUP не реагируют.
Т.е. процессы в памяти присутствуют, но на kill -HUP не реагируют.
Если скрипт в /usr/local/etc/rc.d запускается из шелла, то и скрипт,
и процесс вполне реагируют на приходящие сигналы.

Как мне кажется, дело не в другом окружении.
Что я упустил?

Когда процесс запускается, он наследует от родителя его окружение.
В это окружение входит также состояние реакции процесса на сигналы,
включая игнорирование/блокировку блокируемых сигналов.

Некоторые процессы имеют такой баг: они устанавливают свои обработчики-реакции
на сигналы, но ошибочно предполагают, что сигналы SIGHUP при запуске не
заблокированы,
а это предположение не всегда верно и если процесс устанавливает обработчик для
сигнала,
он должен озаботиться явной разблокировкой его.

Например, такой баг есть в squid, я его им зарепортил в 2016-м с простым
исправлением, но без какой-либо реакции вообще.
https://bugs.squid-cache.org/show_bug.cgi?id=4494
https://bugs.squid-cache.org/attachment.cgi?id=3337

В FreeBSD можно посмотреть состояние блокировок сигналов запущенного процесса:

# ps -wo pid,sigmask,sigignore,command -p 53667
PID BLOCKED IGNORED COMMAND
53667 0 18788002 /usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf

В данном случае у squid нет заблокированных сигналов и есть игнорируемые.

Предлагаю сравнить в вашем случае это у процессов, запущенных при загрузке или
вручную,
будет ли разница?

И если не секрет, что за процесс?

Все так и есть. Процесс иногда в состоянии с флагом игнорировать SIGHUP.

И если не секрет, что за процесс?

Это старый, но модифицированный вариант vpnc.

Спасибо за объяснение сути проблемы!

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

Hello Oleg V. Nauman.

On Wed, 30 Jun 2021, 18:01, you wrote:

On 2021 M06 30, Wed 08:23:42 EEST Yaroslav Shvets wrote:

Hello.

А какую реакцию на SIGHUP Вы ожидаете?

Записи в логи, манипуляции с фаерволом, переконнекты на удаленные системы.

Если запуск скрипта, а соотвественно и последующий запуск процесса произошел
во время загрузки системы, то и скрипт, и процесс на SIGHUP не реагируют.
Т.е. процессы в памяти присутствуют, но на kill -HUP не реагируют.
Если скрипт в /usr/local/etc/rc.d запускается из шелла, то и скрипт, и
процесс вполне реагируют на приходящие сигналы.

Ошибка вполне может быть тут, а не при загрузке.

Как мне кажется, дело не в другом окружении.
Что я упустил?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

Hello George.

On Wed, 30 Jun 2021, 17:50, you wrote:

Hello!

On Wed, 30 Jun 2021 at 17:48:25 (+0300), Anton Saietskii wrote:

Как мне кажется, дело не в другом окружении.
Что я упустил?

Наверное, демонстрацию скрипта, а первым делом сравнение его с аналогичными.

Плюсую. Было бы удобнее понимать, о чём речь, представляя, о чём речь =)

Скрипты объемные. Надо резать и упрощать.
Наверное так и буду делать, пока не докопаюсь.

Пальцем в небо: а никакой разницы в состоянии и флагах процессов нет при
запуске руками и при старте системы?
ps axo 'pid,ppid,flags,flags2,state,command' -p

Интересная мысль. Посмотрю, как будет возможность.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

Hello Lena.

On Wed, 30 Jun 2021, 17:33, you wrote:

Команду kill дает пользователь root?

Exim запускается из /usr/local/etc/rc.d и на kill -HUP реагирует.

Да. Конечно kill из под root'а.
И процессы висят в памяти из под рута.
Только в случае автостарта, ни скрипт, ни процесс не реагируют на SIGHUP,
но если запускать их вручную, то потом они отлично получают и обрабатывают
SIGHUP. Хоть вручную, хоть из под крона.

Exim запускается из /usr/local/etc/rc.d и на kill -HUP реагирует.

И не только Exim.
Поэтому я уверен, что я где-то что-то упускаю из вида.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] сигнал для процесса


Hello.

В /usr/local/etc/rc.d есть скрипт, который запускает некий процесс.
При получении сигнала SIGHUP и скрипт, и процесс отдельно умеют
этот сигнал обрабатывать.
Т.е. выполняют отвественную за это логику.

Если запуск скрипта, а соотвественно и последующий запуск процесса произошел
во время загрузки системы, то и скрипт, и процесс на SIGHUP не реагируют.
Т.е. процессы в памяти присутствуют, но на kill -HUP  не реагируют.
Если скрипт в /usr/local/etc/rc.d запускается из шелла, то и скрипт,
и процесс вполне реагируют на приходящие сигналы.

Как мне кажется, дело не в другом окружении.
Что я упустил?

--
Yaroslav Shvets

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] releng-13 не проходит installworld

2021-06-16 Пенетрантность Yaroslav Shvets


Hello Anton.

releng/13.0

-- make.conf --
NO_GUI= true
NO_X=   true
OPTIONS_UNSET=  GUI
OPTIONS_UNSET=  X11

# with SASLv2:
SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2

DEVELOPER=yes
-- cut --

По-поводу, "DEVELOPER=yes" уже и не помню, когда и зачем ставил.
Без него не пробовал.

On Tue, 15 Jun 2021, 22:26, you wrote:


Ну и make.conf, конечно -- туда тоже можно странного и ломающего впихнуть.
Кстати, а что такое "releng-13"? Знаю только "stable/13" и "releng/13.0"...

On Tue, Jun 15, 2021 at 7:19 PM Yaroslav Shvets  wrote:


Hello Anton Saietskii.

src.conf в системе отсутсвует

On Tue, 15 Jun 2021, 14:33, you wrote:


Может, сперва хотя бы src.conf проверить?

On Tue, Jun 15, 2021, 14:32 Eugene Grosbein  wrote:


15.06.2021 16:41, Yaroslav Shvets пишет:

Hello All.

Успешно обновился из исходников с releng-12.2 до releng-13.
При пересборке releng-13 из releng-13 не инсталится мир:


Такие вопросы лучше всего задавать в список рассылки sta...@freebsd.org.
Или можно сразу PR оформлять в багзилле и в нём CC: ставить
sta...@freebsd.org.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd





--
Yaroslav Shvets





--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] releng-13 не проходит installworld

2021-06-15 Пенетрантность Yaroslav Shvets


Hello Eugene.

Решил сначала переспросить, может известный косяк,
но мимо меня прошло.

On Tue, 15 Jun 2021, 14:33, you wrote:


Может, сперва хотя бы src.conf проверить?

On Tue, Jun 15, 2021, 14:32 Eugene Grosbein  wrote:


15.06.2021 16:41, Yaroslav Shvets пишет:

Hello All.

Успешно обновился из исходников с releng-12.2 до releng-13.
При пересборке releng-13 из releng-13 не инсталится мир:


Такие вопросы лучше всего задавать в список рассылки sta...@freebsd.org.
Или можно сразу PR оформлять в багзилле и в нём CC: ставить
sta...@freebsd.org.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd





--
Yaroslav Shvets
ART CAPITAL Investment Group
CIO, CSO
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] releng-13 не проходит installworld

2021-06-15 Пенетрантность Yaroslav Shvets


Hello Anton Saietskii.

src.conf в системе отсутсвует

On Tue, 15 Jun 2021, 14:33, you wrote:


Может, сперва хотя бы src.conf проверить?

On Tue, Jun 15, 2021, 14:32 Eugene Grosbein  wrote:


15.06.2021 16:41, Yaroslav Shvets пишет:

Hello All.

Успешно обновился из исходников с releng-12.2 до releng-13.
При пересборке releng-13 из releng-13 не инсталится мир:


Такие вопросы лучше всего задавать в список рассылки sta...@freebsd.org.
Или можно сразу PR оформлять в багзилле и в нём CC: ставить
sta...@freebsd.org.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd





--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] releng-13 не проходит installworld

2021-06-15 Пенетрантность Yaroslav Shvets


Hello All.

Успешно обновился из исходников с releng-12.2 до releng-13.
При пересборке releng-13 из releng-13 не инсталится мир:

-- cut --
===> stand/i386 (install)
===> stand/i386/btx (install)
===> stand/i386/btx/btx (install)
===> stand/i386/btx/btxldr (install)
===> stand/i386/btx/lib (install)
===> stand/i386/libi386 (install)
===> stand/i386/mbr (install)
install   -o root -g wheel -m 444   mbr /boot/mbr
===> stand/i386/pmbr (install)
install   -o root -g wheel -m 444   pmbr /boot/pmbr
===> stand/i386/boot0 (install)
install   -o root -g wheel -m 444   boot0 /boot/boot0
===> stand/i386/boot0sio (install)
install   -o root -g wheel -m 444   boot0 /boot/boot0sio
===> stand/i386/boot2 (install)
objcopy -S -O binary boot1.out boot1
objcopy -S -O binary boot2.out boot2.bin
btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx 
-l boot2.ldr  -o boot2.ld -P 1 boot2.bin

make[6]: exec(btxld) failed (No such file or directory)
*** Error code 1

Stop.
make[6]: stopped in /usr/src/stand/i386/boot2
*** Error code 1

Stop.
make[5]: stopped in /usr/src/stand/i386
*** Error code 1

Stop.
make[4]: stopped in /usr/src/stand
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
-- cut --

Куда смотреть?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Посоветуйте 10Gbps сетевой адаптер

2019-09-30 Пенетрантность Yaroslav Shvets


On Fri, 27 Sep 2019, 17:06, you wrote:


27.09.2019 17:56, Yaroslav Shvets пишет:

Hello.

Посоветуйте нормальный сабж.
Бюджет - разумный. Нет необходимости
экономить 20-30% стоимости и брать откровенно плохой,
но и нет смысла переплачивать в разы, если разница
с хорошим невелика.

Пиковый трафик ожидается до 10Gbps, средний в несколько гигабит.
Интересует безглючность железа и драйверов под FreeBSD.



https://ark.intel.com/content/www/ru/ru/ark/products/68669/intel-ethernet-converged-network-adapter-x520-da1.html

Есть такой же у них, но двухпортовый.

1 порт US $46,88 
https://www.ebay.com/itm/NEW-Intel-X520-DA1-E10G41BTDA-10GbE-Ethernet-Converged-Network-Adapter/133091684606
2 порта US $88,88 
https://www.ebay.com/itm/Supermicro-Dual-Port-10GB-Ethernet-Adapter-AOC-STGN-I2S-X520-DA2-REV-2-0/132884975857?epid=110317440


Всем спасибо!

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] gpart не видит

On Fri, 27 Sep 2019, 14:05, you wrote:

27.09.2019 18:01, Yaroslav Shvets пишет:

Таблицы разделов нет.
Судя по всему ufs развернули прямо на /dev/raid/r0
Спасибо за подсказку. Это мне в голову не пришло.

Увеличить такую UFS при смене диска на бОльший можно при помощи growfs на лету.

Это ясно. Но лучше переделаю на нормальный GPT.

Если том не загрузочный - нет никакого смысла в таблице разделов на нём.
Можно просто сделать это tunefs -L mydata /dev/raid/r0
Чтобы glabel status показывал метку и можно было монтировать как
/dev/ufs/mydata.
Такая метка лежит в суперблоке UFS и не требует отдельных секторов в конце или
где-то ещё.

GPT на таком массиве лишь оверхед, потенциальная головная боль при увеличении и
больше ничего.

В общем случае - согласен.

Но иногда удобно нарезать фиксированные куски партишенами GPT.
Например, выделить 10GB партишен под определенную задачу
и знать, что квота гарантированно не превысится.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] gpart не видит


On Fri, 27 Sep 2019, 13:53, you wrote:


27.09.2019 17:48, Yaroslav Shvets пишет:


Таблицы разделов нет.
Судя по всему ufs развернули прямо на /dev/raid/r0
Спасибо за подсказку. Это мне в голову не пришло.


Увеличить такую UFS при смене диска на бОльший можно при помощи growfs на лету.


Это ясно. Но лучше переделаю на нормальный GPT.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] Посоветуйте 10Gbps сетевой адаптер


Hello.

Посоветуйте нормальный сабж.
Бюджет - разумный. Нет необходимости
экономить 20-30% стоимости и брать откровенно плохой,
но и нет смысла переплачивать в разы, если разница
с хорошим невелика.

Пиковый трафик ожидается до 10Gbps, средний в несколько гигабит.
Интересует безглючность железа и драйверов под FreeBSD.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] gpart не видит


On Fri, 27 Sep 2019, 11:56, you wrote:


27.09.2019 13:38, Yaroslav Shvets пишет:


Есть Adaptec'овский рейд: зеркало из двух дисков.
В системе видится как /dev/raid/r0

Возникла необходимость без развала рейда изменить размеры разделов, но
gpart его не видит. Что делать?


Если gpart "не видит" разделов по стандартным смещениям на диске, значит таблиц 
разделов по этим смещениям нет.
С аппаратными рейдами такое бывает - они могут откусывать кусочек в начале 
диска под свои метаданные,
рапортовать хосту соответственно уменьшенный размер массива и во все обращениях 
"хоста" к диску
добавлять смещение так, чтобы хост (включая BIOS) видел "начало" диска по этому 
смещению.

Тогда при уносе дисков на другую машину без аппаратного контроллера gpart не 
увидит таблицу разделов.

Вариант - таблица на месте, но повреждена, так бывает с GPT.

Так что нужно больше информации - какой именно Adaptec, где запускается gpart -
на машине с контроллером или нет, какая таблица разделов была (MBR или GPT).
И ещё неплохо бы показать вывод dd if=/dev/raid/r0 bs=512 count=1 | hd


Таблицы разделов нет.
Судя по всему ufs развернули прямо на /dev/raid/r0
Спасибо за подсказку. Это мне в голову не пришло.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] gpart не видит


Hello.

Есть Adaptec'овский рейд: зеркало из двух дисков.
В системе видится как /dev/raid/r0

Возникла необходимость без развала рейда изменить размеры разделов, но
gpart его не видит. Что делать?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

2019-09-26 Пенетрантность Yaroslav Shvets


On Thu, 26 Sep 2019, 11:48, you wrote:


On 26.09.2019 05:23, Yaroslav Shvets wrote:


Создал PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825


Ещё надо упомянуть, что удаление lagg0 и пересоздание его и влана вручную (с 
указанием конкретных команд)
даёт рабочий влан. Это исключит подозрения в проблемах окружения на твоей 
стороне и в твоей криворукости,
о чём всегда есть подозрения у разработчиков, пока их не развеять.


Упомянул.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 21:26, you wrote:


On 25.09.2019 23:26, Yaroslav Shvets wrote:


On Wed, 25 Sep 2019, 15:15, you wrote:


On 25.09.2019 18:16, Yaroslav Shvets wrote:


Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf?


Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё 
ломается
из-за корявой последовательности, кроме vlanhwfilter.

Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с 
rc.conf.


Почти наверняка проблема действительно в драйвере lagg.
Есть ли возможность поменять laggproto lacp на laggproto failover на время 
ребута,
а потом уже выставить laggproto обратно, например в /etc/rc.local ?

И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он 
рабочим.


В rc.conf поставил "laggproto failover", /etc/rc.local - "laggproto lacp",
порты коммутатора в режиме lacp.

При загрузке в console.log:

lagg0: flags=8843 metric 0 mtu 1500

options=81249b
ether 00:e0:81:ba:ad:90
laggproto failover lagghash l2,l3,l4
laggport: em0 flags=5
laggport: em1 flags=0<>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29

lagg0.11: flags=8843 metric 0 mtu 1496
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

...
Firewall rules loaded.
Starting local daemons: <в этом месте отработал '/sbin/ifconfig lagg0 laggproto 
lacp laggport em0 laggport em1 up'>
...

После загрузки:

# ifconfig -v lagg0
lagg0: flags=8843 metric 0 mtu 1500

options=81249b
ether 00:e0:81:ba:ad:90
laggproto lacp lagghash l2,l3,l4
lagg options:
flags=10
flowid_shift: 16
lagg statistics:
active ports: 2
flapping: 0
lag id: [(8000,00-E0-81-BA-AD-90,01CB,,),
 (0001,2C-36-F8-4E-47-93,03E8,,)]
laggport: em0 flags=1c 
state=3d
[(8000,00-E0-81-BA-AD-90,01CB,8000,0003),
 (0001,2C-36-F8-4E-47-93,03E8,0001,000B)]
laggport: em1 flags=1c 
state=3d
[(8000,00-E0-81-BA-AD-90,01CB,8000,0004),
 (0001,2C-36-F8-4E-47-93,03E8,0001,000C)]
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29

# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1496
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

Интерфейс в нерабочем состоянии.

tcpdump на lagg0.11 видит только исходящие пакеты, входящих - нет.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 21:20, you wrote:


On 26.09.2019 01:16, Eugene Grosbein wrote:

On 25.09.2019 23:26, Yaroslav Shvets wrote:


On Wed, 25 Sep 2019, 15:15, you wrote:


On 25.09.2019 18:16, Yaroslav Shvets wrote:


Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf?


Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё 
ломается
из-за корявой последовательности, кроме vlanhwfilter.

Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с 
rc.conf.


[attachments skipped]

Прошу создать баг (PR) в 
https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System
Описать проблему, обязательно приложить этот rc.conf и console.log,
не забыть упомянуть, что device vlan есть в ядре.

И прислать мне номер PR.


Да, и обязательно надо указать, что это апгрейд с 11.3, в котором всё работало.


Создал PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 21:26, you wrote:


On 25.09.2019 23:26, Yaroslav Shvets wrote:


On Wed, 25 Sep 2019, 15:15, you wrote:


On 25.09.2019 18:16, Yaroslav Shvets wrote:


Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf?


Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё 
ломается
из-за корявой последовательности, кроме vlanhwfilter.

Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с 
rc.conf.


Почти наверняка проблема действительно в драйвере lagg.
Есть ли возможность поменять laggproto lacp на laggproto failover на время 
ребута,
а потом уже выставить laggproto обратно, например в /etc/rc.local ?

И поглядеть, с каким mtu будет в таком случае создан lagg0.11 и будет ли он 
рабочим.


А на коммутаторе порты должны остаться в позе lacp?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 15:15, you wrote:


On 25.09.2019 18:16, Yaroslav Shvets wrote:


Т.е. в качестве workaround можно отключить -vlanhwfilter на em0,em1 в rc.conf?


Не знаю. Вряд ли. mtu=1496 всё равно сам не исправится и кто его знает, что ещё 
ломается
из-за корявой последовательности, кроме vlanhwfilter.

Хорошо бы воспроизвести проблему "ребутом" и показать console.log вместе с 
rc.conf.


--
Yaroslav ShvetsSep 25 18:39:00  gw1 kernel: Setting hostuuid: 
0cb452fa-5734-11e5-bb0b-00e081baad90.
Sep 25 18:39:00  gw1 kernel: Setting hostid: 0xef5d4ffc.
Sep 25 18:39:00  gw1 kernel: Starting file system checks:
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-root: FILE SYSTEM 
CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-root: clean, 
7955823 free (1903 frags, 994240 blocks, 0.0% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-tmp: FILE SYSTEM 
CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-tmp: clean, 
16240544 free (48 frags, 2030062 blocks, 0.0% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/gpt/pt_ssd250_root: FILE SYSTEM 
CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/pt_ssd250_root: clean, 
51980144 free (43040 frags, 6492138 blocks, 0.1% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/ufs/raidfs: FILE SYSTEM CLEAN; 
SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/ufs/raidfs: clean, 72353497 
free (462401 frags, 8986387 blocks, 0.1% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-var: FILE SYSTEM 
CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-var: clean, 
16102996 free (7460 frags, 2011942 blocks, 0.0% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-varlog: FILE 
SYSTEM CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-varlog: clean, 
29536064 free (632 frags, 3691929 blocks, 0.0% fragmentation)
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-usr: FILE SYSTEM 
CLEAN; SKIPPING CHECKS
Sep 25 18:39:00  gw1 kernel: /dev/gpt/disk2-gpt-usr: clean, 
198834254 free (116750 frags, 24839688 blocks, 0.0% fragmentation)
Sep 25 18:39:00  gw1 kernel: Mounting local filesystems:.
Sep 25 18:39:00  gw1 kernel: Setting hostname: gw1.
Sep 25 18:39:00  gw1 kernel: Additional TCP/IP options: rfc1323 
extensions=NO.
Sep 25 18:39:00  gw1 kernel: Setting up harvesting: 
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Sep 25 18:39:00  gw1 kernel: Feeding entropy: .
Sep 25 18:39:00  gw1 kernel: Created clone interfaces: lagg0 
lagg0.11.
Sep 25 18:39:00  gw1 kernel: Starting Network: lo0 em0 em1 enc0 
lagg0 lagg0.11.
Sep 25 18:39:00  gw1 kernel: lo0: 
flags=8049 metric 0 mtu 16384
Sep 25 18:39:00  gw1 kernel:  
options=680003
Sep 25 18:39:00  gw1 kernel:  inet 127.0.0.1 netmask 
0xff00
Sep 25 18:39:00  gw1 kernel:  inet6 ::1 prefixlen 128
Sep 25 18:39:00  gw1 kernel:  inet6 fe80::1%lo0 prefixlen 64 
scopeid 0x6
Sep 25 18:39:00  gw1 kernel:  groups: lo
Sep 25 18:39:00  gw1 kernel:  nd6 
options=21
Sep 25 18:39:00  gw1 kernel: em0: 
flags=8843 metric 0 mtu 1500
Sep 25 18:39:00  gw1 kernel:  
options=81249b
Sep 25 18:39:00  gw1 kernel:  ether 00:e0:81:ba:ad:90
Sep 25 18:39:00  gw1 kernel:  media: Ethernet autoselect 
(1000baseT )
Sep 25 18:39:00  gw1 kernel:  status: active
Sep 25 18:39:00  gw1 kernel:  nd6 
options=29
Sep 25 18:39:00  gw1 kernel: em1: 
flags=8843 metric 0 mtu 1500
Sep 25 18:39:00  gw1 kernel:  
options=81249b
Sep 25 18:39:00  gw1 kernel:  ether 00:e0:81:ba:ad:90
Sep 25 18:39:00  gw1 kernel:  hwaddr 00:e0:81:ba:ad:91
Sep 25 18:39:00  gw1 kernel:  media: Ethernet autoselect 
(1000baseT )
Sep 25 18:39:00  gw1 kernel:  status: active
Sep 25 18:39:00  gw1 kernel:  nd6 
options=29
Sep 25 18:39:00  gw1 kernel: enc0: flags=0<> metric 0 mtu 1536
Sep 25 18:39:00  gw1 kernel:  groups: enc
Sep 25 18:39:00  gw1 kernel:  nd6 
options=29
Sep 25 18:39:00  gw1 kernel: lagg0: 
flags=8843 metric 0 mtu 1500
Sep 25 18:39:00  gw1 kernel:  
options=81249b
Sep 25 18:39:00  gw1 kernel:  ether 00:e0:81:ba:ad:90
Sep 25 18:39:00  gw1 kernel:  laggproto lacp lagghash l2,l3,l4
Sep 25 18:39:00  gw1 kernel:  laggport: em0 flags=0<>
Sep 25 18:39:00  gw1 kernel:  laggport: em1 flags=0<>
Sep 25 18:39:00  gw1 kernel:  groups: lagg
Sep 25 18:39:00  gw1 kernel:  media: Ethernet autoselect
Sep 25 18:39:00  gw1 kernel:  status: active
Sep 25 18:39:00  gw1 kernel:  nd6 
options=29
Sep 25 18:39:00  gw1 kernel: lagg0.11: 
flags=8843 metric 0 mtu 1496
Sep 25 18:39:00  gw1 kernel:  options=403
Sep 25 18:39:00  gw1 kernel:  ether 00:e0:81:ba:ad:90
Sep 25 18:39:00  gw1 kernel:  inet xx.xx.170.82 netmask 
0xfff0 broadcast 62.80.170.95
Sep 25 18:39:00  gw1 kernel:  groups: vlan
Sep 25 18:39:00  gw1 kernel:  vlan: 11 vlanpcp: 0 parent 
interface: lagg0
Sep 25 18:39:00  gw1 kernel:  media: Etherne

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 13:35, you wrote:


On 25.09.2019 05:47, Yaroslav Shvets wrote:

On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ не 
продублировал сюда.


On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой получился
нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить по 
его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.


Нерабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1496
 options=403
 ether 00:e0:81:ba:ad:90
 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
 groups: vlan
 vlan: 11 vlanpcp: 0 parent interface: lagg0
 media: Ethernet autoselect
 status: active
 nd6 options=29

Рабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1500
 options=403
 ether 00:e0:81:ba:ad:90
 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
 groups: vlan
 vlan: 11 vlanpcp: 0 parent interface: lagg0
 media: Ethernet autoselect
 status: active
 nd6 options=29


Воспроизвел проблему на 11.3 последовательностью:

ifconfig lagg0 create
ifconfig lagg0.11 create
ifconfig lagg0 laggproto lacp laggport em0

Дело в том, что в чипах сетевых Intel есть аппаратная поддержка vlanhwfilter и 
она очень полезная:
если сеть флудит порт фреймами с разнообразными вланами, то чип фильтрует поток 
и передаёт хосту
только те фреймы, теги которых соответствуют созданным вланам у хоста.

При создании нового влана драйвер добавляет в этот фильтр новый тег.
Если создавать вланы напрямую поверх em0, то это работает всегда.
Если

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 13:35, you wrote:


On 25.09.2019 05:47, Yaroslav Shvets wrote:

On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ не 
продублировал сюда.


On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой получился
нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить по 
его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.


Нерабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1496
 options=403
 ether 00:e0:81:ba:ad:90
 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
 groups: vlan
 vlan: 11 vlanpcp: 0 parent interface: lagg0
 media: Ethernet autoselect
 status: active
 nd6 options=29

Рабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1500
 options=403
 ether 00:e0:81:ba:ad:90
 inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
 groups: vlan
 vlan: 11 vlanpcp: 0 parent interface: lagg0
 media: Ethernet autoselect
 status: active
 nd6 options=29



Воспроизвел проблему на 11.3 последовательностью:

ifconfig lagg0 create
ifconfig lagg0.11 create
ifconfig lagg0 laggproto lacp laggport em0

Дело в том, что в чипах сетевых Intel есть аппаратная поддержка vlanhwfilter и 
она очень полезная:
если сеть флудит порт фреймами с разнообразными вланами, то чип фильтрует поток 
и передаёт хосту
только те фреймы, теги которых соответствуют созданным вланам у хоста.

При создании нового влана драйвер добавляет в этот фильтр новый тег.
Если создавать вланы напрямую поверх em0, то это работает всегда.
Если

Re: [freebsd] В releng-12 опять поломали lagg?


On Wed, 25 Sep 2019, 04:02, you wrote:


On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ 
не продублировал сюда.



On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.

Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени 
успеть починить к 12.1-RELEASE.

Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag 
-vlanhwfilter

-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой 
получился

нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить 
по его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.


Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его 
создать,
но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис 
создания?


ifconfig vlan11 create vlan 11 vlandev lagg0 up
# проверить работу интерфейса, а затем:
ifconfig vlan11 name lagg0.11
# и снова проверить работу интерфейса


Только, конечно, не вручную, а через rc.conf:

cloned_interfaces="lagg0 vlan11"
ifconfig_vlan11="vlan 11 vlandev lagg0"
#ifconfig_vlan11_name="lagg0.11"

Сначала без смены имени.


Со старообрядческим синтаксисом через rc.conf получается вполне
рабочий интерфейс vlan11:
# ifconfig -v vlan11
vlan11: flags=8843 metric 0 mtu 1500
   options=403
   ether 00:e0:81:ba:ad:90
   inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
   groups: vlan
   vlan: 11 vlanpcp: 0 parent interface: lagg0
   media: Ethernet autoselect
   status: active
   nd6 options=29

Ручное переименование оставляет интерфейс рабочим:
# ifconfig vlan11 name lagg0.11
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 
1500

   options=403
   ether 00:e0:81:ba:ad:90
   inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
   groups: vlan
   vlan: 11 vlanpcp: 0 parent interface: lagg0
   media: Ethernet autosel

Re: [freebsd] В releng-12 опять поломали lagg?


On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ не 
продублировал сюда.


On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой получился
нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить по 
его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.

Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его 
создать,
но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис 
создания?

ifconfig vlan11 create vlan 11 vlandev lagg0 up
# проверить работу интерфейса, а затем:
ifconfig vlan11 name lagg0.11
# и снова проверить работу интерфейса


Только, конечно, не вручную, а через rc.conf:

cloned_interfaces="lagg0 vlan11"
ifconfig_vlan11="vlan 11 vlandev lagg0"
#ifconfig_vlan11_name="lagg0.11"

Сначала без смены имени.


А вот если пойти по второму варианту, потом удалить нерабочий интерфейс и снова
его создать через "ifconfig vlan11 create vlan 11 vlandev lagg0 up", то
он все равно получается нерабочим.

# ifconfig -v vlan11
vlan11: flags=8843 metric 0 mtu 1500
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
    status: active
nd6 options=29

Т.е. где-то внутри "таблицы интерфейсов системы" уже что-то поломано.
И удаление/пересоздание интерфейсов уже ничего не исправляет.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


Hello Владимир Друзенко.

On Wed, 25 Sep 2019, 04:38, you wrote:


25.09.2019 04:20, Yaroslav Shvets пишет:

Hello.


Нерабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0
mtu 1496
    options=403
    ether 00:e0:81:ba:ad:90
    inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
    groups: vlan
    vlan: 11 vlanpcp: 0 parent interface: lagg0
    media: Ethernet autoselect
    status: active
    nd6 options=29

Рабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0
mtu 1500
    options=403
    ether 00:e0:81:ba:ad:90
    inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
    groups: vlan
    vlan: 11 vlanpcp: 0 parent interface: lagg0
    media: Ethernet autoselect
    status: active
    nd6 options=29


А какой MTU на lagg0? А на em0 и em1?


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

Отвечая на вопрос Владимира Друзенко:

На em0,em1,lagg0 - mtu равен 1500.

В обоих случаях?


Да. Т.к. сервер сейчас выступает по ночам в качестве стенда для
экспериментов, то я убрал ручное выставление mtu.

Все mtu выставляются по дефолту.
В rc.conf'е о них ни слова.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


Hello.


Нерабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0
mtu 1496
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

Рабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0
mtu 1500
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29


А какой MTU на lagg0? А на em0 и em1?


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

Отвечая на вопрос Владимира Друзенко:

На em0,em1,lagg0 - mtu равен 1500.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?


On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ не 
продублировал сюда.


On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой получился
нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить по 
его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.

Во-вторых: что будет, если во втором варианте удалить интерфейс и снова его 
создать,
но вместо новомодного синтаксиса lagg0.11 использовать старый синтаксис 
создания?

ifconfig vlan11 create vlan 11 vlandev lagg0 up
# проверить работу интерфейса, а затем:
ifconfig vlan11 name lagg0.11
# и снова проверить работу интерфейса


Только, конечно, не вручную, а через rc.conf:

cloned_interfaces="lagg0 vlan11"
ifconfig_vlan11="vlan 11 vlandev lagg0"
#ifconfig_vlan11_name="lagg0.11"

Сначала без смены имени.


Со старообрядческим синтаксисом через rc.conf получается вполне
рабочий интерфейс vlan11:
# ifconfig -v vlan11
vlan11: flags=8843 metric 0 mtu 1500
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

Ручное переименование оставляет интерфейс рабочим:
# ifconfig vlan11 name lagg0.11
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1500
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 op

Re: [freebsd] В releng-12 опять поломали lagg?


On Tue, 24 Sep 2019, 07:55, you wrote:


On 24.09.2019 11:26, Eugene Grosbein wrote:

Просьба отвечать в рассылку, а то я и сам не обратил внимания и свой ответ не 
продублировал сюда.


On 24.09.2019 06:50, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Сразу скажу: результаты экспериментов у меня странные.

Последовательность 1:
-
Если делать все руками, то все работает.
Примерно так:
ifconfig em0 up
ifconfig em1 up
ifconfig lagg0 create
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и это не зависит от -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
т.е. все работает в разных сочетаниях

Последовательность 2:
-
Если разрешить часть работы проделать rc.conf'у, примерно так:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0 lagg0.11"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается нерабочим
хотя выглядит абсолютно нормальным

Последовательность 3:
-
Аналогично последовательности 2, но убираем из cloned_interfaces
создание lagg0.11, предполагая сделать его руками:
-- rc.conf --
ifconfig_em0="up"
ifconfig_em1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 up"

А потом вручную доделать:
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> интерфейс lagg0.11 оказывается рабочим
и выглядит абсолютно нормально

Итого: руками все создаем - все работает,
имеем cloned_interfaces="lagg0 lagg0.11" - не работает,
имеем cloned_interfaces="lagg0", а потом руками досоздаем lagg0.11 -
опять все работает.

Создается впечатление, что в cloned_interfaces lagg0.11 как-то неправильно
создается (или раньше чего-то), или как-то не так, как руками.

Причем интересно, что если взять последовательность 2, при которой получился
нерабочий интерфейс lagg0.11, удалить интерфейс, снова его создать:
ifconfig lagg0.11 destroy
ifconfig lagg0.11 create
ifconfig lagg0.11 inet 
--> то все равно интерфейс получается нерабочий

Последовательность 1 отличается от последовательности 2
очередностью создания 11-го vlan'а и "собиранием" lagg'а
'ifconfig lagg0.11 create' и
'ifconfig lagg0 laggproto lacp laggport em0 laggport em1 up'.
Но при ручном варианте (последовательность 1) очередность
собирания lagg0 и создания lagg0.11 не имеет значения.
Интерфейс lagg0.11 в любом случае оказывается рабочим.

Вобщем, странные вещи происходят.


Во-первых, чудес не бывает и нерабочий интерфейс наверняка можно отличить по 
его состоянию.
Покажи вывод ifconfig -v lagg0.11 в "нерабочем" виде и в "рабочем" для 
сравнения.


Нерабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1496
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

Рабочий интерфейс:
# ifconfig -v lagg0.11
lagg0.11: flags=8843 metric 0 mtu 1500
options=403
ether 00:e0:81:ba:ad:90
inet xx.xx.170.82 netmask 0xfff0 broadcast xx.xx.170.95
groups: vlan
    vlan: 11 vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

Hello Eugene Grosbein.

On Tue, 24 Sep 2019, 12:09, you wrote:

On 19.09.2019 23:34, Yaroslav Shvets wrote:

Hello Eugene.

On Thu, 19 Sep 2019, 19:27, you wrote:

18.09.2019 9:45, Yaroslav Shvets пишет:

Hello All.

При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10
перестали работать сетевые интерфейсы.
Т.е. выглядят как рабочие, но по ним ничто не ходит.

Сеть сделана так:
em0 em1 собраны в lagg0
на lagg0 делаются vlan'ы
на другом конце cisco свитч с аггрегированными портами.

При откате на 11.3 все начинает работать.
При создании vlan'ов на em0 все начинает работать.
Не работает только на vlan'ах поверх lagg0

Никто не сталкивался?

В 12.0-RELEASE вообще плохо с драйверами сетевых Intel, что em, что igb.
Что-то чинили в 12-STABLE. Предлагаю либо обновиться до неё, либо сидеть на
11.3 и ждать 12.1,
которая уже приближается.

Похоже таки нахомутали. Попробую 12-STABLE.
Отпишусь потом. Спасибо.

Возможно, что в 12 у тебя не настроена подгрузка if_vlan.ko нигде до начала
настройки интерфейсов
и его нет в ядре. Добавь if_vlan_load="YES" в /boot/loader.conf.

Ядро на основе GENERIC (т.е. включает его):
device vlan# 802.1Q VLAN support

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

2019-09-23 Пенетрантность Yaroslav Shvets


Hello Eugene Grosbein.

On Mon, 23 Sep 2019, 08:51, you wrote:


23.09.2019 8:46, Yaroslav Shvets пишет:


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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.


Очень может быть, что дело как раз в сломанном аппаратном offload для 
vlanhwtag/vlanhwfilter.
Более того, такое уже бывало в старых версиях, но с другими драйверами.

Крайне желательно это выяснить побыстрей, пока ещё есть немного времени успеть 
починить к 12.1-RELEASE.
Но времени совсем немного.


Попробую сегодня ночью.
По результатам отпишусь.

--
Yaroslav Shvets

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

2019-09-22 Пенетрантность Yaroslav Shvets

Hello Eugene.

On Sat, 21 Sep 2019, 10:16, you wrote:

21.09.2019 3:31, Yaroslav Shvets пишет:

Hello All.

On Thu, 19 Sep 2019, 19:27, you wrote:

18.09.2019 9:45, Yaroslav Shvets пишет:

Hello All.

Сеть сделана так:
em0 em1 собраны в lagg0
на lagg0 делаются vlan'ы
на другом конце cisco свитч с аггрегированными портами.

Никто не сталкивался?

JFYI:
Увы. Переход на 12.1-PRERELEASE r352519 ничего не дал.
vlan'ы поверх lagg (собранного из двух em) не работают.

А не помогает ли отключение всяческих offload на em? Только это делать надо до
объединения
их в lagg: ifconfig em0 -rxcsum -txcsum -tso4 -vlanmtu -vlanhwtag -vlanhwfilter
-vlanhwcsum -vlanhwtso
И для em1 тоже.

Если вдруг поможет, то было бы неплохо найти именно тот флаг из них, что решает
проблему
(простым перебором или дихотомией).

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

Пока выяснилось, что сам lagg работает с нетегированными пакетами.
Проблема только - с тегированными. Т.е. не работает ни один
из vlan'ов построенных на lagg, но сам lagg - рабочий.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

2019-09-20 Пенетрантность Yaroslav Shvets


Hello All.

On Thu, 19 Sep 2019, 19:27, you wrote:


18.09.2019 9:45, Yaroslav Shvets пишет:

Hello All.

При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10
перестали работать сетевые интерфейсы.
Т.е. выглядят как рабочие, но по ним ничто не ходит.

Сеть сделана так:
em0 em1 собраны в lagg0
на lagg0 делаются vlan'ы
на другом конце cisco свитч с аггрегированными портами.

При откате на 11.3 все начинает работать.
При создании vlan'ов на em0 все начинает работать.
Не работает только на vlan'ах поверх lagg0

Никто не сталкивался?


В 12.0-RELEASE вообще плохо с драйверами сетевых Intel, что em, что igb.
Что-то чинили в 12-STABLE. Предлагаю либо обновиться до неё, либо сидеть на 
11.3 и ждать 12.1,
которая уже приближается.


JFYI:
Увы. Переход на 12.1-PRERELEASE r352519 ничего не дал.
vlan'ы поверх lagg (собранного из двух em) не работают.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] В releng-12 опять поломали lagg?

2019-09-19 Пенетрантность Yaroslav Shvets


Hello Eugene.

On Thu, 19 Sep 2019, 19:27, you wrote:


18.09.2019 9:45, Yaroslav Shvets пишет:

Hello All.

При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10
перестали работать сетевые интерфейсы.
Т.е. выглядят как рабочие, но по ним ничто не ходит.

Сеть сделана так:
em0 em1 собраны в lagg0
на lagg0 делаются vlan'ы
на другом конце cisco свитч с аггрегированными портами.

При откате на 11.3 все начинает работать.
При создании vlan'ов на em0 все начинает работать.
Не работает только на vlan'ах поверх lagg0

Никто не сталкивался?


В 12.0-RELEASE вообще плохо с драйверами сетевых Intel, что em, что igb.
Что-то чинили в 12-STABLE. Предлагаю либо обновиться до неё, либо сидеть на 
11.3 и ждать 12.1,
которая уже приближается.


Похоже таки нахомутали. Попробую 12-STABLE.
Отпишусь потом. Спасибо.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] В releng-12 опять поломали lagg?

2019-09-19 Пенетрантность Yaroslav Shvets


Hello All.

При обновлении системы с 11.3-RELEASE-p3 на 12.0-RELEASE-p10
перестали работать сетевые интерфейсы.
Т.е. выглядят как рабочие, но по ним ничто не ходит.

Сеть сделана так:
em0 em1 собраны в lagg0
на lagg0 делаются vlan'ы
на другом конце cisco свитч с аггрегированными портами.

При откате на 11.3 все начинает работать.
При создании vlan'ов на em0 все начинает работать.
Не работает только на vlan'ах поверх lagg0

Никто не сталкивался?

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние

2019-08-01 Пенетрантность Yaroslav Shvets

Hello.

On Wed, 31 Jul 2019, 23:46, you wrote:

https://kb.vmware.com/s/article/2061834
Оно?

On Wed, Jul 31, 2019, 23:43 Yaroslav Shvets wrote:

Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 20:19, you wrote:

01.08.2019 0:16, Alexander Sheiko пишет:

Не выйдет. Сервер - виртуалка.

Посмотрите документацию, может там есть что-то явное про включение
прохождения GRE.

Гипервизор в данном случае пропускает GRE, но часть пакетов дропает,

поведение известное.

Работать схема в таких условиях не будет.

Хорошая теория, многое объясняет (c)

Очень похоже на правду. Тем более у клиентов
нет проблем соединения с mpd5, которые стоят на чистом железе
и других гипервизорах.

Диагноз подтвердился: некорректная работа гипервизора VMware ESXi-5.5.
Миграция на другой гипервизор или замена проблемных сетевых карт решает вопрос.
Тут подробности, кому интересно: https://kb.vmware.com/s/article/2061834
Всем спасибо за участие.

Отдельное спасибо Eugene Grosbein за диагностику
и Anton Saietskii за ссылку.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Alexandr Davidenko.

On Wed, 31 Jul 2019, 20:50, you wrote:


31.07.19 12:34, Yaroslav Shvets пише:

Что удивительно: тот же клиентский хост на Windows 10
без проблем соединяется еще с пятком других mpd5-серверов в том числе
и таких же версий с одним и тем же конфигом под управлением от 11.x-releng 
до 12.0-releng.


Чем именно этот проблемный сервер отличается от тех, к которым удается
установить pptp-соединение не пойму.


А эти другие mpd5-серверы тоже виртуальные? Или на железе?
Если виртуальные, то на том же хосте или на других? Если на других,
то искать разницу.


Другие mpd5 железные и под гипервизорами, но на других
гипервизорах и версиях.


Хост с гипервизором в другой порт свитча переключить пробовали?


Пока нет. Попробую сначала отработать версию с гипервизором.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние


Hello Alexander Sheiko.

On Wed, 31 Jul 2019, 20:35, you wrote:



В письме от Срд, 31 Июл 2019, 20:12 Yaroslav Shvets пишет:


Не выйдет. Сервер - виртуалка.


Как вариант - настройте L2TP без IPSEC (отключается в реестре в винде,
будет шифрование RC4, как в PPTP).


Вопрос с подключением решен просто переподключением на другой mpd.
Но интересно докопаться до сути с проблемным сервером.
Чтобы не тратить время в будущем.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние


Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 20:19, you wrote:


01.08.2019 0:16, Alexander Sheiko пишет:


Не выйдет. Сервер - виртуалка.


Посмотрите документацию, может там есть что-то явное про включение
прохождения GRE.


Гипервизор в данном случае пропускает GRE, но часть пакетов дропает, поведение 
известное.
Работать схема в таких условиях не будет.


Хорошая теория, многое объясняет (c)

Очень похоже на правду. Тем более у клиентов
нет проблем соединения с mpd5, которые стоят на чистом железе
и других гипервизорах.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 13:08, you wrote:


31.07.2019 16:34, Yaroslav Shvets пишет:


Hello All.

На сервере:
---
12.0-RELEASE-p8

$ifconfig em5
em5: flags=8843 metric 0 mtu 1500

options=81009b
ether 00:0c:29:6a:c0:b1
inet 10.10.0.8 netmask 0xff00 broadcast 10.10.0.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29

firewall:
первой же строчкой
allow ip from any to any via em5

в него же и ловятся все пакеты через em5


Что значит "ловятся"?


Это значит, что пакеты, ходящие по этой сетевой карте em5, подпадают
под это правило и не подпадают под множество других нижележащих правил.




установлен mpd5-5.8_10 путем 'pkg install mpd5'

mpd.conf практически штатный из пакета
(изменена одна строчка: 'set pptp self 10.10.0.8'):
-- cut --
...
default:
load pptp_server
...
pptp_server:
set ippool add pool1 192.168.1.50 192.168.1.99
create bundle template B
set iface enable proxy-arp
set iface idle 1800
set iface enable tcpmssfix
set ipcp yes vjcomp
set ipcp ranges 192.168.1.1/32 ippool pool1
set ipcp dns 192.168.1.3
set ipcp nbns 192.168.1.4
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
create link template L pptp
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap
set link keep-alive 10 60
set link mtu 1460
set pptp self 10.10.0.8
set link enable incoming
-- cut --

Клиент:
---
Windows 10. Находится в той же подсети 10.10.0.0/24, никакой маршрутизации
и промежуточных фаерволов нет.

Подключиться к pptp-серверу не удается.

cat /var/log/mpd.log:
-- cut --
Jul 31 11:57:35 gw mpd[571]: [L-1] Accepting PPTP connection


Протокол PPtP использует два типа пакетов: протокол TCP(6) по порту 1723
для управляющего соединения и протокол GRE (47) для туннелирования PPP.

Судя по последней строчке в квоте выше, пакеты TCP проходят нормально,
так как управляющее соединение устанавливатся и даже начинается согласование 
PPP,
которое выполняется обменом пакетов GRE, несущих внутри себя туннелированные
фреймы PPP/LCP:


Jul 31 11:57:35 gw mpd[571]: [L-1] Link: OPEN event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Open event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Initial --> Starting
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: LayerStart
Jul 31 11:57:35 gw mpd[571]: [L-1] PPTP: attaching to peer's outgoing call
Jul 31 11:57:35 gw mpd[571]: [L-1] Link: UP event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Up event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Starting --> Req-Sent
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigReq #1
Jul 31 11:57:35 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:35 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:35 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:35 gw mpd[571]: [L-1]   MP MRRU 2048
Jul 31 11:57:35 gw mpd[571]: [L-1]   MP SHORTSEQ
Jul 31 11:57:35 gw mpd[571]: [L-1]   ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: rec'd Configure Request #0 (Req-Sent)
Jul 31 11:57:35 gw mpd[571]: [L-1]   MRU 1400
Jul 31 11:57:35 gw mpd[571]: [L-1]   MAGICNUM 0x09ec61cb
Jul 31 11:57:35 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   CALLBACK 6


Во время согласования параметров идёт параллельно два обмена опциями:
сервер отправляет свои, нумеруя из последовательно, а клиент отправляет свои.

Сервер отправил свой запрос LCP за номером 1 и получил запрос
LCP от клиента (от Windows) за номером 0, уже хорошо.


Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigRej #0
Jul 31 11:57:35 gw mpd[571]: [L-1]   CALLBACK 6


Сервер отверг опцию CALLBACK в предложении клиента номер 0, теперь клиент
должен перепослать своё предложение за вычетом этой опции, если отказ сервера
до клиента дошел - или клиент перепошлет предложение в неизменном виде,
если фрейм с отказом не дошел.


Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: SendConfigReq #2


За целых две секунды ничего не произошло и это плохо, так как клиент должен был
либо согласиться на предложение сервера за номером 1, либо прислать ConfigRej,
но ни того, ни другого не случилось (возможно, пакет потерялся) и сервер
перепосылает свой запрос повторно в неизменном виде за номером 2:


Jul 31 11:57:37 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:37 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:37 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:37 gw mpd[571]: [L-1]   MP MRRU 2048
Jul 31 11:57:37 gw mpd[

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние


Hello Alexander Sheiko.

On Wed, 31 Jul 2019, 20:04, you wrote:



В письме от Срд, 31 Июл 2019, 19:39 Yaroslav Shvets пишет:


Нет. Испробовано три разных клиента: Win7, Win10 и другая Win10.
Все три клиента не могут установить pptp-соединение. Ни удаленно
через внешние линки, ни внутри одного ethernet-сегмента.


Воткнуть клиент напрямую в сервер проверенным шнурком.


Не выйдет. Сервер - виртуалка.




Я сначала грешил на 12-stable, потом перевел на 12.0-releng.
Картина одинаковая. Ставил ядра с других рабочих vpn-серверов.
Работать не хочет.


Проблема явно в сервере или в свиче / шнурке.


--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 19:52, you wrote:


31.07.2019 23:47, Nike пишет:


Может конфликт ip-адресов?

Что там arp выдает?


Конфликт возможен, но не заметить его надо постараться: и Windows ругалась бы 
на конфликт,
и FreeBSD тоже - на конфликт со своим адресом прямо орало бы про конфликт в 
логи,
а про конфликт на IP-адресе Windows ругалось бы в виде многочисленных записей 
подобного вида:

kernel: arp: 192.168.0.24 moved from 70:38:ee:cd:93:c6 to 70:38:ee:ce:7e:70 on 
bge0


Нет. Это точно не конфликт адресов.
Не работает сразу через несколько статических аплинков.
Подключение внутри одного ethernet-сегмента уже потом было сделано,
чтобы исключить фильтрацию на уровне провайдеров и т.п.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 19:48, you wrote:


31.07.2019 21:50, Alexander Sheiko пишет:


В письме от Срд, 31 Июл 2019, 12:34 Yaroslav Shvets пишет:



Чем именно этот проблемный сервер отличается от тех, к которым удается
установить pptp-соединение не пойму.

Может есть у кого-то мысли, что нужно проверить?


Евгений выше красиво всё расписал, но я бы начал с попытки подключения к
серверу этого же или любого другого клиента (ноутбук), постепенно
укорачивая к нему физический путь (последовательно исключая промежуточные
свичи).


Александр, к вам тоже напрямую почта от меня не проходит, с моего персонального 
релея,
который кроме меня лично больше никого не релеит. Уверяю, что спам через него 
не льется
и почему ваш barracudacentral.org меня листит как poor reputation, я без 
понятия.

  - Transcript of session follows -
... while talking to mail.univ.kiev.ua.:

DATA

<<< 550-"You in blacklist - b.barracudacentral.org -->
<<< 550 http://www.barracudanetworks.com/reputation/?pr=1=116.203.149.156;
550 5.1.1 ... User unknown
<<< 503-All RCPT commands were rejected with this error:
<<< 503-"You in blacklist - b.barracudacentral.org -->
<<< 503-http://www.barracudanetworks.com/reputation/?pr=1=116.203.149.156;
<<< 503 Valid RCPT command must precede DATA

Могу предположить, что они вслед за Гуглем некорректно определяют гео-таргетинг
этого блока IPv4 116.203/16 как индийский, хотя реально это Hetzner.
но по большому счету, мне это безразлично - кто хочет получать от меня почту, 
тому и разбираться.
А кто не хочет, навязываться нет смысла :-)



Hetzner много где блокируют из-за обильного спама от их клиентов.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Nike.

On Wed, 31 Jul 2019, 19:47, you wrote:


Может конфликт ip-адресов?

Что там arp выдает?



Конфликта нет. Адреса менялись. arp-ы правильные.
Да и логи сервера показывают, что обращаются именно к нему.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние

Hello Oleg V. Nauman.

On Wed, 31 Jul 2019, 19:45, you wrote:

On Wednesday, July 31, 2019 7:39:59 PM EEST Yaroslav Shvets wrote:

Hello Alexander Sheiko.

On Wed, 31 Jul 2019, 19:26, you wrote:

В письме от Срд, 31 Июл 2019, 19:14 Yaroslav Shvets пишет:

Письма Евгения я пока никакого не вижу, но укорачивать нечего.

http://mailman.uafug.org.ua/pipermail/freebsd/2019-July/001093.html

Логически - это одна подсеть /24, а физически это один коммутатор.

А другой клиент с этим сервером нормально работает?

Нет. Испробовано три разных клиента: Win7, Win10 и другая Win10.
Все три клиента не могут установить pptp-соединение. Ни удаленно
через внешние линки, ни внутри одного ethernet-сегмента.

Я сначала грешил на 12-stable, потом перевел на 12.0-releng.
Картина одинаковая. Ставил ядра с других рабочих vpn-серверов.
Работать не хочет.

Попробуйте прицепить клиента напрямую другим шнурком.

Шнурки клиентов были разные. Шнурка сервера по-сути не существует.
Сервер - виртуалка под VMware.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Eugene Grosbein.

On Wed, 31 Jul 2019, 19:32, you wrote:


31.07.2019 23:14, Yaroslav Shvets пишет:


Письма Евгения я пока никакого не вижу, но укорачивать нечего.


Была копия напрямую и копия в список рассылки. В список дошла,
да и копия напрямую была доставлена нормально, принята relay=mxs.shvets.name:

Jul 31 10:09:07 hz sm-mta[41296]: x6VA8vjp041293: to=, 
delay=00:00:07, xdelay=00:00:05, mailer=esmtp, pri=75163, relay=mxs.shvets.name. 
[95.67.101.50], dsn=2.0.0, stat=Sent (x6VA92bq089345 Message accepted for delivery)

Время UTC. От меня пули улетели, копайте антиспам на своей стороне :-)


Нашел письмо. Попало под местный dnsbl.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соедин??ние


Hello Alexander Sheiko.

On Wed, 31 Jul 2019, 19:26, you wrote:


В письме от Срд, 31 Июл 2019, 19:14 Yaroslav Shvets пишет:


Письма Евгения я пока никакого не вижу, но укорачивать нечего.


http://mailman.uafug.org.ua/pipermail/freebsd/2019-July/001093.html


Логически - это одна подсеть /24, а физически это один коммутатор.


А другой клиент с этим сервером нормально работает?


Нет. Испробовано три разных клиента: Win7, Win10 и другая Win10.
Все три клиента не могут установить pptp-соединение. Ни удаленно
через внешние линки, ни внутри одного ethernet-сегмента.

Я сначала грешил на 12-stable, потом перевел на 12.0-releng.
Картина одинаковая. Ставил ядра с других рабочих vpn-серверов.
Работать не хочет.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello Alexander Sheiko.

On Wed, 31 Jul 2019, 17:50, you wrote:



В письме от Срд, 31 Июл 2019, 12:34 Yaroslav Shvets пишет:



Чем именно этот проблемный сервер отличается от тех, к которым удается
установить pptp-соединение не пойму.

Может есть у кого-то мысли, что нужно проверить?


Евгений выше красиво всё расписал, но я бы начал с попытки подключения к
серверу этого же или любого другого клиента (ноутбук), постепенно
укорачивая к нему физический путь (последовательно исключая промежуточные
свичи).


Письма Евгения я пока никакого не вижу, но укорачивать нечего.
Логически - это одна подсеть /24, а физически это один коммутатор.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mpd5-сервер не устанавливается pptp соединение


Hello All.

Ядро на сервере на основе GENERIC'а.
netgraph не вкомпилен.

Подбрасывал ядро с работающего mpd5-сервера.
Никакого эффекта не дало.

--
Yaroslav Shvets
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] mpd5-сервер не устанавливается pptp соединение


Hello All.

На сервере:
---
12.0-RELEASE-p8

$ifconfig em5
em5: flags=8843 metric 0 mtu 1500

options=81009b
ether 00:0c:29:6a:c0:b1
inet 10.10.0.8 netmask 0xff00 broadcast 10.10.0.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29

firewall:
первой же строчкой
allow ip from any to any via em5

в него же и ловятся все пакеты через em5

установлен mpd5-5.8_10 путем 'pkg install mpd5'

mpd.conf практически штатный из пакета
(изменена одна строчка: 'set pptp self 10.10.0.8'):
-- cut --
...
default:
load pptp_server
...
pptp_server:
set ippool add pool1 192.168.1.50 192.168.1.99
create bundle template B
set iface enable proxy-arp
set iface idle 1800
set iface enable tcpmssfix
set ipcp yes vjcomp
set ipcp ranges 192.168.1.1/32 ippool pool1
set ipcp dns 192.168.1.3
set ipcp nbns 192.168.1.4
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
create link template L pptp
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap
set link keep-alive 10 60
set link mtu 1460
set pptp self 10.10.0.8
set link enable incoming
-- cut --

Клиент:
---
Windows 10. Находится в той же подсети 10.10.0.0/24, никакой маршрутизации
и промежуточных фаерволов нет.

Подключиться к pptp-серверу не удается.

cat /var/log/mpd.log:
-- cut --
Jul 31 11:57:35 gw mpd[571]: [L-1] Accepting PPTP connection
Jul 31 11:57:35 gw mpd[571]: [L-1] Link: OPEN event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Open event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Initial --> Starting
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: LayerStart
Jul 31 11:57:35 gw mpd[571]: [L-1] PPTP: attaching to peer's outgoing call
Jul 31 11:57:35 gw mpd[571]: [L-1] Link: UP event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Up event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Starting --> Req-Sent
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigReq #1
Jul 31 11:57:35 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:35 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:35 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:35 gw mpd[571]: [L-1]   MP MRRU 2048
Jul 31 11:57:35 gw mpd[571]: [L-1]   MP SHORTSEQ
Jul 31 11:57:35 gw mpd[571]: [L-1]   ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: rec'd Configure Request #0 (Req-Sent)
Jul 31 11:57:35 gw mpd[571]: [L-1]   MRU 1400
Jul 31 11:57:35 gw mpd[571]: [L-1]   MAGICNUM 0x09ec61cb
Jul 31 11:57:35 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1]   CALLBACK 6
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigRej #0
Jul 31 11:57:35 gw mpd[571]: [L-1]   CALLBACK 6
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: SendConfigReq #2
Jul 31 11:57:37 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:37 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:37 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:37 gw mpd[571]: [L-1]   MP MRRU 2048
Jul 31 11:57:37 gw mpd[571]: [L-1]   MP SHORTSEQ
Jul 31 11:57:37 gw mpd[571]: [L-1]   ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: rec'd Configure Request #2 (Req-Sent)
Jul 31 11:57:37 gw mpd[571]: [L-1]   MRU 1400
Jul 31 11:57:37 gw mpd[571]: [L-1]   MAGICNUM 0x09ec61cb
Jul 31 11:57:37 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: SendConfigAck #2
Jul 31 11:57:37 gw mpd[571]: [L-1]   MRU 1400
Jul 31 11:57:37 gw mpd[571]: [L-1]   MAGICNUM 0x09ec61cb
Jul 31 11:57:37 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: state change Req-Sent --> Ack-Sent
Jul 31 11:57:39 gw mpd[571]: [L-1] LCP: SendConfigReq #3
Jul 31 11:57:39 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:39 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:39 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:39 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:39 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:39 gw mpd[571]: [L-1]   MP MRRU 2048
Jul 31 11:57:39 gw mpd[571]: [L-1]   MP SHORTSEQ
Jul 31 11:57:39 gw mpd[571]: [L-1]   ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:41 gw mpd[571]: [L-1] LCP: SendConfigReq #4
Jul 31 11:57:41 gw mpd[571]: [L-1]   ACFCOMP
Jul 31 11:57:41 gw mpd[571]: [L-1]   PROTOCOMP
Jul 31 11:57:41 gw mpd[571]: [L-1]   MRU 1500
Jul 31 11:57:41 gw mpd[571]: [L-1]   MAGICNUM 0x0fde2eb7
Jul 31 11:57:41 gw mpd[571]: [L-1]   AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:41 gw

Re: [freebsd] pkg и зависимости

2017-03-01 Пенетрантность Yaroslav Shvets

Hello Eugene Grosbein.

On Wed, 1 Mar 2017, 12:40, you wrote:

On 01.03.2017 17:33, Yaroslav Shvets wrote:

Hello Eugene.

On Mon, 27 Feb 2017, 12:13, you wrote:

С официальным репозиторием пакетов - никак. Ты либо живешь с теми версиями,
которые есть в репозитории и НИКАКИХ отклонений не допускаешь,
либо пользуешься портами и тогда не используешь pkg upgrade,
либо создаёшь собственный репозиторий пакетов и ставишь из него.

Не обязательно так строго. IRL вполне работают такие схемы:
95% всего живет из официального репозитория.
Остальные 5% живут из собственных репозиториев и/или портов.
pkg lock, где нужно.

pkg lock всего, что установил сам из портов и всех зависимостей,
которые собирал с недефолтными опциями :-) Иначе pkg будет регулярно
настаивать на сносе этого и переустановки дефолтнособранных пакетов.
В любом случае смысл в pkg upgrade отпадает.

Я бы сказал так: pkg upgrade делает большую часть рутинного
обновления, не загружая компиляцией дисковую подсистему, память, процы.

Остальные 5% или больше-меньше, у кого как, делается руками, если
пакет из стандартного репозитория не устраивает.
После сборки выкладывается в собственный репозитарий.

В таком варианте достаточно большой процент серверов
обновляется полностью только pkg upgrade'ом.
Часть пакетов приходит из стандартного репозитория,
часть - из собственного.

Ресурсы тратятся только на разовую сборку и выкладывание
в свой репозитарий.

--
yar

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] Re: [freebsd] Re: [freebsd] ntpdate стартует раньше, чем bind


Hello Mykola Dzham.

/usr/local/etc/rc.d/named не патченый из bind910-9.10.2P3

Устнавливался так: pkg install bind910

внутри:
# REQUIRE: NETWORKING ldconfig syslogd
# BEFORE: SERVERS

On Sun, 30 Aug 2015, 18:30, you wrote:




On 30 Aug 2015, at 16:59, Yaroslav Shvets <yaros...@shvets.name> wrote:

Hello All.

FreeBSD 10.2-RELEASE-p2.
ntpdate стартует раньше, чем bind. Видно по rcorder.
Т.к. в /etc/resolv.conf стоит первым 127.0.0.1,
то ntpdate неприлично тормозит при ризолвинге ntp-серверов.

Что правильно делать? Править /etc/rc.d/ntpdate или /usr/local/etc/rc.d/named?


Похоже смотреть что за /usr/local/etc/rc.d/named у Вас такой. Системный 
стартует раньше ntpdate, мало того это явно задано:

$ fgrep REQUIRE /etc/rc.d/ntpdate
# REQUIRE: NETWORKING syslogd named


--
yar

[freebsd] Re: [freebsd] ntpdate стартует раньше, чем bind


Hello All.

Всем спасибо за обсуждение.

Вопрос про правку скриптов, конечно, был риторический.
Играться с этим при каждом обновлении никто не будет.

Пока, увы, прийдется отказаться от удобства dns-ризолвинга
и напрямую указать ip-адреса в ntpdate_hosts="" в rc.conf

--
yar

[freebsd] Re: [freebsd] ntpdate стартует раньше, чем bind


Hello Alexander.

On Mon, 31 Aug 2015, 01:22, you wrote:


Пользуйтесь! Вон многими natd в десятке востребован :).


Кстати об альтернативе natd, ядерный nat разве научился
иметь более одного globalport?

--
yar

[freebsd] Re: [freebsd] Re: [freebsd] ntpdate стартует раньше, чем bind