b10up

Azt vedd számításba, hogy optikánál akár 10km is lehet a szegmens hossza. Bár nem láttam még rá példát a környékemen, hogy ezt kimaxolták volna. Egy szegmensen mikor a cégnél voltam, max 64 eszköz lehetett, de mintha hallottam volna olyat is, hogy 32 a plafon. Bár ennyire konstans módon nem szokott túlterher jelentkezni, de nem is lehetetlen, valószínűbb a beállítási hiba. A másik: Optikán a pppoe login is vágja a sebességet és az optikai profil is. Mármint ezekben állítják be. Nagyon extrém szerencsétlen esetben, ha erősen manuálisan piszkálták a portot létesítéskor megeshet, hogy fordítva kaptad az optikai profilban a sebességeket. Erre egy profil resetet tudsz kérni hibabejelentéssel, házilag nem tudod megoldani. Esetleg -bár nem hiszem-, de próbálhatsz egy olyat is, hogy a géped lan kártyájában az ipv6 supportot letiltod.

Üdv, ez lehet azért, mert a letöltési irány teli van, és ennyi jut neked, de az is lehet, hogy a speedtest szerver van koppon. Mérj egyet a speedtest.net oldalon valami budapesti szerveren, akár több eltérőn is. Ott is ez a helyzet?

Voltam szerelő, az ilyen címek általában csak "útba estek". Volt, hogy kutya megrágta a kábel végét, vagy csak festés miatt el lett vágva. Az ilyen munkáért maximum 1-2 *****abb kolléga szokott számlázni, ha rosszabb napja van Egyébként igen, kicseréli, ha emiatt nem tudsz netezni, felveszik hibára. Ha "csak úgy", akkor kismunkára veszik fel, amire sokat is kell várnod és fizetni is kell általában.

Küldtem privátot

Attól függ. Ha van a VPN-en át net elérésed, szerintem sima ügy. A szerver piszkálása nélkül is megoldható. Csak kell 2 VPN kliens a routerben, mindegyiknek megadni, hogy melyik interfészen mehet ki, aztán súlyozással beállítani az arányokat, hogy melyiket mennyire terhelheti.

OpenWRT kell hozzá, azzal fogja tudni. Kell pár extra beállítás, de szerencsére nem agysebészeti beavatkozás. A bejövő kapcsolat lehet akár ethernet porton, akár wifin de akár USB-n mobilmodem /telefon is. Gyakorlatilag úgy kombinálod és szabályozod, ahogy nem szégyelled. Tud load balancingot és failovert is. Bonding szervernek VPN..... most, hogy mondod, kicsit módosítasz pár szabályon, akkor lenne rá ötletem

Nálam egy Ubiquiti EdgeRouter Lite 3 van, de egyébként már egy sima TP-Link routerrel is meg lehet csinálni, hogy a 4. lan portot is levágod WAN-nak(vagy akár többet is). Vagy wifin lehet egyszerre AP és kliens a szomszéd wifs routerére. Volt egy időszak, amikor szomszéd meg saját 10 megás DSL-ünket összefűztük 20 megára Amúgy meg failoverben ez sokáig ment így, ha leakadt a saját, akkor a szomszédéra váltott addig. Nem tragédia amúgy, ha két külső IP van, be van állítva, hogy a cél IP cím "ragadjon", aztán akkor egy helyre csak az egyik kapcsolaton indít szálakat. Kevés eset van csak, amikor nem hatékony. A csatolt képen egybe van fűzve egy 100M-s koax ami olyan 85-99 között ingadozik, és egy DSL ami 18-25M

Nálunk kis faluTV-s szolgáltató ad 150M-t koaxon. Viszont napi szinten fekszik ki. Szóval most van egy koaxos vonal, ami hol megy, hol nem, ez mellé jön egy siralmas DSL, ami bűnlassú, de mindig van. Ez van összebondingolva egy 3 portos routerrel. Itt nem hal le a szerver

