The OpenNET Project / Index page

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

Удалённая DoS-уязвимость в IPv6-стеке FreeBSD

21.08.2019 22:08

Во FreeBSD устранена уязвимость (CVE-2019-5611), позволяющая вызвать крах ядра (packet-of-death) через отправку специально фрагментированных пакетов ICMPv6 MLD (Multicast Listener Discovery). Проблема вызвана отсутствием необходимой проверки в вызове m_pulldown(), что может привести к возврату не непрерывных цепочек mbufs, вопреки ожидания вызывающей стороны.

Уязвимость устранена в обновлениях 12.0-RELEASE-p10, 11.3-RELEASE-p3 и 11.2-RELEASE-p14. В качестве обходного пути защиты можно отключить поддержку фрагментации для IPv6 или фильтровать на межсетевом экране опции в заголовке HBH (Hop-by-Hop). Интересно, что приводящая к уязвимости ошибка была выявлена ещё в 2006 году и устранена в OpenBSD, NetBSD и macOS, но осталась неисправленной во FreeBSD, несмотря на то, что разработчики FreeBSD были уведомлены о проблеме.

Также можно отметить устранение во FreeBSD ещё двух уязвимостей:

  • CVE-2019-5603 - переполнение счётчика ссылок на структуры данных в mqueuefs при использовании 32-разрядных библиотек в 64-разрядном окружении (32-bit compat). Проблема проявляется при включении mqueuefs, которая не активна по умолчанию, и может привести к доступу к файлам, каталогам и сокетам, открытым процессами, принадлежащими другим пользователям, или для организации доступа к внешним файлам из jail-окружения. При наличии у пользователя root-доступа в jail, уязвимость позволяет получить root-доступ на стороне хост-окружения.
  • CVE-2019-5612 - проблема при многопоточном доступе к устройству /dev/midistat при возникновении состояния гонки может привести к чтению областей памяти ядра вне границ выделенного для midistat буфера. На 32-разрядных системах попытка эксплуатации уязвимости приводит к краху ядра, а на 64-разрядных позволяет узнать содержимое произвольных областей памяти ядра.


  1. Главная ссылка к новости (https://lists.freebsd.org/pipe...)
  2. OpenNews: Уязвимости в TCP-стеках Linux и FreeBSD, приводящие к удалённому отказу в обслуживании
  3. OpenNews: Уязвимость в ядре Linux, позволяющая вызвать крах через отправку UDP-пакета
  4. OpenNews: Уязвимости в драйвере ozwpan, позволяющие удалённо вызвать крах ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51332-freebsd
Ключевые слова: freebsd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (82) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:14, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    -DWITHOUT_INET6
     
     
  • 2.2, Catwoolfii (ok), 22:18, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ага, больше делать нефиг
     
  • 2.6, Аноним (6), 22:59, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Да уж пора с -DWITHOUT_INET4 собирать, а вы всё в каменном веке.
     
     
  • 3.13, Michael Shigorin (ok), 23:36, 21/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы что? :)
     
     
  • 4.58, Аноним (6), 20:26, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы не собирать мёртвый код, когда общаешься с миром только по IPv6.
     
  • 3.23, Онаним (?), 08:52, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чего? INET4 ещё INET6 переживёт.
     
     
  • 4.59, Аноним (6), 22:12, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну-ну v4 скоро физически закончатся Этого, увы, ещё не произошло - новости о ... большой текст свёрнут, показать
     
     
  • 5.62, Zil (?), 00:10, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    новости про кончину ipv4 адресов я читаю с 2006 года
     
     
  • 6.64, qwerty123 (??), 00:30, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >новости про кончину ipv4 адресов я читаю с 2006 года

    "новости про кончину паровозов я читаю с 1933 года".

     
  • 6.65, Аноним (6), 00:38, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > новости про кончину ipv4 адресов я читаю с 2006 года

    Я про это явно написал. Читаете, да не понимаете что написано.

     
  • 5.66, Онаним (?), 08:21, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну-ну. v4 скоро физически закончатся.

    NAT давно отменили?

     
     
  • 6.75, Аноним (6), 16:37, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну-ну. v4 скоро физически закончатся.
    > NAT давно отменили?

    Расскажи как ты сервера за NAT'ом будешь хостить, нечитатель.

     
     
  • 7.77, Онаним (?), 19:57, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    1. За счёт хомяков и мелкорастов можно наосвобождать очень много
    2. Про такую штуку, как балансировщик/реверс прокси/DNAT ты, конечно же, не слышал
     
     
  • 8.79, Аноним (6), 23:29, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну конечно, так все и бросились нахаляву освобождать тебе адреса За неслабые де... большой текст свёрнут, показать
     
  • 3.29, тигарэтоя (?), 11:05, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да. там уже с подобной "инициативой" старый тролль bz@ вылез. начав ответ с "what is ping(8)? I don't have it"
     
  • 3.49, Минона (ok), 16:34, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да чего уж там мелочиться -DWITHOUT_INET_ALL
     
     
  • 4.82, Ano (?), 21:45, 09/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В банках годная тема. Они оч. любят всё законсервировать в оффлайн. Почему-то с обновлениями без-ти обязательно. Забавные затейники.
     

  • 1.3, аннон (?), 22:45, 21/08/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –5 +/
     
     
  • 2.4, Fracta1L (ok), 22:49, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 3.14, Michael Shigorin (ok), 23:46, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.5, Аноним (5), 22:49, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • –2 +/
     
  • 2.7, Аноним (6), 23:00, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 2.9, Аноним (9), 23:09, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 3.16, Аноним (16), 00:08, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 4.18, Аноним (18), 02:05, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     
     
  • 5.34, пох. (?), 11:28, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 2.11, Аноним (9), 23:11, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.12, Аноним (12), 23:24, 21/08/2019 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 3.19, Аноним (18), 05:28, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 4.21, лютый жабист__ (?), 08:41, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 4.24, пох. (?), 09:46, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 4.40, анонн (ok), 12:08, 22/08/2019 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     

     ....ответы скрыты (14)

  • 1.8, Аноним (6), 23:06, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Люблю баги с паниками, когда их латаешь можно не перезагружаться - система останется уязвимой, но если её положат, она перезапустится уже с обновлением и мы получим столько же даунтайма сколько при штатном перезапуске, а если не положат, не получим даунтайма вообще.
     
     
  • 2.27, Нанобот (ok), 10:02, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а при панике дисковые кеши хоть сбрасываются? и то ж иначе может приключиться потеря данных...
     
     
  • 3.31, Аноним (31), 11:23, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да кому их жалко-то?
     
     
  • 4.38, Нанобот (ok), 11:47, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > да кому их жалко-то?

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

     
     
  • 5.52, Аноним (6), 17:00, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет, не может - как-бы базы данных обязаны нормально обрабатывать такие ситуации, поэтому логгирование там не просто так. Потере данных - в зависимости от настроек может быть. В моём случае либо не может, либо наплевать.
     
  • 3.51, Аноним (6), 16:53, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > а при панике дисковые кеши хоть сбрасываются?

    Нет конечно, иначе можно повредить данные на диске.

     
  • 2.80, rihad (ok), 15:34, 25/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Только паника случится в прайм тайм, а запланированный ребут как правило приходится делать рано утром (или поздно ночью). Ситуация lose-lose (для админа).
     
  • 2.83, Ano (?), 21:50, 09/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > но если её положат, она перезапустится

    И будет выговор, т.к. ребут форсмажорный и мониторинг не скроет и не дадут в январе 13-ю зарплату.

     

  • 1.15, Alexey (??), 23:58, 21/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не, ну для полного и бесповоротного перехода на IPv6 еще не все готовы, а если сказали как подправить, так это всегда хорошо.
     
  • 1.20, iPony129412 (?), 06:10, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Интересно, что приводящая к уязвимости ошибка была выявлена ещё в 2006 году и устранена в OpenBSD, NetBSD и macOS, но осталась неисправленной во FreeBSD, несмотря не то, что разработчики FreeBSD были уведомлены о проблеме.

    Ну всплыло оно из проруби...
    Вообще тема про IPv6 с точки зрения безопасности весьма интересная, как с проблемами в софте, так и в настройках.

     
     
  • 2.25, пох. (?), 09:48, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Вообще тема про IPv6 с точки зрения безопасности весьма интересная, как с
    > проблемами в софте, так и в настройках.

    да нет в ней ничего интересного. Творение комитетчиков на попилах, воплощенное японцами с мозгами не от мира сего и протолкнутое с помощью FUD и шантажа. Ни одной из проблем, якобы призванных решать - не решило. Вот вообще ни одной - кроме несуществующих.

    Нет ipv6 - нет кучи новых проблем.


     
     
  • 3.28, Гентушник (ok), 11:02, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Исчерпание IP адресов?
    Отсутствие в необходимости костыле-NAT-а?

    Это первое что приходит в голову.

     
     
  • 4.32, Аноним (31), 11:23, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Исчерпание IP адресов?

    вранье

    > Отсутствие в необходимости костыле-NAT-а?

    вранье

    и так у вас - все.

     
     
  • 5.43, Hewlett Packard (?), 13:30, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Google is increasing the prices for Google Compute Engine (GCE) VMs using external IPv4 addresses, starting in 2020, according to messages sent to Google Cloud Platform customers. Starting on January 1, 2020, a standard GCE instance will cost an additional $0.004 per hour, with preemptable GCE instances costing an additional $0.002 per hour, if they use an external IPv4 address—essentially, an extra $2.92 or $1.46 per month, respectively.
    > Last year, father of the internet—and Google's Chief Internet Evangelist—Vint Cerf declared that enterprise IT ships avoiding the problem of IPv4 need to "get with the program," as IPv6 standards were published years prior.
     
  • 5.53, Гентушник (ok), 17:06, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Отсутствие в необходимости костыле-NAT-а?
    > вранье

    Хорошо, объясните мне тогда зачем мне нужен NAT в IPv6 для какого-то массового случая?

    Ну вот например есть локальная сеть подключенная к одному провайдеру интернета. В локалке есть компы, на которых запускают всякие торренты, ходят на ftp (в активном или пассивном режиме), звонят через sip.

    Так же в этой локалке есть серверы: ftp, http и всякие разные другие.

    Зачем тут нужен NAT?

     
     
  • 6.60, Эксперт по всему (?), 22:37, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очевидный мульхоминг, что нужно почти любому офису
     
     
  • 7.61, Гентушник (ok), 23:39, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Очевидный мульхоминг, что нужно почти любому офису

    С мультихомингом в IPv6 всё так же плохо как и в IPv4, да. Правда насчёт нужности "почти любому офису" вы явно преувеличиваете. А если что-то крупное, то можно и AS взять.

     
     
  • 8.72, пох. (?), 10:09, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    с ним там сильно хуже из-за непомерных запросов протокола и омерзительного диза... текст свёрнут, показать
     
  • 4.39, Аноним (39), 12:05, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в современных условиях НАТ уже особо не мешает, тк современный софт пишется с учетом этого. даже наоборот, ограниченное кол-во адресов позволяют многим на этом зарабатывать. а бабло как известно решает.
     
     
  • 5.44, Hewlett Packard (?), 13:32, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > The natural solution to that would be NAT, but prices are also changing for Cloud NAT Gateway, with Google indicating that they "will charge $0.0014/hr for each VM instance up to a maximum of $0.044/hr (32 or more instances). Gateways that are serving instances beyond the maximum number are charged at the maximum rate."
     
  • 5.45, qwerty123 (??), 14:09, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >в современных условиях НАТ уже особо не мешает, тк современный софт пишется с учетом этого.

    пилять.

    SIP и все что c применением RTSP.
    IPSec
    XMPP

    и вообще все, что требует построения сокетов с обеих сторон, или от клиента к клиенту

    NAT это пушечное ядро на ноге всего мультимедиа и костыль на всем IT.

     
     
  • 6.46, Andrey Mitrofanov_N0 (??), 14:40, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > NAT  мешает всему IT следить за пользуемыми и стукам-стукам в вашингтонский обком.

    //fix

     
  • 6.56, пох. (?), 17:45, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>в современных условиях НАТ уже особо не мешает, тк современный софт пишется с учетом этого.
    > пилять.

    пилять, ты почти не ошибся
    > SIP и все что c применением RTSP.

    даааа! И хорошо еще если исходники доступны - можно выпилить к хренам этот "учьот"

    > IPSec

    даааа! тут и исходники не помогут. Только массовые расстрелы.

    > XMPP

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

    А с двумя предыдущими - это просто праздник какой-то.
    Нет, если бы он НЕ писался с учетом непонятных авторам технологий - все бы в общем и целом могло бы даже и работать - если не помойкороутер натит, конечно.

    > NAT это пушечное ядро на ноге всего мультимедиа и костыль на всем

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


    P.S. один из способов борьбы с sip - использовать сеть 100.100.
    Большинство горе-писателей не в курсе, поэтому свою искусственную идиотию они не проявят. А дальше даже линух со своим nf_nat_sip справится. ssip, к счастью великому, дальше PoC не пошел.

     
     
  • 7.63, qwerty123 (??), 00:26, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >нормальный софт не лезет не в свое дело
    >можно выпилить к хрена
    >один из способов борьбы с sip
    >я бы еще и в тазик с цементом,

    "Моя борьба"
    собрание сочинений, opennet, Анонимуc.

     
  • 5.48, Гентушник (ok), 15:38, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > тк современный софт пишется с учетом этого

    Ага, в каждой софтине какой-нибудь свой костыль, а в некоторых ничего и нету, например у ftp и http-серверов приходится ПРОБРАСЫВАТЬ ПОРТ.
    Ну с ftp конечно вообще всё плохо, там ещё второе соединение на другой диапазон портов, приходится ещё пробрасывать и этот диапазон портов, либо пользоваться несекьюрными хелперами nf_nat_ftp.

    И так со всеми протоколами которые используются не одно соединение на один порт, а несколько разных.

    p2p тоже отсасывает у NAT-а, т.к. приходится либо ПРОБРАСЫВАТЬ ПОРТ, либо включать несекьюрный upnp на роутере (и то, если программа это поддерживает), либо пользоваться сторонними серверами (бриджами). Классный p2p получается с бриджами!

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

     
     
  • 6.57, пох. (?), 17:48, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > другой диапазон портов, приходится ещё пробрасывать и этот диапазон портов, либо
    > пользоваться несекьюрными хелперами nf_nat_ftp.

    какой ужас, нисикьюрна-нисикьюрна. Зато мы топим за p2p и "каждому холодильнику по public ip", ага.

    "и ведь этот еще из лучших". Впрочем, Атоса тогда нае...ли, а тут,походу, все честно.


     
  • 6.67, Онаним (?), 08:25, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > NAT это адовый костыль, я бы с удовольствием перешёл на IPv6

    Так переходи. Отключай IPv4, и вперёд - в дивный новый мир с:
    - нечитабельными адресами
    - полуроутингом через одно место
    - пачкой туннелей различных сортов и запахов
    - тремя конфликтующими способами автоконфигурации в одном флаконе
    - отсутствием нормальной автоконфигурации в PPP - надо городить по инстансу DHCPv6 внутри PPP на каждого клиента
    - потенциально не способными поместиться в память любого устройства neighbour tables
    И т.д., и т.п.

    Академическое овно ожидаемо не взлетает... вангую, что IPv6 кончится раньше IPv4, по причине появления более вменяемой альтернативы.

     
     
  • 7.68, Andrey Mitrofanov_N0 (??), 08:32, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Академическое овно ожидаемо не взлетает... вангую, что IPv6 кончится раньше IPv4, по
    > причине появления более вменяемой альтернативы.

    "И у нас стало 15 стандартов" --https://xkcd.com/927/

     
  • 7.70, пох. (?), 09:55, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Академическое овно ожидаемо не взлетает... вангую, что IPv6 кончится раньше IPv4, по
    > причине появления более вменяемой альтернативы.

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

     
     
  • 8.73, Hewlett Packard (?), 11:57, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Про то что сейчас называют IPv4 тоже когда-то так думалось ... текст свёрнут, показать
     
     
  • 9.74, пох. (?), 16:20, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    во времена начала ipv4 все делали из дерьма и палок и типовой магистральный ка... текст свёрнут, показать
     
     
  • 10.78, Hewlett Packard (?), 23:15, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ISO OSI делали из слоновой кости и концентрированных седин Результат не впечатл... текст свёрнут, показать
     
     
  • 11.81, пох. (?), 16:32, 26/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    это в те же времена делали Сейчас вот такие же люди не те же, те уже в гробу л... текст свёрнут, показать
     
  • 8.76, Онаним (?), 19:55, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Значит будем жить на v4 ... текст свёрнут, показать
     

  • 1.22, Онаним (?), 08:51, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Удалённая FreeBSD-уязвимость в IPv6 стеке DOS.
     
     
  • 2.41, пнончик (?), 12:56, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Название товара на алижкспрессе
     

  • 1.26, анон (?), 09:57, 22/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    решительно заявляю: эта ваша бздя - РЕ-ШЕ-ТО!
     
     
  • 2.30, тигарэтоя (?), 11:09, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    решительно и категорически присоединяюсь, даже принес пруфов свежих: http://www.opennet.dev/opennews/art.shtml?num=51333
     
     
  • 3.33, пох. (?), 11:26, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну нет драйверов - нет проблемы, ага.

    (хотя, конечно, особенно доставил "doublefree в rio500". Интересно, многие тут успели родиться, чтобы помнить, wtf? И да, да - из ведра выпилена куча нужных вещей, а вот этот мусор - старательно тянется двадцать лет.)

     
     
  • 4.35, тигарэтоя (?), 11:31, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну можно же дальше пойти - написать "тут-то удалееенно, а там надо флеееешечку пихать, физически!"
     
     
  • 5.36, пох. (?), 11:35, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ну можно же дальше пойти - написать "тут-то удалееенно, а там надо
    > флеееешечку пихать, физически!"

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

     
     
  • 6.37, тигарэтоя (?), 11:41, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ты про WITHOUT_INET6[_SUPPORT] ?:)
     
     
  • 7.42, пох. (?), 13:03, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну да. Там-то штатная инфраструктура для делания как надо, а не как кому-то показалось правильным, все еще работает из коробки и при минимуме телодвижений.

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

     
     
  • 8.47, Andrey Mitrofanov_N0 (??), 14:46, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Аскориида Слово-то какое красивое grep ipv6 -R etc sysctl d ... текст свёрнут, показать
     
     
  • 9.50, пох. (?), 16:48, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    эх, митрофанушка, если б ты еще знал, ЧТО на самом деле делают эти крутилки - ты... текст свёрнут, показать
     
  • 9.54, пох. (?), 17:09, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    поможем , пожалуй, митрофанушке исполнить сепукку sysctl net ipv6 conf all ... текст свёрнут, показать
     
     
  • 10.69, Andrey Mitrofanov_N0 (??), 08:34, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Объясню, что ты д---л, и пойду дальше ... текст свёрнут, показать
     
     
  • 11.71, пох. (?), 09:59, 23/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    боюсь что тебе уже вполне удачно удалось объявить что д-л - ты сам Можешь идти ... текст свёрнут, показать
     
  • 2.55, Аноним (55), 17:19, 22/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Иди ка ты .....
    БЫСТРО!
    РЕШИТЕЛЬНО!!
     

  • 1.84, Аноним (84), 20:32, 20/10/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    никогда такого не было и вот опять!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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