btz

@Eszes Árpád

Cache törlés a Beállítások/Tárhely menüből (Ilusztráció 4.4-es Androiddal, újabb vagy más verzióknál eltérhet, de szerintem sok különbség nincs)

Itt rá kell rákattintani a "Gyorsítótárazott adatok" feliratra, majd okézni.

Vagy Recoweryvel wipe cache (A recovery mód előhívása készülékenként eltérő lehet. Az enyémet pl ki kell kapcsolni majd Volume down gomb és power gomb együttes nyomásával jön elő)

Így néz ki a felület.

Recovery használata esetén ments le minden fontos adatot mert akár törölheted is azt, szóval a sima wipe cachen kívül inkább semmihez ne nyúlj, ha nem tudod mit eredményez.

És ha csinálsz egy teljes cache törlés, majd újraindítást? (Tárhely beállítások körül kell szétnézni az összes cache törlésével kapcsolatban)

Ha ez sem segít, wipe cache-t kéne megpróbálni recovery mode-ból.

@Toxi Külföldi ez az FTP szerver?

@fgabor87

Amennyiben publikus ipv4 címet továbbra is kapod a T-től a HGW-d wan interfészére, addig elérhetők lesznek NAT mögül portforwarddal a belső hálón üzemelttett ipv4 eszközök, mint eddig, ha használtál ilyet. A belső hálózatodat pedig te szabályzod nem a T, amennyiben nem kapcsolod ki a dhcpv4 servert a routereden/HGW-den addig természetesen megkapják a LAN-os eszközök a szokásos helyihálózati 192,168.0...... vagy 192.168.1...... stb ipv4 címüket.

Indítsd újra a készüléket, majd

Beállítások -> Alkalmazások -> Összes vagy minde  alklamazás (eltérő lehet) -> System UI vagy Rendszer UI cache törlése

Újabb készülék újraindítás.

Ellenőrizd, hogy ez megoldotta e a problémát.

Értem, akkor nem tudom miért eszik sok aksit a Facebookod, majd ha lesz hatos androidos telóm, akkor kíváncsi leszek a viselkedésére. 4.4 alatt sok gond nincs vele, csak néha "megakad" de ez minden masszívabb applikációnál előfordul, mert nem mai darab a tabletem

@Tamas586

Azért írtam hogy érdemes bekapcsolni mindkettőt, mert vannak olyan kliensek, amik csak az egyiket vagy a másikat támogatják vagy nem teljesen, így kiegészítik egymást.

Nálam pont ez a helyzet. Van Win7 kliens nem támogatja az RA által hirdetett RDNS infókat ezért a dns szerver címet a dhcp szerver mondja meg neki (mondjuk ezt megadhatnám statikusan is, de egy ehhez nem értő felhasználó szívna vele). Van Android 4.4 kliens, ami komplete nem ismeri a DHCPv6 ot (rootolva természetesen lehet letölteni, hozzá olyan alkalmazást, ami által megkaphatja dhcpv6 által is a címét, de rootolva nem tarthatom mert pl használom a TVGO-t is néha, az meg nem enged műsort nézni rootolva, tehát vagy dhcpv6 vagy TVGO)

Tehát nekem a LAN-on lévő DHCP beállítás így néz ki

Stateless + Stateful

Amúgy nálad is bekapsolható egyszerre, ahogy nézem, a másik Asusos routeren nem tudom miért nem lehet egyszerre mindkettő menjen.

Amúgy az RADVD nem dhcp server hanem Router Advertisement Daermon, ami az RA (Router Hirdetés) szolgáltatás működéséért felelős. Az RA is a szolgáltatói prefixet hírdeti és a dhcpv6 is, szóval nem egy helyi unicast címet ad az RA sem.

A Play alkalmazás beállításainál lehet ezt megadni. Csak azért kérdeztem meg mert sokak úgy gondolják, az a probléma, hogy nem frissítik az FB alkalmazást, vagy ha friisítik is, de ki van kapcsolva az automatikus frissítés, akkor az FB app alternatív frissítési csatornák után kezd kutakodni, ez jobban meríti az aksit, mint ha engedélyezve lenne a Playen.

Az majdnem a legújabb ha jól tudom. Nincs kikapcsolva a Facebook app automatikus frissítése, vagy globálisan az automatikus frissítés?

Hányas verziójú Android? Nekem ilyet nem szokott írni, lehet hogy ezt újabb verziókban vezették be, nekem még a jó "öreg" kitkat verzió van.

Én használom a FB alkalmazást, sőt a csoport és a Page Mager alkalmazásokat is, az aksim 64%-on van hajnali 5 óra óta.

Én sem vagyok Android szakértő, csak követni szoktam Androidos fórumokat, olvastam egy két cikket  az Android memória kezeléséről, és arról, hogy hogyan is kell ésszerűen használni a task killer appokat, vagy a beépített alkalmazás kilövést. A legtöbb esetben jobb az Androidra bízni a memória kezelést mint az userre. Az értesítésre külön folyamat működik a rendszerben, ezért az app kilövéses módszerrel egy jól megírt alkalmazás esetében nem lőjük ki azt is.

