Mivel sikerült elérned ezt a 21 napos uptime-ot? Legújabb firmware és más semmi?

Mielött megvettem beleolvastam a topicba. Akkor épp valaki tápcserével foglalkozott. Ez nálam is így van 2,5 A minőségi táppal dugtam össze hátha, illetve legfrissebb sw, ap modban. Máshoz nem nyultam, illetve a wifi nevét irtam át.

Ez hihetetlen, na mondom kipróbálom amit írtál.

Kezdtem egy restore-al, majd miután újra indult a rendszer, felraktam a 3310-t.
Rendszer újra indul, majd ismét restore.
Miután megint felállt a rendszer, bementem a frissítőbe, jelezte, hogy van új firm, felrakta, restart.
Felállt megint a rendszer és ismét kapott egy restore-t, majd miután ismét újra indult vissza állítottam minden beállítást.
Már 3 napja meg és semmi baromság nem került a logba.
Most mi van?
Én firmeltem már jó pár eszközt de ilyet még nem pipáltam
Nem akarom elkiabálni, de most nagyon ok minden.

Így én már a 10. napnál tartok jelenleg. Azért ez így már nekem oké lenne, ha nem naponta kétszer indulna újra..

i11 White 64GB, AirPods 2, Lumix GX7

Azért a wifi-re nem mondamám, hogy ócska.
Az 5ghz, az árához képest baromi jó 400Mb/s volt már csúcsban, valamint a 2,4-is tudott tartósan 100Mb/s és ezt a tp link sem tudta 2,4-en megállt 80Mb/s-nél.
A hatótávra sem panaszkodok.
Mivel nálam a wifi másodlagos így nem foglalkozom vele túl nagy lendülettel de azért leteszteltem, fontos dolgok csak kábellel mennek.

Amúgy az 5ghz rész nem érdemes piszkálni, de a 2,4-et érdemes.
átenni n-only, /40mhz/ a b/g Protection automatikusan letiltásra kerül így a 40mhz elérhető (ilyenkor széles csatornán üzemelsz, de ha sok a wifi 2,4 a szomszédban akkor a nagy interferencia miatt még rosszabb lehet, mint szűk csatornán és ilyenkor a b/g eszközök sem látják a wifit).
Amúgy ha megteheted csak 5Ghz-t használj, főleg teljesítményre, távolságra már nem jó.
Pl, nálam kb 30 2,4Ghz-es wifi van ami zavar de 5G-n csak én "sugárzok" és ez meg is érződik teljesítményben.

Nekem azóta nem indult újra, igaz csak hetente egyszer csinálta, a múltkor volt csak egy egymás utáni kettő de ennyi. Azóta meg megcsináltam ahogy te is és semmi hiba, hát bízom benne

[ Szerkesztve ]

Sziasztok VAN ÚJ fw. Most néztem

WAN Connection: DNS probe failed (0/2)

Nekem ezt naponta elég sűrűn kiírja, nem von maga után újraindulást, ezt a szolgáltató hibája miatt írja ki, általában amikor ez hibaüzenet megjelenik, szakad a WDSL egy pillanatra.

Tcom internet, egy húgy a szolgáltatásuk.

30 napnál járok újraindulás nélkül.

És tényleg, bár nem túl hosszú a bugfix lista. Sajnos...

Köszi az infót, tegnap néztem még akkor semmi nem volt, de én most várok Majd ha elkezdi a hülyeségét akkor felrakom.

i11 White 64GB, AirPods 2, Lumix GX7

Nem sok, de jobb mint a semmi

Bug fixed
- fix randomly redirect to router login page issue

Ezt a digi-nél is kiírja
És nem csak ez a modell, ezen lovagolnak külföldön is és mindenki csak találgatni tud miért csinálja.
A 30 nappal te leszel a csúcstartó, habár mintha valaki 40-et írt volna egyszer, de hajrá

[ Szerkesztve ]

Nincs mit.Enyém még szervizben,határidő 11.24.

Az szép, de még így is megdőlhet a rekord, eddig ő áll a legközelebb