Nem ez az oka. A központ hal be. Egyébként már kb húsvét óta megy ez a játék legalább. Pontosabban ezt egyszerűen ki tudod szűrni Belépsz a menübe, és ha a bondingnál legalább egy UP van, akkor a szerver rendben, esetleg csak az egyik szál nem megy. Viszont ha mindegyik down, az szerverhalál. A HGW viszont folyamatosan próbálkozik, újraindítgatni nem érdemes emiatt.

A bejövőre, de optikán kapnod kellene a 2HD streamet. Boxok közötti belső kapcsolat mindenképpen 100MBit/s UTP. Alternatív megoldásnál kevesebb, de 10Mbit/s akkor is minimum megvan.

VDSL-en legalább 24 (vagy 33?) MBit/s elérhető sebesség, optikán alapból mehet. Koaxon nem tudom, azt hiszem ott is ED3-on mehet.

Nálam 4-6 óra az átlag... sajnos semmilyen módszert nem ismerek, hogy gyorsítsam.

Az a helyzet, hogy ahogy látom, a központi oldal esik le. Ilyenkor egy pillanatra megszakad minden szál, és utána tisztán a natolt DSL-es címen fog menni az eszköz. Restart ezen nem segít, az eszköz folyamatosan próbálkozik. Ha DSL led zölden világít és a mode türkizen, akkor csak idő kérdése és magától megjavul.

Látom 2 routered van. A T-sből DMZ az asus felé, asusból a nas felé, így jó lesz. Esetleg a WAN IP címed nézd meg a speedtest.net-en, utána a T-s HGW-ben, ha ez a kettő nem egyezik, akkor NAT-ot kaptál.

És pont ez az, hogy tegyük fel, egy panelházban vagy vendégségben, kellene ez a sz.r, fizetsz is érte mondjuk, és 2-3 ilyen hotspot között ugrál. Mindegyiknél újra be kell logolni. PC-n még ki lehet kapcsolni a legtöbb wifi kártyánál a roamingot, de telefonnál esélytelen. Egyébként néha engem sem enged be. Sőt sokszor hiába nyitom meg az alkalmazást, nem léptet be, viszont weblapról pedig elsőre. PPPoE-t úgy értem, hogy vagy azt a PPPoE kapcsolatot használja, amit az előfizető is, vagy esetleg még egyet, mint IPTV vagy VoIP interfész. Igazából ez az egész fon inkább technikai érdekesség/kényszermegoldás mint egy stabil plusz szolgáltatás.

Akkor ezzel még lesznek kísérletezések. Itthon nálam 3 AP van, mind azonos SSID. Telefonfüggő, hogy hogyan kezelik a BSSID-váltásokat. A régebbi kliensek, amik nem tudnak roamingot, ragaszkodnak ahhoz, amihez kapcsolódtak, és ha totál elhal a jel, akkor újra keres, újra hitelesít és újra kér IP-t. Viszont az újak nem DHCP-znek BSSID váltáskor és skype közben maximum a szó vége csuklik el váltáskor. Ezt majd megnézem, hogy a külső IP-k hogyan vannak, mert egyébként sehol nem látszik neki külön VLAN DSL ágon. Esetleg az lehet, hogy kiépítene még egy PPPoE kapcsolatot userenként vagy az egész hotspotnak egyet?...

Ha az ESSID nem változik csak a BSSID, akkor pont ez lenne a lényege, hogy az IP marad, és pl egy skype hívás nem szakad meg. Ezt egy Wi-Freen simán megcsinálom, de egy Fon-on esélytelen. Persze azért ez extrém igény, hogy valaki nyilvános hotspotok között tudjon is mászkálni és akarjon is. Fon-on a belső IP mindenesetben egy privát, aminek a hatóköre a HGW-ig tart, az NAT-olja az előfizető IP címéből. Wi-Free esetében ha jól láttam, ez a LAN szegmens még a coaxon belül is folytatódik, ott a coaxrouterek nem végeznek natolást. Igaz ott portál sincs. Egyébként ha jól emlékszek, volt már 84-es IP-m fon spotról is. Majd ha szomszédomnál is beaktiválják, vagy hozzáférek egy ponthoz, akkor kísérletezek vele még, de úgy emlékszek, az előfizetőével azonos WAN IP-n osztozik.

