[pawel40]

В сторону похорон 8186 им на кладбище давно прогулы ставят. А остальным копать в сторону чтения данного топика. А на 300 метров вообще копать в сторону куска оптики и не срать в эфир.

Согласен что пора на покой им. Оптику нет возможности кинуть туда.

[sfstudio]

Согласен что пора на покой им. Оптику нет возможности кинуть туда.

Ну дык может проще выбрать что-нить на том же ралинке у которых запас по CPU и раме есть, да и радиочасть по чувствительности значительно превосходит глухие по сегодняшним меркам риалтэки? Да и код wifi драйвера открыт и заведомо менее проблемен, более того совместимость с аферос на должном уровне и ещё стопка собственных фирменных мелких фишек при работе 2х одинаковых девайсов. Цена вопроса копейки, на 300 метров в N режиме да на 40МГц канале будет жить явно веселее, а проц не будет затыкаться от высокого pps, в отличии от полупрограммного радио в 8186 с ралинком всё веселее и нагрузка на проц при одинаковом pps значительно ниже. Более того RT3052 легко переваривает 80Мбит NAT`а если нужно правда не с очень высоким pps. Короче говоря ставить сейчас 8186 на соединение 2х сегментов сети да ещё в засранном эфире, да ещё с текущими требованиями к пропускной способности как-то странно. Самый дешовый вариант это RT3050 железки. На 300 метров проверено работают зачудительно даже в весьма грязном эфире.

[pawel40]

Ну дык может проще выбрать что-нить на том же ралинке у которых запас по CPU и раме есть, да и радиочасть по чувствительности значительно превосходит глухие по сегодняшним меркам риалтэки? Да и код wifi драйвера открыт и заведомо менее проблемен, более того совместимость с аферос на должном уровне и ещё стопка собственных фирменных мелких фишек при работе 2х одинаковых девайсов. Цена вопроса копейки, на 300 метров в N режиме да на 40МГц канале будет жить явно веселее, а проц не будет затыкаться от высокого pps, в отличии от полупрограммного радио в 8186 с ралинком всё веселее и нагрузка на проц при одинаковом pps значительно ниже. Более того RT3052 легко переваривает 80Мбит NAT`а если нужно правда не с очень высоким pps. Короче говоря ставить сейчас 8186 на соединение 2х сегментов сети да ещё в засранном эфире, да ещё с текущими требованиями к пропускной способности как-то странно. Самый дешовый вариант это RT3050 железки. На 300 метров проверено работают зачудительно даже в весьма грязном эфире.

Это железо довольно давно стоит у меня, вот недавно просто решил попробовать wive. Короче в чистом WDS заработал стабильно линк. С эфиром мне повезло почти чистый.

При следующем абгрейде поставлю что то на RT3050 скорее всего.

[sfstudio]

Это железо довольно давно стоит у меня, вот недавно просто решил попробовать wive. Короче в чистом WDS заработал стабильно линк. С эфиром мне повезло почти чистый.

При следующем абгрейде поставлю что то на RT3050 скорее всего.

Лучше таки 3052 с 4Мб флэша/32 рамы, там кэш побольше и частота CPU повыше(особенно если объеденяются 2 сегмента сети через радио), разница в цене часто незначительна. А то что в голом WDS оно заработало стабильно ничего удивительно. Всёж таки WDS+AP это насилие над радиомодулем.

[Les1at]

никто не отвечает потому что всё просто, или есть иная причина? Может что то ещё нужно рассказать?

 

как я понимаю,

ETH0-интерфейс LAN

ETH1-виртуальный интерфейс, если поднимать PPPoE,PPTP,...??

WLAN-интерфейс по wi-fi

[sfstudio]

никто не отвечает потому что всё просто, или есть иная причина? Может что то ещё нужно рассказать?

 

как я понимаю,

ETH0-интерфейс LAN

ETH1-виртуальный интерфейс, если поднимать PPPoE,PPTP,...??

WLAN-интерфейс по wi-fi

Как настроите так и будет.

[Les1at]

мож после обеда будет настроение )

[sfstudio]

мож после обеда будет настроение )

настроите != настроение. Сырцы открыты, логика известна, инструменты известны, в гугле ещё никого не банили как и на opennet. Вперёд.

[Les1at]

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

[Les1at]