Nekem az átvételi jegyzőkönyvön van a dátum. (Vásárló részére történő visszaszolgáltatásának várható időpontja:2016.11.24.)

[ Szerkesztve ]

Érdekes nekem nincs rajta konkrét dátum csak annyi, hogy 30nap. Én október 28-án adtam le.

Fórumtárs segít ahol tud. Akkor tiéd előbb érkezik,majd oszd meg az új élményedet.

Vagy többet javítottak mint ami ki van írva vagy nem tudom, mert sokkal szebben indul log alapján, már a WAN Connection: DNS probe failed (0/2) is eltűnt.
Lehet jó lesz hosszútávon ?

Új és régi.

------3.0.0.4.380.4089-------------------------------------------------------------------
Aug 1 02:00:34 192.168.1.1 pppd[428]: PPP session is 4156 (0x103c)
Aug 1 02:00:34 192.168.1.1 pppd[428]: Connected to xx:xx:xx:xx:xx:xx via interface eth0
Aug 1 02:00:34 192.168.1.1 pppd[428]: Using interface ppp0
Aug 1 02:00:34 192.168.1.1 pppd[428]: Connect: ppp0 <--> eth0
Aug 1 02:00:37 192.168.1.1 pppd[428]: PAP authentication succeeded
Aug 1 02:00:37 192.168.1.1 pppd[428]: peer from calling number xx:xx:xx:xx:xx:xx authorized
Aug 1 02:00:37 192.168.1.1 pppd[428]: local LL address fe80::6dce:xxxx:xxxx:xxxx
Aug 1 02:00:37 192.168.1.1 pppd[428]: remote LL address fe80::794d:xxxx:xxxx:xxxx
Aug 1 02:00:37 192.168.1.1 pppd[428]: local IP address xxx.xx.xxx.xx
Aug 1 02:00:37 192.168.1.1 pppd[428]: remote IP address xx.xx.xx.xx
Aug 1 02:00:37 192.168.1.1 pppd[428]: primary DNS address xx.xx.xx.xx
Aug 1 02:00:37 192.168.1.1 pppd[428]: secondary DNS address xx.xx.xx.xx
Aug 1 02:00:37 192.168.1.1 rc_service: ip-up 557:notify_rc start_firewall
Aug 1 02:00:37 192.168.1.1 dnsmasq[385]: read /etc/hosts - 6 addresses
Aug 1 02:00:37 192.168.1.1 dnsmasq-dhcp[385]: read /etc/ethers - 2 addresses
Aug 1 02:00:37 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:00:37 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:00:39 192.168.1.1 wan: finish adding multi routes
Aug 1 02:00:39 192.168.1.1 rc_service: ip-up 557:notify_rc stop_upnp
Aug 1 02:00:39 192.168.1.1 rc_service: waitting "start_firewall" via ip-up ...
Aug 1 02:00:39 192.168.1.1 kernel: registering ipv6 ROUTE target
Aug 1 02:00:39 192.168.1.1 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug 1 02:00:40 192.168.1.1 kernel: nf_conntrack_rtsp v0.6.21 loading
Aug 1 02:00:40 192.168.1.1 kernel: nf_nat_rtsp v0.6.21 loading
Aug 1 02:00:41 192.168.1.1 rc_service: ip-up 557:notify_rc start_upnp
Aug 1 02:00:41 192.168.1.1 rc_service: waitting "stop_upnp" via ip-up ...
Aug 1 02:00:41 192.168.1.1 rc_service: zcip 625:notify_rc start_firewall
Aug 1 02:00:41 192.168.1.1 dnsmasq[385]: read /etc/hosts - 6 addresses
Aug 1 02:00:41 192.168.1.1 dnsmasq-dhcp[385]: read /etc/ethers - 2 addresses
Aug 1 02:00:41 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:00:41 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:00:41 zcip client: configured 169.254.175.120
Aug 1 02:00:42 192.168.1.1 kernel: registering ipv6 ROUTE target
Aug 1 02:00:42 192.168.1.1 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug 1 02:00:43 WAN Connection: WAN was restored.

