Problem with UDP receive

[spamcoll]

Hello,

I need to send and receive UDP packets using nRF9160DK via NB-IoT network. I'm able to achieve this using Serial LTE modem. However I need to write my own application to use SPI, LED, etc... I tried to modify UDP example to be able to not only send UDP packets but also receive them. 

The only modification to original UDP example code is in main.c in function server_transmission_work_fn:

static void server_transmission_work_fn(struct k_work *work) {
    int err;
    char buffer[CONFIG_UDP_DATA_UPLOAD_SIZE_BYTES] = {valve_state};

    printk("Transmitting UDP/IP payload of %d bytes to the ",
           CONFIG_UDP_DATA_UPLOAD_SIZE_BYTES + UDP_IP_HEADER_SIZE);
    printk("IP address %s, port number %d\n",
           CONFIG_UDP_SERVER_ADDRESS_STATIC,
           CONFIG_UDP_SERVER_PORT);

    err = send(client_fd, buffer, sizeof(buffer), 0);
    if (err < 0) {
        printk("Failed to transmit UDP packet, %d\n", errno);
        return;
    }


    printk("Start receive\n");
    int max_len = 25;
    char data[576];
    err = recvfrom(client_fd, data, max_len, 0, NULL, NULL);
    if (err < 0)
        printk("Receive unsuccessful: %d \n", err);

    printk("First byte is: %d\n", data[1]);

    k_delayed_work_submit(&server_transmission_work, K_SECONDS(CONFIG_UDP_DATA_UPLOAD_FREQUENCY_SECONDS));
}

I basically added just function recvfrom. I'm using newest sdk version 1.5.1.

After restart nRF9160 successfully connect to network, send UDP packet and start waiting for downlink packet. But after I send packet from server application doesn't receive anything and continues waiting forever.

As I said, the receive worked fine when I used Serial modem LTE and from what I looked to the source code the sequence of commands to modem was the same. Can anybody explain this behaviour or help solve my problem?

Thanks for any help

[Carl Richard]

Hello!

Apologies for the late answer here. Did you try to simply do recv instead of recvfrom? It should work as the socket should be connected to the server. A colleague of mine made a simple sample on fetching time from an NTP server using UDP a while back. You can use that as a reference!

Best regards,
Carl Richard

[spamcoll]

I have tried use recv instead of recvfrom, but no luck.

I also tried to compile your NTP server but I got this cmake error:

error: NET_RAW_MODE (defined at subsys/net/ip/Kconfig:53) is assigned in a configuration file, but
is not directly user-configurable (has no prompt). It gets its value indirectly from other symbols.
See http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_NET_RAW_MODE.html and/or look up
NET_RAW_MODE in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

I didn't find any solution to this error, but maybe the NTP server was build for older version of ncs than what I have (I assume it because last commit to NTP is two years old).

But from what I looked into code, the sequence of command is quite similar to my UDP example. Do you think it would be possible to identify the source of problem in my code? I was thinking, maybe the problem is in one of the config files. The problem isn't surely in the hardware since I can receive messages just fine with Serial modem LTE application. 

[Carl Richard]

Hello again!

Understood. Thanks for testing! You are correct that the sample is very old, so it's likely that it won't work out of the box. However, you could be correct that it may be an issue with your configuration. Please share your "prj.conf" as well as "<project_directory>/build/zephyr/include/generated/autoconf.h".

Best regards,
Carl Richard

[spamcoll]

I use the default "prj.conf" you use in ntp sample.

Since cmake was not successful the file <project_directory>/build/zephyr/include/generated/autoconf.h" was not generated. I checked and in other successfully compiled projects "autoconf.h" is generated. 

[Carl Richard]

Thanks! Could you share the configuration and autoconf from the sample you initially tested as well? The one that built successfully that is. 

I think we should focus on that, and not the NTP sample for now.

Best regards,
Carl Richard