Zyxel T-56 ping spikes

  • 4 September 2023
  • 43 reacties
  • 1341 Bekeken
C
Reputatie 1

Hi all, pardon the engels, I am seeing the weirdest latency spikes to my new Zyxel T-56 modem, from devices directly attached to it. 

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.533 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=516 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.578 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=210 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.568 ms

 

If I run a tcpping to google.com , so that is now LAN to WAN, and not just LAN to router. 

 

255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.677 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.382 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  554.650 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.165 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.706 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.652 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  6.536 ms
255  ams16s37-in-f14.1e100.net (172.217.23.206)  7.220 ms

 

I see the same thing?

This is weird how it gets these spikes, on LAN being directly attached I would expect to see max maybe 2ms. Not 516ms. Is this router getting overloaded, or is the hardware just kinda cheap? 

Tommie van Odido 7 maanden geleden

Hey @ChaosMonkey, welcome to our Community!

Good that you are sounding the alarm for this. I immediately went to check for you and I see that you have your own router/switch connected. Could you run these two commands if you have unplugged everything and are only connected directly wired to your laptop/desktop? Ping -n 50 1.1.1.1 & Ping -n 50 8.8.8.8 in CMD. Do this with only the Zyxel modem connected to your network with a wired connection. Suppose you have a VPN, disable it too.

Bekijk origineel

43 reacties

Tommie van Odido
Rank
Reputatie 7
Badge +9

Hey @ChaosMonkey, I've messaged @Sven-Odido to take a look at your connection but he can't see anything at the moment because the MikroTik is connected. Could you connect the Zyxel and take out the MikroTik in between? Then we can check the connection!

Life is too short to drink bad wine!
C
Reputatie 1

Hey @ChaosMonkey, I've messaged @Sven-Odido to take a look at your connection but he can't see anything at the moment because the MikroTik is connected. Could you connect the Zyxel and take out the MikroTik in between? Then we can check the connection!

Hi @Tommie van Odido , well yes I unplugged the Zyxel because I want a stable connection. 
I have reconnected the Zyxel now. It was barely 30 seconds since it got a new IP address, and I moved from .118 to a .120 subnet and immediately I see this 


Sep 20 14:11:48 kern.alert kernel: [  156.597862] UDP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=216.131.89.252 DST=5.132.120.x LEN=1500 TOS=0x00 PREC=0x00 TTL=5 ID=0 DF PROTO=UDP SPT=52415 DPT=37207 LEN=1480 
Sep 20 14:12:01 kern.alert kernel: [  169.949677] UDP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=89.184.168.213 DST=5.132.120.x LEN=1500 TOS=0x00 PREC=0x00 TTL=9 ID=0 DF PROTO=UDP SPT=39937 DPT=37207 LEN=1480 
Sep 20 14:13:14 kern.alert kernel: [  243.173178] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=6856 DF PROTO=TCP SPT=42381 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173180] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=47025 DF PROTO=TCP SPT=48579 DPT=60088 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173182] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39797 DF PROTO=TCP SPT=42757 DPT=8000 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173207] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=24989 DF PROTO=TCP SPT=35647 DPT=45554 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:14 kern.alert kernel: [  243.173209] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=8550 DF PROTO=TCP SPT=57091 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:15 kern.alert kernel: [  244.198202] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39054 DF PROTO=TCP SPT=36549 DPT=5521 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:17 kern.alert kernel: [  246.212050] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=64885 DF PROTO=TCP SPT=55707 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:17 kern.alert kernel: [  246.212052] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=28483 DF PROTO=TCP SPT=36763 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431698] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=56367 DF PROTO=TCP SPT=47297 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431700] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=611 DF PROTO=TCP SPT=44243 DPT=34002 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431706] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=17186 DF PROTO=TCP SPT=44723 DPT=8118 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:22 kern.alert kernel: [  250.431728] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=30961 DF PROTO=TCP SPT=44313 DPT=8291 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614956] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=43047 DF PROTO=TCP SPT=44341 DPT=3128 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614957] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=39801 DF PROTO=TCP SPT=42757 DPT=8000 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614959] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=6860 DF PROTO=TCP SPT=42381 DPT=1080 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614985] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=61062 DF PROTO=TCP SPT=41211 DPT=33002 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:30 kern.alert kernel: [  258.614987] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=15474 DF PROTO=TCP SPT=59503 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725769] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=29997 DF PROTO=TCP SPT=58295 DPT=8888 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725771] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=4 DF PROTO=TCP SPT=38833 DPT=9001 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725777] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=20097 DF PROTO=TCP SPT=38013 DPT=8118 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725799] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=52411 DF PROTO=TCP SPT=36189 DPT=8888 WINDOW=64240 RES=0x00 SYN URGP=0 
Sep 20 14:13:46 kern.alert kernel: [  274.725824] SYN_FLOODING ATTACK:IN=eth1.3 OUT= MAC=10:71:b3:a1:dc:bd:00:0e:00:00:00:04:08:00 SRC=185.191.225.130 DST=5.132.120.x LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=30377 DF PROTO=TCP SPT=52321 DPT=8123 WINDOW=64240 RES=0x00 SYN URGP=0 
 