------ 3.0.0.4.380.3971-------------------------------------------------------------------
Aug 1 02:00:34 192.168.1.1 pppd[434]: PPP session is 2644 (0xa54)
Aug 1 02:00:34 192.168.1.1 pppd[434]: Connected to xx:xx:xx:xx:xx:xx via interface eth0
Aug 1 02:00:34 192.168.1.1 pppd[434]: Using interface ppp0
Aug 1 02:00:34 192.168.1.1 pppd[434]: Connect: ppp0 <--> eth0
Aug 1 02:00:37 192.168.1.1 pppd[434]: Remote message: Too many sessions^J
Aug 1 02:00:37 192.168.1.1 pppd[434]: PAP authentication failed
Aug 1 02:00:37 192.168.1.1 pppd[434]: Connection terminated.
Aug 1 02:00:37 192.168.1.1 pppd[434]: Sent PADT
Aug 1 02:00:41 192.168.1.1 rc_service: zcip 560:notify_rc start_firewall
Aug 1 02:00:41 192.168.1.1 dnsmasq[385]: read /etc/hosts - 6 addresses
Aug 1 02:00:41 192.168.1.1 dnsmasq-dhcp[385]: read /etc/ethers - 2 addresses
Aug 1 02:00:41 zcip client: configured 169.254.175.120
Aug 1 02:00:42 192.168.1.1 kernel: registering ipv6 ROUTE target
Aug 1 02:00:42 192.168.1.1 start_nat_rules: apply the nat_rules(/tmp/nat_rules__eth0)!
Aug 1 02:00:42 192.168.1.1 kernel: nf_conntrack_rtsp v0.6.21 loading
Aug 1 02:00:42 192.168.1.1 kernel: nf_nat_rtsp v0.6.21 loading
Aug 1 02:00:46 192.168.1.1 stop_nat_rules: apply the redirect_rules!
Aug 1 02:00:47 192.168.1.1 pppd[434]: PPP session is 2387 (0x953)
Aug 1 02:00:47 192.168.1.1 pppd[434]: Connected to xx:xx:xx:xx:xx:xx via interface eth0
Aug 1 02:00:47 192.168.1.1 pppd[434]: Using interface ppp0
Aug 1 02:00:47 192.168.1.1 pppd[434]: Connect: ppp0 <--> eth0
Aug 1 02:00:50 192.168.1.1 pppd[434]: Remote message: Too many sessions^J
Aug 1 02:00:50 192.168.1.1 pppd[434]: PAP authentication failed
Aug 1 02:00:50 192.168.1.1 pppd[434]: Connection terminated.
Aug 1 02:00:50 192.168.1.1 pppd[434]: Sent PADT
Aug 1 02:01:00 192.168.1.1 pppd[434]: PPP session is 3974 (0xf86)
Aug 1 02:01:00 192.168.1.1 pppd[434]: Connected to xx:xx:xx:xx:xx:xx via interface eth0
Aug 1 02:01:00 192.168.1.1 pppd[434]: Using interface ppp0
Aug 1 02:01:00 192.168.1.1 pppd[434]: Connect: ppp0 <--> eth0
Aug 1 02:01:03 192.168.1.1 pppd[434]: PAP authentication succeeded
Aug 1 02:01:03 192.168.1.1 pppd[434]: peer from calling number xx:xx:xx:xx:xx:xx authorized
Aug 1 02:01:03 192.168.1.1 pppd[434]: local LL address fe80::3d20:xxxx:xxxx:xxxx
Aug 1 02:01:03 192.168.1.1 pppd[434]: remote LL address fe80::2c5b:xxxx:xxxx:xxxx
Aug 1 02:01:03 192.168.1.1 pppd[434]: local IP address xx.xx.xx.xx
Aug 1 02:01:03 192.168.1.1 pppd[434]: remote IP address xx.xx.xx.xx
Aug 1 02:01:03 192.168.1.1 pppd[434]: primary DNS address xx.xx.xx.xx
Aug 1 02:01:03 192.168.1.1 pppd[434]: secondary DNS address xx.xx.xx.xx
Aug 1 02:01:03 192.168.1.1 rc_service: ip-up 624:notify_rc start_firewall
Aug 1 02:01:03 192.168.1.1 dnsmasq[385]: read /etc/hosts - 6 addresses
Aug 1 02:01:03 192.168.1.1 dnsmasq-dhcp[385]: read /etc/ethers - 2 addresses
Aug 1 02:01:03 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:01:03 192.168.1.1 dnsmasq[385]: using nameserver xx.xx.xx.xx#53
Aug 1 02:01:05 192.168.1.1 wan: finish adding multi routes
Aug 1 02:01:05 192.168.1.1 rc_service: ip-up 624:notify_rc stop_upnp
Aug 1 02:01:05 192.168.1.1 rc_service: waitting "start_firewall" via ip-up ...
Aug 1 02:01:05 192.168.1.1 kernel: registering ipv6 ROUTE target
Aug 1 02:01:05 192.168.1.1 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug 1 02:01:06 192.168.1.1 rc_service: ip-up 624:notify_rc start_upnp
Aug 1 02:01:06 192.168.1.1 rc_service: waitting "stop_upnp" via ip-up ...
Aug 1 02:01:08 WAN Connection: DNS probe failed (0/2)
Aug 1 02:01:08 WAN Connection: WAN was restored.
Aug 1 02:01:13 WAN Connection: DNS probe succeeded (1/2)

