redstorm

opensource - он такой разный. :)) иногда даже делается just for fun, not profit. хотя, если задуматься, это конечно весьма печально.., особенно когда потом это еще используют и в итоге не отдают возможно полезных изменений/доработок. в моем случае я же не кричал что это критично, да и не в праве кого-то заставлять мне помогать..., просто совершенно спокойно изложил мысль, и очень благодарен за ваши ответы и помощь. спасибо. насчет conntrack.. на x86 для корректного pptp passthru надо modprobe ip_gre modprobe ip_nat_pptp modprobe ip_conntrack_pptp на точке, я так понимаю, те же модули подгружать? хотя это почти риторический вопрос... еще раз спасибо за прошивку и исходники.

это из серии "хорошо поставленная задача заменяет девушку как минимум на две недели" :D задача то некритичная, как раз "+1 инет для себя любимого" и "чтоб на сервера в другой локалке не из инета ходить" :))) изначально хотелось чтобы оно просто работало без принудительного ребута, что уже, можно сказать, достигнуто)). далее, конечно, захотелось чтобы роутер роутил в обе стороны. сейчас сделал так, что на точке поднимается vpn клиент, коннектится к серверу за wifi-ем и в итоге через туннель уже все замечательно роутится, хоть скорость и не выше 500-600kB/s, но это в разы быстрее чем через инет (и время отклика 3-5ms vs 30-100ms), так что отчасти я уже сделал что хотел. ...теперь продолжение - gre туннель через 2 nat'а - вымысел или реальность? будет ли работать l2tpd? все это, и возможно многое другое.. если не надоест конечно ковырять этот зуксиль... )) PS. да, я конечно прекрасно понимаю, что лучше просто поставить линуксовый x86 роутер с wifi + ethernet сетевухами, но ставить его, грубо говоря, некуда. для точки же как раз нашлось место, она есть "здесь и сейчас" и уже даже делает то что нужно...

1. трабл с зависанием точки решился после изучения логов /var/log/messages и поиском в форуме по ключевым словам .. итак, еще раз напомню, стабильность на zyxel p330w в качестве роутера между сетями с обильными бродкастами достигается установкой параметра в sysctl net.ipv4.route.max_size = 15360 надеюсь, кому-то это поможет. 2. насчет wds: еще не пробовал. у dlink-2100 вроде как раз wds присутствует в опциях... nat2.5 пробовал включать и выключать (без wds) - изменений не было. попробую с wds и напишу как оно стало. 3. не работает arp_ignore. тоесть, хочу чтобы роутер на каждом интерфейсе отвечал на арпы предназначающиеся только для адресов (алиасов) данного интерфейса. ставил и так net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1 и эдак net.ipv4.conf.wlan0.arp_ignore = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth1.arp_ignore = 1 результат - одинаковый. девайз отвечает на каждом интерфейсе арпом на все свои адреса (которые на других интерфейсах). пробовал данные опции на обычном x86 линуксе, и все работало как надо. тоесть отвечалось только на адрес текущего интерфейса. если это уже обсуждалось, то прошу извинить..я пока не нашел.

железка работает в режиме wireless client, бридж выключен, ибо ненужен. на каждом из интерфейсов (eth0, eth1, wlan0) свой ip. между eth0 и eth1 роутинг работает нормально. а вот в wlan0 .. уже писал выше. в принципе, есть подозрение, что мак может обнулять и access point, но в этом случае неясно, почему не видно пакетов на wlan0 интерфейсе, когда все работает (тоесть были такие моменты, когда пакеты между eth и wlan маршрутизировались и ходили как и задумывалось, но tcpdump на точке не отображает в эти моменты их ни на wlan интерфейсе, ни на eth...; однако, когда неработает - видно, что приходят пакеты с нулевым маком назначения, хотя изначально в локалку они отсылаются на mac адрес назначения wireless client). как workaround задумываю сделать туннель, но все же неясно почему так происходит и хочется это пофиксить.

на эзернет роутинг работает нормально. (тоесть и nat и роутинг работают) а маршрутизация ipv4 пакетов с wlan0 интерфейса не работает, тк по какой-то причине пакеты, с адресом назначения отличным от ipv4 адреса интерфейса wlan0 приходят к точке (видно с помощью tcpdump на wlan0 интерфейсе, если точнее)с нулевым маком назначения. точка их не принимает.. точнее, не обрабатывает. в те редкие моменты, когда работало - эти пакеты не видно tcpdump-ом на wlan0 интерфейсе. PS. пробовал поставить rp_filter = 0. не помогло. с arp_proxy работает, но в этом режиме точка отвечает на arp-ы вообще всех хостов, которые не приписаны роутингом к данному интерфейсу (что является крайне нежелательным режимом изза возможного конфликта адресов). тоесть arp_proxy не подходит.

еще раз хочу поблагодарить Создателя прошивки :-) но вот только вопрос с занулением мака назначания по wifi все еще актуален (все интерфейсы исключены из бриджа, нужен просто роутинг). так вот, почему-то nat работает нормально - а с роутингом зануляется. даже на 0.3.8. (тоесть перепрошил на последнюю версию - ситуация не изменилась). в чем там может быть трабл? если это известный баг, конечно... заранее спасибо за любую информацию.

