abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 02:00 | Nová verze

Byl vydán Debian 9.1, tj. první opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.9, tj. devátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 9
22.7. 15:50 | Zajímavý článek

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice zveřejnila čtyřiačtyřicetistránkovou výroční zprávu za rok 2016. K dispozici je ve formátu pdf ve vysokém (21,68 MB) a nízkém (7,1 MB) rozlišení. Zpráva byla vytvořena ve Scribusu.

Ladislav Hagara | Komentářů: 0
22.7. 14:40 | Zajímavý software

Mozilla.cz informuje, že Firefox Focus pro Android, velmi jednoduchý prohlížeč zaměřený na anonymní prohlížení, dosáhl milionu stažení. Firefox Focus blokuje sledující prvky a reklamy a při ukončení automaticky smaže všechna uložená data stránek, historii prohlížení a cookies.

Ladislav Hagara | Komentářů: 17
22.7. 14:20 | Komunita

Vyplněním dotazníku na Formuláře Google lze ovlivnit výběr výchozích aplikací v Ubuntu 18.04 LTS. Podrobnosti v příspěvku Dustina Kirklanda na Ubuntu Insights [reddit].

Ladislav Hagara | Komentářů: 6
21.7. 11:30 | Komunita

Etherpad (Wikipedie), svobodný online webový textový editor umožnující spolupráci v reálném čase, se stal oficiálním projektem organizace Software Freedom Conservancy (Wikipedie). Vývojáři Etherpadu se tak mohou stejně jako vývojáři dalších projektů soustředit pouze na vývoj softwaru a vše kolem zařídí Software Freedom Conservancy. Spuštěna byla instance Etherpadu pad.sfconservancy.org.

Ladislav Hagara | Komentářů: 3
21.7. 10:40 | Zajímavý článek

Lukáš Růžička se v článku Workrave ve Fedoře aneb jak si nevytunelovat karpál na MojeFedora.cz věnuje aplikaci Workrave (Wikipedie) na sledování času stráveného na počítači, která může pomoci vyhnout se negativním účinkům práce s počítačem (RSI, CTS), nebo je alespoň výrazně zmírnit.

Ladislav Hagara | Komentářů: 1
21.7. 10:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Shadow Warrior: Special Edition běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 2
20.7. 23:11 | Nová verze

Byla vydána verze 2.4.0 analyzátoru síťového provozu Wireshark. Jedná se o první stabilní verzi nové řady 2.4. Podrobný přehled novinek v poznámkách k vydání. V červnu proběhla konference SharkFest’17 US věnovaná Wiresharku. Záznamy přednášek jsou k dispozici na YouTube.

Ladislav Hagara | Komentářů: 12
20.7. 13:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřeného přístupu na 142. brněnský sraz, který proběhne v pátek 21. července od 18:00 hodin ve Sport Centru Srbská (Srbská 4). Od 19:00 je pro zájemce zamluveno hřiště na plážový volejbal.

Ladislav Hagara | Komentářů: 0
20.7. 12:34 | Bezpečnostní upozornění

V GNOME Soubory, původně Nautilus, konkrétně v generování náhledů exe, msi, dll a lnk souborů byla nalezena a opravena bezpečnostní chyba CVE-2017-11421 s názvem Bad Taste. Při otevření složky obsahující tyto soubory může být spuštěn VBScript obsažen v názvech těchto souborů.

Ladislav Hagara | Komentářů: 3
Těžíte nějakou kryptoměnu?
 (2%)
 (2%)
 (17%)
 (78%)
