SYN Flooding [solved]

[mundodisco8]

I updated the router to the latest firmware (RT-AC56U, 380.57), and since then, I find a lot of items in the system long regarding SYN flooding

12:37:38 kernel: TCP: Possible SYN flooding on port 34829. Sending cookies.

There are hundreds of those messages, happening at bursts of 10-20 of them at different intervals (sometimes there is around 10 minutes between bursts, sometimes is just a minute). The port changes everytime the router is rebooted (this last time, the affected ports were 34829 and 49068. The origin are both my laptop and a raspberry pi I use as a music player (running Volumio). I've seen some posts with similar issues in the forum, but all seem to affect a specific port, not random ports.

I really don't know how to troubleshoot this problem, does anybody know what are the steps to take in this case? Should I just ignore it? I tried reflashing the last firmware and resetting to factory defaults, and it doesn't fix the issue.

 

[L&LD]

Have you allowed WAN access to your router? If you turn it off, does it stop the messages?

Someone is trying to hack you (if I understand this issue correctly).

 

[mundodisco8]

No, I haven't. The router presents the issue even after resetting it to factory defaults. I haven't mentioned in the other post, but I ran the netstat tool, and the only devices that have connections in waiting status are my own laptop (which would match the you have been hacked / malware hypothesis), and a raspberry pi that I have running volumio with wan access disabled (I think the chances of that being hacked / malware'd are less likely).

I will try to get the previous firmware flashed today, to see if that fixes it and will report back.

 

[martinr]

Troubleshoot by disconnecting both the laptop and Pi from the router long enough to prove whether or not you get the sane symptoms with nothing connected. Then connect either the Pi or the laptop and do the same again until you find the device that causes the symptoms. And then work through the programs you have running on that device until uou find the one. I get the impression you think Volumio may be the culprit, shutting it down will soon verify that.

 

[mundodisco8]

I suspect it has to do something with DHCP. During the night, I had enough messages to fill the log (since yesterday at 22h). The only other messages I got where like this one

Mar  5 00:23:22 dnsmasq-dhcp[8765]: DHCPREQUEST(br0) 192.168.2.95 ac:9b:0a:0e:99:44
Mar  5 00:23:22 dnsmasq-dhcp[8765]: DHCPACK(br0) 192.168.2.95 ac:9b:0a:0e:99:44 android-e9b5068866fc2a22

And most of them came from my android phone. During the night, other devices were on: a NAS, an iPhone, and iPad and an Android TV, plus the already mentioned Raspberry Pi running Linux. I attach a copy of the log.

I disabled DHCP and after a couple of hours, I only got one message, indicating 2 calls suppressed around 10 minutes after I did it, that could be from connections that were left open before I disabled DHCP.

So all points to DHCP, isn't it?

 

[mundodisco8]

WHAT IF...? I'm using my ISP's router to connect to the internet just as a modem (I'm using Talktalk in the UK, who provides a D-LINK 3680), in bridge mode (it's a setting in the DLINK manager) , and the RT-AC56U linked to it in PPPoE mode. I forgot to disable DHCP in the DLINK. I turned it off, and reenabled DHCP in the ASUS. So far, I only got a bunch of lines indicating that my devices are requesting their addresses but no SYN-related messages so far...

I will leave it for a couple of hours and come back to you.

 

[martinr]

.

I disabled DHCP and after a couple of hours, I only got one message, indicating 2 calls suppressed around 10 minutes after I did it, that could be from connections that were left open before I disabled DHCP.

So all points to DHCP, isn't it?

I'm not sure you can blame DHCP at all. I used Google (possible syn flooding on port sending cookies) and there's a fair bit on it eg picking one at random http://ben.goodacre.name/tech/Possible_SYN_flooding_on_port_xxx._Sending_cookies_(Linux)

You really don't want to be disabling DHCP, seems to me it might be like disconnecting the malfunction indicator light on the dashboard rather than finding put which sensor is causing it to illuminate.

You could try the 50:50 method as used for example in Windows clean boot troubleshooting: disconnect half the devices, if the problem's gone, the offending device is in the 50% not connected, so you disconnect the current batch and connect half of the batch in which you now know the problem device lies... You get the idea. Much quicker than a one-at-a-time method.

You'll soon crack it, but do have a rumage through Google's output for your error message, and enjoy the cookies, when they arrive.

 

[martinr]

....... The router presents the issue even after resetting it to factory defaults. .

Just to clarify: even after restoring to factory default settings (and only manually resetting the absolute minimum eg only wireless security settings) and with all the devices connected (or is that before you connect them), you still see the logfile messages - possible syn flooding etc?

 

[Nullity]

If you want to precisely determine your problem, you could install tcpdump on the Asus device and run tcpdump 'tcp[tcpflags] & tcp-syn != 0 and src net 192.168'. That command will log all SYN packets originating from from 192.168.*.*. You could remove the "src net" part to log all syn packets.

You could append -w filename.pcap to log to a file.

 

[mundodisco8]

Hi, thanks for your help, I really appreciate the time you are taking to try to help me fix this issue, and learn during the process of doing it.

@martinr You are right about the cause/indicator thing. I didn't realized that I might not be fixing the issue, just muting it. It is also true that I can find other people with my issue on the internet, believe me that I tried to solve it before coming to the forum to ask for help, but finding answers doesn't mean that I understand what they mean. In the link that you sent, for example, it tells how to detect the problem, and how increasing the limit could stop it. I don't know what implications that might have, so I prefer to come here and ask. I will keep experimenting and unplugging bits from my network to see if I see a pattern or a culprit.

@Nullity I tried the tcpdump command you sent, no SYN packages were detected, even after leaving it running for a good couple of hours, with or without the src net bit. Could it be that I'm listening to the wrong network adapter?

 

[martinr]

No problem. We're here to help. I hope you didn't think I was trying to fob you off or to suggest you look elsewhere. And we, well I, always learn something as a result of someone else's snag!

"Muting" rather than fixing: that's a great way of putting it.

 

[Nullity]

@Nullity I tried the tcpdump command you sent, no SYN packages were detected, even after leaving it running for a good couple of hours, with or without the src net bit. Could it be that I'm listening to the wrong network adapter?

Yeah the adapter/interface may be a concern (I use "-i br0" with my RT-N66U).

Disregarding an error in the command, could it be that you have no actual problem?

 

[ColinTaylor]

You said in your first post that the source was your laptop and raspberry pi. If that is always the case then you have found the source of the problem.

The question then becomes, why are these 2 devices continuously trying to connect to non-existent service on the router? Is there some common piece of software running on these two devices?

 

[mundodisco8]

I think I found out what was the cause of the problem, although I'm not sure. The raspberry pi was using DHCP, but I wanted it to have a fixed IP. The raspberry pi runs volumio, which has a simple web frontend. I can't set a fixed IP for the WiFi interface in my version of volumio. In previous versions of Merlin's Asuswrt, I could set the IP as fixed on the router side, but it seems that the new version has changed something, and now it doesn't like the raspberry pi, the WiFi usb dongle or something like that.

Setting the IP address as fixed editing (volumio's) /etc/network/interfaces stopped the raspberry from sending more DHCP requests, and now the router is not complaining. Is not like I solved the problem, because leaving it in DHCP mode cause it to go berserk asking for an address too insistently, but it works for me, so I won't complain. Thanks guys for your involvement and help.

 

[martinr]

Glad you've solved it - and thanks for telling us.

ColinTaylor is worth reading on this, for example:

http://www.snbforums.com/threads/generic-dhcp-question.27333/#post-208005

http://www.snbforums.com/threads/ip-address-resveration.20316/#post-146968

I was going to say there's a lot of stuff around on setting up a static IP address on a Raspberry Pi and I was going to add make sure you make a backup of the interfaces file before modifying it; however, in looking for an example, I found this:

http://raspberrypi.stackexchange.com/questions/37920/how-do-i-set-up-networking-wifi-static-ip

Well worth a read, especially the part:

"The Raspbian released in May 2015 changed the way networking (and particularly WiFi) works.

This applies to the current Foundation releases of Raspbian Jessie and the last Raspbian Wheezy 2015-05-05 (no longer available).

This makes all the existing tutorials obsolete. (Note the tutorials can still be used if you want to use the older style of manual configuration, but this requires specialised knowledge.)"

 

[martinr]

And netwrks posted something that you might find useful:

http://www.snbforums.com/threads/so...when-i-asign-static-ip-mac.24194/#post-180431

 

[mundodisco8]

I know the differences between fixed IP and reserved IP. I tried the reserved IP route first, as I like my devices to keep the DHCP on (specially on devices that have the opportunity to connect to other networks) in case they connect to other networks that have different IP ranges, although to be fair, that is rarely needed (except for my mobile phones and tablet).

In any case, I think that the raspberry pi was getting confused with the reserved IP. It was acquiring it (I could access it addressing it by the intended address), but it seems that it was still sending DHCP requests, for some reason. I don't know if the problem is in the router, the linux distribution (based on raspbian, I think) or the wifi dongle. Setting a fixed IP worked. As the raspberry pi is not going to leave my house, and I don't think I will change my range of IP addresses anytime soon, I don't think that will be a problem anytime soon.

I also had an Android TV that was requesting addresses a lot, although not enough to cause SYN floods. It has two interfaces (wifi and ethernet). It was set in reserved address mode too (different addresses for both adapters, as they like to be both connected for brief periods of time from time to time). I turned off the telly and removed any address bindings and rebooted the router, to clean the address table. Now it doesn't complain, and the TV doesn't need a reserved IP address.

So all good in the hood. I just leave two devices that I need to access remotely with fixed or reserved addresses, and let the rest to use DHCP. No need to overcomplicate stuff.

 

[Nullity]

I wonder why DHCP troubles caused syn flood alerts...

 

[ColinTaylor]

I wonder why DHCP troubles caused syn flood alerts...

I very much doubt it's a DHCP problem per se. Especially as DHCP is broadcast and the SYN packets are unicast. Also, the syslog provided didn't indicate any particular DHCP problems from the routers perspective.

It's more likely (IMHO) to be a problem with the network configuration (or interface) on the Raspberry Pi. Perhaps the interface is "flapping". It could be all sorts of things, but without access to the Pi and going through it in fine detail it's impossible to say.

The OP has found a work around though so that's good. As he says, no need to overcomplicate stuff. Occam's razor