[ Szerkesztve ]

Ez a DNS hibaüzenet nekem fw frissítés után jött és valahol azt olvastam, hogy az új fw-ben alapból bekapcsolt ipv6 miatt lehet. (az ezelőtti fw-ről írták)

Sziasztok!

29. nap szerviz idő után kaptam az üzenetet az üzletből, ahová visszavittem a routert, hogy menjek be. Felajánlották, hogy levásárolhatom vagy visszaadják a vételárat. Annyit lehet, tudni, hogy az Asus vissza sem küldte a készüléket. "2- 5 naponta újraindul." hibával lett leadva javításra. Nálam 5 napnál tovább nem bírta egy huzamban. Visszakértem a pénzt. Még nem tudom milyen routert veszek helyette, hasonló tudásban/árban.

(Megjegyzés: Amíg az Asus RT-AC1200G+ szervizben volt, kénytelen voltam venni egy másik routert. Az Asus RT-N12+ lett a választás. Tudom, más kategória, de valamit használni kellett. Ma 30 napja megy folyamatosan.)

Kitartást kívánok a Asus RT-AC1200G+ tulajdonosoknak!

Üdv Joe

Most is ipv6-on van és már a legújabbal nem csinálja, de ezt olvastam én is és igazából senki nem tudja az okát, már az ms dns-től kezdve mindent írogatnak mindenhol, de ez össz asus betegség.
Volt egy hét mikor azt hittem, hogy az ipv6 miatt kattan meg mert teszteltem egyszer egy d-link 860L-t azt pl az nyírta ki sőt meg is fektette a cpu-t így ha valaki ipv6-t is akar d-linknek azt a verzióját nem ajánlom , de ebben csak ipv4-el is benn volt a dns hiba, így az ipv6 bekavarást kizárnám.
Most úgy tűnik ok minden a legfrissebbel, a dchp kéréseken és a fűzfal bejegyzésen kívül semmi nincs még a logszerón, én remélem, hogy most már tényleg rendben lesz.

Ma reggel én is feltettem a legújabbat, ugyanis a 3971-es 11 nap után megadta magát No, nem indult újra csupán csak reggelre nem volt netem, se wifi se kábel se semmi. Restartolni kellett, úgy volt, de akkor már egyben feltettem a legújabb softot. Érdekes még, hogy kb. 2 naponta új IP-t kaptam pedig a router nem indult újra, pedig ez csak akkor van.

Egyébként jó ez az ipv6, érdemes használni? (DIGI) Azt sem tudom, hogy működik egyébként.

[ Szerkesztve ]

i11 White 64GB, AirPods 2, Lumix GX7

Egyenlőre még annyira nem szükséges az IPv6 használata de idővel az lesz.

