А реально впихнуть интерфейс wi-fi в ethernet свитч, ну то есть bridge интерфейс создать такой?

когда изучал этот вопрос - обнаружил что это осложнено тем что в пакетах wifi присутствует больше полей для mac-адреса чем в ethernet. То есть логика бриджинга ethernet->wifi - должна быть какая-то нетривиальная, и эта фича ядром особо не поддерживается

Не получается загнать Wi-Fi интерфейс в бридж

Ты про такое что ли? https://www.dim13.org/Roaming-between-LAN-and-WLAN (но это опенёк)

это для какой то прошивки?

у меня кейс такой, выпилил кабель до роутера, а виртуалки люблю пускать с бриджом на убунте (qemu/kvm). В общем нужно поместить в br0 интерфейс wi-fi

Заведи виртуалки в отдельный бридж с отдельной подсетью и на раутере просто опиши маршрут на эту подсеть через IP компа

Микротик такое умеет

Умеет. Делал беспроводные бриджи на микротиках как раз. Не идеальное решение, но для сельской местности было вполне нормально, главное использовать WiFi соединение чисто для моста. А для клиентов уже юзать другой WiFi (например, мост только по 2.4ггц интерфейсу, а клиентов подключать только по 5ггц. или наоборот)

Да и обычный не-микротиковский WiFi такое умеет в режиме WDS, микротик просто немного расширяет этот режим (немного быстрее работает).

Вот тут в описании к параметру mode написано подробнее, и вот здесь ещё подробнее написано что выбирать на точке доступа а что на клиенте.

они что, код не возвращают?

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

Микротик такое умеет, они что, код не возвращают?

Забудь ты про этот мокротык. Так и опенврт умеет - собственно это сетап по дефолту в нем. Вопрос в том, какие кастомные патчи там для этого накладываются на ядро и почему они не приняты в mainline, открыт, впрочем.

Никаких патчей для этого не надо. Нужно лишь выполнение одного из условий ниже.

1. Интерфейс WiFi находится в режиме точки доступа.

2. Интерфейс WiFi находится в режиме WDS-клиента (другое название - 4-адресный режим клиента), а точка доступа поддерживает таких не совсем стандартных клиентов.

Проблема, как уже было сказано, в полях заголовка 802.11. Там без WDS всего три поля для MAC-адресов. Тогда как реально бизнес-логикой, если бы WiFi-адаптер в клиентском устройстве можно было бы завести в честный бридж, напрашиваются четыре MAC-адреса: источника Ethernet-пакета (скажем, виртуальной машины в том же брижде), источника радиопакета (т.е. WiFi-карточки), приемника радиопакета (т.е. точки доступа), и приемника Ethernet-пакета (скажем, это может быть какой-нибудь принтер, соединенный с точкой доступа по Ethernet).

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

То, что делает VirtualBox, это не настоящий бридж (L2), а хитрый роутинг (L3) с ProxyARP. MAC-адреса при этом не сохраняются. То же самое можно сделать с помощью parprouted и ndppd, или relayd, в userspace, без модификации ядра.

+1. Только на роутере прописывать не обязательно, достаточно masquerading на хосте

Спасибо, познавательно. А насчет виртуалбокса - он, вроде как, раньше тоже не умел бриджеваться с вайфаем? Починили?

Маскарад только если не надо из физической сети на вм заходить. А если надо то лучше таки маршрут добавить.

Зависит от цели применения. У меня например домашний сервер у которого единственный сетевой интерфейс это WiFi, чтобы с KVM виртуалками это работало нужен демон parprouted. Далее включается форвардинг на интерфейсах и оно работает, в одной сети.