NemoNobody

Tag
  • Tartalmak

    37
  • Csatlakozás időpontja

  • Utolsó látogatás

Minden, amit NemoNobody posztolt

  1. @btz hát annak én is nagyon örülnék, ha végre lehetne! Hol kell kérni, hogy az eszköz bridge legyen és az IPTV is működjön? :-( Igen, a multicastet is meg tudnám oldani, de hát nem lehet. Úgyhogy sajnos ami mondasz az nem segít, és mivel a telekom áll kapcslatban a sagemmel tök hasznos lenne ha leadná hibára, hogy legalább 2-3 éven belül megoldják, viva la france.
  2. Ahelyett, hogy embert ölök inkább kiírom itt magamból, hogy ez a sagemcom 3686 nem egy hulladék de vannak nagyon sötét foltok a lelkében. Nos, az egyik látszólag a DHCPv6, úgy en bloc, meg a prefix delegation specifikusan. Aminek az implementációja így ránézésre egy nagy *****domb. Számos próbálkozás után leszűrtem, hogy: képtelen kezelni a hinteket (általában éppúgy, mint specifikusan a prefix delegation esetében), következésképp nem bírom visszakapni azt a prefixet, amit már egyszer ideadott, és amúgy nem használt; képtelen kezelni a kérésben a prefix-hosszt, és /60-at ad akkor is ha a fejem tetejére állok; ez különösen szerencsétlen, lévén nem is lehet statikus route-ot beállítani, hogy az egész prefixet felém route-olja; képtelen egyszerre több prefixet kiadni; ha kérek, akkor vagy üres válaszokat ad (solicit prefix nélkül), vagy minden kérésre ugyanazt a prefixet adja, ami bizonyára franciaországban hasznos, de nekem nem pont ez volt a vágyam; a dhcpv6 ablak a webes felületen semmit nem tud a PD-kről, se mutatni, se törölni, se statikusan beállítani, se semmi se; a „reset dhcpv6 server” jelentése „reset modem”, persze ezt nem mondja sehol, én meg nagyon örültem hogy leölte a netet; úgy tűnik, mintha nem is tudna több PD-t kiadni több DUID-nak sem, a második eszköz csak vár-vár a válaszra… de itt már elveszítettem a türelmem, így lehet, hogy csak én nyomtam el valamit, de gyanús, hogy mégsem. Olyan jó lenne, ha ezeket a bugokat mondjuk javítanák… Vagy ha lehetne egy normális satikus route-ot beállítani. Megjegyzem az is csodás lenne ha a Nagylila nem változtatná meg a prefixet, ha a modem picit le van kapcsolva, de hát miért akarjak jót...
  3. Kicsit reménytelen ennyire konkrét műszaki kérdést feltenni, de ha jól érzékelem, akkor a matávos google cache elérhetetlenné vált (legalábbis innen docsisról), ipv6-on mindenképp, a v4-et most nem tudom egyszerűen megnézni, de mintha ott is. Ez nem most kezdődött, már pár napja így van. Van, aki arra tippelget hogy google probléma, van aki szerint pedig nem. Én ezt innen nem látom, csak azt, hogy a matávos ipv6-on semmiféle google play nem megy, és a youtube is időnként végtelenbe réved.
  4. Azóta jó, lekopogom. Láthaóan valami központi update volt, néhány reboot, és azóta virul mint a rózsaszál.
  5. Sziasztok. Rákerestem, sok mindent találtam, de pont ilyet nem, így kénytelen vagyok mesélni. Teljesen új előfizetés, 500-as kábel+IPTv. Sagemcom 3686 V2. Mögötte etherneten STB, másik etherneten pedig mindenféle informatika: gépek, wifi router és rajta lógó mobilok, satöbbi. A gépek mindent (is) csinálnak. Aktív IPv6 PD, subnetek. Minden megy szépen. (Na jó, őszinte leszek, a wifiket az első pár napban lekapcsoltam, mert elképzelhetetlenül instabil volt, de nem baj, nem kell, van máááásik.) Azonban... pár nap alatt azt tapasztaltam hogy a net instabil lett. Nézem a trace-t és mindjárt az első hop (ami maga a sagem etherneten) magas ping és pkt loss. Nem vagyok én ehhhez szokva, mondom neki, és rátettem egy smokeping grafikont. Reboot. Másnap megint csuklott, ránéztem, és bevallom, ilyen rondát eddig nem láttam: illetve közelebbről: Vagyis az eszköz nagyjából egy nap alatt lineárisan elkezd egyre lassabban és lassabban pingelni, majd szétesik. Ez tipikusan akkor szokott történni, amikor elfogy a CPU: egy ideig terhelődik, míg eléri a 100%-ot és utána nem bírja feldolgozni és csomagot veszít. Mivel 2-3 reboot után a jelenség nem szűnt meg, sőt, konzekvensen ugyanazt nyújtotta, szóltam a Cégnek hogy ez van, őket nem érdekelték a műszaki részletek, „rossz a net”, „modemet cserélünk”. Jó, ha ramhibás esetleg, akkor segíthet, legyen. Na, megjött ma az új példány. Smokeping maradt, hogy lássam, hogy jó lett. Sajnos nem lett jó. Ugyanaz. Olvasgatva viszont a fórumot kicsit megrettentem: ha bejelentem a hibát, akkor a következő az lesz, hogy kinyírják az ipv6-ot, vagy a tévét, vagy a sávszélességet? Mert úgy tűnik, ez a modem nem bírja a rendes használatot (pedig még torrent nem is ment rajta), én pedig használni akarom, azért van. A mostaninál aktívabban, ráadásul. A sima felület nem nagyon ad rendszerinfókat: nem látom, hogy mi fogy el (memó, cpu), vagy mitől ragad be, nem látni a conntrack táblát (lehet, hogy kicsire vették és nem bírja a session számot?), ... De jó lenne megoldani, mert a napi reboot messze esik az optimálistól (és nem is tudom még távolról rebootolni). Van vajon lehetőségem belenézni? Látott már valaki ilyet? És megoldotta? Vagy Obi van Kenobi volt az utolsó remény?
  6. Addig is annak aki esetleg olvassa, de nem érti: Ez azt jelenti, hogy minden google szolgáltatás ami nagyobb file-okat kezel (google play, youtube, google music, google books, google drive, ...) cache-el (gyorsítótáraz), és ami szerepel a LilapacaSzolgáltató (MT) helyi cache serverén azt nem amerikából kapod hanem a lilapacától. Mivel a lilapaca cache nem érhető el, vagy nem működik, így a tartalmat nem kapod meg. A google play örökké teker, a youtube örökké bufferel, a zenék és a pdf-ek örökké töltődnek. Ha olyan tartalmat kérsz ami nincs benne a helyi cache-ben akkor pedig minden szépen működik. Ez a ritkán nézett esetekben lehetséges.
  7. Oké, én is bejelentettem; valóban tegnap óta tudnak róla. Remélem addig is míg kiderítik hogy mi van (mondjuk nem egy űrtechnológiai probléma megnézni, mert a cache nem is pingel) nyomnak rá egy cache draint hogy a google ne küldje oda az ügyfeleket (vagy, ha esetleg értelmes mérnök olvassa, kiszedi a hibás subneteket a bgp-ből, hint hint), mert kikerülni szinte lehetetlen.
  8. 99% hogy a google cache elérése hibás, és így a cache-elt forgalom nem fog menni, beleértve MINDEN ami google, kezdve az androidos google play frissítésektől a youtube tartalmakon át akár a publikusan osztott drive tartalmakig. Normális helyeken ez kritkus hiba.
  9. Hát ez igazán klassz, és nem kellene cache draint kérniük akkor ahelyett, hogy napok óta leölik a google forgalmat?
  10. Elnézést, hogy beleszólok (ez a standard felütésem), de szerintem teljesen fölösleges. 421 4.7.1 <mail.nordtelekom.hu[80.253.180.10]>: Client host rejected: Access denied due to massive spamming (20181112)> vagyis a nordtelekom.hu írta a fenti üzenetet, így velük kell megbeszélni, nem a nagylilapacával. Amúgy előtte érdemes körbenézni, hogy minden oké-e. Ezen túl pedig nicsolyan, hogy „Legtöbb Blacklist”: van ami 4 óra alatt expire-ol és van, ami 4 év alatt. Amúgy az üzenet alapján ez kézi tiltás a nordtelecomnál.
  11. @Tima ha semmi nem sikerül akkor küldéshez használd az ottani szolgáltató mailserverét küldéshez, általában engedik, hogy „bármilyen” feladóval küldj levelet, ha helyi ügyfél vagy.
  12. kabelnet

    A btz által linkelt oldal nem annyir rossz, nézd meg azt is, hátha mond konkrétumokat. Amúgy az általános válasz: nem, semmiféle nat nem kell. Nekem kézi configgal megy: a routerem kér egy /64-et a hgw-től magának, és a maradékokat a /56-ból a másik interface-ekre, ahol szintén /64-eket oszt ki a wifire, a lanra, stb.re. Aztán pedig simán layer3-ban route-ol a subnetek között. (Jó, erre én rátettem még egy kis dinamikus route-ot, egy pici ospfv3 meg ilyesmik, de ez már tényleg csak cseresznye a tortahabon.)
  13. kabelnet

    Így, hogy a prefix mérete nem is látszik, én inkább nem szólnék hozzá. :-) Meg ugye jó lenne tudni, hogy amit írsz az melyik eszköz a háromból (hgw, cisco, enduser), és leginkább hogy mit lát a wrt.
  14. kabelnet

    Nem tudom fejből, mit tud az openwrt de dhcpv6 kellene, lehetőleg PD (prefix delegation request), és azt tudja tovább osztani, ha ezt akarod. Ha nem kérsz prefixet, nincs mit osszon, szegény gondolom azért fanyalodik a local címekre.
  15. Csak belebeszélek, nem segítek. :-P Eseélyesen a 25-ös portot nem engedi a külföldi szolgáltatód (sem). Használd az 587-et 25 helyett. A kettő fizikailag ugyanaz (a „t-email” a „t-online”-ra mutat). Akkor nincs szerintem, amennyire látom küldésnél kell azonosítanod (smtp authentication) magad. Be van állítva a küldéskori azonosító és jelszó?
  16. (Reklamálni ingyen van. :-)) A Té büszke arra, hogy milyen gyors, biztos lelkiismereti okból kijavítják! ;-) Amúgy szinte biztos hogy van rajta hiba, ha ilyen, ha más nem, akkor fatális overbooking, de inkább zaj.
  17. Kalásznetről amúgy annyit: ügyfélszolgálat munkanapokon 9-17 óra között, ha ez mond valakinek valamit, például a péntek 16.50-kor leállt modem meséjéből. Amúgy én voltam náluk és maradéktalanul elfogadhatatlan volt minden, kezdve azzal, hogy mielőtt átvették a hálózatot 2 év alatt kb. 30 perc leállás volt, utána egy hónapban kb. 100 óra, utána pedig periodikusan havonta 2-5-10 órák, a karbantartásokat nem jelentették be, a műszerészeknek meg általában én segítettem mert a központtól nem kapták meg az adatokat. Amikor lemondtam és vissza kellett vinni a modemet akkor meg országosan kábé 2 helyen lehetett leadni.
  18. Érdemesebb rákérdezni, mint utólag vitatkozni, szerintem. Ha telefonálsz, írd fel az időpontot és az ügyintéző nevét és hogy pontosan mit mondott (amúgy ez örökérvényű jótanács).
  19. Isten ments! Most működik! :-P
  20. @anonymus nem szeretem az ilyet, de október 3-án délben rebootoltam a scriptemmel, és azóta 500 µsec alatt van folyamatosan, 0% packetloss. v. MAGYAR_3.97.0, nem látok firmware frissítést (verziószám alapján, de lsd lentebb), így erősen hajlok afelé hogy valaki valamit eltekert a cmts-en, és most visszatekerte, mert én nem változtattam semmit. Thu 04 Oct 2018 22:26:31 Notice (6) SW Download INIT - Via Config file bac21401000106d8d775e091fd Thu 04 Oct 2018 22:27:24 Notice (6) SW download Successful - Via Config file
  21. Csak magánvélemény. 1) Ha visszavették a sebességed, akkor a szolgáltatást erre hivatkozással szerintem retorzió nélkül felmondhatod: nem változtathatnak szerződést minőségromlással. 2) Ha a szerződésváltozás miatt többet kell fizetned, akkor is felmondhatod hűségidős bünti nélkül, mivel hátrányosan és egyoldalúan változtattak szerződést. Ebbe beletartoznak a kedvezmények (megvonása) is. Általában az ÁSZF ezt részletesen leírja, de ha nem, akkor az EHT (hírközlési törvény) illetve a szerződésekről szóló rendeletek (amiket az ÁSZF nem bírálhat felül).
  22. Az a nehéz, hogy amikor már annyira rossz hogy egyértelmű akkor 300ms körül van a ping és 20% felett a pktloss, és akkor már a fórumra is nehezen tudok postolni, hogy „most” lehet megnézni. Persze megpróbálhatom bejelenteni hogy 33 és 124 (aztán vagy tudnak vele mit kezdeni, vagy nem), de félek, hogy ez a problémámtól független. Most kb. 24-32 óránként jut el a katatón állapotig. Nem tudom, van-e bármi esélye úgy hibát bejelenteni hogy „a modemcsere nem fog rajta segíteni, informatikusnak kellene látni a problémát”. Amúgy Linuxosoknak/*nixosoknak reboot_the_damn_modem.sh: #!/bin/sh echo "Get session key..." SKEY=`curl -s http://192.168.0.1/login.asp | perl -ne 'if(/var SessionKey = (\S+);/) {print "$1\n";}'` echo "Login... ($SKEY)" curl -X POST -d "loginUsername=admin&loginPassword=SZUPERTITKOSJELSZO&loginOrInitDS=0" http://192.168.0.1/goform/login?sessionKey=$SKEY echo "Get session new key..." SKEY=`curl -s http://192.168.0.1/RgSetup.asp | perl -ne 'if(/var SessionKey = (\S+);/) {print "$1\n";}'` echo "Issue reboot... ($SKEY)" curl "http://192.168.0.1/goform/RgSetup?sessionKey=$SKEY" \ -H 'Referer: http://192.168.0.1/RgSetup.asp' \ --data 'WanLeaseAction=0&ApplyRgSetupAction=0&RebootAction=1'
  23. Lement a következő teszt is: amikor szétesik a ping akkor a koaxról nyugodtan le lehet húzni, ugyanolyan tré marad. @anonymus, láttál rajta valami relevánsat? Most 2 napot is kibírt.
  24. sagemcom

    @anonymus Az IPv6 témában az a nehéz, hogy megtanultunk „IPV4-ül gondolkozni”, a V6 pedig más. Itt nem az a szempont, hogy hány címet használunk el, meg hogyan subneteljük hatékonyan. Sokkal fontosabb szempont a hatékony aggregáció, a minél simább automatizáció, az azonnali működés, a szükség szerinti szegmentálhatóság. Amikor beszéljetünk róla az első fura arcok akkor jönnek, amikor megszámolják az ujjaikon hogy valójában hány darab /64 (!, nem ipv6) van abban a bizonyos /32-ben, amit legkisebb prefixként kapni lehet. :-) Konkrétan mindenkinek minden eszközére lehetne statikus címet adni, beleértve a kispárnát és fogkefét is, ha csak a darabszámot néznénk. Amúgy statikus címekkel hatékonyabb is üzemeltetni. [Jópofa ez a fórum, akár hsz írása közben is ki tud léptetni.]
  25. sagemcom

    @btz Egy darab /56-ot ad az ügyfélnek, és egy másik prefixből kap saját WAN címet (az egy /128). Az előbbiből a legelső /64-et szórja fel minden interface-re, onnan ad DHCPv6-os addresst, a prefixet pedig DHCPv6/PD-vel lehet elkérni tőle. Ez egyébként teljesen megfelel a RIPE ajánlásnak, alapvetően korrekt. Sajnos az a rész, hogy a prefix legyen statikus már nem sikerült, de kis lépésekkel haladunk a kánaán felé. :-)