Egy dolog állandó: a változás - Internet powered by Vodafone Internet 150 with CBN CH7465VF & Asus RT-AC65P

Nekem naponta kérte az új ip-t a digi-től, pedig hetente újítanak, de mióta az új van még mindig az indulás kori ip van benne, szal azért mondom, hogy nagyon nagyon bízom benne,hogy sikerült rendbe rakni

Ipv6-bekepcsolhatod, semmilyen hátrányt, nem fogysz érezni, sőt vannak oldalak ahol javul, gyorsabban eléred, javul a ping kevesebb a hope. Ráadásul biztonságosabb is, végpontól végpontig titkosítás használható, 4-nél ezi inkább vpn-el kell elérni de utólag belekerül ez a "funkció".
A face, full ipv6, a google szolgáltatásai, youtube szintén, sőt nco..-is kivéve a torrentek, magyarországon még nincs ipv6 tracker.
Én főleg munka és tesztelés miatt használom, és mert miért ne
apple termékek már régóta, andoid 4.4-tól biztosan tudja, windows szintén, én azt mondom használd.
Dual stack-ben megy, így nem lesz bajod ha egy oldal csak ipv4 képes, de ha elérhető akkor a 6-t a priorizált.
A diginél így tudod beállítani.

[ Szerkesztve ]

Nincs mit, azért van a fórum

Aug 18 12:50:05 miniupnpd[683]: upnp_event_recv: recv(): Connection reset by peer
Aug 1 02:00:09 syslogd started: BusyBox v1.17.4
...
Aug 1 02:01:11 ntp: start NTP update
Nov 15 02:21:24 rc_service: ntp 674:notify_rc restart_upnp

Ez 3 és fél hónapi folyamatos üzemet jelent?
(Minden újrainduláskor aug.1-re teszi a dátumot, majd kb egy perc működés után szinkronizálja azt) Ezt tegnap tegnap előtt néztem meg, amikor belefutottam ebbe a fórumba, és láttam az újraindulásos problémákat.

Igen mikor újra indul, aug 1 az "alapértelmezett" idő, majd mikor feláll a kapcsolat a wan-oldalon lerántja ntp-n a pontos időt, azért látod ezt az eltérést. ez nem jelent 3,5 hónap üzemidőt.
Tedd fel a mostani legújabb firmet, hát ha megszünek az újraindulások is.
Az upnp-t meg kapcsold ki a francba nyiss kézzel portot ha kell.
3.0.0.4.380.4089

[ Szerkesztve ]

Így sem?
A log szerint nem történt semmi aug. 18. -tól a november 15-i újraindulásig...

