This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

TCP-server cannot accept clients

Hi!

I'm developing a TCP server running on the nRF9160, but there seem to be a problem with accepting clients. The code is very simple, just calls to socket, bind, listen, accept. But the accept fails as soon as a client tries to connect. ERROR on accept returned -1, errno: 134. I have pasted the code below.

I'm connected to a Cat-M network before I start the server and I have successfully connected from the nRF9160 to another server. But I cannot get the nRF9160 to act as a server. Can you please investigate this?

I'm using:
fw-nrfconnect-nrf tag v1.1.0
Zephyr tag v2.0.99-ncs1
nrfxlib v1.1.0
Modem firmware: 1.1.0

int parentfd; /* parent socket */
int childfd; /* child socket */
int portno; /* port to listen on */
int clientlen; /* byte size of client's address */
struct sockaddr_in serveraddr; /* server's addr */
struct sockaddr_in clientaddr; /* client addr */

portno = 8080;
parentfd = socket(AF_INET, SOCK_STREAM, 0);
if (parentfd < 0) {
	LOG_ERR("ERROR opening socket");
	return;
}

memset(&serveraddr, 0, sizeof(serveraddr));
serveraddr.sin_family = AF_INET;
serveraddr.sin_addr.s_addr = INADDR_ANY;
serveraddr.sin_port = htons((unsigned short)portno);

if (bind(parentfd, (struct sockaddr *) &serveraddr, sizeof(serveraddr)) < 0) {
	LOG_ERR("ERROR on binding");
	return;
}

if (listen(parentfd, 5) < 0) {/* allow 5 requests to queue up */ 
	LOG_ERR("ERROR on listen");
	return;
}

while (1) {
	LOG_INF("TCP server waiting for client...");

	childfd = accept(parentfd, (struct sockaddr *) &clientaddr, &clientlen);
	if (childfd < 0) {
		LOG_ERR("ERROR on accept returned %d, errno: %d", childfd, errno);
		LOG_ERR("Closing server");
		close(parentfd);
		break;
	}

	LOG_INF("server established connection");
	
	tcp_handle_client(childfd);

	close(childfd);
} 

Kind regards

Mattias Eriksson

