Debian dropping TCP requests


#1

I’m using a USB->Ethernet adapter, so this shouldn’t have to do with the wifi ARP issues discussed earlier.

I have a piece of software that runs on the dragonboard and listens for incoming TCP connections. Client software running on another machine connects to the IP:port and can pull off data. This software works fine on other machines, clients can connect and get data, etc. On the dragonboard the server starts up fine, but as soon as the first client tries to connect, I get the following output in /var/log/messages, kern.log, and syslog, and the connection times out:
Jun 3 17:45:44 hostname kernel: [ 39.183685] TCP: request_sock_TCP: Possible SYN flooding on port 3490. Dropping request. Check SNMP counters.

Where 3490 is the listening port of the code. It doesn’t seem to matter what port I choose, I always get that message with the applicable port number, and the client connection times out. Is there some default sysctl setting that could be causing this? Even trying to connect to the port with telnet triggers the error and subsequent timeout.

An example C++ server code that shows the problem is below:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
  int fd = -1;
  int sock = socket(AF_INET, SOCK_STREAM, 0);

  if(sock<0){
    printf("could not open server socket");
    return -1;
  }
  struct sockaddr_in addr;
  memset(&addr, 0, sizeof(addr));
  addr.sin_family = AF_INET;
  addr.sin_port = htons(3490);
  addr.sin_addr.s_addr = htonl(INADDR_ANY);

  if(bind(sock, (struct sockaddr *) &addr, sizeof(addr))<0){
    printf("could not bind server socket");
    return -1;
  }

  if(listen(sock, 0)<0){
    printf("could not listen on server socket");
    return -1;
  }

  fd = ::accept(sock, NULL, NULL);

  printf("accepted a connection: %d\n",fd);

  return 0;
}

#2

This is solved.

It looks like it was a kernel change, some time between 3.10 (where I’ve been doing all of my other testing) and 4.4 (what the Dragonboard is running), the backlog parameter in listen() was reinterpreted so that “0” means “no connections at all” instead of “no backlog after the first connection”, and since the default kernel config on the Dragonboard doesn’t have syncookies enabled it was causing it to drop the connection.

I’ve upped the second parameter in listen() from zero and it’s now accepting connections, something that wasn’t necessary on older kernels, but that’s fine. If it comes to it I may also recompile the kernel with syncookies enabled.


#3

i am not very familiar with SYN_COOKIES option, but it looks like something we could/should enable by default in our builds… if you agree and would like that to happen, can you please open a bug for it?