Unable to send packets with UDP sock #8457

rfuentess · 2018-01-26T15:56:15Z

Hi people,

Description

I was working with a simple sock UDP client/server code when I noticed I lost the ability to send UDP messages. Though, the gcoap example is working fine.

As I was unable to determine the source of my problem, I run test/gnrc_sock_udp in the current master and got errors. Can anyone else confirm this behavior?

Steps to reproduce the issue

tests/gnrc_sock_udp$ BOARD=native make all test

Expected results

Execution of the test with the release 2017.10:

./tests/01-run.py
/home/rfuentess/Projects/RIOT/tests/gnrc_sock_udp/bin/native/tests_gnrc_sock_udp.elf  
RIOT native interrupts/signals initialized.
LED_RED_OFF
LED_GREEN_ON
RIOT native board initialized.
RIOT native hardware initialization complete.

main(): This is RIOT! (Version: 2017.10-bigboss-HEAD)
Calling test_sock_udp_create__EADDRINUSE()
Calling test_sock_udp_create__EAFNOSUPPORT()
Calling test_sock_udp_create__EINVAL_addr()
Calling test_sock_udp_create__EINVAL_netif()
Calling test_sock_udp_create__no_endpoints()
Calling test_sock_udp_create__only_local()
Calling test_sock_udp_create__only_local_reuse_ep()
Calling test_sock_udp_create__only_remote()
Calling test_sock_udp_create__full()
Calling test_sock_udp_recv__EADDRNOTAVAIL()
Calling test_sock_udp_recv__EAGAIN()
Calling test_sock_udp_recv__ENOBUFS()
Calling test_sock_udp_recv__EPROTO()
Calling test_sock_udp_recv__ETIMEDOUT()
 * Calling sock_udp_recv()
 * (timed out with timeout 1000000)
Calling test_sock_udp_recv__socketed()
Calling test_sock_udp_recv__socketed_with_remote()
Calling test_sock_udp_recv__unsocketed()
Calling test_sock_udp_recv__unsocketed_with_remote()
Calling test_sock_udp_recv__with_timeout()
Calling test_sock_udp_recv__non_blocking()
Calling test_sock_udp_send__EAFNOSUPPORT()
Calling test_sock_udp_send__EINVAL_addr()
Calling test_sock_udp_send__EINVAL_netif()
Calling test_sock_udp_send__EINVAL_port()
Calling test_sock_udp_send__ENOTCONN()
Calling test_sock_udp_send__socketed_no_local_no_netif()
Calling test_sock_udp_send__socketed_no_netif()
Calling test_sock_udp_send__socketed_no_local()
Calling test_sock_udp_send__socketed()
Calling test_sock_udp_send__socketed_other_remote()
Calling test_sock_udp_send__unsocketed_no_local_no_netif()
Calling test_sock_udp_send__unsocketed_no_netif()
Calling test_sock_udp_send__unsocketed_no_local()
Calling test_sock_udp_send__unsocketed()
Calling test_sock_udp_send__no_sock_no_netif()
Calling test_sock_udp_send__no_sock()
ALL TESTS SUCCESSFUL

Actual results

Execution of the test with current master (2018.04-devel-46-g8ab83):


./tests/01-run.py
/home/rfuentess/Projects/RIOT/tests/gnrc_sock_udp/bin/native/tests_gnrc_sock_udp.elf  
RIOT native interrupts/signals initialized.
LED_RED_OFF
LED_GREEN_ON
RIOT native board initialized.
RIOT native hardware initialization complete.

main(): This is RIOT! (Version: 2018.04-devel-46-g8ab83-bigboss)
Calling test_sock_udp_create__EADDRINUSE()
Calling test_sock_udp_create__EAFNOSUPPORT()
Calling test_sock_udp_create__EINVAL_addr()
Calling test_sock_udp_create__EINVAL_netif()
Calling test_sock_udp_create__no_endpoints()
Calling test_sock_udp_create__only_local()
Calling test_sock_udp_create__only_local_reuse_ep()
Calling test_sock_udp_create__only_remote()
Calling test_sock_udp_create__full()
Calling test_sock_udp_recv__EADDRNOTAVAIL()
Calling test_sock_udp_recv__EAGAIN()
Calling test_sock_udp_recv__ENOBUFS()
Calling test_sock_udp_recv__EPROTO()
Calling test_sock_udp_recv__ETIMEDOUT()
 * Calling sock_udp_recv()
 * (timed out with timeout 1000000)