C
Reputatie 1

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

C
Reputatie 1

Hi @Tommie van Odido , 

 

Odido connects with smardc to the AMS-IX right? If I do a traceroute to 9.9.9.9 I see the same IP address twice. And it’s always when it goes from your 10.10.10.x range to the 80.249.x.x range where the latency spikes happen. (When the router isn’t being attacked and failing) .
When I do a traceroute to 8.8.8.8 (google) it doesn’t seem to run through the AMS-IX , and the ping is a lot more stable. Maybe there is an issue with your connection and routing at AMS-IX? 

 

S
Rank
Reputatie 7
Badge +4

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

I havent had time yet to dive into this. When a lot of port scans etc are happening at the same time its normal to see a slight increase in latency for a few pings. But not the amount you are seeing. I will have to look more into that when I have more time on my hands, Sorry for the inconvenience.

Also keep in mind that when a lot of ICMP pings are sent by one host, the DOS protection on the T56 will kick in as well. 

Helpt hier soms Tommie van Odido
C
Reputatie 1

@Sven-Odido you can have a look now, maybe we need a faster way to communicate, because these attacks come the moment this router turns on

I havent had time yet to dive into this. When a lot of port scans etc are happening at the same time its normal to see a slight increase in latency for a few pings. But not the amount you are seeing. I will have to look more into that when I have more time on my hands, Sorry for the inconvenience.

Also keep in mind that when a lot of ICMP pings are sent by one host, the DOS protection on the T56 will kick in as well. 

Not a problem, would it then be okay if I swap back to the mikrotik and only switch to the T56 when you have some time? 

 

I am curious ipv6 needs ICMP in order to work, is the T56 DoS protection setup in a way that it would allow that without raising any flags? It seems to only trigger on the ICMP request count number, so if you ping and stop and ping and stop it seems to not flag it. 

S
Rank
Reputatie 7
Badge +4

Not a problem, would it then be okay if I swap back to the mikrotik and only switch to the T56 when you have some time? 
​​​

Yess Of course, I will let you know when the T56 need to be connected again. 

 

Helpt hier soms Tommie van Odido
C
Reputatie 1

@Sven-Odido Well I think I found the cause of my latency variation. Interesting that the route doing hit this exchange or IP when going to google. It seems your interconnect (well I am guessing it’s the interconnect) is overloaded, perhaps old or buggy firmware? 

Have a look at these ping results, I took it on my router as well. So then there is nothing in the path that can cause any issues. 

 

 

To my knowledge, with fibre, this should never be the case. It’s normal to see a hop in between have packet loss but if the latency goes up from that hop and travels onwards, then that hop is the issue. 

An avg of 18ms, that puts me somewhere close to Mora in Mydrid. 
Already I am sitting at 6ms for 30km, when the avg for fibre is 1ms per 100km. Which is already a bit high. 

S
Rank
Reputatie 7
Badge +4

I dont have any insights in that part of the network. Im still looking into the spike happening when the port scans are happening. 

 

 

Helpt hier soms Tommie van Odido
P
Reputatie 2

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

C
Reputatie 1

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

@pockeyhock yes, I managed to get a very stable ping by ditching the Odido provided router.

Do you also have the new T56, did you try disabling/enable the DoS protection? Does your latency also bounce around and on occasion the connection drops?  

 

What appeared to be the cause of my latency spikes, was patched out from causing issues in the linux kernel long ago. Also to note the logs weren’t so great when it came to seeing what the cause was, gaining full console access, via UART/SSH, could probably give a better idea of what is going on.

 

@Sven-Odido , seems this could be a common problem then?

P
Reputatie 2

@ChaosMonkey Did you ever end up resolving this issue? Me and some others are experienceing ur same issue.

@pockeyhockyes, I managed to get a very stable ping by ditching the Odido provided router.

