Choose your future

Сначала предыстория.

Мой домашний канал в Интернет подключен на маршрутизатор FreeBSD, который изначально был поставлен для двух целей - держать шифрованный IPSEC туннель на работу (независимо от того, какая именно операционка и с какими настройками загружена в данный момент на десктопе) и считать трафик (в те давние времена ещё не было безлимитки) и сравнивать показания с провайдерскими. Ну, там ещё кеширующий DNS-сервер для десктопной винды крутился, потому что провайдерский периодически глючил. С приходом безлимитки надобность в обсчете пропала, зато там поселился торрент-клиент.

Однажды запустил IRC-клиента не как обычно, через ssh на рабочей машинке, а локально дома. Трафик пошел через NAT (ng_nat) на домашнем маршрутизаторе, чем мгновенно отправил его в панику. Ситуация была повторяемой на 100%, крешдамп ядро исправно писало, по данным крешдампа был создан Problem Report kern/118432, который завис на три месяца, а IRC-клиент отправился обратно внутрь screen в сессии ssh на рабочую машину.

Через три месяца на проблему обратили внимание и в скором времени исправили. Дело было в том, что очень долгое время библиотека libalias, реализующая трансляцию адресов и портов, в FreeBSD использовалась только в пользовательских процессах (natd и ppp) и для достижения кардинально другой производительности была портирована в ядро на тот период относительно недавно. Модуль трансляции IRC-трафика, ничтоже сумняшесь, заводил буфер в максимальный размер IP-пакета (64K) прямо в стеке, в автоматической переменной. Размер стека для пользовательского процесса в FreeBSD ограничен в 64M, так что это сходило с рук. Для ядерного же кода размер стека ограничен несколькими килобайтами, так что при попытке использовать такой буфер моментально происходил неисправимый page fault в ядре (реально double page fault) и, как следствие, паника и ребут. Проблема была решена заведением буфера в хипе (heap) вместо стека и всё стало работать нормально. Это было в марте 2008-го.

Теперь свежая история.

Компания Infinet Wireless (бывшая AquaComptek Group) производит замечательные во всех отношениях радиомаршрутизаторы Revolution Wireless Router (RWR), работающие с собственной операционной системой WanFlex. Которая, судя по всему, много сетевого кода позаимствовала из мира unix семейства BSD или даже конкретно FreeBSD: многие команды сетевого звена имеют схожий синтаксис, а главное - идеологию c похожими системами FreeBSD (bpf/ifconfig/ipfw/nat/route/tun), хотя другие подсистемы совсем иные (QoS, собственно радиочасть etc.)

У нас используется более 70 таких радиомаршрутизаторов разных моделей, поэтому бываю на форуме производителя. И вот сегодня там появилось сообщение одного такого же пользователя RWR, чей маршрутизатор стал часто ребутится. Как выяснилось, от вирусной активности на машинах потребителя, подхвативших трояна, самостоятельно генерирующего IRC-трафик. И NAT у них включен как раз на RWR (а не на FreeBSD, как у нас).

Бывают же такие совпадения.