I've been trying to carve out time to work on #LoRA again and have revisited https://git.oit.cloud/morgan/esp_netif_lora, my ESP-IDF IP over LoRa driver.

Today I got broadcast and multicast working, my test app, they just need to be put in the driver, with config options.

I've outlined a fix to allow for multiple interfaces if a device has more than one radio.

With multicast working, I think I can finally do #CoAP discovery!

kinda last major improvement for this to be useful is some sort of MTU enforcement.

@nils I did have some reservations about using @ratatui_rs for embedded devices (mainly that they're natively pixel based, so why go through a typewriter interface when there's no legacy) -- but seeing how reasonable that looks in code already at this quick prototype makes me reconsider.

Don't hold your breath for a text based #CoAP web browser, but I'd love to build one.

The sign is a lie (and they knew that advance: train goes only to Köln), but still on my way to #FOSDEM.

Happy any time to talk about #CoAP, #CBOR, #DectNrPlus, IoT security and embedded Rust development, especially on @ariel and @RIOT_OS.

RIOT Summit 2018 @ Amsterdam - Keynote by Jaime Jiménez (Ericsson)

https://makertube.net/w/3owgfnGMGoiVBVQKAwcZ6q

@reiver I think #CoAP is a good fit. It's easy enough to explain on a napkin, extensible, has the familiar REST semantics, and can be implemented on the smallest of devices.

Plus it has a well-vetted security mechanism that is lightweight enough to be implemented by a single person.

We're gathering momentum for slipmux, a transport of #CoAP over serial ports. That specification allows #embedded developers on simple boards that just have a UART to use the same tools with it as for talking to devices across the Internet. This includes security: I guess I just sent the first encrypted request over slipmux ever, and its security setup was unmodified from #ArielOS's CoAP example.
Implementation is available in #RiotOS (#C), and WIP for Ariel (#RustLang) and #aiocoap (#Python).

… and it was a success: We implemented runtime updates over #CoAP, and with our stack's access control, restricting changes to the VM code to authorized users is just a matter of four lines of config.

#IETFHackathon

Development of aiocoap, my Python CoAP library, is approaching its next breaking release.

If there's anything about its usability as a library that has been bugging you, especially if it would require breaking changes: Let me know soon, either here or on the issue tracker at https://github.com/chrysn/aiocoap/issues

#aiocoap #Python #CoAP

@khalid Now that toot makes me kind'a feel bad about wanting to introduce coap:// to that list of #smolweb protocols.

Then again, #CoAP excels at proxying (and was carefully designed to facilitate it even across protocols), so a client could go through a CoAP proxy to access any of the others (unless it happens to implement any of the others as well).

Thanks to @pyodide and @ProjectJupyter, using #CoAP is becoming more accessible: The latest version of the #aiocoap documentation has examples that can be run directly from the documentation, and access CoAP peers through a WebSocket-to-UDP cross proxy:

<https://aiocoap.codeberg.page/aiocoap/doc/pyodide.html#contrib-pyodide>

#Python

Ahhhhhh, our Internet-Draft is in the #RFC Editor queue 😱 #IETF #DNS #CoAP #DoC #DNSoverCoAP https://www.rfc-editor.org/current_queue.php#draft-ietf-core-dns-over-coap

I'm fixing #aiocoap's memory leak tests to finally run as async functions: the original tests employed mechanisms from the age of tulip (back when asyncio was developed out-of-tree), and Python 3.14 dropping some obsolete mechanisms.

Good riddance, but also tough work fixing subtle possible leaks that are suddenly easier to discover.

#Python #CoAP

… and #IETF is not far behind, with https://datatracker.ietf.org/doc/draft-ochkas-cose-ascon/ almost ready to assign algorithm identifiers so this can be used in #OSCORE for #CoAP.

Discussions during the current #IETF meeting led me to write a new draft on a compact CoAP URI expression, Short Paths In CoAP (ShoPinC, following the trade tradition of contrived acronyms).

As not all of the #CoAP crowd is reading the IETF lists, I'm soliciting opinions or feedback from here as well.

https://chrysn.github.io/shopinc/draft-amsuess-core-shopinc.html

#DNS over #CoAP because you can always run X over Y at an IETF hackathon.

#IETF123

I hope that by the end of the year, I can use this in my favorite embedded OSes, @RIOT_OS and @ariel, as well as on bare metal systems, for firmware updates or encrypted #CoAP communication.

@chris_gammell You might want to join this year's @RIOT_OS summit: Rumor has it that there will be a presentation on the tools we use there to bridge the gaps between actual shell use (like, bidirectional character streams) and #CoAP based RPC.
(I didn't plan anything yet, but I do have an implementation of SSH-/mosh-like access to stdin/-out, so maybe I should file a talk too?)

Just released v0.3.1 of my slipmux implementation on crates.io! This releases prominent feature is support for usage in !no_std environments. Check it out at https://crates.io/crates/slipmux

#Slipmux #Rust #Coap #Embedded

As for multicast Block1 (block-wise PUT/POST request)… I think the block-size would have to be negotiated up front via a separate custom option.

Call it MCBlock1 (option 65000), unsigned integer consisting of:
- bits 0-3: SZX - Size exponent
- bit 4: P - Proposal
- bit 5: S - Master selection
- bit 6: C - Master cancellation

When a node wishes to send a blockwise file to a multicast group (via PUT or POST request payload) steps would be:

1. it sends a payload-less NON message to the group with the MCBlock1 option: SZX=its proposed block size exponent, P=1 (this is a proposal), S=0 & C=0 (no selections made)
2. The nodes that hear it, reply NON unicast, with their MCBlock1 responses; SZX=receiver's preferred SZX (same or less than sender), P=1, S=0 & C=0.
3. The sender picks one respondent, sends a UNICAST CON to that node with MCBlock1 with chosen SZX, P=0 (this is now the negotiated block size), S=1 ("I choose you") and C=0.
4. Respondent ACKs that CON message with Block1 set with a matching SZX (and block 0)… it has agreed.
5. Sender now sends to the group a NON message with MCBlock1 to the group: chosen SZX, P=0, S=0 and C=0.
6. The group nodes reply with a NON echoing the options as an acknowledgement.
7. Transfer begins using CON message Block1 with the agreed SZX … the chosen node ONLY sends the ACKs.

If the chosen node stops responding: sender sends a NON MCBlock1 C=1 unicast to that node, then goes back to step 3 to select another node… at step 4 the node responds with Block1 specifying the starting point, and the transfer resumes at step 7.

#CoAP #BlockwiseTransfer #RFC7959