Nekem is app van, ami tapasztalatom szerint hol tud hitelesíteni, hol nem. Érdekes, mert a captive portal bejön böngészőből, a jelszó appban is jó, de valamiért nem mindig hitelesít, néha kézzel kell belogolnom. A portál valóban egy távoli szerveren fut, viszont a hitelesítő szoftver az helyi, minden eszközön. Ez olyasmi mint a hotspotsystem.com megoldása, ha jól látom. Egyébként néztem, az ügyfél publikus IP/NAT-olt IP-jét kapom meg, ha fonnal lépek be is, legalábbis 724-eseken még biztosan. A biztonságot az adja, hogy kétfelé van NAT-olva HGW-n belül, és a hotspot kliense a fon azonosítóhoz rendeli a látogatott IP címeket. Viszont pont itt van a probléma a cellaváltással. Minden fonos HGW-nek van 172.x.x.x privát IP-je, benne pár kiosztható címmel. Tegyük fel: Első hgw-n feljelentkezek, eszközöm megkapja a 172.16.8.64-et (csak példa), ezzel van net, külső ip-m mondjuk az ügyfél 100.64.13.4 NAT-olt címe. A eset: Második HGW felé mozgok, telefon átmegy, de mivel azonos az SSID, nem fog új IP-t kérni, de ezen már van a 172.16.8.64 címen eszköz. Kész is az IP ütközés. B eset: Második HGW felé mozgok, telefon átmegy, 172.16.8.64-es IP szabad. Viszont captive vezérlőben nem vagyok benne, mert ez már másik HGW, másik alháló, másik vezérlő. Mire az alkalmazásnak ez feltűnik, már meg is szakadt az összes online munkamenetem. App újra hitelesít, de itt ügyélnek van egy 84.x.x.x külső címe, szintén sok alkalmazás elszáll. B/2 : Második HGW-re átléptem sikeresen, viszont telefon valamiért visszaugrik az előzőre. Tegyük fel, valamiért megőrizte a fonos munkamenetemet, így csak kívülről látszok hirtelen a 100.x helyett a 84.x- publikus címről. Azért furcsa ez az egész, mert a Wi-Free esetében a modemrouterekben nincs captive vezérlő, csak van még egy VLAN, egy alháló az egész, és az ki van hozva egy második interface-n, radius védelemmel. Itt nem is probléma az AP-k közti ugrás, mert a külső és belső IP cellák közti ugrásnál azonos marad végig. Upsz, kicsit hosszú lett.

Itt is frissült a szomszédé A Local Network\ Status fülön ott a fon állapot, de csak annyit ír alá, hogy "NOT OK". Egyébként csak egy elméleti kérdés, még nem volt időm tesztelni: Fon esetében hogyan van az access pointok közötti váltás? U_P_C Wi-Free esetében ugye nincs captive portal, csak radiusos hitelesítés, és ha jól látom, az egész egy nagy alhálózat. Ott ha mozgok ilyen pontok között mobillal, gond nélkül ugrál közöttük, lanos IP változatlan és a publikus is. Na de itt ez a Fon, minden access pointon ott a captive portal vezérlője, mindegyik egy saját kis alhálózatot alkot, itt ha AP-t vált az eszköz, változik a publikus IP, a lanon ráadásul nem is fog kérni az eszköz újat, akár ütközhet is. Valaki ezt tesztelte? Mert ha most a sok entryn is bekapcsolják, szerintem ez a szakadozások melegágya lesz. És azért aki a portálon keresztül vesz egy X órás jegyet pénzért, nem biztos, hogy örülni fog neki, ha az eszköze nekiáll AP-ket váltogatni bizonyos esetekben.

