Where was this mentioned? I have never heard this in the past, and it seems unlikely unless the SSH password was never changed and the device is directly connected to the internet, but am curious.
hello raychu,
after much head-scratching, we have a suspicion as to what could be going on here. in your problem description, of particular note is the part where you say that the units are installed in remote locations. and you didnât say so, but i assume that the computer where you are running the FE config app is local? meaning that communications between your browser and the Shakes happens across a network where there are possibly routers and firewalls involved?
when this is the case, there are two ports through which traffic must be able to flow:
- 8765
- 8766
one is used for the keepalive signal, while the other is used to transport the live data displayed on the home screen.
please confirm the following:
- any and all firewalls that may exist, between the computer where you run the FE app and the Shakes you need to access, have been configured to allow all traffic to pass through the two ports listed above, in both directions.
once this has been done, please report back the effect, if any, on how the FE app behaves.
thanks in advance,
richard
hi Seizmolog,
i have replied to raychuâs post regarding the problem of the FE app âgoing downâ, it can be found here.
can you also please confirm any firewall / router settings which may be coming into play?
cheers,
richard
Hi Richard,
Sorry I didnât see you response, apologies.
My case is this one too : shake & jam are connected on the net through a LTE router, and all input traffic is deny, unless some from specific IP address. Let me try to open ports you mentioned, Iâll give you feedback soon.
1 Like
Hi ivor,
Thanks for your suggestion. The browser page now works very well after I modified my port fowarding settings in the router connected to my Shake.
By the way, I am not sure if I need to be concerned about network risks due to the disclosure these two specific ports. Do you have any suggestions for avoiding hecker intrusion?
Best, Ray
We went to one of the locations yesterday and the interface worked fine locally but not remotely. If this is the case, it would involve a lot of work to open two additional ports for 12 devices at our national school internet service provider.
The ports we usually open with our provider are as follows:
- 380 permit tcp host [deleted] host [deleted] eq 22
- 390 permit tcp host [deleted] host [deleted] eq www
- 400 permit tcp host [deleted] host [deleted] eq 18000
Which worked fine with the old web interface.
@Seizmolog, @raychu, @benjamin.vial
thank you all for your feedback, it has been very helpful.
what we now know:
- access from
rs.localto remotely located shakes requires port-forwarding to be enabled on the shake-side router, and / or firewall settings to be reconfigured - in some cases, this can be a non-trivial requirement, making the new
rs.localpotentially unusable
because of this, we are looking to re-work the solution to NOT use these two ports, thus alleviating the need to reconfigure routers and / or firewalls. this new solution will be provided in the upcoming patch release V21.1.
thanks again for your cooperation in helping us identify the exact nature of the problem.
warm regards,
richard
Another issue with v21. When I add datacast clients, the last one is not saved. As such, in order to add my two clients, I have to add a dummy third and the first two are saved.
To duplicate this issue:
-
Add two clients. Note that the second client is not receiving UDP packets. (Or just do a browser refresh and note that the 2nd client has disappeared. Or just look at the two config files, only the first client is saved).
-
Try again to add that 2nd client. Note the same as above.
-
Add the 2nd client and a dummy third client. Note that the second is now saved.
hello @jkline,
thanks for the report and the details, always appreciated.
this is a known issue and has been fixed, to be provided in patch release 21.1.
cheers,
richard