Implement support for LLC sockets by ernestask · Pull Request #1948 · obgm/libcoap

ernestask · 2026-04-03T07:20:57Z

Useful in embedded contexts, where devices might only have a link-layer connection, but still need to exchange information.

ernestask · 2026-04-03T07:26:14Z

The bulk of the code is for address/port/URI handling.

Since this is something that is used at $JOB, I’d love to get this (seemingly) generic feature merged (of course, in a form that is deemed appropriate) and only keep hacking $JOB-specific things on top.

ernestask · 2026-04-13T12:30:14Z

Ping, is this something that could live upstream?

mrdeep1 · 2026-04-13T13:11:14Z

It is something that can be added in upstream , modelled as how AF_UNIX support is done. However, how you specify the Host in the URI in a way that the parser can understand and differentiate between IPv4, IPv6, AF_UNIX and AF_LLC is what I am thinking about.

I am thinking something like

coap://llc[00:11:22:33:44:55]:sap/some/path

where :sap is mandatory. then for the -a option (client) or -A option (server) this could be provided as llc[00:11:22:33:44:55]:sap or perhaps coaps://llc[00:11:22:33:44:55]:sap to differentiate between different upper layer protocols.

I also would prefer not to have to use the -4 option, but use the equivalent AF_UNIX support so that should another AF_* be added, it is easy to slot in.

Support would need to be added in for DTLS and potentially TCP(Stream) and TLS.

ernestask · 2026-04-13T14:01:48Z

Thanks for taking a look!

It is something that can be added in upstream , modelled as how AF_UNIX support is done. However, how you specify the Host in the URI in a way that the parser can understand and differentiate between IPv4, IPv6, AF_UNIX and AF_LLC is what I am thinking about.

I am thinking something like
coap://llc[00:11:22:33:44:55]:sap/some/path
where :sap is mandatory. then for the -a option (client) or -A option (server) this could be provided as llc[00:11:22:33:44:55]:sap or perhaps coaps://llc[00:11:22:33:44:55]:sap to differentiate between different upper layer protocols.

I also would prefer not to have to use the -4 option, but use the equivalent AF_UNIX support so that should another AF_* be added, it is easy to slot in.

Your suggestion looks pretty clean, I like it. Trying to figure out URIs for this was the most time-consuming. :)

Support would need to be added in for DTLS and potentially TCP(Stream) and TLS.

Aye.

Switching back to draft, will change the address handling and then look at additional protocol support.

ernestask · 2026-04-15T08:14:57Z

DTLS and TCP works, didn’t test TLS, but nothing should prevent that from working as well.

One caveat: getpeername() fails for SOCK_STREAM sockets:

Apr 15 10:58:36.862  1 WARN coap_socket_connect_tcp1: getpeername: Transport endpoint is not connected

I believe that one is a kernel bug, so I proposed a fix: https://lore.kernel.org/netdev/20260415063457.1008868-1-ernestas.k@iconn-networks.com/T/

Example use (of course, substitute own interface addresses):

Server

coap-server -U coap+tcp -A 'llc[00:03:7f:12:79:79]:dc'

Client

coap-client -a 'llc[2a:dc:4b:14:4c:41]:dc' 'coap+tcp://llc[00:03:7f:12:79:79]:dc/time'

mrdeep1 · 2026-04-16T15:38:48Z

Thanks for doing this.

coap_print_addr() and coap_print_ip_addr() need updating to handle AF_LLC.

Server man pages (and usage()) need updating for -U option usage, and man / usage() need updating with a LLC example.

One caveat: getpeername() fails for SOCK_STREAM sockets:

Need to do a LLC check here I guess.

mrdeep1 · 2026-04-16T16:11:35Z

Also wondering whether :sap should be in hex, or decimal to be compatible with other host:port definitions.

ernestask · 2026-04-16T16:26:58Z

Also wondering whether :sap should be in hex, or decimal to be compatible with other host:port definitions.

IMO, it would be somewhat unusual to use decimal numbers in this case.

ernestask · 2026-04-16T17:24:18Z

coap_print_addr() and coap_print_ip_addr() need updating to handle AF_LLC.

Done, pending decision re hex vs decimal notation.

Server man pages (and usage()) need updating for -U option usage, and man / usage() need updating with a LLC example.

Updated man pages and added address examples for server under -A in usage, not sure what would be a better place there.

One caveat: getpeername() fails for SOCK_STREAM sockets:

Need to do a LLC check here I guess.

Done, hopefully I’m not wrong about the kernel issue and that will resolve itself eventually.

mrdeep1

In general looking good.

In your environment what is the SAP you are using?

