maxik tak na Nku chodi lepe nv2 to ano, ale ze by byl Nstreme vsude nejpruraznejsi tak to zas ne. Kde je hodne zaruseno protlaci nv2 vic, alespon me a pridnesnich rychlostech se muze casto stat ze wifi jede na max tudiz latency control je fajn vec to nstreme nema a pak jsou haluz odezvy kdyz to jde na strop.
majklik What's new in 5.16 (2012-May-09 17): *) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels Tak tohle se jim silně nepovedlo. O tohle se na pár stech mistech opírám. :-( Klasiké použití: Mám GRE tunely uvnitř IPsec transportu a dělám kontrolu, že tunel přišel opravdu přes IPsec. V mangle značkuji pakety ESP a následně ve filteru nad gre rozhranním testuji, že paket má marku, že dorazil původně jako ESP. Tak vím, že to opravdu prošlo IPsecem a ne nějaký podvrh nebo chybná IPsec konfiguce. :-(
selic Vy, co máte problém s disconnecty, zkusili jste zvýšit hodnotu Disconnection timeout z default 3s? Já jsem tam dal 10s, mžikové výpadky ve spojení tam stále jsou, ale aspoň se ušetří čas na reconnection :(
pfadmin Moment, to moc nechápu, timeout když zvednu, tak ZKRÁTÍM čas výpadku? Měl jsem za to, že ten timeout je interval, kdy to hlídá, jestli se může spojit, takže by měl bejt co nejkratší ne? Díky za případné osvětlení, pokud to chápu blbě.
hapi disconnect-timeout (time; default: 3s) - čas od třetího špatného odeslání ( 3*(hw-retries+1) pakety byly ztracené) (jenom v nejnižší datarate) (to jest poprvé od první aktivace on-fail-retry-time) kdy se klient odpojí. (logged as "extensive data loss"). samozřejmně že se do toho montuje i řazení rychlostí takže už to asi nebude tak docela pravda ale princip je stejnej. Otázka je jestli to má vůbec nějakej vliv když tam z protokolu 802.11 nezbyl ani ten název a tedy nikdo vůbec neví jestli tohle platí i pro NV2. Platí pro to i hw retries? nebo si to protokol řeší sám? nebo do toho furt zasahujou protokoly samotný karty? řeší NV2 pouze to co se posílá za data ve wifi rámci nebo řeší i ten samotnej rámec? To jsou takový otázky který by měl mikrotik nějak více specifikovat a objasnit problematiku. Tak nějak mám pocit že ty ladící prvky co tam jsou už nějak moc nefungujou když se přepne na NV2.
honzam disconnect-timeout (time; default: 3s) - čas od třetího špatného odeslání ( 3*(hw-retries+1) pakety byly ztracené) (jenom v nejnižší datarate) (to jest poprvé od první aktivace on-fail-retry-time) kdy se klient odpojí. (logged as "extensive data loss"). samozřejmně že se do toho montuje i řazení rychlostí takže už to asi nebude tak docela pravda ale princip je stejnej. Otázka je jestli to má vůbec nějakej vliv když tam z protokolu 802.11 nezbyl ani ten název a tedy nikdo vůbec neví jestli tohle platí i pro NV2. Platí pro to i hw retries? nebo si to protokol řeší sám? nebo do toho furt zasahujou protokoly samotný karty? řeší NV2 pouze to co se posílá za data ve wifi rámci nebo řeší i ten samotnej rámec? To jsou takový otázky který by měl mikrotik nějak více specifikovat a objasnit problematiku. Tak nějak mám pocit že ty ladící prvky co tam jsou už nějak moc nefungujou když se přepne na NV2. Právě že na foru psali že HW retries u NV2 nejsou vůbec použité. Protokol si to řeší sám. Je jedno co tam napíšeš. Tudíž asi i discoonnect-timeout je hodnota která tam je jenom pro 801.11
honzam myslel sem si to. kde to tam bylo? když to najdu tak dám citaci. Ale je to už starší příspěvek a bude to někde zahrabané