Aug 14 23:02:29 disk_monitor: Got SIGALRM...
Aug 15 07:53:48 miniupnpd[683]: upnp_event_recv: recv(): Connection reset by peer
Aug 17 12:07:32 miniupnpd[683]: upnp_event_recv: recv(): Connection reset by peer
Aug 18 10:36:52 miniupnpd[683]: HTTP Connection from 192.168.143.112 closed unexpectedly
Aug 18 12:50:05 miniupnpd[683]: upnp_event_recv: recv(): Connection reset by peer
Aug 1 02:00:09 syslogd started: BusyBox v1.17.4
Aug 1 02:00:09 kernel: klogd started: BusyBox v1.17.4 (2015-12-01 09:54:59 CST)
Aug 1 02:00:09 kernel: Linux version 2.6.36.4brcmarm (gitserv_asus@wireless-pub1) (gcc version 4.5.3 (Buildroot 2012.02) ) #1 PREEMPT Tue Dec 1 10:04:01 CST 2015
Aug 1 02:00:09 kernel: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7f
Aug 1 02:00:09 kernel: CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Aug 1 02:00:09 kernel: Machine: Northstar Prototype
Aug 1 02:00:09 kernel: Ignoring unrecognised tag 0x00000000
Aug 1 02:00:09 kernel: Memory policy: ECC disabled, Data cache writealloc
Aug 1 02:00:09 kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Aug 1 02:00:09 kernel: Kernel command line: root=/dev/mtdblock2 console=ttyS0,115200 init=/sbin/preinit earlyprintk debug
Aug 1 02:00:09 kernel: Memory: 125488k/125488k available, 5584k reserved, 0K highmem
Aug 1 02:00:09 kernel: Virtual kernel memory layout:
Aug 1 02:00:09 kernel: vector : 0xffff0000 - 0xffff1000 ( 4 kB)
Aug 1 02:00:09 kernel: fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
Aug 1 02:00:09 kernel: DMA : 0xf7e00000 - 0xffe00000 ( 128 MB)
Aug 1 02:00:09 kernel: vmalloc : 0x88800000 - 0xf0000000 (1656 MB)
Aug 1 02:00:09 kernel: lowmem : 0x80000000 - 0x88000000 ( 128 MB)
Aug 1 02:00:09 kernel: modules : 0x7f000000 - 0x80000000 ( 16 MB)
Aug 1 02:00:09 kernel: .init : 0x80008000 - 0x80038000 ( 192 kB)
Aug 1 02:00:09 kernel: .text : 0x80038000 - 0x803e3000 (3756 kB)
Aug 1 02:00:09 kernel: .data : 0x803fc000 - 0x8041ef40 ( 140 kB)
Aug 1 02:00:09 kernel: Mount-cache hash table entries: 512
Aug 1 02:00:10 kernel: Found ST compatible serial flash with 256 64KB blocks; total size 16MB
Aug 1 02:00:10 kernel: ACP (Accelerator Coherence Port) enabled
Aug 1 02:00:10 kernel: bio: create slab <bio-0> at 0
Aug 1 02:00:10 kernel: PCI: no core
Aug 1 02:00:10 kernel: PCI: no core
Aug 1 02:00:10 kernel: PCI: Fixing up bus 0
Aug 1 02:00:10 kernel: PCI: Fixing up bus 1
Aug 1 02:00:10 kernel: PCI: scanning bus 0 !!!
Aug 1 02:00:10 kernel: PCI: Fixing up bus 0
Aug 1 02:00:10 kernel: VFS: Disk quotas dquot_6.5.2
Aug 1 02:00:10 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Aug 1 02:00:10 kernel: pflash: found no supported devices
Aug 1 02:00:10 kernel: bcmsflash: squash filesystem found at block 30
Aug 1 02:00:10 kernel: Creating 5 MTD partitions on "bcmsflash":
Aug 1 02:00:10 kernel: 0x000000000000-0x000000040000 : "boot"
Aug 1 02:00:10 kernel: 0x000000040000-0x000000ff0000 : "linux"
Aug 1 02:00:10 kernel: 0x0000001ef214-0x000000dc0000 : "rootfs"
Aug 1 02:00:10 kernel: 0x000000dc0000-0x000000ff0000 : "jffs2"
Aug 1 02:00:10 kernel: 0x000000ff0000-0x000001000000 : "nvram"
Aug 1 02:00:10 kernel: === PPTP init ===
Aug 1 02:00:10 kernel: Registering the dns_resolver key type
Aug 1 02:00:10 kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Aug 1 02:00:10 kernel: ctf: module license 'Proprietary' taints kernel.
Aug 1 02:00:10 kernel: Disabling lock debugging due to kernel taint
Aug 1 02:00:10 kernel: et_module_init: passivemode set to 0x0
Aug 1 02:00:10 kernel: et_module_init: txworkq set to 0x1
Aug 1 02:00:10 kernel: et_module_init: et_txq_thresh set to 0xce4
Aug 1 02:00:11 kernel: et_module_init: et_rxlazy_timeout set to 0x3e8
Aug 1 02:00:11 kernel: et_module_init: et_rxlazy_framecnt set to 0x20
Aug 1 02:00:11 kernel: bcm_robo_enable_switch: EEE is disabled
Aug 1 02:00:11 kernel: eth0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 9.10.178.27 (r584393)
Aug 1 02:00:11 kernel: wl_module_init: passivemode set to 0x0
Aug 1 02:00:11 kernel: wl_module_init: txworkq set to 0x1
Aug 1 02:00:11 kernel: PCI: Enabling device 0001:01:00.0 (0140 -> 0142)
Aug 1 02:00:11 kernel: eth1: Broadcom BCM43227 802.11 Wireless Controller 9.10.178.27 (r584393)
Aug 1 02:00:11 kernel: External imprecise Data abort at addr=0x2ae44004, fsr=0x1c06, pc=0x2aadf7a0 lr=0x2ad0c16c ignored.
Aug 1 02:00:11 kernel: eth2: Broadcom BCM43c8 802.11 Wireless Controller 9.10.178.27 (r584393)
Aug 1 02:00:11 stop_nat_rules: apply the redirect_rules!
Aug 1 02:00:11 WAN Connection: Fail to connect with some issues.
Aug 1 02:00:18 dnsmasq[382]: warning: interface ppp1* does not currently exist
Aug 1 02:00:18 RT-AC1200G+: start httpd
Aug 1 02:00:19 disk monitor: be idle
Aug 1 02:00:19 miniupnpd[414]: version 1.9 started
Aug 1 02:00:19 miniupnpd[414]: HTTP listening on port 41570
Aug 1 02:00:19 miniupnpd[414]: Listening for NAT-PMP/PCP traffic on port 5351
Aug 1 02:00:19 hour monitor: daemon is starting
Aug 1 02:00:19 syslog: Generating SSL certificate...
Aug 1 02:00:20 pppd[428]: pppd 2.4.7 started by drparoczai, uid 0
Aug 1 02:00:20 pppd[428]: Connected to 00:25:90:e3:dc:e7 via interface eth0
Aug 1 02:00:20 pppd[428]: Connect: ppp0 <--> eth0
Aug 1 02:00:20 syslog: module ledtrig-usbdev not found in modules.dep
Aug 1 02:00:20 syslog: module leds-usb not found in modules.dep
Aug 1 02:00:21 kernel: SCSI subsystem initialized
Aug 1 02:00:23 pppd[428]: PAP authentication failed
Aug 1 02:00:23 pppd[428]: Connection terminated.
Aug 1 02:00:33 pppd[428]: Connected to 00:25:90:e3:dc:e7 via interface eth0
Aug 1 02:00:33 pppd[428]: Connect: ppp0 <--> eth0
Aug 1 02:00:36 pppd[428]: PAP authentication failed
Aug 1 02:00:36 pppd[428]: Connection terminated.
Aug 1 02:00:41 rc_service: zcip 565:notify_rc start_firewall
Aug 1 02:00:41 zcip client: configured 169.254.45.77
Aug 1 02:00:42 start_nat_rules: apply the nat_rules(/tmp/nat_rules__eth0)!
Aug 1 02:00:43 kernel: nf_conntrack_rtsp v0.6.21 loading
Aug 1 02:00:43 kernel: nf_nat_rtsp v0.6.21 loading
Aug 1 02:00:46 pppd[428]: Connected to 00:25:90:e3:dc:e7 via interface eth0
Aug 1 02:00:46 pppd[428]: Connect: ppp0 <--> eth0
Aug 1 02:00:49 pppd[428]: PAP authentication failed
Aug 1 02:00:49 pppd[428]: Connection terminated.
Aug 1 02:01:00 pppd[428]: Connected to 00:25:90:e3:dc:e7 via interface eth0
Aug 1 02:01:00 pppd[428]: Connect: ppp0 <--> eth0
Aug 1 02:01:03 pppd[428]: PAP authentication succeeded
Aug 1 02:01:03 pppd[428]: peer from calling number 00:25:90:E3C:E7 authorized
Aug 1 02:01:03 pppd[428]: local IP address 178.164.193.226
Aug 1 02:01:03 pppd[428]: remote IP address 10.0.0.1
Aug 1 02:01:03 pppd[428]: primary DNS address 193.110.56.8
Aug 1 02:01:03 pppd[428]: secondary DNS address 193.110.57.4
Aug 1 02:01:03 rc_service: ip-up 626:notify_rc start_firewall
Aug 1 02:01:04 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Aug 1 02:01:04 wan: finish adding multi routes
Aug 1 02:01:05 WAN Connection: WAN was restored.
Aug 1 02:01:09 rc_service: ip-up 626:notify_rc stop_upnp
Aug 1 02:01:09 rc_service: ip-up 626:notify_rc start_upnp
Aug 1 02:01:09 rc_service: waitting "stop_upnp" via ip-up ...
Aug 1 02:01:09 miniupnpd[414]: shutting down MiniUPnPd
Aug 1 02:01:11 miniupnpd[675]: version 1.9 started
Aug 1 02:01:11 miniupnpd[675]: HTTP listening on port 33799
Aug 1 02:01:11 miniupnpd[675]: Listening for NAT-PMP/PCP traffic on port 5351
Aug 1 02:01:11 ntp: start NTP update
Nov 15 02:21:24 rc_service: ntp 674:notify_rc restart_upnp