mrdeep1 · 2026-04-17T09:46:40Z

 #define COAP_SOCKET_CAN_CONNECT  0x0800  /**< non blocking client socket can now connect without blocking */
 #define COAP_SOCKET_MULTICAST    0x1000  /**< socket is used for multicast communication */
 #define COAP_SOCKET_SLAVE        0x2000  /**< socket is a slave socket - do not close */
+#define COAP_SOCKET_WANT_SENDTO  0x4000  /**< socket requires a destination address for sending */


I do not believe that COAP_SOCKET_WANT_SENDTO is needed as COAP_SOCKET_CONNECTED is set when COAP_SOCKET_WANT_SENDTO is set.

Perhaps the flag itself isn’t necessary, but sendmsg() without a destination address results in the local socket address being used:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/llc/af_llc.c?id=85cb0757d7e1f9370a8b52a8b8144c37941cba0a#n945

Notice how &llc->addr is used and not &llc->daddr:

if (addr) { if (msg->msg_namelen < sizeof(*addr)) goto out; } else { if (llc_ui_addr_null(&llc->addr)) goto out; addr = &llc->addr; }

Not sure if this behavior is intended, need to spend more time looking at the code, but some way to force using sendto() is needed. Otherwise, the client will just send messages to itself (Wireshark quickly revealed why nothing seemed to work).

Yes, we need to keep this. However, it is required to not do a send(), but to do a sendmsg() or sendto() depending on whether HAVE_STRUCT_CMSGHDR is set or not circa line 680 in src/coap_dgrm_posix.c.

Right, sorry, I use those three interchangably (since send() and sendto() are pretty much just wrappers for sendmsg(), at least on Linux). Indeed the goal is to avoid plain send() and go straight to sendmsg() with constructed header or sendto() with destination address.

Should I change anything here?

No change required here.

ernestask · 2026-04-17T10:12:49Z

In general looking good.

In your environment what is the SAP you are using?

I see equal parts of AC and AE. This is all before my time, so I can just guess that random not-well-known values were picked.

mrdeep1 · 2026-04-17T12:37:30Z

We need to document a client example in man/coap-client.txt.in for llc. It seems we need the -a option for coap/coaps, but not for coap+tcp/coaps+tcp..

ernestask · 2026-04-17T14:04:45Z

We need to document a client example in man/coap-client.txt.in for llc. It seems we need the -a option for coap/coaps, but not for coap+tcp/coaps+tcp..

Ah, that would be something to fix. AF_LLC sockets auto-bind to the first available interface if not bound explicitly. Requiring -a always rules out surprising behavior.

Useful in embedded contexts, where devices might only have a link-layer connection, but still need to exchange information.

ernestask · 2026-04-17T15:25:32Z

Pushed a change to require -a for clients when the destination is an LLC host and added an example to the client man page.

ernestask force-pushed the llc branch 5 times, most recently from a06fffd to a69852a Compare April 9, 2026 12:00

ernestask marked this pull request as draft April 13, 2026 14:01

ernestask force-pushed the llc branch 4 times, most recently from 867dcfa to f44f6d2 Compare April 15, 2026 07:58

ernestask marked this pull request as ready for review April 15, 2026 08:14

ernestask force-pushed the llc branch from f44f6d2 to cc5f975 Compare April 15, 2026 08:22

ernestask force-pushed the llc branch 2 times, most recently from 725721f to ca1a8dc Compare April 16, 2026 17:21

mrdeep1 requested changes Apr 17, 2026

View reviewed changes

ernestask force-pushed the llc branch from ca1a8dc to d448a26 Compare April 17, 2026 10:25

Implement support for LLC sockets

f375f3c

Useful in embedded contexts, where devices might only have a link-layer connection, but still need to exchange information.

ernestask force-pushed the llc branch from d448a26 to f375f3c Compare April 17, 2026 15:24

Conversation

ernestask commented Apr 3, 2026

Uh oh!

ernestask commented Apr 3, 2026

Uh oh!

ernestask commented Apr 13, 2026

Uh oh!

mrdeep1 commented Apr 13, 2026

Uh oh!

ernestask commented Apr 13, 2026

Uh oh!

ernestask commented Apr 15, 2026

Uh oh!

mrdeep1 commented Apr 16, 2026

Uh oh!

mrdeep1 commented Apr 16, 2026

Uh oh!

ernestask commented Apr 16, 2026

Uh oh!

ernestask commented Apr 16, 2026

Uh oh!

mrdeep1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mrdeep1 Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

ernestask Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrdeep1 Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

ernestask Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

mrdeep1 Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

ernestask commented Apr 17, 2026

Uh oh!

mrdeep1 commented Apr 17, 2026

Uh oh!

ernestask commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ernestask commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ernestask Apr 17, 2026 •

edited

Loading

ernestask commented Apr 17, 2026 •

edited

Loading