ну вот первые результаты, нат поднялся, вафля стоит

 

проблема с DNS

 

на точке всё резолвится, но на клиенте - нет.

 

поставил DNS внешний в resolf.conf, что нужно ещё сделать, чтобы заработал днс на клиенте (при условии что клиент настроен на точку)?

 

p.s. разобрался, нужно было добавить правила в iptables

Изменено 28 мая, 2010 пользователем Les1at

[Nestik]

Прошивка wive-ng 0.3.18. Проблема с DHCP решилась, действительно проблема в том что провайдер не понимает DHCP пакеты размером больше 576 байт, тогда как udhcpc посылает пакеты размером 590 байт. Проблема решается перекомпиляцией busybox c патчем от openwrt 241-udhcpc-oversized_packets.patch, Патч для текущей версии bosybox 1.15.2 можно взять здесь. Мож кому пригодится.

[sfstudio]

Прошивка wive-ng 0.3.18. Проблема с DHCP решилась, действительно проблема в том что провайдер не понимает DHCP пакеты размером больше 576 байт, тогда как udhcpc посылает пакеты размером 590 байт. Проблема решается перекомпиляцией busybox c патчем от openwrt 241-udhcpc-oversized_packets.patch, Патч для текущей версии bosybox 1.15.2 можно взять здесь. Мож кому пригодится.

Ну вот и ладушки. А вообще такие патчи нужно выполнять опционально отключаемыми через конфиг и засылать в mainline busybox`а. Однако я впервые сталкиваюсь с такой проблемой и у себя врятли повторю чтобы проверить оттестить и сделать красивый патч дл текущей 1.16.1 версии. Если вы займётесь причешете патч сделаете его отключаемым из конфига (это не сложно) и зашлёте в мэйллист бизибокса попробую помочь протолкнуть в мэинстрим. А иначе раз из раза за собой граблю толкать не хочется. А значит включение сего патча в wive-ng-rtnl/wive-ng-dsl/wive-ng является сомнительным шагом.

[sfstudio]

Хотя, включу в wive* и запощу ща в мэйл лист это дело для 1.16.1 посмотрим примут нет. Запостил https://bugs.busybox.net/show_bug.cgi?id=1849 посмотрим примут нет. Советую подтвердить что баг существует у них в багзилле добавив отзыв к моему посту, авось быстрее примут.

[Nestik]

Хотя, включу в wive* и запощу ща в мэйл лист это дело для 1.16.1 посмотрим примут нет. Запостил https://bugs.busybox.net/show_bug.cgi?id=1849 посмотрим примут нет. Советую подтвердить что баг существует у них в багзилле добавив отзыв к моему посту, авось быстрее примут.

Ну на самом деле это не баг, на сколько я понял из RFC размер 590 для dhcp пакетов является вполне допустимым, просто некоторые, считают пакет максимальным в 576 байт не принимая во внимание что 14 байт могу занимать ИП заголовки. Вообщем действительно косяк провайдера, а не клиента. Я к сожалению не программист и с Си совершенно не знаком, убил три дня на компиляцию и поиск актуального патча, поэтому врядли смогу вам в этом помочь.

[sfstudio]

Ну на самом деле это не баг, на сколько я понял из RFC размер 590 для dhcp пакетов является вполне допустимым,

Я где-то написал что это баг? =) Хотя да в багзилле, ну погорячился =) Ну и с чьей стороны баг я не уточнял =)

 

просто некоторые, считают пакет максимальным в 576 байт не принимая во внимание что 14 байт могу занимать ИП заголовки.

Поэтому выставил статус критикал.

 

Вообщем действительно косяк провайдера, а не клиента. Я к сожалению не программист и с Си совершенно не знаком, убил три дня на компиляцию и поиск актуального патча, поэтому врядли смогу вам в этом помочь.

Ну главное чтобы было желание, посмотрим что ответят по репорту в багзилле.

[sfstudio]

В общем ответили. Нужно снять tcpdump`ом полный dump в hex режиме до патча и после патча. Сделаете?

[Nestik]

