в мануале к железу

написано ж, documentation

ну может анб и выложили, чтобы искали

чот мне кажется доки по ME под жуткими NDA

ну надо уточнить, под каким из вариантов лицензии выкладывал Танненбаум

а то может статься, он имеет полное право подать в суд

чот мне кажется доки по ME под жуткими NDA

не повод нарушать закон

на сайте миникса bsd-type

ну, есть несколько вариаций BSD-лицензии просто

судя по его письму в суд он подать не может

и денег требовать тоже

с деньгами-то всё понятно

а вот юридический язык программирования он может и не знать

вполне возможно, зря унижается

но это надо точный вариант лицензии читать таки

Чет @spam-а нападало

А тут модератор-то есть?

необнаружено

терпение, все будет

блин, обновил десктоп клиент телеграмма, они раньше звездочку на против ника писали, сейчас впритык

Чет @spam-а нападало

почистил вместе со спамерами

почистил вместе со спамерами

?

я долго втыкал в картинку, и пытался найти там связь с freebsd

ты не один

https://twitter.com/encthenet/status/939907371186270208

Freebsd ещё не научилась изменять swap с отрезанием места у существующего раздела?

зачем?

При создании свапа ошибся, нужер х10

Freebsd ещё не научилась изменять swap с отрезанием места у существующего раздела?

Сделай своп в файле - гибче некуда

А уменьшать fs - вроде как действительно до сих пор нельзя. А так порой хочется...

ну так уменьшать почти нигде нельзя, не фиг промахиваться в таких вещах, есть не уверенность, оставь место, вот расширять везде где не попадя можно

ну, всегда для таких вещей было стандартом backup/restore

собственно говоря, вся нужная информация обычно находится в /usr/local или /var/db

Сделай своп в файле - гибче некуда

Угу, в хендбуке есть же

ну, всегда для таких вещей было стандартом backup/restore

для freebsd - dump/restore|send/receive

Ещё одно наблюдение — primarycache=metadata практически отключает prefetch и в результате на базах, на виртаулках с небольшим размером сектора, на больших файлах которые вычитываются небольшими кусками будет наблюдаться значительное замедление работы с диском.

https://www.servethehome.com/exploring-best-zfs-zil-slog-ssd-intel-optane-nand/

При создании свапа ошибся, нужер х10

Лучше памяти добавь)

Блыыын, не ищите дешёвого говна и не верьте D-Link'у. Взял DWL-520+ не обратив внимания на +, внутри Texas instruments ACX 100, шоб его нелёгкая забрала.

ой, да у них с названиями же полный зоопарк :) хотя что там у них, у меня вон линксис, в девичестве сиска, так он под одной моделью шел, в разных ревизиях, мне частично повезло и моя ревизия уже шла потом ка следующая модель :)

Дык я тоже на ревизию смотрел. А плюсик пропустил…

Блыыын, не ищите дешёвого говна и не верьте D-Link'у. Взял DWL-520+ не обратив внимания на +, внутри Texas instruments ACX 100, шоб его нелёгкая забрала.

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

Дык я тоже на ревизию смотрел. А плюсик пропустил…

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

я как то ssd сдал, так как оно на SATA3 не завелось :)

Сам думаю. С рук брал. Оно старое как дерьмо мамонта, полудохлые дрова дропнули в 2014 из портов.

Из Windows есть дрова на XP и предыдущие, 64bit скорее всего не заведётся никак.

Доброго времени суток. Есть такой вопрос: Приобрел переходник USB to LAN Xiaomi, пытаюсь завести на фре amd64 10.3R, он вроде определился

Bus /dev/usb Device /dev/ugen7.2: ID 2717:0011

usbconfig -d ugen7.2 dump_curr_config_desc ugen7.2: <USB 10100 LAN xiaomi> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

Как узнать его чипсет?

bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff

Всем доброго дня!

Как у спецов по FreeBSD, прошу у вас помощи. Есть freebsd с внешним адресом 1.2.3.4, есть внутренняя сеточка 192.168.6.0/24, есть в ней сервер 192.168.6.101. У него два порта 80 и 443. ipfw: nat 1 tcp from any to 1.2.3.4 10001 in via external_interface nat 1 tcp from 192.168.6.101 80 to any out via external_interface nat 1 tcp from any to 1.2.3.4 10002 in via external_interface nat 1 tcp from 192.168.6.101 443 to any out via external_interface natd nat 1 config log if em1.31 reset same_ports deny_in redirect_port tcp 192.168.6.101:80 10001 redirect_port tcp 192.168.6.101:443 10002 Описанным выше образом порты сервера из локалки проброшены наружу и доступны. Теперь пытаюсь сделать так, чтобы этот сервер был доступен из внутренней сети по внешнему адресу. Делаю так: ipfw nat 3 tcp from any to 1.2.3.4 10001 in via internal_interface nat 3 tcp from 192.168.6.101 80 to any out via internal_interface nat 3 tcp from any to 1.2.3.4 10002 in via internal_interface nat 3 tcp from 192.168.6.101 443 to any out via internal_interface natd nat 3 config log if em0 deny_in redirect_port tcp 192.168.6.101:80 1.2.3.4:10001 redirect_port tcp 192.168.6.101:443 1.2.3.4:10002 И возникает такая проблема, что запросы от другого компа во внутренней сетке не натятся. То есть на фре я вижу перенаправленные, но не замаскированные запросы. Можете подсказать, что я тут делаю не так?

Используйте kernel nat

libalias внутри различает пакеты по in и out для определения, натить или разначивать обратно, а тут случай однорукого роутера получается