Calling test_sock_udp_recv__socketed()
Calling test_sock_udp_recv__socketed_with_remote()
Calling test_sock_udp_recv__unsocketed()
Calling test_sock_udp_recv__unsocketed_with_remote()
Calling test_sock_udp_recv__with_timeout()
Calling test_sock_udp_recv__non_blocking()
Calling test_sock_udp_send__EAFNOSUPPORT()
Calling test_sock_udp_send__EINVAL_addr()
Calling test_sock_udp_send__EINVAL_netif()
Calling test_sock_udp_send__EINVAL_port()
Calling test_sock_udp_send__ENOTCONN()
Calling test_sock_udp_send__socketed_no_local_no_netif()
tests/gnrc_sock_udp/main.c:454 => 0x804ca20
*** RIOT kernel panic:
FAILED ASSERTION.

    pid | name                 | state    Q | pri | stack  ( used) | base addr  | current    
      - | isr_stack            | -        - |   - |   8192 (   -1) |  0x806b800 |  0x806b800
      1 | idle                 | pending  Q |  15 |   8192 (  568) |  0x8069600 |  0x806b474
      2 | main                 | running  Q |   7 |  12288 ( 2756) |  0x8066600 |  0x8069474
      3 | ipv6                 | bl rx    _ |   4 |   8192 ( 1184) |  0x8074800 |  0x8076674
      4 | udp                  | bl rx    _ |   5 |   8192 ( 1248) |  0x80727c0 |  0x8074634
        | SUM                  |            |     |  45056 ( 5756)

*** halted.

Versions

~/RIOT$ ./dist/tools/ci/print_toolchain_versions.sh
Installed toolchain versions
----------------------------
          native gcc: gcc (Debian 4.9.2-10) 4.9.2
          msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
             avr-gcc: avr-gcc (GCC) 4.8.1
   arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
    mips-mti-elf-gcc: missing/error
./dist/tools/ci/print_toolchain_versions.sh: 81: ./dist/tools/ci/print_toolchain_versions.sh: clang: not found
arm-none-eabi-newlib: "2.5.0"
 mips-mti-elf-newlib: missing/error
            avr-libc: "1.8.0svn" ("20111229")
            cppcheck: Cppcheck 1.67
          coccinelle: spatch version 1.0.0-rc22 with Python support and with PCRE support

The text was updated successfully, but these errors were encountered:

miri64 · 2018-01-26T15:59:27Z

I'm going to look into it ASAP.

kYc0o · 2018-01-26T16:00:22Z

I was thinking, why sock is not into the release specs?

miri64 · 2018-01-26T16:01:34Z

I was thinking, why sock is not into the release specs?

The test @rfuentess is using is in the release specs (Task 2), so it would have come up eventually.

kYc0o · 2018-01-26T16:04:05Z

Oh I see, I thought it was not included because I didn't find it explicitly into the single hop tests or something like that.

rfuentess · 2018-01-26T16:15:05Z

After playing with git bisect I got this:

861035f22d94ad063153ce180a04d827246d8fad is the first bad commit
commit 861035f22d94ad063153ce180a04d827246d8fad
Author: Martine Lenders <[email protected]>
Date:   Thu Jul 27 15:26:49 2017 +0200

    gnrc: integrate gnrc_netif2
    
    Not link-able, since NDP and NC are missing (intentionally)

:100644 100644 3f3975fc32bd625a6743ecbd382441596332365c e2ddc51554eacd323ce7631c3d22e3f3787e24e7 M	Makefile.dep
:040000 040000 ae1bd50c430f30ddb2a616c9be70a55553cd6e8b 5f81f5ad68315c2cb0ad4b4449e9c6d07908ad10 M	boards
:040000 040000 29a75bb50a0cf4f88ecf64f4b5bceae2affa67df ff867fc6120380a1c2c8a9d0132a06840ebd327a M	cpu
:040000 040000 b410586268dbd6011ff0a9f84ad99079eff3da9a b012fa166da40828bb207cce015803107ade9e9f M	examples
:040000 040000 48c21375bc8452951dd32d4e4f8654c4414ad1e1 b1b4bf98400e8ec649e935cb742f8877cb0c8e7d M	pkg
:040000 040000 9565c4cb96f78ece69bd3bd305efbf7955b6630c e723baff26b13e82c851fca7bc71cef26069346f M	sys

miri64 · 2018-01-26T16:37:41Z

gnrc: integrate gnrc_netif2

Well that was to be expected that is was one of these reworks ;-). Found the error in the tests at least btw (will open a PR in a moment), but I'm not sure this helps you with your sock_udp problem.

miri64 · 2018-01-26T16:40:39Z

See #8459

miri64 · 2018-01-26T16:41:02Z

@rfuentess can you see if your other problems are also fixed with #8459?

rfuentess · 2018-01-26T16:49:03Z

@miri64 #8459 already tested, and sadly not, my UDP client is still not working. Which is bizarre, the commit previous to the faulty one is not giving me problems with my sock UDP client.

By the way, my client believes the message was sent (sock_udp_send returns value greater than zero), but the package is never send.

miri64 · 2018-01-27T06:31:19Z

Not fixed, as reported by @rfuentess.

miri64 · 2018-01-27T06:32:16Z

I'll look into it. Error codes can mean nothing with GNRC.

ilf-S · 2018-01-27T14:50:19Z

We encountered an issue that could potentially be related to this one, but we are not sure.

