>>Странно...
>>Ведь всё, что вы делаете в ./crypto_us - это ioctl() команда на выполнение netdev_rx_handler_register() (ну, и + дублирование адресов MAC & IP).
>>Почему то же нельзя сделать в функции инициализации модуля? Или почему это не работает из функции инициализации модуля? ... проверяли?
>>Так как это було сделано в предыдущем варианте.
В конечном счете, как мне видится, модуль будет загружаться при старте системы и будет создаваться что-то типа /dev/net/crypto. Далее я буду открывать это устройство и давать ему команды на создание crypto интерфейса, его ассоциацию с подчиненным интерфейсом ну и его удаление. Поэтому я просто вынес хардкод имени подчиненного интерфейса из тела модуля. Опять же, пока рано говорить о конечной архитектуре взаимодействия с модулем.
>> skb->dev = priv->slave;
>> вот здесь подменился выходной интерфейс?
Да, это перекладывание из crypto в wlan0
На вскидку то, что вызывает вопросы:
>>1. Как мне помнится из У.Стивенса "Illustrated TCP/IP" в системе (в компьютере) не может быть 2 сетевых интерфейса, принадлежащих к
>> одной подсети (IP:маска).
>>т.е. могут быть eth0=192.168.1.1:255.255.255.0 & eth0=192.168.2.1:255.255.255.0
>>или eth0=192.168.1.1:255.255.255.248 & eth0=192.168.2.33:255.255.255.248 (маска /28).
>>но не может быть 192.168.1.1/24 & 192.168.1.2/24
Ну это в реальном мире, но ведь у нас "виртуальное" устройство, которое почти полностью поглощает весь трафик проходящий через wlan0, а не два равноправных устройства. В конечном счете я расчитываю пустить весь трафик через crypto, а wlan0 не будет присутствовать в таблице маршрутизации. Поєтому желательно, чтобы адрес должен быть тот же что и у настоящего устройства - реальное устройство получает адрес по DHCP или статически. Ну а исходящий трафик должен иметь тот же IP адрес источника, чтобы не нарушать существующие настройки маршрутизации принятые в сети. Представьте, что вы подключились к беспроводной сети и автоматически получили IP адрес. В этом случае логично было бы если пакеты, исходящие из вашего устройства имеют именно этот адрес в качестве источника, а не какой-то который ві сами себе назначили. Кроме того, тот факт что у вас 2 интерфейса с одинаковыми адресами никому кроме вас не известен - извне он будет видится как один (более того у них даже одинаковый МАК адрес! - причина в том, что точка доступа вероятно не пропустит пакеты с несоответствующим МАК адресом, кроме того реальное устройство и не примет в ответ фрейм у которого будет МАК отличный от МАК-а самого реального устройства).
Возможно в конечном счете с wlan0 вообще придется убрать IP адрес, но тогда наверное некоторые сопутствующие вещи тоже перестанут работать. Не знаю какие именно, но возможно ARP, мультикаст.... Надо пробовать.
И еще, по-поводу одинаковых IP адресов. Идея такой реализации с перекладыванием исходящих пакетов из псевдо-интерфейса в реальный у меня появилась на основе двух вещей
1) Трафик шейпер, написанный Аланом Коксом работает на том же принципе:
http://lwn.net/1998/1119/shaper.html
Цитата: The host/address, mask, and broadcast parameters need to match those of the underlying physical interface.
2) Insane инетрфейс, который эмулирует потерю пакетов используя аналогичный принцип:
http://www.linux.it/~rubini/docs/vinter/vinter.html
Цитата:
borea# insmod insane ; # load module
borea# ifconfig insane borea ; # give same IP as eth0
Так что, как видите, идея не нова
>> После удаления маршрута у вас
>> route del -net 172.28.155.0/24 wlan0
>> наверное, нужно добавить новый? :
>> route add -net 172.28.155.0/24 crypto
Тут дело в том, что когда поднимется crypto интерфейс с адресом 172.28.155.7, то для него автоматически добавляется запись в таблицу маршрутизации. Все что остается это удалить маршрут 172.28.155.0/24 wlan0, и весь 172.28.155.0 трафик "потечет" через crypto
>>P.S. пока у меня идёт компиляция ядра 3.0.9 ... закончится - посмотрю runtime.
А зачем вы компилируете, почему бы не установить из репозитория
sudo apt-get install linux-image-3.0.0-16
sudo apt-get install linux-headers-3.0.0-16
(пишу по памяти - может неправильное название пакетов)