Parents
  • Hi.

    First of all, I need a bit more information to make sense of the error you get, 134.

    NCS can be built with two different libc implementations, newlib and Zephyr's own minimal implementation. Which one of those are you using (, i.e. have you enabled the newlib implementation)?

    If you are using newlib, you can get an explanation of the error by calling strerror(). It is declared in string.h, and returns a string that explains the error.

    Best regards,

    Didrik

  • Thanks for fast response!

    Yes, I'm using newlib (CONFIG_NEWLIB_LIBC=y).

    This is the error string I get from strerror(134): 'Not supported'.

    You can see the error code for newlib here also (for example): Newlib errno.h

    That is not good.. According to your nrfxlib/bsdlib documentation you support both TCP client and server (http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/bsdlib/README.html)

    Note that the error is returned when a client connects, not when the function is called.

    Kind regards

  • Hi

    We use eSIM from Stream/ARM. We are connected to Telia Cat-M in Linköping, Sweden.

    I have attached a modem trace.

    Modem firmware: 1.1.0
    Using nRF9160 DK

    trace-2020-01-28T15-41-57.041Z.bin

    Here is the log from the application (I have replaced apn/user/pass with ---):

    Initializing BSD...
    Result: 0
    Initializing AT cmd...
    Result: 0
    Initializing AT notif...
    Result: 0
    Initializing LTE...
    [00:00:01.992,004] <dbg> at_cmd.at_cmd_driver_init: Common AT socket created
    [00:00:01.992,156] <dbg> at_cmd.at_cmd_driver_init: Common AT socket processing thread created
    [00:00:01.992,156] <dbg> aResult: 0
    LTE connect
    t_cmd.socket_thread_fn: AT socket thread started
    [00:00:01.996,643] <dbg> at_notif.module_init: Initialization
    [00:00:02.000,549] <dbg> at_cmd.at_write: Sending command AT%XSYSTEMMODE=1,0,0,0
    [00:00:02.014,038] <dbg> at_cmd.at_write: Bytes sent: 22
    [00:00:02.014,068] <dbg> at_cmd.at_write: Sending command AT%XMODEMTRACE=1,2
    [00:00:02.023,254] <dbg> at_cmd.at_write: Bytes sent: 18
    [00:00:02.023,254] <dbg> at_cmd.at_write: Sending command AT+CEREG=5
    [00:00:02.031,158] <dbg> at_cmd.at_write: Bytes sent: 10
    [00:00:02.031,219] <dbg> at_cmd.at_write: Sending command AT%XEPCO=0
    [00:00:02.039,184] <dbg> at_cmd.at_write: Bytes sent: 10
    [00:00:02.039,215] <inf> lte_lc: Using legacy LTE PCO mode...
    [00:00:02.039,215] <dbg> at_cmd.at_write: Sending command AT+CGDCONT=0,"IP","---"
    [00:00:02.047,851] <dbg> at_cmd.at_write: Bytes sent: 32
    [00:00:02.047,882] <inf> lte_lc: PDP Context: AT+CGDCONT=0,"IP","---"
    [00:00:02.047,882] <dbg> at_cmd.at_write: Sending command AT+CGAUTH=0,"PAP","---","---"
    [00:00:02.056,518] <dbg> at_cmd.at_write: Bytes sent: 34
    [00:00:02.056,549] <inf> lte_lc: PDN Auth: AT+CGAUTH=0,"PAP","---","---"
    [00:00:02.060,150] <dbg> lte_lc.w_lte_lc_connect: Network mode: AT%XSYSTEMMODE=1,0,0,0
    [00:00:02.060,150] <dbg> at_cmd.at_write: Sending command AT%XSYSTEMMODE=1,0,0,0
    [00:00:02.067,718] <dbg> at_cmd.at_write: Bytes sent: 22
    [00:00:02.067,749] <dbg> at_cmd.at_write: Sending command AT+CFUN=1
    [00:00:02.130,249] <dbg> at_cmd.at_write: Bytes sent: 9
    AT response: '+CEREG: 2,"0019","0187EB0C",7,0,0,"11100000","11100000"
    '
    
    [00:00:16.891,326] <dbg> at_notif.notif_dispatch: Dispatching events.
    
    [00:00:16.891,357] <dbg> at_notif.notif_dispatch: ctx=0x00000000, handler=0x0000d409
    [00:00:16.905,212] <dbg> at_notif.notif_dispatch: ctx=0x00000000, handler=0x00013bad
    [00:00:16.905,364] <dbg> lte_lc.parse_nw_reg_status: Network registration status: 2
    AT response: '+CEREG: 5,"0019","0187EB0C",7,,,"11100000","11100000"
    '
    
    uarte:~$ Result: 0
    [00:00:18.497,375] <dbg> at_notif.notif_dispatch: Dispatching events.
    
    [00:00:18.497,375] <dbg> at_notif.notif_dispatch: ctx=0x00000000, handler=0x0000d409
    [00:00:18.507,751] <dbg> at_notif.notif_dispatch: ctx=0x00000000, handler=0x00013bad
    [00:00:18.507,904] <dbg> lte_lc.parse_nw_reg_status: Network registration status: 5
    uarte:~$ tcp server
    [00:00:23.658,905] <inf> tcp_srv: TCP server waiting for client...
    [00:00:30.511,474] <err> tcp_srv: ERROR on accept returned -1, errno: 134
    [00:00:30.511,505] <err> tcp_srv: ERROR 'Not supported'
    [00:00:30.511,505] <err> tcp_srv: Closing server

    Best regards

  • May I ask why you want to run a TCP server on the nRF91?

    Looking at the IP traffic in your trace, I only find a single TCP handshake. Also, from the modem side, it looks like the accept() call succeeds, and new socket is created. So it does not look like the problem is in the modem. I have heard that the TCP server support in bsdlib is not very strong, because of the limited use server functionality would have on a low power cellular device.

  • We are migrating from our current solution (using 2g/3g/4g) where our cloud/server connects to devices and pushes data once in a while. This infrastructure is not something we can change in a heartbeat.

    We also want to be able to connect a telnet shell to the devices every once in a while for development, debugging and configuration.

    It sounds promising that it all looks good from the modems point of view.

    It does not sound good that the server support in bsdlib "is not very strong". I think it is odd that you would not support it, why would server be so much more strange or difficult than client? Is it something you will fix or will you stop supporting it?

    Best regards

  • I have asked the bsdlib team for clarification and will get back to you when I get an answer.

    The reason for why the server functionality is not as tested as the client functionality is that in most use cases, the nRF91 will be the client, and the one to initiate the contact. This is both due to power management concerns, but also due to the way the LTE network is implemented. From a power management perspective, it is not optimal to be connected to the network at all times and listen for incoming connections. And from the network side, the device is often heavily sandboxed behind NAT and firewalls, controlled by the network operators. All this means that the server functionality is not much used, and therefore not given as much attention as the client functionality.

    That said, as we do list it as a supported feature, and provide the necessary APIs to use it, it should definitely work. If it is a bug that is causing your problems, I expect that it will be fixed, and I do not expect that we will drop support for TCP server functionality. But, when it comes to support of features etc. your Regional Sales Manager would be more appropriate than a DevZone case. Anyway, as I said, I have asked the bsdlib team to look into your problems, and will get back to you when I get a reply from them.

  • Thank you.

    I understand that this is not the most common use case. NAT is not a problem for us since our devices are not public on the internet, we have VPN to our network providers.

    We look forward hearing what the bsdlib team says.

    Best regards

Reply Children
No Data
Related