12 replies to this topic

[pimpim]

Hi,

When we play stream from OpenWebif from network dmesg inform that is tcp flood:

TCP: request_sock_TCP: Possible SYN flooding on port 8001. Sending cookies.  Check SNMP counters.

Its posible to fix this bug?

Thanks!

[WanWizard]

It is not a bug, it is the kernel's response to a high volume of TCP SYN packets, and happens when the client doesn't keep a connection open to fetch the next data, but constantly creates new connections.

 

Because it happens is rapid succession, the kernel perpares itself for a possible SYN flood attack (which never happens, a normal client would always complete the SYN,SYN-ACK,ACK handshake. 

 

So it's a sign of a lousy client. Just ran 10 minutes of stream to VLC, only one SYN packet, to start the connection.

[pimpim]

Hi,

Thanks for reply.

I try several boxes on all (mutant hd51) same  problem. When i start stream from vlc one line i dmesg with flood is added. After that we can close vlc and start again more flood  messages does not apear, only first time after reboot openpli think that flood arive from VLC. tcpdump does show any flood, only two lines of sync is added:

Before flood message:

 

.....

[    9.823906] Console: switching to colour dummy device 80x30

[   10.194580] f0b00000.etherne:01: Broadcom BCM7439 (2) PHY revision: 0x10, patch: 1

[   10.203857] bcmgenet f0b00000.ethernet: configuring instance for internal PHY

[   11.741107] bcmgenet f0b00000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

[   13.504245] NET: Registered protocol family 10

[   13.509917] Segment Routing with IPv6

[   18.905587] random: crng init done

 

 

VLC started:

root@hd51:~# tcpdump -i eth0 'tcp[13] & 2 != 0'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

20:40:54.087829 IP 192.168.1.104.59843 > hd51.local.8001: Flags [S], seq 2196199139, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

20:40:54.097958 IP hd51.local.8001 > 192.168.1.104.59843: Flags [S.], seq 908562754, ack 2196199140, win 29200, options [mss 1460], length 0

 

 

Flood apeared:

...

[   18.905587] random: crng init done

[   64.089487] TCP: request_sock_TCP: Possible SYN flooding on port 8001. Sending cookies.  Check SNMP counters.

[   72.188926] device eth0 left promiscuous mode

 

Any suggestion?

I think its openpli bug, something wrong with enigma2 process. I think some kernel limits must be rised.

 

 

It is not a bug, it is the kernel's response to a high volume of TCP SYN packets, and happens when the client doesn't keep a connection open to fetch the next data, but constantly creates new connections.

 

Because it happens is rapid succession, the kernel perpares itself for a possible SYN flood attack (which never happens, a normal client would always complete the SYN,SYN-ACK,ACK handshake. 

 

So it's a sign of a lousy client. Just ran 10 minutes of stream to VLC, only one SYN packet, to start the connection.

[betacentauri]

And what problems do you have except of this warning message?

[WanWizard]

I think its openpli bug, something wrong with enigma2 process. I think some kernel limits must be rised.

 

What part of "it is not a bug" did you miss?

[pimpim]

Hi,

" it is the kernel's response to a high volume of TCP SYN packets"  But i do not see with tcpdump high volumes of tcp syn? Why dmesg error is displayed? You can try to play stream from web you will see one line of flood will be registered to dmesg. Did you sure its correct?

[betacentauri]

If tcpdump don’t show much SYN packets, then it looks like a kernel “bug”. We don’t maintain the kernel.

[WanWizard]

The HD51 runs kernel 4.10.12, and so do 20 other boxes we make images for (all mutants, all zgemma's, the axas, the vimastecs). It is quite a recent kernel, I doubt it has bugs in something as established as syn flood protection.

 

We don't inject any custom sysctl tuning commands. You can check the current kernel values in /proc/sys/net/ipv4/tcp_*. Interestingly, on my Duo4K I seem to miss the tcp_syncookies setting, but an Amiko (which runs 4.10.6) has got it, and it is enabled.

[pimpim]

Hi,

Yes i know about sysctl tunning i try change many values, but nothing helps.

Wihout net.ipv4.tcp_syncookies = 1 we cannot connect to 8001 at all.

Now current value is net.ipv4.tcp_syncookies = 1 

 

I try modifty: 

 

net.core.netdev_max_backlog = 1000000

net.ipv4.tcp_max_syn_backlog = 1000000

net.core.somaxconn = 1000000

net.core.wmem_max=12582912

net.core.rmem_max=12582912

net.ipv4.tcp_rmem= 10240 87380 12582912

net.ipv4.tcp_wmem= 10240 87380 12582912

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_sack = 1

net.ipv4.tcp_no_metrics_save = 1

net.ipv4.tcp_synack_retries=1000

 

But do not help

 

 

 

The HD51 runs kernel 4.10.12, and so do 20 other boxes we make images for (all mutants, all zgemma's, the axas, the vimastecs). It is quite a recent kernel, I doubt it has bugs in something as established as syn flood protection.

 

We don't inject any custom sysctl tuning commands. You can check the current kernel values in /proc/sys/net/ipv4/tcp_*. Interestingly, on my Duo4K I seem to miss the tcp_syncookies setting, but an Amiko (which runs 4.10.6) has got it, and it is enabled.

[betacentauri]

But again why is this so important? Do you have problems or is it only because one line is visible in the log?

[pimpim]

I have several hangs, i want free dmesg

[WanWizard]

I doubt this is causing that. If the kernel reports syn flooding (the default counters are quite low), chances are there is, and you have an issue elsewhere.

[pimpim]

Thanks for suggestions!

 

I doubt this is causing that. If the kernel reports syn flooding (the default counters are quite low), chances are there is, and you have an issue elsewhere.