RC-1216H Webpage connection

[Remote_Mike]

Hi
I am using the RC-1216H for controlling the SteppIR antenna via the SteppIR controller (DATA IN/DATA OUT interface).
If I am opening my webbrowser (IE or Google Chroma) I can access the webpage of the RC-1216H. But after a while (about 15 secs or so) the green Online LED on the webpage stops blinking and restars after a while. It seems that the RC-1216H looses the connection to my browser or the 1216H Webserver hangs up. How can that be???

Even with the WebSwitch 1216H I have the same problem. After I have connected the Webserver of the WebSwitch I am loosing the remote connection and I have to restart (reload or open the webpage again) the webpage.

It is really annyoing and I don't have any idea to solve that problem.
Thanks for your  help!
Mike

[Jan (Microbit)]

It seems to me that the network connection between your PC and the RC-1216H and/or 1216H is not working well, which then will cause "lost connection". The network connection needs to fast enough be able to deliver replies to the status requests sent by RC-1216H/1216H in order for the connection to stay active.

Do you experience delays at other times? For ex. when browsing other pages of the devices?

[Remote_Mike]

Dear Jan

Beside the RC1216H and Webswitch 1216H I am using the RRC-1258MkIIs which works pretty well.
I am loosing the connection to the RC1216H and Webswitch even when nothing other is on duty (no Ethernet traffic) on my remote site. That means the ADLS modem/router is in idle mode (1500kbps down/150kbps up).

I am under the impression that the Java-Script called by the RC1216H webpage produces some traffic jam due to timeouts. The Java Script calls a recursive function with timer settings (500ms, 1000ms). Could these timer settings (or timeout settings) cause the traffic jam and blocks my remote site router?
I do understand that the webpage caller (Source) sends every second a status request to the RC1216 (Destination) and counts up therefore the port number (Source port). But is it really necessary to do so every second for live status requests?

Thank you for your reply!

Kind regards
Mike

[Jan (Microbit)]

The word "live" in live status requests implies that the updates should ideally be instantly, so the one second timeout was chosen as a "compromise" giving a visual feedback which is not too slow making people think the system did not react to commands while still not overload both the device itself and the connection.

This subject was brought up elsewhere also and I got access to a system showing similar symptoms which led to some changes made in the Javascript in order to better handle situations with slow network responses. If you force a reload of the web page you should get the new script and then you can see if it behaves nicer. Still there will be a need for a network access with as low response times as possible.

[Remote_Mike]

Hi Jan

Thanks a lot for your support. I appreciate it very much!
Now it's a little bit better and my webpages get not blocked so often but I have still some trouble.
If I pinging my remote site (to my remote ADLS Modem) than I will get a reply time of about 33ms (with 32bytes packets). That seems to me pretty quick. Furthermore I have a continous data stream without timeouts even with larger ping packets (1000 bytes).

But as soon as I start the RC1216H (for SteppIR controlling) or the Webswitch 1216H (for Rotor controlling) after a certain time I get timeouts and the webpages of the RC1216H or Webswitch get disconnected and my ADSL router will be blocked. The ping time increases dramatically to >500ms per ping or I get even timeouts.
The data normally sent by RC1216H are just a few bytes (20 bytes to about 500 bytes per frame).

I just wondering if the latency times of the webservers of the RC1216H (or the Webswitch) are short enough to respond to the ACK- and SYN-packets? Respectively I am wondering if the refresh time (Timeouts) specified in the Java scripts are still to short.

Unfortunately I get also lots of TCP checksum errors if I am tracking the Ethernet packets with Wireshark. Formerly I disabled the TCP offload in the network settings and therefore I couldn't see the errors. Maybe this information helps.

Somtehing is still strange with the webservers and I would be very happy if we could solve my problem.

Thanks in advance.

Kind regards
Mike

[sm2o]

Check that the router has the latest firmware if it has Try to change the router, There are lot of bad routers out there, specially those which are comming from the ISP with the subscription, I doub't we can do anything just for your setup as it's OK in the rest of the world.

73 de mike

[Jan (Microbit)]

Remote_Mike:

I am still not convinced that this is a problem concerning the web servers of RC-1216H/1216H. The IP stack used is a well known stack which has worked well in almost every  case, so I do not think there are latency problems etc in it.

As for the Javascript timeouts the change I made was so that a new request is newer issued until the previous has got a reply. Doing so I figured that it would better adopt to slow responses.

What is strange is that your ADSL modems "chokes" by those periodically HTTP requests. It seems to me like Mike said that the router/modem isn't able to release its resources fast enough and so gets filled up by "lingering" requests.

[Remote_Mike]

Hi!

Finally I've found the problem!
The SteppIR webpage tries to send continuously some Ethernet packets to the remote webserver of the RC-1216H.
For some reasons the sending source port will be incremented for every packet.
Modern routers have a port scanning blocker (so called DoS protection). Unfortunately my remote router misinterprets the continuous flow of incrementing source port IP-packets as a DoS attack and blocked the traffic after a certain time. I had to disable the DoS protection of my remote router.
I couldn't use the SteppIR remote rig if If I hadn't analyzed the problem by myself with Wireshark. Unfortunately I cannot find any words about disabling DoS or similar statement in any user manual.

Kind regards
Mike

[Jan (Microbit)]

Still I find it strange that it reacts to increasing source ports, not destination ports as the browser sends the AJAX requests to the same port, unlike something which does a real port scan.

[Remote_Mike]

Hi Jan

The reaction of my router makes absolutely sense to me.
As described in several documents concerning the DoS attack the TCP and UDP based packet flooding attack tools sometimes alter source and/or destination port numbers to make reacting with packet filtering by service more difficult [e.g. "Trends in Denial of Service Attack Technology"].

At my point of view nowadays state of the art routers have to block increasing source port numbers unless this function is disabled. My new router has the option to disable the DoS firewall. Maybe a short statement in the RC-1216 user manual would make sense to point that out.

Mike

[Jan (Microbit)]

Then what does not make sense is why the PC and its web browser cause the source port number to increase for every request made?

[Jan (Microbit)]

But the TCP/IP stack we are talking about is the one in the PC, meaning it isn't possible to inspect it on a source code level. The only thing which is under our control is how the Javascript, which runs in the PC's web browser, behave and that script merely sends periodically HTTP requests to the 1216.

[Remote_Mike]

This behaviour of incrementing port numbers is called "ephemeral port".
When the connection terminates, the ephemeral port is available for reuse, although most IP stacks won't reuse that port number until the entire pool of ephemeral ports have been used.  So, if the client program reconnects, it will be assigned a different ephemeral port number for its side of the new connection.
Look for the words "ephemeral port" on the internet and you will find the explanation.

Mike

[Jan (Microbit)]

Then I see interesting problems arising in many, if not all, AJAX web page scenarios where the browser issues periodically requests in order to achieve updates of only parts of the web page if the router/firewall consider that being DoS behavior.

[HB9AZT]

This is a very interesting discussion. I had some issues with my webswitch operating as antenna rotator-interface with an old hygain-rotator. Sometimes you could start the rotator, the brake is open, but the rotator appeared to be blocked. Listening to the signals, I had the impression that the antenna is turning despite the static view of the display. Other users had the same issues. Switching off the SPI in the router solved this problem, now the display is working fine again!
Had this issue on a dlink-router.

73 de Mark, HB9AZT