Most ezt nem tudom mitől van, de a legújabb fw-n nem mennek át a portok, hiába nyitok manuálisan és ha be van pipálva az upnp, akkor sem. Eddig ilyen gondom nem volt Nem értem.

[ Szerkesztve ]

i11 White 64GB, AirPods 2, Lumix GX7

de az aug. 1 előtt ott volt a 18 is. sztem jó lehet az

A legrégebbi 3.0.0.4.380.1234 fw. van fent.

Nekem nincs port átirányítás hiba minden fasza, most is a cégtől írok, ssh tunelen a saját netemen keresztül .
Jó ip-hez van rendelve a port ? esetleg az eszköz azt az ip-t kapja vissza?
Érdemes dhcp reservation-t beállítani, így az adott mac-hez mindig az az ip kerül vissza
Nyomj neki egy restore-t és állítsd vissza kézzel mindent, ha van mentésed régebbről azt ne rakd fel.

[ Szerkesztve ]

Valóban, így már érthető a dolog
Így már meg lehet a 3,5 hónap, kivéve ha baszott logolni a többit
De akárhogy is volt, gratula az eredményért.
Ilyet mindenkinek

Igen ez lesz ha hazamegyek, ugyanis eddig még nem volt restore egyszer sem.

i11 White 64GB, AirPods 2, Lumix GX7