Celkem 46 hlasů
 Komentářů: 2, poslední dnes 03:34
    Rozcestník

    Dotaz: Prehazene a duplicitni odezvy z pingu

    24.6.2013 11:33 Bill Gates
    Prehazene a duplicitni odezvy z pingu
    Přečteno: 824×
    Zdravím, předně se omlouvám, možná je toto téma špatně zařazeno, nicméně nebyla by tu dobrá kromě ostatních poraden také "Síťová poradna"? Zde by se mohly řešit problémy týkající se sítí a vůbec komunikace? Jen návrh.

    Nicméně zpět k problému. Může mi prosím někdo popsat jak je možné že dochází k následujícímu jevu duplicitních a přeházených odezev z pingu? Stalo se mi to nedávno u jednoho poskytovatele internetu, kterému už asi týden vypadává net, stále si ale nejsem jist, zdali je problém u mě a nebo mimo mou domácí síť a tak hledám, zkouším.

    Narazil jsem na následující problém u pingu:
    [10:09:42]-[/usr/bin]
    [root@ntb]# ping seznam.cz
    PING seznam.cz (77.75.72.3) 56(84) bytes of data.
    64 bytes from 77.75.72.3: icmp_req=2 ttl=245 time=674 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=1 ttl=245 time=14159 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=3 ttl=245 time=3622 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=4 ttl=245 time=2530 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=6 ttl=245 time=9837 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=5 ttl=245 time=13102 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=7 ttl=245 time=14184 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=7 ttl=245 time=17390 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=15 ttl=245 time=11620 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=13 ttl=245 time=14350 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=12 ttl=245 time=16774 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=17 ttl=245 time=13375 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=18 ttl=245 time=12574 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=20 ttl=245 time=10851 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=21 ttl=245 time=9920 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=11 ttl=245 time=20012 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=24 ttl=245 time=7462 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=26 ttl=245 time=6189 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=19 ttl=245 time=13645 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=14 ttl=245 time=18680 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=16 ttl=245 time=17135 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=25 ttl=245 time=8277 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=30 ttl=245 time=4021 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=10 ttl=245 time=24395 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=32 ttl=245 time=3543 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=29 ttl=245 time=7813 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=8 ttl=245 time=28966 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=22 ttl=245 time=15267 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=28 ttl=245 time=10120 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=27 ttl=245 time=13552 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=23 ttl=245 time=18216 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=31 ttl=245 time=11875 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=35 ttl=245 time=12881 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=36 ttl=245 time=12319 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=37 ttl=245 time=12975 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=39 ttl=245 time=11405 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=39 ttl=245 time=11514 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=38 ttl=245 time=13337 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=34 ttl=245 time=17351 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=33 ttl=245 time=18356 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=43 ttl=245 time=8616 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=41 ttl=245 time=10810 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=42 ttl=245 time=9984 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=47 ttl=245 time=5641 ms
    64 bytes from www.seznam.cz (77.75.72.3): icmp_req=44 ttl=245 time=8918 ms
    a) horzné odezvy

    b) ztrátovost paketů

    c) přeházené odezvy (to by se možná dalo pochopit i když považuji to za bordel)

    d) duplicitní odezvy (nechápu)

    Tohle jsem viděl v momentě kdy providerovi asi týden blbnul net. Mezi mou wifi a AP providera signál naprosto v pohodě, ale jeho AP mě sem tam odhlašovalo a znovu přihlašovalo na POE, některé jeho AP občas mizely a zase se objevovaly (restarty AP?). Střídal jsem několik providerových AP ve vzdálenosti od 2 do 12km, problém se projevoval na všech jeho AP i když signál na všechny AP mám relativně dobrý.

    Dnes se mi ale zdá, že se to vrátilo do normálu a jede to stabilně, poznám to protože poslouchám jeden internetový stream a minulý týden to byla katastrofa, jak odezvy webu, tak přerušování streamu, který nestíhal bufferovat a ani tunelování VPNkou na jiný můj server a tím jiného providera si s tím neporadilo. Dneska od rána bez výpadku. Možná právě provider něco řešil a blbla mu chvíli infrastruktura, nevím, hádám.

    Kde taková věc - viz ping výše může vzniknout? Setkal se někdo někdy s něčím podobným a zjistilo se co je příčinou?

    Dík za informace a názory.

    Odpovědi

    24.6.2013 12:24 NN
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    smycka ve smerovani, HW problemy etc.
    26.6.2013 16:48 Bill Gates
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Provider odpovedel ze pry je to asi problem se signalem moji wifi.

    Dalsi zajimavy ping ze vcerejska:
    [root@ntb]# ping seznam.cz
    PING seznam.cz (77.75.76.3) 56(84) bytes of data.
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=3 ttl=245 time=12.4 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=12.9 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=23.0 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=128 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=9.44 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=128 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=240 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=11 ttl=245 time=276 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=11 ttl=245 time=283 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=7.68 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=23.0 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=126 ms (DUP!)
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=14 ttl=245 time=7.06 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=16 ttl=245 time=9.16 ms
    64 bytes from www.seznam.cz (77.75.76.3): icmp_req=17 ttl=245 time=9.19 ms
    ^C
    --- seznam.cz ping statistics ---
    22 packets transmitted, 8 received, +7 duplicates, 63% packet loss, time 25616ms
    rtt min/avg/max/mdev = 7.065/86.609/283.238/101.122 ms
    
    Muj signal na jeden 11km vzdaleny AP providera:

    Signal strength: -75 dBm

    Noise floor: -89 dBm

    Transmit CCQ: 90.2%

    TX/RX Rate: 9.0 Mbps / 12.0 Mbps

    Muj signal na druhy 3km vzdaleny AP toho sameho providera:

    Signal strength: -72 dBm

    Noise floor: -90 dBm

    Transmit CCQ: 93.8%

    TX/RX Rate: 24.0 Mbps / 18.0 Mbps

    Je to spatny nebo dobry signal?

    26.6.2013 17:43 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Niektore pakety sa musia opakovat a caka sa na ich potvrdenie, preto mozu dorazit v inom poradi. Je to normalny prejav zarusenej linky, pricom vzdialenost nehra az taku dolezitu ulohu. Ved to mozes vidiet sam. Doporucoval by som pripojit sa na take AP, kde budes dosahovat lepsie CCQ pri downloade. Meranie CCQ, ked sa nic neprenasa, alebo len sem-tam nejaky ping nema prave velku vypovedaciu hodnotu.
    26.6.2013 18:43 Bill Gates
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    To CCQ ktere uvadim je pri zatezi kolem 300kbytes/s download neboli asi 2.5mbps. Stahovan byl v tom momente gparted.iso odsud (139.5 MB).

    Chapu to spravne ze mnou uvadene CCQ je hodne dobre? To znamena cim vyssi hodnota tim lepsi ?
    26.6.2013 19:06 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Cim vyssie CCQ tym by to malo chodit lepsie. Bohuzial toto je len nejake meranie tvojeho klienta. Pre posudenie, kde moze byt problem by bolo potrebne mat k dispozicii meranie z obidvoch stran v rovnakom case. Take nieco dokaze robit provider. Mozno preto to vyhodnotil ako problem u teba. Blizsie sa k tomu neda povedat o moc viac, pretoze ak pouzivas 2.4G wifi klienta a mas ho napojeneho na svoje domace wifi, ktore je tiez 2.4G, tak sa mozes spolahlivo zarusit sam. Je to celkom dost casty pripad, zvlast ak sa pouzije domace wifi na 40MHz. Treba brat do uvahy, ze rusi nielen domaci router, ale aj pocitace nanho napojene. Antena, ktora je na streche ti spolahlivo chyti vysielania aj z domacich pocitacov a routra. Pravdepodobne pouzivas 24dBi antenu. Ak ano, tak signal z druheho AP by si mal mat aspon o 10dB lepsi, pokial to druhe AP nema nahodou opacne otocenu antenu.
    26.6.2013 19:49 Bill Gates
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Wifi je Ubiquity AirGrid M5-HP, tedy na 5ghz, odtud kabelem do switche a odtud kabely do konkretnich PC. Kolik dBi ma moje antena to nevim, ale dostal jsem to jako original k ubiquity a je to velke sito.
    26.6.2013 22:47 lertimir | skóre: 60 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    ta kilometráž je strašná. Pokud je to AP, které má mnoho klientů, tak je to neuvěřitelný bordel. Kdysi dávno, když byl Ethernet na sběrnici a koaxu nebo později na UTP a na HUBech platilo, že síť může být maximálně tak veliká, aby i nejmenší paket (84 oktetů) byl dostatečně velký na to, aby jeho čelo při vysílání dosáhlo i nejvzdálenější systém dříve než vysílání skončí. Pak byl v celé síti jen jeden paket a pomocí CDMA/CD se řešilo, kdy mohu vysílat a jak poznám, když vyrobím kolizi.

    Vzduch (nebo vysílací pásmo) je v podstatě taková sběrnice o kterou se všichni perou. Jenže nejsem na ni schopen poslouchat, když vysílám a navíc jednotlivé stanice nejsou schopny slyšet mnohdy jedna druhou. Takže začnou vysílat, když si naměří, že kanál je volný, ale to klidně může být situace, že jiná stanice z druhé strany vysílá. Zvláště v takovýchto kilometrech. Nebo řekněme v případě stanice 3 km vzdálené, tak začne vysílat stanice a 5 us po ní začne vysílat AP protože si také změří, že kanál je volný (čelo vlny dorazí až za 10 us). Mnoho stanic na obrovských vzdálenostech může vyrobit obrovské množství kolizí protože nejsou schopni se zasynchronizovat. A pak si dokážu představit, že 90% času je kolizní stav a jen 10% užitečný datový přenos. A ty duplicity jsou znovu vyslání paketu, který měl kolizi (z pohledu AP) nicméně vám dorazil dobře, protože ostatní signály, které u AP s ním iterferovaly, se vzdáleností (a směrovostí antény) zaslábly.

    Pokud je to pro vás jediná možnost připojení, zkusil bych se z poskytovatelem domluvit a instaloval si u něj druhé vlastní Ubiquity a udělal si spojení bod-bod.
    27.6.2013 10:36 Jan Kratochvíl | skóre: 12
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    perfektní vysvětlení....
    27.6.2013 14:07 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Kazdy vysielany ramec nesie v sebe informaciu o dlzke vysielania a stanice ktore su v dosahu si podla toho nastavia sietovy vektor. Problem je vsak so stanicami, ktore niesu z nejakeho dovodu v dosahu (napriklad su odtienene smerovymi antenami). Znamejsie je to pod oznacenim problem skryteho uzla.
    27.6.2013 16:52 lertimir | skóre: 60 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    To jo, ale stanice 3 nebo 12 km bude skoro jistě skrytá těm dalším klientům, navíc, díky konečné rychlosti signálu a velké vzdálenosti, je zpoždění mezi zahájením vysílání a příjmu ostatními stanicemi značné a mezi tím může začít vysílat jiná stanice nebo AP.
    27.6.2013 17:30 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Ak by boli pouzite na pracovnom kanali (a kanaloch susednych) len zariadenia ake ma tazatel, tak by problem skyteho uzla neexistoval. Jeho jednotka pracuje v casovej domene modulaciou TDMA, velmi podobne ako GSM, alebo WiMax. Bohuzial na 5G pasme sa pouziva mnozstvo navzajom nekompatibilnych modulacii (napriklad aj radiovy full duplex). Kazdy vyrobca si vylepsuje svoje zariadenie tak, aby to jemu islo lepsie ako konkurencii. Co na tom, ze konkurencne vyrobky sa medzi sebou nevedia dohodnut aby si neprekazali vo vysielani. Ono to potom na tom pasme aj tak vyzera.
    28.6.2013 11:18 lertimir | skóre: 60 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    V podstatě máte pravdu. Na to, aby sdílení kanálu mnoha subjekty fungovalo i na takovýchto vzdálenostech je nutné, aby byl v provozu nějaký systém rezervace media. Třeba RTS/CTS pro všechny stanice, nebo TDMA. Pomocí malých paketů se dohodne, kdo bude vysílat, zde je pravděpodobnost kolize významně menší a když nastane tak nevadí. A datový paket je pak vysílán už na rezervované médium s větší jistotou, že kolize nenastane. (No druhý důvod špatného příjmu v případě tazetele je síla signálu a rušení. To má tazatel dost na hraně.)
    28.6.2013 12:57 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    RTS/CTS (rovnako ako CF-Poll/CF-ACK) je metoda pristupu na vyssej vrstve, alebo dalo by sa povedat aj s mensou prioritou. Okrem toho musia byt stanice (ruseny a rusiaci) na rovnakom kanali. Rozpoznane ramce z prilahlych kanalov ovladac karty zvycajne zahadzuje. V pripade interferencie bude ramec dropnuty uz priamo firmwarom karty, pretoze nemusi prejst crc kontrolou. Ovladac si v takomto pripade nenastavi NAV (network alocation vector), tudiz vysielanie nebude odlozene. Problem s NAV je tiez v pripade pouzitia modulacie, ktoru prijimac neovlada. Napriklad jednotky 802.11a nerozpoznaju vysielania v modulacii DSSS, alebo 802.11n v mode GF (green field). Existuje este nizkourovovejsia metoda pristupu na medium pod nazvomm CCA (Clear Channel Assessment), ktora je zalozena na principe merania energie. Specifikacia 802.11 blokuje (odlozi) vysielanie ak je energia na kanali vyssia ako -80dBm pre TXPower > 100mW. Bohuzial CCA modul ma viac modov v ktorom sa kombinuje este energia kanalu s detekciou nosnej, pretoze detekovat len energiu by zapricinilo v urcitych pripadoch takmer aj nemoznost komunikovat. Napriklad vyzarovanie z MW, alebo inych radiovych zdrojov (nie wifi) by moholo podstatne znemoznit spravnu funkcnost. Prave tato detekcia nosnej zapricini zavislost na urcitej modulacii, ktora je neziaducou v pripade interferencii pri roznych modulaciach. Niektore sofistikovanejsie zariadenia (napr.Cisco) maju moznost nastavovat parametre CCA modulu, takze s takymito zariadeniami je mozne sa vyhrat do sytosti. Bezne wifi jednotky maju CCA modul nastaveny len na jeden mod zvycajne ako ED+CS (Energy detect + Carrier Sense) a neda sa to menit aj ked urcita moznost existuje. Niektore ovladace (firmware) maju moznost nastavovat tzv.citlivost (Sensitivity). V Linuxe prikazom: iwconfig wlan0 sens... Tym sa da nastavit treshold pre odmietnutie ramca a je to dost ucinna metoda v pripade interferencii z rovnakeho, alebo prilahleho kanala ak ma stanica signal z AP aspon -60dBm. Zavisi potom na SNR a kvalite ovladaca ako sa to bude spravat.
    27.6.2013 13:50 gogol
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Spojenie PtP moze pomoct, ovsem iba v pripade ineho kanalu a merania zarusenia na obidvoch stranach. Ono totiz 5G pasmo nieje az take prazdne ako sa o nom hovori. Bezne na nom chodia PtP linky prevadzkovatelov, ktore spajaju pristupove body v mensich lokalitach napriklad aj na pasme 2.4G. To by este nemuselo vadit, ovsem tieto linky chodia nekompatiblne s wifi specifikaciou, Tudiz wifi klient nic nenaskenuje a pre neho sa zda, ze na tom pasme nic nieje. Velmi dobra pomocka je spektralny analyzer. Niektore Ubi jednotky ho obsahuju uz vo firmware.
    27.6.2013 23:29 Igor | skóre: 8
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Zdravim, Pracujem tiez s wifi technologiami.Som tiez pripojeny cez AirGridM5HP..... Vas problem vyzera v zaruseni kanalu.

    JA mam taketo statistiky:
    Síla signálu: -49 dBm
    Noise Floor:-95 dBm
    Odchozí CCQ:100 % 
    TX/RX Rate:150 Mbps / 150 Mbps
    airMAX:Zapnuto
    airMAX Priority:High
    airMAX Quality: 99 %
    airMAX Capacity: 49 %
    
    mne to ide zruba 60-70 Mbit/s....

    Na 100% je to zaruseny kanal.
    Tell me again what that '-r' option to rm does...?
    27.6.2013 23:35 Igor | skóre: 8
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Este som zabudol dodat:
    Channel/Frequency:40 / 5200 MHz
    Channel Width:40 MHz (Lower)
    Vzdálenost: 1.5 miles (2.4 km)
    Polarizacia: Horizontal
    
    Tell me again what that '-r' option to rm does...?
    28.6.2013 16:35 ironman
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Problem je nejspis v zarusenem prostoru. Oskenovat vzduch na kazde strane a zmenit kanal na nejmene zaruseny.
    Jeste bych mel par pripominek ke zminenemu spoji presneji k jeho delce 11km?! To se nekdo asi posral ne. Jako nezlobte se na me, ale radiovy spoj na 11km v 5GHz nemuze nikdy dobre fungovat. Pokud to neni zrovna nad polem, kde neni siroko daleko zadna civilizace.
    Dneska poskytuje internet kazdy Tonda (tondove prominou) z vesnice, ktery nakoupi 5GHz technologii od Ubiquiti nebo Mikrotiky. Pak to strili na desitky kilometru daleko a v konecnem zaveru se divi ze to nefunguje.
    Kdyby radeji investovali ti radobi pipaci do poradne technologie na 10GHz a poskytli v destinacich kvalitni linku. Ne to chce kazdy byt nejpozdeji do mesice majitelem audin, bavoraku apod. ale kvalita poskytovanych sluzeb stoji za ho.no. Bohuzel clovek bydlici na konci sveta ma smulu. O2 jsou par.hanti, kteri za sve nesluzby chteji neslusny prachy.
    28.6.2013 22:57 Bill Gates
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    Bydlim skoro na konci sveta a ten 11km spoj mi svihal na 2.5mbps vklidu a stabilne (coz me osobne tedy uplne staci), az tedy do jiste doby. Nejsem provider, jsem zakaznik providera, ktery nabizi konektivitu na svych ve zdejsim okoli umistenych AP, kdy klient si poridi vlastni technologii nebo mu provider proda nejakou vhodnou a klientova strana zustava majetkem a ve sprave klienta. Ta 11km cesta je kopec / kopec s primym vyhledem, tesne lizajici 2 mesta, ktere jsou asi odhadem 60m pod trasou kudy svisti signal. 3km spoj je na nejblizsi mesto, AP je uvnitr toho mesta.
    28.6.2013 23:04 Bill Gates
    Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
    No jinak tedy doplnim, ze jsem dnes pootocil antenu na jiny AP stejneho providera (opet kopec / kopec) s primym vyhledem a tentokrat jsem na 2.3 km. Sviha to na me skromne naroky hodne v pohode. Lepe nez predtim a absolutne bez vypadku. Takze asi skutecne problem nekde ve vzduchu. Patrne problem nebyl celou tu dobu az do nedavne doby kdy se neco ve vzduchu zmenilo a bylo po srande. Vypadky patrne v momente kdyz nekdo konkretni zacal vysilat a me tak zarusil drive volny vzduch. Mozna vznikly nove vysilaci stanice a tim to cele slo do kopru. Takze zkratka jsem na jinem AP o 45 stupnu vedle a jedu.

    Diky vsem za komenty, dost mi to pomohlo ve vyreseni tady te zahady a dost me to poucilo o zajimavych vecech.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.