NemoNobody

És visszajött a 3686 és megy is szépen az ipv6 pd.

Úgy tűnik nincs megoldás, az eszköznek hibás a firmware-e, pontosabban Jean kifelejtette belőle a teljes dhcpv6 menüt, meg persze mindent ami ezzel jár, plusz kifelejtette belőle a syslogot is.

A megoldás emiatt az, hogy kérjem, hogy cseréljék vissza SagemCom 3686 v2-ra ami előtte volt.

Kérdéses, hogy bárki leadja-e a sagemnek hibára.......... úgyhogy a következő cserénél már kínos lesz, amikor elfogy a 3686-os a raktárakból is.

Én már csak akkor dumálok amikor fáj. Megint fáj.

Kihalt a régi sagem, és Boldog Tulajdonosa™ lettem egy SagemCom HomeBox Wireless Router F@st 3890V3 csodának. Ami amúgy, hozzávetőlegesen problémamentesen megy.

Kivéve hogy eltűntek a DHCPv6 beállítások. És hát így nem is csoda, hogy eltűnt a DHCPv6 is teljesen. Tök jó, hogy van PD, de hogyan kellene hozzájutnom? Kapok DHCPv6 üzeneteket, nagyon izgalmas: No addresses available for this interface.

Kit kell megölnöm hogy a PD-t kiadja?

Attól sem vagyok maradéktalanul boldog hogy RA-n behirdeti a fdaa:bbcc:ddee::/64 prefixet. Minek is? Azon túl, hogy bosszantson?

Nem IPv6, de nem találom a syslog server remote IP megadását sem. Ennek sem tudok így maradéktalanul örülni, mert nincs logom, nem látom, mikor gyakja le magát akármiért is, nem beszélve az „okos” tűzfaláról, aminek szintén örülnék ha látnám a logját.

Vannak esetleg titkos mozdulatok, eldugott ikonok (az egész menü egy rémálom, semmi nem ott van aholgondolnám), mágikus klikkek, hogy a régi funkcionalitást vissza lehessen nyerni? Ötlet....?

Köszönöm előre! is.

@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.

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

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.

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.

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.

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.

Hát ez igazán klassz, és nem kellene cache draint kérniük akkor ahelyett, hogy napok óta leölik a google forgalmat?

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.

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.

@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.

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

Í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.

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.

Csak belebeszélek, nem segítek. :-P

Ekkor: 10/21/2018 at 10:53, Tima írta:

 mail.t-online.hu (port 25) ez sem működik,

Eseélyesen a 25-ös portot nem engedi a külföldi szolgáltatód (sem). Használd az 587-et 25 helyett.

Ekkor: 10/21/2018 at 10:53, Tima írta:

nálam nem is ez  a beállítás működik, hanem a mail.t-email.hu.

A kettő fizikailag ugyanaz (a „t-email” a „t-online”-ra mutat).

Ekkor: 10/21/2018 at 10:53, Tima írta:

Nem tudom van-e összefüggés, hogy a bejövőnél nem POP3-at használok, hanem IMAP-ot, de a bejövő levelekkel nincs gond,

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ó?

(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.

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.

11 órája, Pistapapa írta:

Küldtek levelet és abban az van, hogy az megszűnik, de hogy majd tájékoztatnak, ha végbement az átállás. Most türelmesen várok.

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

20 órája, Roli82 írta:

@NemoNobody

Ha túl sokszor van újraindítva (négyszeres újraindítás) a Sagem akkor ki lehet csikarni belőle, hogy újra lehúzza és telepítse az éppen aktuális stabil szoftvert a szerverről.

Isten ments! Most működik! :-P

@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.

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

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'

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.