Ога. )) кстати, точка без радиатора и на прошивке 0.2.16 вместе с этим блинкером в авторане уже up 1 day, 18:01... а другая - с радиатором, вентилятором и 0.3.8 - ребутается. похоже, проблема всетаки в самой точке. жаль, это бы ему явно не помешало( я про него подумал уже после того, как написал предыдущий пост. но в любом случае спасибо за подсказку.

ай, совсем забыл. кинул в авторан скрипт один, чтобы наглядно видеть что точка жива. так вот..как показал эксперимент, при waitsec=1 даже ранее стабильная точка стабильно ребутается.) видимо, переполнение какое-то.. но с радиатором определенно работает лучше. [ZyXEL-ss20-GW@/]# cat /etc/scripts/led_blinker.sh #!/bin/sh ccount=0; waitsec=5; maxparam=20; while [ inf ] do ccount=`expr $ccount + 1` echo "<<< IN $ccount >>>" led_param1=0; led_param2=$maxparam; i_start=`expr $led_param1 + 1`; i_end=$led_param2; for i in `seq $i_start $i_end` do led_param1=`expr $led_param1 + 1`; led_param2=`expr $led_param2 - 1`; echo $led_param1,$led_param2>/proc/leds/led0; echo $led_param2,$led_param1>/proc/leds/led1; echo "<in> var1=$led_param1;var2=$led_param2"; sleep $waitsec; done echo "<<< OUT $ccount >>>" led_param1=$maxparam; led_param2=0; i_start=`expr $led_param2 + 1`; i_end=$led_param1; for i in `seq $i_start $i_end` do led_param1=`expr $led_param1 - 1`; led_param2=`expr $led_param2 + 1`; echo $led_param1,$led_param2>/proc/leds/led0; echo $led_param2,$led_param1>/proc/leds/led1; echo "<out> var1=$led_param1;var2=$led_param2"; sleep $waitsec; done done еще одна причина, по которой хочу собрать себе из соурсов (sdk) - мониторить температуру проца. вот, собственно, и спрашивал. нужно ли туда копировать wifi драйвер из последней версии, или там уже с пофиксенным багом с нулевым маком назначения? (как я понимаю, во всех билдах одинаковое ядро и можно просто скопировать с последней прошивки?)

sfstudio, спасибо за подсказку. а в последней версии sdk (2.17) он тоже не пофиксен? (на случай, если хочу заливать имижд собранный из сырцов со своими настройками чтоб уж сразу не конфигурить...) вообщем, я тоже думал, что нужно попробовать залить последнюю. ну и провод, думаю, действительно не мешает подцепить, интересно почему точки ребутаются самопроизвольно с разным интервалом. уже и радиатор поставил, стало лучше (не виснет намертво) но всеравно ребутается.

кратко: была ли у кого-либо ситуация с обнулением mac адреса назначения на входящих пакетах с wifi интерфейса? подробно: x.x.x.x -> eth0 [ zyxel, wive-ng ] wlan0 (00:aa:bb:cc:dd:ee) ... wifi [ dlink 2100, standart ] lan <- y.y.y.y (00:21:22:23:24:25) зуксиль c wive-ng 2.16 как роутер. (отсылает пакеты в wifi нормально - принимает с нулевым маком назначения) [ZyXEL-ss20-GW@/]# /mnt/cifs/tcpdump -i wlan0 -n -e icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:20:19.411681 00:aa:bb:cc:dd:ee > 00:21:22:23:24:25, ethertype IPv4 (0x0800), length 98: x.x.x.x > y.y.y.y: ICMP echo request, id 57914, seq 1, length 64 15:20:19.411681 00:21:22:23:24:25 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: y.y.y.y > x.x.x.x: ICMP echo reply, id 57914, seq 1, length 64 пингуемый хост. (как видно, отсылает ответы на правильный мак) linux-u235:~ # tcpdump -n -e -i eth1 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 13:22:53.371218 00:aa:bb:cc:dd:ee > 00:21:22:23:24:25, ethertype IPv4 (0x0800), length 98: x.x.x.x > y.y.y.y: ICMP echo request, id 57914, seq 1, length 64 13:22:53.371344 00:21:22:23:24:25 > 00:aa:bb:cc:dd:ee, ethertype IPv4 (0x0800), length 98: y.y.y.y > x.x.x.x: ICMP echo reply, id 57914, seq 1, length 64 как следствие, роутер не роутит (не принимает пакеты с нулевым адресом назначения для роутинга), что весьма печально )) может, как вариант, кто-то знает, как заставить девайз роутить пакеты с нулевым маком назначения?)))) ИНОГДА оно все работает, те пинги проходят. увы, не отловил этот момент пока tcpdump'ом. еще интересный факт - на такой же точке (но с wive-ng 3.x версии) все работало, но тк точка зависала намертво, была заменена другой, прошитой ранее. прошить ее до 3.x версии пока нет возможности.