No to nezní moc pozitivně. Já ho používám jako AP a jede bez problémů. Ale ten bridge, to by mě fakt zajímalo. Co myslíte, jak by to mohlo jet na asi 2km síto 21dB + 5m RG213 vs. 19dB Pacific wireless síto + 8m H1000, v trase zasahují jen špičky stromů. Teď tam je ASUS WL-500b na WDS, ale toho WDS bych se rád zbavil, shazuje to tu zbytek sítě (nižší průchodnost :( ) a nahradil to bridgem založeným právě na 2x EUSSO...
Včera jsme tyhle dvě zařízení chvíli testovali na stole proti sobě v režimu bridge a rychlosti byly 2 - 3 MB/s, podle +- WEPu, SuperG, apod... O víkendu tím budeme připojovat sí? na cca 400 m (dvě 18dB síta; 10m kabel).
Samozřejmě že v normě by to asi úplně nebylo, ale pokud možno aby to bylo co nejméně přes. Jinak, co se dodržování týče, tak se mi zdá, že na to všichni dlabou. Jak by jinak bylo možný, že kamarád tady (v Písku) chytil providera (konkrétně Český net) až ze Zadova, a to se stejnou sílou signálu jako naše místní AP?
Prave jsem upgradnul FW na 19.7 b18
OVSEM stalo se to, ceho jsem se bal, ztratilo se nastavni IP a predpokladam konfigurace cela.. !!!
takze na zarizeni se ted vubec nedostanu, mmusim pockat az budu mit moznost se k nemu dostat fyzicky.. :((
Tak jsem se na zarizeni dostal a nastavil IP v rozsahu site.
Ja uz to nechapu.. ted jsem tam flashnul nejnovejsi firmware ze stranek vyrobce a takto vypadaji pindy z LOKALNIHO routeru na AP, ktere je na router pripojene Ethernetem !!
Proste hruza des.. :-/ Vubec nechapu, jak se zarizeni muze chovat az tak spatne, nikdy jsem nic podobneho nevidel :(
# ping 10.108.17.106
PING 10.108.17.106 (10.108.17.106) from 10.108.17.105 : 56(84) bytes of data.
64 bytes from 10.108.17.106: icmp_seq=1 ttl=127 time=1245 ms
64 bytes from 10.108.17.106: icmp_seq=2 ttl=127 time=232 ms
64 bytes from 10.108.17.106: icmp_seq=3 ttl=127 time=0.360 ms
64 bytes from 10.108.17.106: icmp_seq=4 ttl=127 time=4623 ms
64 bytes from 10.108.17.106: icmp_seq=5 ttl=127 time=3623 ms
64 bytes from 10.108.17.106: icmp_seq=6 ttl=127 time=2623 ms
64 bytes from 10.108.17.106: icmp_seq=7 ttl=127 time=1624 ms
64 bytes from 10.108.17.106: icmp_seq=8 ttl=127 time=624 ms
64 bytes from 10.108.17.106: icmp_seq=9 ttl=127 time=113 ms
64 bytes from 10.108.17.106: icmp_seq=10 ttl=127 time=0.328 ms
64 bytes from 10.108.17.106: icmp_seq=11 ttl=127 time=103 ms
64 bytes from 10.108.17.106: icmp_seq=12 ttl=127 time=3597 ms
64 bytes from 10.108.17.106: icmp_seq=13 ttl=127 time=2597 ms
64 bytes from 10.108.17.106: icmp_seq=14 ttl=127 time=1596 ms
64 bytes from 10.108.17.106: icmp_seq=15 ttl=127 time=577 ms
64 bytes from 10.108.17.106: icmp_seq=16 ttl=127 time=0.317 ms
64 bytes from 10.108.17.106: icmp_seq=17 ttl=127 time=1164 ms
64 bytes from 10.108.17.106: icmp_seq=18 ttl=127 time=164 ms
64 bytes from 10.108.17.106: icmp_seq=19 ttl=127 time=2660 ms
64 bytes from 10.108.17.106: icmp_seq=20 ttl=127 time=1660 ms
64 bytes from 10.108.17.106: icmp_seq=21 ttl=127 time=660 ms
64 bytes from 10.108.17.106: icmp_seq=22 ttl=127 time=0.311 ms
64 bytes from 10.108.17.106: icmp_seq=23 ttl=127 time=0.327 ms
64 bytes from 10.108.17.106: icmp_seq=24 ttl=127 time=4044 ms
64 bytes from 10.108.17.106: icmp_seq=25 ttl=127 time=3044 ms
64 bytes from 10.108.17.106: icmp_seq=26 ttl=127 time=2044 ms
64 bytes from 10.108.17.106: icmp_seq=27 ttl=127 time=1045 ms
64 bytes from 10.108.17.106: icmp_seq=28 ttl=127 time=45.3 ms
64 bytes from 10.108.17.106: icmp_seq=29 ttl=127 time=0.312 ms
64 bytes from 10.108.17.106: icmp_seq=30 ttl=127 time=534 ms
64 bytes from 10.108.17.106: icmp_seq=31 ttl=127 time=524 ms