Nekem azért tűnik elhamarkodottnak ez az egész, mert pl. Budapesten tényleg relatív lassú tud lenni a 4G, 4G+ még mobilon is, (<30Mbit/s), de például nálunk vidéken mindig 130M fölött mérek, szinte kihasználatlan a torony. Ahogy a területi kiváltságok vannak árkedvezmény formában, ugyanígy lehetne itt is hasonló, csak fordítva, ahol szinte üresben áll a torony, ott nem igazán kéne visszafogni a gyorsítót. Szerintem nem kéne sokat ráfizetned, hogy megszabadulj tőle.

Engem az lepett meg, hogy például facebookos oldalon egy szó nem esett róla. Pedig azzal rendesen foglalkoznak, lehet, hogy ott sikerülne sorstársakat szerezni.

Na a tesztem szerint 28 perc DSL nélküli időt visel el, utána elkattan. A mode led továbbra is türkiz, de az internet led kialszik. Viszont nem kell szinkronba kerülnie ahhoz, hogy visszakapcsolja, szinkronizálás közben már visszaengedi.

Már nem. Eddig így volt, de a limittel együtt ez is változott. Indításkor csak a DSL éledése után ad netet, ha a kapcsolat megszakad, egy kicsit még megy 4g-vel, aztán letiltja. Hogy pontosan hány percet, azt még nem mértem meg.

2017-06-18 18:55:03 System Error Porcess [voice] run excepition: [voice][ERROR]:Send SIP packet fail, error:Operation not permitted 2017-06-18 18:54:31 System Error Porcess [voice] run excepition: [voice][ERROR]:Send SIP packet fail, error:Operation not permitted 2017-06-18 18:53:36 System Error Porcess [voice] run excepition: [voice][ERROR]:Send SIP packet fail, error:Operation not permitted 2017-06-18 18:53:07 System Error Porcess [voice] run excepition: [voice][ERROR]:Send SIP packet fail, error:Operation not permitted 2017-06-17 12:50:35 System Error LTE Tunnel DOWN. 2017-06-16 04:04:51 System Error DSL Tunnel DOWN. 2017-06-14 12:57:29 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:55:16 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:54:07 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:53:30 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:53:09 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:52:56 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:52:47 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:52:40 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:52:28 System Error DSL Tunnel DOWN. 2017-06-14 12:52:08 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:51:34 System Error LTE network error <407>. 2017-06-14 12:51:31 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:51:13 System Error LTE network error <407>. 2017-06-14 12:51:10 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:50:59 System Error LTE network error <407>. 2017-06-14 12:50:57 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:50:50 System Error LTE network error <407>. 2017-06-14 12:50:48 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:50:46 System Error LTE network error <407>. 2017-06-14 12:50:41 System Error LTE Tunnel Request do not receive respond. 2017-06-14 12:50:40 System Error LTE network error <407>. 2017-06-14 12:50:28 System Error LTE Tunnel DOWN. 2017-06-11 12:50:40 System Error LTE Tunnel DOWN. Amióta bevezették a limitet, rendszeresen tele van ezekkel a log, ilyenkor voip nincs, család velem kiabál, csak a restart segít, hogy hozzájussak a csodás, limitált 4G sebességhez, miután elfüstölt a 10 giga. Ezt más is tapasztalja?

Ahogy nézem, ebben a menüben csak target portot lehet megadni, source portot nem, és jelen esetben a target nem a lan, hanem a net oldal. Így viszont pont a torrentezést nem lehet belőni vele rendesen. Még azt tudod csinálni, hogy ha külön eszközzel töltesz, hogy annak minden forgalmát átnyomod DSL-re.