Recent content by JackJack

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

  1. J

    asuscomm.com

    looks like you have some issues with certificate.... try setting to automatic and see if it works
  2. J

    DDNS, AX86U-PRO, inadyn isn't called after wan IP change ?

    To resolve I had to use: cru a dynpatch "*/5 * * * * /usr/sbin/inadyn --once" every 5 minutes it call inadyn service. It's soft on DDNS side as it actually call server for update only if ip get changed. As IP is buffered and checked internally in the router before deciding it need update...
  3. J

    DDNS, AX86U-PRO, inadyn isn't called after wan IP change ?

    I've made another test.... Disconnected WAN cable Instead of using UI to disable/enable WAN. Router recognize disconnection (logs and in UI "internet status" as diconnected..... And recognize correctly when WAN is up again and show correctly new assigned IP (if it changes). But DDNS inadyn...
  4. J

    DDNS, AX86U-PRO, inadyn isn't called after wan IP change ?

    Yes, it does change (verfied on logs and on router UI and from external web services) Fact that ASUS router show new correct IP also means that it doesn't only get new ip, but it recognize it and get it. (not a semple new IP under a GNAT service for a simple speak... in those caases I know that...
  5. J

    DDNS, AX86U-PRO, inadyn isn't called after wan IP change ?

    DDNS at first works as expected and record is registered on asuscomm.com Problem arise when you go manually to network-map (first menu on left) and select "internet status" and apply for a switch off of "internet connection". Wait for changed to apply.... and then back to "on" to restore wan...
  6. J

    Traffic spike fix from 384.14_2 was reverted in 386.1

    I've started to use vnStat (entware) and this software can calculate traffic as expected and isn't influenced by those spikes. So it's not a kernel issue. On my setup those spikes can be easily reproduced by turning off WAN and then back online. Doing so there's high probability (more than 50%)...
  7. J

    Traffic spike fix from 384.14_2 was reverted in 386.1

    Using 386.2_6 on a RT-AC86U Found how to recreate spike issue. Since a few releases, those spikes are few and probably I've found a scenario where there's a high probability to recreate a spike. Early 386.x firmiwares, all you had to do for those spikes was just waiting (usually few minutes)...
Top