Recent content by MaziahBebop

Thanks for everything you do Sir Merlin. Sent a quick tip via PayPal.

60 days achievement unlocked. Thunderstorm at 57 days was almost enough to make me pull the plug though.

Hi @SomeWhereOverTheRainBow, yes agreed, pretty much exactly what dave14305 mentioned further up too. My question now is... if I am seeing a duplicated request (one coming from the router MAC and one from the TV MAC with the same time-stamps), can I safely ignore this. I was actually happy to...

Ax88u + pi-hole with unbound. I see the dual requests from one connected client, my LG TV. I had not noticed it until reading this thread, which prompted me to search the pi-hole logs for requests from the router, and sure enough, a whole bunch of requests from the router matching the timestamps...

Try using 192.168.50.1 (not router.asus.com).

I think what is being said is.... to achieve this: Do this:

I thought the same initially but upon closer reading this won't work, because the 192.168.0.100 ip is the ip of the Asus router. @ColinTaylor 's solution looks like the best way forward I think.

As per @fg64, 47 days uptime at this moment. Open VPN server and clients running all the time. Ram usage steady on 50%. Ax88u and .19 appear to be good together.

Sorry to be harping on about temperature every time I post in this thread, just for my own satisfaction I hope someone here can correct my thoughts on this: My assumptions were that the Broadcom chip in the ac88u was Cortext A9 based, with a rated range up to 85°C. 87°C in the screen shot is...

When using channels 100-128, your service can be interrupted by radar signals (weather radar, etc). See here (link). I'm not saying this is your problem, but its a problem worth looking into, because it can result in your router switching to a different channel, even when you set the channel...

Radar detected overnight? Would be interested in knowing how the Asus routers handle that occurrence. From blog post elsewhere: " In some solutions, APs that detect radar will move to channel 36 exclusively. In other solutions, APs will choose to move to any of the available non-DFS channels...

With the 4 Ds in mind (Do it now, Do it later, Delegate it, or Dump it), is the github clearing issues task something you could delegate to a community member? I mean, there must be someone who is (a) motivated to help, (b) able to help, and (c) trusted to not stuff it up. Just an idea anyways!

Can you repost a new screenshot of the recent errors in the log?

After reading your replies, and some of the logs, here is my suggestion: Download a fresh ovpn file from Proton. Check that you're downloading the correct ovpn file (it's for routers) Don't edit the file Upload the fresh ovpn to the router. Don't edit any settings in your router VPN client...

Also using ProtonVPN. Almost zero connectivity issues. My conf also straight from their dashboard: # ============================================================================== client dev tun proto tcp remote <--snip--> 443 remote <--snip--> 5995 remote <--snip--> 8443 remote-random...