Dotaz: Prehazene a duplicitni odezvy z pingu

[Bill Gates]

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

[NN]

smycka ve smerovani, HW problemy etc.

[Bill Gates]

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?

[gogol]

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.

[Bill Gates]

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 ?

[gogol]

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.

[Bill Gates]

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.

[lertimir]

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.

[Jan Kratochvíl]

perfektní vysvětlení....

[gogol]

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.

[lertimir]

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.

[gogol]

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.

[lertimir]

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ě.)

[gogol]

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.

[gogol]

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.

[Igor]

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.

[Igor]

Este som zabudol dodat:

Channel/Frequency:40 / 5200 MHz
Channel Width:40 MHz (Lower)
Vzdálenost: 1.5 miles (2.4 km)
Polarizacia: Horizontal

[ironman]

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.

[Bill Gates]

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.

[Bill Gates]

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.