Do you also have the new T56, did you try disabling/enable the DoS protection? Does your latency also bounce around and on occasion the connection drops?  

 

What appeared to be the cause of my latency spikes, was patched out from causing issues in the linux kernel long ago. Also to note the logs weren’t so great when it came to seeing what the cause was, gaining full console access, via UART/SSH, could probably give a better idea of what is going on.

 

@Sven-Odido, seems this could be a common problem then?

Personally the connection doesnt drop at all for me. Its very stable and the uptime is great but then every couple minutes i will get 400-600ms latency spikes, yes i tried to disable DoS protection it seemed to work for a bit but ended up falling back to what was happening before. What’s interessting though is that if I disable DoS protection my ping in a certain game would load instantly where as it would take ages before with having DoS protection on. I am not on linux, windows machine here.

P
Reputatie 2

Do you not have any latency spikes at all anymore after replacing the t-56? That sounds great. I think truly a firmware patch is needed and a look into what the cause might be to these spikes @Sven-Odido @Tommie van Odido 

C
Reputatie 1

Do you not have any latency spikes at all anymore after replacing the t-56? That sounds great. I think truly a firmware patch is needed and a look into what the cause might be to these spikes @Sven-Odido @Tommie van Odido 

Except for some oddness within the AMS-IX data center doing some odd route flip flop at a much higher rate than it should, my latency has been really stable. I used to feel that 200-400ms (600ms at times) latency spikes a lot in games as well. Since disconnecting the T56 I have had none of that. It’s been a month that it has been smooth. Except for that route change that will cause a spike, I don’t see the other constant or high 200-600ms spikes, within a 100 packets sent with a long running ping.

 

Curious enough, I can disconnect my Mikrotik and connect the T56, and within half an hour I will see the latency spikes. Disconnect the T56 and reconnect my Mikrotik, and boom immediate smooth ping. Same public IP address, or I can force a new one (in both swaps). So it’s not even that it’s an issue with my IP address. It seems to purely be the router. My guess is something is looking for these devices and then trying to do something towards them.

P
Reputatie 2

Ive picked up some weird routerlogs aswell toward gameservers, my computer is apparently sending ping of deaths to different servers, if I had to guess there might be something with the firewall configurations on these things, personally scared to disable it and test if i still have the spikes with it off haha. Mostly have these suspicions because of how my ping would load instantly with dos protection off on some games where it took ages to load before, i can only assume it has to do something with security.

C
Reputatie 1

Ive picked up some weird routerlogs aswell toward gameservers, my computer is apparently sending ping of deaths to different servers, if I had to guess there might be something with the firewall configurations on these things, personally scared to disable it and test if i still have the spikes with it off haha. Mostly have these suspicions because of how my ping would load instantly with dos protection off on some games where it took ages to load before, i can only assume it has to do something with security.

Is the ping of death originating from your PC from running long pings to check your latency?
It’s kind of funny how the router logs pings of death as a security thing, because this was patched in the linux kernel and doesn’t cause issues, so it shouldn’t even feature as some security warning as it can’t harm the device.

I tried to disable the firewall, it didn’t really make an impact at all. I saw port scans and connection attempts to ports that were not open, even with UPnP disabled. While this should be a simple iptables firewall, the CPU seems to get overloaded and then the whole device slows down.

 

Have a look if your latency also spikes to 400ms if you just run a long ping from your PC to the router.

 

I wonder if it’s not due to these bugs https://itwire.com/business-it-news/security/linux-devices-vulnerable-to-ping-of-death-attack.html.

 

Would also be awesome if this could be referenced https://javapipe.com/blog/iptables-ddos-protection/.

My setup will allow me to actually help and even Man-In-The-Middle packet capture to inspect what is causing the slowness, but I would also need access to the admin console of the router to get a linux shell to make changes to the core tcp stack and firewall to see how we can address this. If Odido’s policies can allow for this, I am willing to help fix this.

P
Reputatie 2

Nothing from my pc to the router, except a 5ms spike that I only saw once, rest of them were all sub 1ms. The issues seem to be strictly when connecting to the actual internet, not LAN. And no idea about the first part to be honest, I just picked up that it flags my computer sending ping of death attacks to multiple gameservers, doesnt seem to be anything else though like google servers or twitch etc...

P
Reputatie 2

@ChaosMonkey 

 

Could you provide some screenshots (can use the ones here with the tests u did strictly with the zyxel). Maybe if we get more people to post it becomes a priority issue and we get a fix soon.

Reageer


ForumvoorwaardenCookie instellingen