NemoNobody

Tag
  • Tartalmak

    37
  • Csatlakozás időpontja

  • Utolsó látogatás

NemoNobody a fórumon

  • Rang
    Tudományos főtag
    1
    1

    Megoldóember

    Megoldóember vagyok, a fórum indulásától ennyi válaszom fogadták el megoldásként a fórumtagok

Profil megtekintések

310 profilmegtekintés
  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. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Hát ez igazán klassz, és nem kellene cache draint kérniük akkor ahelyett, hogy napok óta leölik a google forgalmat?
  8. 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.
  9. 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.
  10. @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.
  11. 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.)
  12. 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.
  13. 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.
  14. 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ó?
  15. (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.