Recent content by Blkpanthr

That makes sense. thanks.

no, that would defeat the purpose of gaging the router throughput. I will never use a client connected directly to my gateway, so removing the router from the network chain for testing would be pointless as that's not a viable topology for me. this is getting severely off topic, lets move on.

Wired, directly to the router. Using a wireless client would introduce unnecessary latency...

from a desktop. with chrome. not sure what exactly you want here.

i ran both of those from a desktop client with chrome, not the router.

something wrong with that cloudfare test site. Ookla gives me 14ms 958/180 consistently over months That cloudflare site while more detailed, gives me 34.4ms 822/170

92u is on beta 2, no release until the bugs get worked out per Merlin....

92U on beta2. up 7 days. no issues (that im aware of)

turns out i was on beta1. the 92U was not in the initial batch of beta2 releases. it was uploaded 3 days ago and i never went back to check. dirty upgrade to beta2 fixed the 6hz not showing on the network map page.

Same on my BE92U. Not in network map, but shown on wireless log. wireless log says its connected multiteam (2) AX spec. only error in the console (chrome) is "clients.asp:1 Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist." pops up when i click on...

hmmm...it seems subnet routing has changed on the alphas. i used to have to use an ssh command to be able to add a route to my modems subnet (192.168.100.1) and it didnt survive reboot so i had to add it back everytime i updated or rebooted the device. Its no longer in the routing table, but i...

i seem to have the stuck wan ip renewal issue again. after messing with it for the day, nothing seemed to unstick it. multiple reboots of both the modem and the router, leaving everything off for a couple hours, restarting the wan service through SSH, etc. I found a bizarre way to force it...

i should have said an "additional" reboot. 1st being the flash itself.

i have found a second reboot after flash avoids this problem. I have noticed a cron issue within incorrect time/date sync in the logs corresponding with this. Im not sure if its related.

strange bug, but for the last 2 betas, once i flash the time doesnt get reset correctly after the reboot and it locks out the web login once the initial login is timed out. an additional reboot from SSH fixes it but odd... 92U ec 31 19:00:37 kernel: skb_free_task created successfully with...