Igen, sajnos nem volt pontos a probléma körül írás, így csak ebből lehet kiindulni.

Milyen típusú a mobil router? Maradjon benne midkettő. Slaac is, DHVPv6-PrefixDelegation is.

Úgy értettem hogy azzal "elhagyhatjuk" az alkalmazást, de "kilőni" csak abban az esetben célszerű, ha nem megfelelően működik. Amúgy erre az esetben alkalmazható, a Beállítások menüben az alkalmazás beállításokban kikeresni az adott alkalmazást, majd a "Kényszerített leállítás" lehetőséget választani.

Szóval Android esetén használjuk inkább az alkalmazás elhagyásához inkább a Home vagy a vissza gombot, az alkalmazás választót is inkább csak választásra használjuk ne kilövésre.

Home gomb megnyomása esetleg?

A SIM is T amit beletettél?

Szerintem a legegyszerűbben úgy jársz, hogy lereseteled és az usmer manulál instrukciói alapján újból beállítod az egészet.

Adsl net HGW-vel? Akkor légyszives mellékelj egy képernyőmentést a HGW admindelületén található vonali információkról.

És akkor itt is az ígért módosítás, mostmár jobban hasonlít az openwrt tűzfalkeretrendszerében található szabályokhoz. 

ip6tables -F
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -A FORWARD -p tcp -m tcp --destination [IDE: IPV6 CÍM] --dport 8080 -j DROP #(Vagy ACCEPT ha meg akarom nyitni a portot a destination résznél megjelölt ip címmel rendelkező gépen)
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT --protocol udp --src fe80::/10 --source-port 547 --destination fe80::/10 --destination-port 546 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT #(Drop ha nem akarjuk a pinget)
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type bad-header -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-request -j ACCEPT #(Drop ha nem akarjuk a pinget)
ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type unknown-header-type -j ACCEPT
 

Több szabályt fel lehet venni, különböző gépek portjaira, nyitni és zárni lehet őket, akár mind a ~65000  portot le lehet zárni, mintha NAT mögött lenne a gép.

@Tamas586

Nem tudja a router, hogy melyiken van a webszerver. A tesztelés ideje alatt gyakran változtattam a tabletem ipv6 ip címén és nem volt kedvem átirogatni a célgép címét a szabályban, ezért inkább ezt nem szabályoztam le egy gépre, szóval ha lett volna 10 webszerveres gépem, akkor ezzel mind a 10-re nyitott lenne a 8080-as port.

A FE80 kommunikáció a dhcpv6-hoz kell, ahogy az openwrt-s tűzfal szabályban is benne van, elég lenne csak source portnak az 547 célportnak pedig az 546, de ahogy a fenti hszben is írtam, az egyszerűsíés kevéért kihagytam az iptables szabályból. Később ha több időm lesz foglalkozni vele akkor bele rakom az iptables szabályba is a portokat, és azt is hogy a cél ip range is csak FE80....lehet.

Szerintem érdemes brkapcsolva hagyni mind a kettőt, mert ha van Android 5 alatti oprendszerrel rendelkező telefonod, tableted, akkor az csak slaac-al kaphat ipv6 címet, én is stateless + stateful beállításon hagytam a routerem dhcpv6 beállításait.

@Tamas586

Iptables az iptables mindkét rendszeren, Linux alapú rendszer a Dd-wrt és az Openwrt is. Az Openwrt-nek van egyfajta külön tűzfal keretrendszere, ami áttudja kicsit bolygatni az iptables dolgait, de én most magamnak megoldottam (igaz csak áttmenetileg), hogy csak az iptables adja a szabályokat a saját routeremben.

Így néz ki az iptables parancssor, amit hozzáadtam annak érdekében hogy ne szűnjön meg az ipv6

ip6tables -F
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j DROP #(Vagy ACCEPT ha meg akarom nyitni a portot)
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -s fe80::/10 -j ACCEPT
ip6tables -A INPUT -p IPv6-icmp -j ACCEPT
ip6tables -A OUTPUT -p IPv6-icmp -j ACCEPT
ip6tables -A FORWARD -p IPv6-icmp -j ACCEPT

Lényegében csak az ICMPv6 forgalmat engedélyeztem újra mind az INPUT, FORWARD, OUTPUT láncon, plusz a FE80::/10 kommunikációt. Plusz tesztelés képpen a 8080-as port nyitásához, zárásához egy sort, ez másnak nem kell, ezt csak azért raktam bele, hogy teszteljem vele, mikor és milyen iptables szabályok alapján érhető el a tabletemre telepített teszt webszerver, amit ipv6-on keresztül lehet csak elérni, ipv4 esetén nem, mivel le van NAT-olva.

Az openwrt-s forgalmi szabály beállításoknak az analógiájára csináltam, mondjuk én kicsit egyszerűsítettem az iptables parancs formát, hogy átláthatóbb legyen most a tesztelésnél (később majd teljesen finomhangolom az openwrts beállítás szerint, különbontva az icmpv6 fajtákat, stb)...