тут надо сесть и порисовать на бумажке проходы и роутинг, ведь после разначивания (при one_pass=0) пакет станет из той же сети в ту же сеть, и может подпасть не под те правила

libalias внутри различает пакеты по in и out для определения, натить или разначивать обратно, а тут случай однорукого роутера получается

а если подсети на in & out совпадают?

тут не помню, в код смотреть надо

вроде ему сравнительно пофиг, кроме своего же внешнего адреса, главное файрволом нужные пакеты зарулить

ERROR: S client not available

кстати для отладки можно посоветовать заменить этот конфиг на всамделишный natd и включить в том вывод отладочного лога - по строчке на каждый пакет... только много тестовых пакетов не гнать, понятно ))

ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 9c:eb:e8:61:4f:bb inet 192.168.0.151 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::9eeb:e8ff:fe61:4fbb%ue0 prefixlen 64 scopeid 0x9 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Победил Xiaomi))

И что там было?

Ну хотя если и до этого интерфейс был то он её знал

Как у спецов по FreeBSD, прошу у вас помощи. Есть freebsd с внешним адресом 1.2.3.4, есть внутренняя сеточка 192.168.6.0/24, есть в ней сервер 192.168.6.101. У него два порта 80 и 443. ipfw: nat 1 tcp from any to 1.2.3.4 10001 in via external_interface nat 1 tcp from 192.168.6.101 80 to any out via external_interface nat 1 tcp from any to 1.2.3.4 10002 in via external_interface nat 1 tcp from 192.168.6.101 443 to any out via external_interface natd nat 1 config log if em1.31 reset same_ports deny_in redirect_port tcp 192.168.6.101:80 10001 redirect_port tcp 192.168.6.101:443 10002 Описанным выше образом порты сервера из локалки проброшены наружу и доступны. Теперь пытаюсь сделать так, чтобы этот сервер был доступен из внутренней сети по внешнему адресу. Делаю так: ipfw nat 3 tcp from any to 1.2.3.4 10001 in via internal_interface nat 3 tcp from 192.168.6.101 80 to any out via internal_interface nat 3 tcp from any to 1.2.3.4 10002 in via internal_interface nat 3 tcp from 192.168.6.101 443 to any out via internal_interface natd nat 3 config log if em0 deny_in redirect_port tcp 192.168.6.101:80 1.2.3.4:10001 redirect_port tcp 192.168.6.101:443 1.2.3.4:10002 И возникает такая проблема, что запросы от другого компа во внутренней сетке не натятся. То есть на фре я вижу перенаправленные, но не замаскированные запросы. Можете подсказать, что я тут делаю не так?

а разве не будет вот так? допустим локальный 192.168.6.хх лезет к 1.2.3.4, попадает на nat3. Какой после nat3 будет src-ip? и соответственно куда уйдет ответ от 192.168.6.101

а разве не будет вот так? допустим локальный 192.168.6.хх лезет к 1.2.3.4, попадает на nat3. Какой после nat3 будет src-ip? и соответственно куда уйдет ответ от 192.168.6.101

по какой-то причине после nat3 srс-ip остаётся таким же, каким был до него. Пакет приходит на 6.101 и он отвечает непосредственно src-ip'у. Ну а тот не отвечает, так как у него соединение с 1.2.3.4

исли src-ip будет 192.168.6.хх, то ответный пакет на FreeBSD и не попадет

ну все логично :)

А как сделать, чтобы src-ip сменился на ip freebsd?

Ну хотя если и до этого интерфейс был то он её знал

не было

можно повесить алиас на интерфейс из др подсети, допустим 192.168.7.100, в него натить, соответственно ваш 192.168.6.101 будет отвечать к 192.168.7.100, а там nat3 развернет обратно

Там какой-то ASIX?

можно повесить алиас на интерфейс из др подсети, допустим 192.168.7.100, в него натить, соответственно ваш 192.168.6.101 будет отвечать к 192.168.7.100, а там nat3 развернет обратно

а почему нат не меняет src-ip на адрес фряхи? Пробовал и if *inteface_name* и ip 1.2.3.4 в конфиге nat'a

Где-то разначивается?

А с фига ли сорс менять

Точнее я потерял нить

Какие-то слажные технологии с натд

pf.conf rdr и все работало бы

А с фига ли сорс менять

чтобы от дефолт роута на конечной тачке не зависеть

чтобы от дефолт роута на конечной тачке не зависеть

С учётом что это шлюз для выпуска вебсервера во внешний мир - а как иначе то?

Т.е. лучше терять адреса клиентов на внутреннем нат

непонятно, почему в локалке надо обращаться по внешнему адресу роутера, а не напрямую к вебсерверу

С учётом что это шлюз для выпуска вебсервера во внешний мир - а как иначе то?

хз. м.б ассиметрия какаянить и ответы уходят не на natbox, а куда-то еще по srcip адресу

а. nat loopback это

непонятно, почему в локалке надо обращаться по внешнему адресу роутера, а не напрямую к вебсерверу

Nat loopback это решает

непонятно, почему в локалке надо обращаться по внешнему адресу роутера, а не напрямую к вебсерверу

Split dns та ещё боль

Дело в том, что веб выброшен в мир, оттуда работает, всё хорошо. К этому вебу есть ведроприложение, в которое вписывается адрес сервера. Товарищи хотят, чтобы при подключению к корпоративному вайфаю, приложение сохраняло работоспособность, без переписывания адреса сервера на внутренней

без src nat сервис ответит напрямую клиенту, который ждет ответа с внешнего адреса