you are on docsis 3.1 with rogers going mid split for the increase in uploads. That is not docsis 4.0 the only north american providers that have it are comcast and I think that is still in a testing phase.Those are the right speeds - 2Gbps down, 200Mbps up. It's still the old coax/cable system here - still got the old XB7 modem. No fibre in our area at all for either Rogers or Bell. This must be DOCSIS 4.0 then I'd guess? They've been promoting "higher" upload speeds in our area recently.
There was an offer on my Rogers account for a bundle of Rogers Pro 2G Internet, Rogers Ultimate TV and Rogers Home Phone for $185/month, which was like $10/month less than I was already paying for the 1.5G service and all the same stuff so I "upgraded" to it, save $10/month and get the better upload speeds.
It’s DOCSIS 3.1
Companies started upgrading equipment last year in the US and I presume Canada.
Standard has been available for many years with modems available 5+ years ago… but internet companies are slooow.
Nice. Was not sure if DOCSIS 3.1 supported those speeds but a quick google says it does. Support for up to 10Gbps downstream and 1Gbps upstream. Let's GO! I know Rogers has been testing DOCSIS 4.0... but that would likely need a new modem on my end as well.
And yes, these companies move at a glacier pace when it comes to upgrades.
Aug 5 09:25:22 wlceventd: wlceventd_validate_message(249): subtype: event
Aug 5 09:25:22 wlceventd: wlceventd_proc_event(752): eth6: Probe-req from 50:XX:XX:XX:XX
Aug 5 09:25:22 wlceventd: dump_data(277): dump data (86) 40 00 00 00 FF FF FF FF FF FF 50 XX XX XX XX D6 FF FF FF FF FF FF...
Aug 5 09:25:22 wlceventd: wlceventd_proc_socket(997): Done Local Event
Aug 5 09:25:22 wlceventd: wlceventd_proc_socket(993): Recv Local event: 176
Aug 5 09:25:22 wlceventd: wlceventd_proc_event(616): recved 176 bytes from eventfd, ifname: eth6
Aug 5 09:25:22 wlceventd: wlceventd_validate_message(249): subtype: event
Aug 5 09:25:22 wlceventd: wlceventd_proc_event(752): eth6: Probe-req from 50:XX:XX:XX:XX
Aug 5 09:25:22 wlceventd: dump_data(277): dump data (86) 40 00 00 00 FF FF FF FF FF FF 50 XX XX XX XX D6 FF FF FF FF FF FF...
Aug 5 09:25:22 wlceventd: wlceventd_proc_socket(997): Done Local Event
Aug 5 09:25:22 wlceventd: wlceventd_proc_socket(978): No event
Aug 5 09:25:22 wlceventd: main(1246): ticks: 234286
Aug 5 09:25:23 wlceventd: wlceventd_proc_socket(993): Recv Local event: 226
Aug 5 09:25:23 wlceventd: wlceventd_proc_event(616): recved 226 bytes from eventfd, ifname: eth6
With this 2nd firmware update rolled out now 8_2 do we have a rough idea time table wise to when we are likely to see MerlinWRT move over to MerlinWRT ART 5.0 (ASUS WRT 5) will this be end of 2024 Xmas Time or perhaps January 2025 looking ahead.
Hi Thanks for the reply it's Very much appreciated.Merlin has already moved over to Asus 5.0 but only for 2 BE models no other models are supported at this time. Good luck getting a answer on time lines, it's frowned upon here to even ask and often leads to being flamed.
Both @thatdoodle and you need to be more precise about how you've configured NGINX, and where it's running. Don't assume we should just know. It could be on the router, or internally on the LAN. It could be a proxy, or reverse proxy. It could be bound to the WAN, the LAN, or BOTH. Without such details, it's difficult to provide accurate answers or address your concerns.
My assumption w/ @thatdoodle was that he was running NGINX on the router and wanted it bound to the LAN (port 80), which is in conflict w/ the GUI. So he changed the GUI's LAN port to something else (e.g., 8080). And while that solved the problem, it came at the unexpected expense of having the GUI now running on the new port w/ HTTP, when he had specifically requested only HTTPS for the LAN authentication!
That's why I consider it a bug. Had he never needed port 80 for NGINX and simply wanted to limit LAN authentication to HTTPS, the router would NOT have bound the GUI to HTTP/80.
Now when it comes to the WAN side, the GUI is never bound to the WAN. If you enable remote access, then HTTPS is required and a port is opened (8443 by default, although you can change it), where the inbound traffic is redirected (via DNAT) to the GUI on the LAN side (port 80 by default, for http, or 8443, for https, unless you changed these for some reason).
In short, unless you're replicating @thatdoodle's configuration, there shouldn't be any issues w/ port forwarding or opening ports 80/443 on the WAN. At least NOT as far as the GUI is concerned (I can't speak to other services that might also find those same ports appealing, e.g., AiCloud).
For my use case, yes I have (and soon plan on again) run NGINX on the router as a reverse proxy to two web services (family Nextoud server and a website for our local Catholic church group) inside my LAN. As such, my interest is to ensure I can bind NGINX to port 80 and 443 on the WAN.
From the description above, it sounded like the issue was on the LAN side. I was just wanting to confirm my suspicions.
On the one hand, the OP has requested only HTTPS on the LAN side, yet HTTP has been made available over the new port. Then again, the LAN side is usually a trusted network. Then again, if the OP is trying to force the LAN clients through the NGINX proxy, it undermines his efforts.
So technically, I suppose it's a failure of security, but just how much of a failure it represents depends on the OP's intentions and security requirements.
Can see the details reported here:-When authentication set to BOTH instead of default http on a aimesh AP main node , one cannot access remote aimesh node. You have to set authentification to http before you can access Aimesh node.
Also, when Aimesh node led set to off, if there is a power cycle, the led will light up again despite the GUI indicating it’s set to off. This happen on the Aimesh node but not the Aimesh main router though.
Did you look at the syslog for clues as to what the router was having issues with?I lost internet WAN connection. I can reach the router just fine and the manual fw upgrade completed successfully, but I had no WAN connection.
reboot the router then tried updating to 388.8_2 again, still got same error. After this message I reboot the router firmware stays as old version (388.7)
View attachment 60699
Anyone got GT-AXE16000 updated to 388.8_2 ROG successfully?
Did you look at the syslog for clues as to what the router was having issues with?
Thanks for the reply - yes I did look at the log, but I'm not sure what I'm looking for. Attached is the syslog when I applied 388.8_2 and when the router rebooted. I have no idea why my log has random May 5 entries, but it has done that for many years and I've never been able to determine why. I may be overthinking this, but doesn't a Merlin firmware release usually follow an Asus firmware release? Asus's last fw release for the AX3000 was April 2024 which coincides with Merlin 388.7 (which works fine on my AX3000). There has been no firmware release for the AX3000 from Asus since April 2024, so perhaps 388.8 no longer supports the AX3000?Did you look at the syslog for clues as to what the router was having issues with?
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!