...de a lényeg, hogy működik, kapok ipv6-ot és tudom zárni nyitni a portokat openwrt alatt annak tűzfalkeretrendszerét megkerülve (a képen látszik, hogy ki van lőve az engedélyezés az openwrts szabályok mellöl, helyettük az Iptables szabályai vannak életben).

ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j DROP 

hatására filterezi a 8080-as webszerverem portját 

ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j ACCEPT

Hatására pedig engedélyezzük

Később ha érdekel valakit /lesz rá igény, akkor megcsinálom az iptables parancsok teljes hozzáigazítát az openwrt féle szabályokhoz.

17 órája, Tamas586 írta:

Egyenlőre én így állítottam be: (kép1)  (kép2) egy más célú leírás alapján, emiatt nem vagyok biztos a sikerben.

Megcsináltam ezekszerint a szabályok szerint, ugyan ilyen ip6tables parancsokkal, de mint sejtettem nem kapta meg a tabletem az ipv6 címét. Ezért raktam bele plusz pár sort, így most megkapja a címet, de most meg azzal szenvedek, hogy nem tudok portot nyitni a tabletemen futó teszt webszervernek, de még utána kérdezek pár dolognak.

@Tamas586

Ha nincs grafikus felület, akkor sajnos maradnak a parancsok. Openwrt esetén szerencsére a konfigurációs állományok szerkesztése sem túl bonyolult, így grafikus felület nélkül sem kell parancsozni, elég csak szerkeszteni a konfig állományt. DD-WRT esetén nemtudom, hogy milyen lehetőségek vannak konfigurációs állomány szerkesztésére.

@Tamas586 

A fenti példában, ha elindítanék a tabletemen, mondjuk egy FTP szolgáltatást, akkor rögtön zöldre váltana a portscannaren a 21-es port, ezért ha tudod, hogy x ipv6 című gépeden ezt akarsz futtatni, de nem szeretnéd, hogy wan felől is elérhető legyen, akkor csak fel kell venni egy új szabályt a 21-es (FTP szolgáltatáshoz dedikált) port szűrésére

Ekkor a port scanneren kívülről csak annyi látszik, hogy le van filterezve az a port, de belülről elérheted, mert a forrás nem a wanból jön. A wanból filtered-et kap mindenki

Publikus ipv6 alatt ugyanúgy biztonságban lehet tartani egy eszközt, mintha ipv4 nat mögött lenne.

@Tamas586

Szivesen segítek, ezért vagyok/vagyunk itt.

Szerintem a SOHO routereken a lehető legjobb választás az Openwrt, amennyiben a felhasználónak nincs szüksége hardveres NAT-ra. A többi már csak ízlés kérdése.

Közben utána néztem és úgy olvastam, hogy a DD-WRT-ben is van iptables, szóval lehet azt is tűzfalazni.

Teljesen igazad van, a számodra a 18/20 az ideális, nálam engedélyezve volt az echo,  így hoztam egy új szabályt, ami így néz ki:

Ezzel a routerrel lezártam az összes eszközöm ezirányú továbbítását a routeren keresztül (Discard forward).

Majd felmentem az ipv6 tesztoldalra a kliens tabletemmel.

Itt látható, hogy már csak 18/20 pontot kaptam, mivel a routerem kiszűri az icmp echo-requestet. Nem fog válaszolni a pingre.

Felmentem egy online ipv6 ping oldalra. Látható (lenne ha véletlen nem satíroztam volna ki, de az alján valamennyire látszik), hogy 100% packet loss az ipv6 címemre, pedig a tabletem kint van a publikus neten az ipv6 címével.

Majd az egészet ellenőriztem egy ipv6 online portszkennerel is. Látható, hogy a tabletem az összes fontos portja amit kívülről nagyon szeretnek birizgálni, az zárva van. Persze megnézhettem volna mind a 65ezer valahányra, de most idő hiányában ezt nem tettem, de biztos, hogy mind zárva van. Tehát akik hekkelni akarnak, azok nem találják meg a tabletem. Miközben én kiscicás képeket nézek a Google ipv6 only keresőjében vele.

Összegezve: kívülről zártak a portjaim, pingre nem válaszolok, de az eszközömnek publikus ipv6 címe van, amivel látom az ipv6-only oldalakat is. Van még valami amivel ki tudják még deríteni az esetleges támadók, hogy a tabletem publikus ip címmel fent van a neten?

Amint pedig nyitok egy portot, azt ugyan így a router tűzfalán lezárhatom, ha nem akarom használni, annak ellenére, hogy a tabletemen nyitott az adott port, wan felől zártnak fogja mutatni a port scanner, de a tabletemen is lezárhatom a portot, de akkor már a routerrel hiába nyitom meg a lehetőséget, akkor is zárva marad, csak a tabletemmel tudom megnyitni.

Bocs elírtam, Teredo