Compiled the SNTP test on bluepill with attached AT86RF212b. When we try to get NTP time from the server we are not able to. tcpdump on the server shows an incoming and outgoing NTP packet, but the console on RIOT reports this (i'm cleaning up the IPv6 address, as those are routable and public):

<0xff>main(): This is RIOT! (Version: 2018.04-devel-78-g74d3-x220)
> ntpdate 2001:XXX:XXXX:XXXX::1
udp: GNRC_NETAPI_MSG_TYPE_SND
Error receiving message
Error in synchronization
> udp: GNRC_NETAPI_MSG_TYPE_RCV
udp: unable to forward packet as no one is interested in it

This is with ENABLE_DEBUG(1) both on the SNTP and GNRC_UDP modules.

Could this potentially be related or is this another issue?

rfuentess · 2018-01-29T14:46:52Z

My original issue that led me to detect the faulty test is now identified: When link-local addresses are used, an interface must be set explicitly (even if there is only one), before the rework it was not necessary, yet it was a faulty behavior.

PR #8470 mitigates this behavior. Of course, a more robust client is the best solution for scenarios with multiple interfaces.

Sadly, this means that @ilf-S 's issue is not related to this one as they are using global scope addresses.

miri64 · 2018-01-29T14:50:42Z

@ilf-S regarding your problem: it looks like the timeout is set too tight (I think up until now it was only tested in a local set-up). If the problem persists with a larger timeout, please open a separate issue.

miri64 · 2018-01-29T14:55:01Z

(the default timeout is 5000 μs which might indeed be pretty low for a IEEE 802.15.4 multihop scenario).

ilf-S · 2018-01-29T15:48:02Z

I don't know if I should continue writing in this issue, if it's wrong, I'm sorry, let me know if I should open a new one.

Just a bit more info on the issue. Despite using global addresses, we are talking about an SNTP (openntpd) server literary on the next hop (i.e. RaspberryPi serving as BR). My first thought was that the timeout was too low, so I tried with different timeouts going as high as 100000. The result is still the same:

> ntpdate 2001:XXXX:XXXX:1044::1 100000
udp: GNRC_NETAPI_MSG_TYPE_SND
Error receiving message
Error in synchronization
> udp: GNRC_NETAPI_MSG_TYPE_RCV
udp: unable to forward packet as no one is interested in it

Sidenote: tcpdump on RPi shows an incoming NTPv4 packet and an outgoing one. NTP server stats report client querying it. Advises are welcome.

miri64 · 2018-01-29T17:46:51Z

Please let's discuss this in a separate issue, otherwise we risk this discussion to get lost.

miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: network Area: Networking GNRC labels Jan 26, 2018

miri64 self-assigned this Jan 26, 2018

miri64 mentioned this issue Jan 26, 2018

gnrc_ipv6_nib: release packages for forwarding error cases #8459

Merged

smlng closed this as completed in #8459 Jan 26, 2018

miri64 reopened this Jan 27, 2018

This was referenced Jan 29, 2018

Release 2018.01 - RC2 RIOT-OS/Release-Specs#58

Closed

gnrc_sock: set remote network interface implicitly #8470

Merged

rfuentess closed this as completed Jan 29, 2018

rfuentess mentioned this issue Feb 16, 2018

Improving TinyDTLS package and dtls-echo example #7615

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to send packets with UDP sock #8457

Unable to send packets with UDP sock #8457

rfuentess commented Jan 26, 2018

miri64 commented Jan 26, 2018

kYc0o commented Jan 26, 2018

miri64 commented Jan 26, 2018

kYc0o commented Jan 26, 2018

rfuentess commented Jan 26, 2018

miri64 commented Jan 26, 2018

miri64 commented Jan 26, 2018

miri64 commented Jan 26, 2018

rfuentess commented Jan 26, 2018 •

edited

Loading

miri64 commented Jan 27, 2018

miri64 commented Jan 27, 2018

ilf-S commented Jan 27, 2018 •

edited

Loading

rfuentess commented Jan 29, 2018

miri64 commented Jan 29, 2018

miri64 commented Jan 29, 2018

ilf-S commented Jan 29, 2018 •

edited

Loading

miri64 commented Jan 29, 2018

Unable to send packets with UDP sock #8457

Unable to send packets with UDP sock #8457

Comments

rfuentess commented Jan 26, 2018

Description

Steps to reproduce the issue

Expected results

Actual results

Versions

miri64 commented Jan 26, 2018

kYc0o commented Jan 26, 2018

miri64 commented Jan 26, 2018

kYc0o commented Jan 26, 2018

rfuentess commented Jan 26, 2018

miri64 commented Jan 26, 2018

miri64 commented Jan 26, 2018

miri64 commented Jan 26, 2018

rfuentess commented Jan 26, 2018 • edited Loading

miri64 commented Jan 27, 2018

miri64 commented Jan 27, 2018

ilf-S commented Jan 27, 2018 • edited Loading

rfuentess commented Jan 29, 2018

miri64 commented Jan 29, 2018

miri64 commented Jan 29, 2018

ilf-S commented Jan 29, 2018 • edited Loading

miri64 commented Jan 29, 2018

rfuentess commented Jan 26, 2018 •

edited

Loading

ilf-S commented Jan 27, 2018 •

edited

Loading

ilf-S commented Jan 29, 2018 •

edited

Loading