Hi Julius,
thank you very much for your feedback.
Well, its also worth to mention that I have at least 5-6 seconds lag (visible delay) between clicking mouse buttons and really navigating WebUI between tabs etc. to see its doing it.
I tested this on Windows 10 with: Edge, Firefox and Chrome Browser - everywhere that looked the same (Edge was even less responsive I had to click 5-10 times and wait longer for something to happen).
In RutOS 7.4.5 its much better time like 1,5-2sec delay.
I tried to Upgrade RUT240 via bootloader method procedure, but it’s not possible I get:
Update Failed - Error: Incorrect checksum. (I tried with many different OS’es with same fail result, but with GUI same images are OK then can be loaded correctly to device).
Perhaps bootlader itself is too old, but I don’t know how to check it.
I also noticed that problem with high CPU utilization is not limited only to displaying WebUI, but generally speaking its affecting routing proceses and engine, as well.
I’m not sure if you guys apply, by default, some kind of CPU-defender against pinging ICMP and this is typical and usual behavior - even inside LAN, so if not, I’m experiencing some delay-issue.
There are times that I see significant increase in delay with pinging LAN segment network between local device plugged with UTP cable to RUT240.
Here I will give you another simple example:
I have configured RUT240 to Passthrough mode and plugged-in Rut240 LAN-port into my other router Juniper SRX300 behind it.
Now, although I have connected local small public subnet/30 between two devices, in fact I’m trying to ping my local-LAN segment with ICMP Echo.
This, I guess, gives same results with RutOS 7.5 and similarly with 7.4.5 – perhaps its intended by the software, but I’m not sure and convinced here.
If I had RUT240 in normal NAT mode: my PC plugged to LAN port would have: 192.168.1.[100-200] and trying to ping Teltonika gateway: 192.168.1.1.
Topology looks like this (it’s from my other threat, see only pictures from Visio from 2nd or 3rd post):
Pasting my picture for better undersanding simple topology:
RutOS 7.5
So, I’m pinging with source IP: 46.77.101.129 [JuniperSRX] to 46.77.101.130[RUT240]
I see on the statistics something like this - pasting only times when delay is higher, other 1ms ICMPs are skipped:
admin@Router> ping 46.77.101.130 source 46.77.101.129
64 bytes from 46.77.101.130: icmp_seq=28 ttl=64 time=49.612 ms
64 bytes from 46.77.101.130: icmp_seq=47 ttl=64 time=36.847 ms
64 bytes from 46.77.101.130: icmp_seq=48 ttl=64 time=58.954 ms
64 bytes from 46.77.101.130: icmp_seq=66 ttl=64 time=32.293 ms
64 bytes from 46.77.101.130: icmp_seq=85 ttl=64 time=33.798 ms
64 bytes from 46.77.101.130: icmp_seq=104 ttl=64 time=24.264 ms
64 bytes from 46.77.101.130: icmp_seq=123 ttl=64 time=29.564 ms
64 bytes from 46.77.101.130: icmp_seq=136 ttl=64 time=1.305 ms
64 bytes from 46.77.101.130: icmp_seq=142 ttl=64 time=17.331 ms
64 bytes from 46.77.101.130: icmp_seq=161 ttl=64 time=28.038 ms
64 bytes from 46.77.101.130: icmp_seq=181 ttl=64 time=24.427 ms
64 bytes from 46.77.101.130: icmp_seq=200 ttl=64 time=36.679 ms
64 bytes from 46.77.101.130: icmp_seq=258 ttl=64 time=36.046 ms
64 bytes from 46.77.101.130: icmp_seq=316 ttl=64 time=40.609 ms
64 bytes from 46.77.101.130: icmp_seq=335 ttl=64 time=15.638 ms
64 bytes from 46.77.101.130: icmp_seq=354 ttl=64 time=30.484 ms
64 bytes from 46.77.101.130: icmp_seq=373 ttl=64 time=22.999 ms
64 bytes from 46.77.101.130: icmp_seq=374 ttl=64 time=1.224 ms
64 bytes from 46.77.101.130: icmp_seq=375 ttl=64 time=1.226 ms
64 bytes from 46.77.101.130: icmp_seq=376 ttl=64 time=1.350 ms
64 bytes from 46.77.101.130: icmp_seq=412 ttl=64 time=44.337 ms
64 bytes from 46.77.101.130: icmp_seq=431 ttl=64 time=14.591 ms
64 bytes from 46.77.101.130: icmp_seq=451 ttl=64 time=44.754 ms
…
— 46.77.101.130 ping statistics —
1651 packets transmitted, 1651 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.005/3.309/558.929/15.720 ms
RutOS 7.4.5 - Passthrough, same config only earlier OS, same issue only paste fragment of it
admin@Router> ping 46.77.101.130 source 46.77.101.129
PING 46.77.101.130 (46.77.101.130): 56 data bytes
64 bytes from 46.77.101.130: icmp_seq=2 ttl=64 time=43.502 ms
64 bytes from 46.77.101.130: icmp_seq=21 ttl=64 time=19.297 ms
64 bytes from 46.77.101.130: icmp_seq=79 ttl=64 time=48.403 ms
64 bytes from 46.77.101.130: icmp_seq=98 ttl=64 time=24.480 ms
64 bytes from 46.77.101.130: icmp_seq=137 ttl=64 time=39.981 ms
64 bytes from 46.77.101.130: icmp_seq=156 ttl=64 time=15.528 ms
64 bytes from 46.77.101.130: icmp_seq=176 ttl=64 time=14.116 ms
RutOS 7.4.5 - default factory reset settings same scenario I use NAT mode and have default subnet: 192.168.1.0/24 between devices 192.168.1.140 [Juniper] and 192.168.1.1 [RUT240]:
admin@Router> ping 192.168.1.1 source 192.168.1.140
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=45.608 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=27.838 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=11.411 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=16.227 ms
64 bytes from 192.168.1.1: icmp_seq=82 ttl=64 time=42.047 ms
64 bytes from 192.168.1.1: icmp_seq=101 ttl=64 time=34.094 ms
64 bytes from 192.168.1.1: icmp_seq=120 ttl=64 time=11.109 ms
64 bytes from 192.168.1.1: icmp_seq=140 ttl=64 time=14.754 ms
64 bytes from 192.168.1.1: icmp_seq=159 ttl=64 time=39.448 ms
…
…
— 192.168.1.1 ping statistics —
1601 packets transmitted, 1601 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.996/2.615/54.832/6.237 ms
This should not look like this, because LAN IP traffic should almost always be between <1-3ms if device is not saturated and bandwidth utilized to maximum, values like: 50-100ms, ocasionally even ~500ms - proves that software-CPU is in fact overloaded and traffic is delayed, after all. Maybe I am missing something. I dunno. I have also checked ‘Network’ → ‘Firewall’ → Attack Prevention, here REMOTE ICMP REQUESTS section, where I have default settings:
Enable ICMP requests is On
Enable ICMP limit if Off
Also, ‘Firewall’ → ‘General Settings’ → Software flow offloading is On → but nothing changes.
BTW: Thanks as well for looking into SSH-Putty matter. I already changed port from 22 to 9022 as less common and security purpose.
But, my Putty is not by default negotiating ECDSA keys (even I think it has option to handle it) during first connections with RUT’s - it refuses connection and closing session, automatically.
So I guess first, I would need to generate such keys at RUT’s, export them to PC and import again at Putty to properly handle next connection - this overall process is challenging and inconvenient,
rather than using other SSH-Client (TeraTerm) that negotiate ECDSA 256 automatically during first SSH session and works without any problem.
Anyway, thanks for your interest and providing some information.
Kind Regards,
Robert.