Hi, not sure which release caused this bug because I skipped a few releases. With 27 B1 however, accessing the web interface on my M2 behind a router through a nonstandard port doesn’t work anymore with all the configuration items. You should be able to test this and find the offending code.
Thanks!
Hi @sbm,
May I ask you to elaborate on your setup in a bit more detail? It will help me get a full picture if you describe how you accessed the Reach M2 page in the Reach Panel earlier and at which step you face difficulties now.
Sure. I have setup my m2 on the LAN but in order to access it from WAN to use RTK I have mapped several ports on the router. Obviously there is a tcp port for the RTK data, then there is a tcp port for the the web interface, typically port 80 for http. I do not want to use port 80 because of conflicts and security, so I choose a nonstandard port like 9572 or whatever. This has previously worked fine. I map port 9572 on the WAN side of the router to port 80 on the internal ip of the M2 and I can configure it remotely. This solution no longer works unless I use port 80 on WAN. If I use any nonstandard port on the WAN most of the important settings are no longer functional. I can vew status etc, but many of the items are not functional.
Without investigating, my hunch is that there is code on the web interface that is basically hardcoding the port into a data request instead of using a relative path.
Hi @sbm,
Could you please clarify whether your setup requires root access to the receiver? Also, it would be of great help if you can tell me the firmware version installed on the unit before the update.
I do not want to use port 80 because of conflicts and security
May I ask you to tell me how using the nonstandard port should lead to fewer conflicts and better security in your setup? Usually, we recommend working with the ReachView 3 app to connect to the receivers, and such a setup works fine for most of our users’ applications. If we understand why you would like to use a nonstandard port instead, it will help us check which suitable options we can suggest.
Hi @kseniia.suzdaltseva,
I think I upgraded from 2.24.2 dev.
I am accessing my unit remotely and I have another service running on http port 80 on that public IP. Also, obscuring the port reduces random hits from bad actors while the unit is accessible. When accessing the device on a public IP over the internet, it is not possible to use reachview 3, but I am happy to use the web interface from a regular web browser.
I hope this isn’t an indication that you are deprecating the web interface in favor of an app.
Practical application - I don’t want the m2 to log constantly, but I don’t want to go the building where it is located to turn on the logging. I simply access remotely over the internet to turn logging on before I begin a survey.
Hi @sbm,
Thanks for the clarification.
I hope this isn’t an indication that you are deprecating the web interface in favor of an app.
Usually, we recommend our users to work with the ReachView 3 app since it has different coordinate systems support and other new features. Nevertheless, we still support the Reach Panel web interface.
Our apps don’t provide any ready-to-use solutions for remote access to Reach M2 receivers. As you said, it should be possible to reach the web interface via the 80 port. Changing the port to a nonstandard one requires a custom setup, so we can hardly say for sure what might go wrong in this case.
This bug still exists in Reach Firmware 27 Beta2
Hi @sbm,
Our apps don’t provide options for remote connection to Reach M2 devices. It isn’t a bug, but just the way our software works.
We can confirm that we didn’t change anything regarding ports routing. Since Reach Panel is not suited for the remote connection to receivers, we can hardly check what might go wrong if you connect to Reach remotely via a nonstandard port.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.