В общем ответили. Нужно снять tcpdump`ом полный dump в hex режиме до патча и после патча. Сделаете?

Ок. Сделаю.

 

[Nestik]

Снял дампы, поставил расширение txt чтоб можно было сюда залить,

 

Описание файлов:

 

udhcp - Дамп не патченного клиента, правда не с бюзибокса а отдельного, не хочется обратно роутер перешивать, но там также пакеты размером 590 байт и пров не отвечает на них.

udhcp-patched - Дамп пропатченного udhcpc, пров отвечает адрес дисковерится нормально.

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

 

А то что они там написали про опцию BUGGY DHCP SERVER так эта опция насколько я понял позволяет принимать udhcpc большие пакеты в случае если пров в пакете передат слишком большой список маршрутов, и никак не влияет на размер пакетов передаваемых самим udhcpc, но конечно могу и ошибаться, не менял эту опцию.

tcpdump.dhclient.txt

tcpdump.udhcpc.txt

tcpdump.udhcpc_patched.txt

Изменено 30 мая, 2010 пользователем Nestik

[sfstudio]

Ок спасибо сейчас залью в багзиллу. Блин смотрю сделали с разных девайсов да ещё и древнего 0.9.9 udhcpc плохо это блин. Соберите два бизибокса под x86 с патчем и без, ну и полный дамп а не только запросы, нужно полный цикл видеть, уверен ща отправят за нормальными дампами.

[Nestik]

Ок спасибо сейчас залью в багзиллу. Блин смотрю сделали с разных девайсов да ещё и древнего 0.9.9 udhcpc плохо это блин. Соберите два бизибокса под x86 с патчем и без, ну и полный дамп а не только запросы, нужно полный цикл видеть, уверен ща отправят за нормальными дампами.

Ок на днях постараюсь, как время будет.

 

[pawel40]

sfstudio порекомендуйте железку на 3052 чип с высокой мощностью передатчика. Надо линк в 6км поднять со скоростью 30-50мбит.

[nichtraucher]

Народ помогите с настройками Wive 0.6.1 на G700AP

Ситуация такая есть АДСЛ модем с включеным DHCP 192.168.1.1 и точка доступа прошита Wive 192.168.1.2

вот с такими настройками не могу подсоединится к АП через WiFi:

 

/etc/network/interfaces

 

 

BRIDGE_START=no

#When auto_bridge is "yes" then init.script makes bridge itself

# when aut_bridge is "no" then init.script start /etc/network/bridge

AUTO_BRIDGE=yes

 

# Just to make faster load, when not needed.

STP_ENABLE=no

FD_TIMER=0

GCINT_TIMER=0

 

#BR0_USE_DHCP=yes

#BR0_IPADDR=192.168.1.1/24

 

IPV4_FORWARD_ENABLE=yes

START_IPTABLES=yes

 

VLAN_START=no

 

ETH0_ENABLED=yes

ETH0_FORCEIP=no

ETH0_IN_BR0=yes

ETH0_USE_DHCP=no

ETH0_IPADDR=192.168.1.2/24

ETH0_MACADDR=0021910c572e

 

ETH1_ENABLED=no

ETH1_FORCEIP=no

ETH1_IN_BR0=no

ETH1_USE_DHCP=no

ETH1_IPADDR=192.168.1.50/24

ETH1_MACADDR=00006c576977

 

WLAN_ENABLED=yes

WLAN_FORCEIP=no

WLAN_IN_BR0=yes

WLAN_USE_DHCP=no

WLAN_IPADDR=192.168.1.2/24

WLAN_MACADDR=0021910c572e

WLAN_BURST=no

 

#Be carefull. There're many Hardware-specific mibs

WLAN_USE_UNCHECKED_MIBS=no

 

 

/etc/network/wifi/general

 

#!/bin/sh

 

#Set ESSID of wirelless Infrastructure Network

iwpriv wlan0 set_mib ssid="0685005513"

#Uncomment and Set prior bssid to connect

#iwpriv wlan0 set_mib bssid2join=000000000000

 

iwpriv wlan0 set_mib hiddenAP=0

 

#Set Mode: 8 - Client;16 - AP; 32 - AdHoc

iwpriv wlan0 set_mib opmode=16

 

#Set Regulatory Domain:

# "3" - 13 channels available, "6" - 14 channels available.

# FCC=1;IC=2;ETSI=3;SPAIN=4;FRANCE=5;MKK=6

iwpriv wlan0 set_mib regdomain=6

 

#Set Channel here

iwpriv wlan0 set_mib channel=6

 

#Set Initial Gain: in range 0-7

# It seems to be sens but maybe not. Just test

iwpriv wlan0 set_mib initialGain=5

 

#Set TransmitPower for CCK(802.11b) modulation

# Please Change it in variable

CCKPOWER=12

iwpriv wlan0 set_mib TxPowerCCK=`ader $CCKPOWER 14`

#iwpriv wlan0 set_mib TxPowerCCK=1010101010101010101010101010

 

#Set TransmitPower for OFDM(802.11g) modulation

# Please Change it in variable

OFDMPOWER=12

iwpriv wlan0 set_mib TxPowerOFDM=`ader $OFDMPOWER 162`

#iwpriv wlan0 set_mib TxPowerOFDM=10101010101010101010101010101010101010101010101010101010101010101010

101010101010101010101010101010101010101010101010101010101010101010101010101010101

010101010101010101010101010101010101010101010101010101010101010101010101010101010

101010101010101010101010101010101010101010101010101010101010101010101010101010101

0101010101010

 

iwpriv wlan0 set_mib basicrates=4095

iwpriv wlan0 set_mib oprates=4095

iwpriv wlan0 set_mib fixrate=1

iwpriv wlan0 set_mib autorate=1

 

iwpriv wlan0 set_mib band=3

 

iwpriv wlan0 set_mib bcnint=100

 

#RTS/CTS Threshold

iwpriv wlan0 set_mib rtsthres=2346

 

iwpriv wlan0 set_mib fragthres=2346

iwpriv wlan0 set_mib expired_time=50000

iwpriv wlan0 set_mib dtimperiod=1

 

iwpriv wlan0 set_mib show_hidden_bss=1

iwpriv wlan0 set_mib preamble=0

 

iwpriv wlan0 set_mib shortretry=6

iwpriv wlan0 set_mib longretry=6

 

iwpriv wlan0 set_mib Diversity=0

iwpriv wlan0 set_mib DefaultAnt=0

iwpriv wlan0 set_mib RFChipID=7

iwpriv wlan0 set_mib led_type=7

 

#G protection

iwpriv wlan0 set_mib disable_protection=0

 

#For bridged mode set this parameters

# Nat2.5 is technology to change the source MAC to MAC of Wlan-interface

# be carefull it says disabled, so make inverse in your decision

iwpriv wlan0 set_mib nat25_disable=1

# Macclone says all about itself. It just takes MAC of ETHERNET device on other end of line

# and take it for Wlan-interface. be carefull if this enabled it must be one device on a line.

iwpriv wlan0 set_mib macclone_enable=0

 

iwpriv wlan0 set_mib dhcp_bcst_disable=0

 

#Block packets between clients connected

# 0 - disable; 1 - block relay;2 - block relay but passup

iwpriv wlan0 set_mib block_relay=0

 

iwpriv wlan0 set_mib wifi_specific=0

 

 

 

[sfstudio]

Ок спасибо сейчас залью в багзиллу. Блин смотрю сделали с разных девайсов да ещё и древнего 0.9.9 udhcpc плохо это блин. Соберите два бизибокса под x86 с патчем и без, ну и полный дамп а не только запросы, нужно полный цикл видеть, уверен ща отправят за нормальными дампами.

Ок на днях постараюсь, как время будет.

Патч прияли https://bugs.busybox.net/show_bug.cgi?id=1849 YES!

 

[Nestik]

Патч прияли https://bugs.busybox.net/show_bug.cgi?id=1849 YES!

Замечательно терь значить можнобудет обновлятся. Кстати ещё вопросик, не критичный. PPPTP c MTU 1500 после прохождения нескольких пакетов вешает роутер намертво. Мож кто знает как это побороть? с MTU 1400, полёт нормальный.

[sfstudio]

Патч прияли https://bugs.busybox.net/show_bug.cgi?id=1849 YES!

Замечательно терь значить можнобудет обновлятся. Кстати ещё вопросик, не критичный. PPPTP c MTU 1500 после прохождения нескольких пакетов вешает роутер намертво. Мож кто знает как это побороть? с MTU 1400, полёт нормальный.

PPTP с 1500 поверх чего? Вы оверхид то посчитайте для PPTP какой там может быть MTU/MRU 1500 байт?