Ja, viszont rossz volt a matekom, nincs az csak majdnem három hónap... Azelőtt viszont májustól 1,2,3,5 naponként rendszeresen újraindult. kíváncsi vagyok a folytatásra, de egyelőre még nem akarom frissíteni

A port forward alapfeltétele a fix-ált IP cím, ennek a legideálisabb megoldása a kliens eszköz MAC címe alapján történő beállítás.

Egy dolog állandó: a változás - Internet powered by Vodafone Internet 150 with CBN CH7465VF & Asus RT-AC65P

Hálózatos voltam, nekem ez nem újdonság, én úgy is használom
Amúgy nem alapfeltétel, és nem is biztos, hogy ugrik a hozzárendelt ip, mert általában a dhcp ugyan azt adja vissza ugyan abban a hálózatban, ha lehetséges, és nincs máshogy bekonfigolva. (pl nekem a telefonom kezdetek óta ugyan azt kapja vissza).
Inkább azt mondanám, hogy erősen ajánlott.
De pont ugyan azt írtam amit te most nekem.
Szépen megfogalmazva (dhcp reservation)

[ Szerkesztve ]

A héten sem jelentkeztek a rúterrel kapcsolatban, így több mint egy hónapja oda van.
Ennek annyi előnye van, hogy rá tudok kérdezni:
a legújabb fw-el indult már újra valakinek?

Tizen-sok nap után újraindult, 4 nappal ezelőtt.
Most vettem észre, sok vizet nem zavart.
3.0.0.4.380_3971
FW frissítéssel kivárom a következő újraindulást.

Sziasztok! Ma vettem egy ilyen routert.
Van új firmware:
http://www.asus.com/Networking/RT-AC1200G-plus/HelpDesk_Download/

A Traffic Manager-t elrontották, a Yandex.DNS szűrés nem működik, a Firmware Version Check sem működik, kicsit olyan barkács hangulata van,