#IPv6, #EUI64 und #IoT

Ein deutscher Heizungshersteller bietet ein IoT Connector für seine Heizungen/Wärmepumpen an. Dieser kann DualStack (yeah) allerdings EUI64 GUA (😭 ).
DNS ist #IPv4only A/AAAA Queries und im Moment sind alle Endpunkt für APIs #IPv4only weil #azure

Was können wir tun, damit #lwIP #RFC7217 #RFC8981 kann?

was sich so alles fast acht Jahre lang in open Source Code unbemerkt verstecken kann.

https://github.com/SmingHub/Sming/issues/2936

#bug #lwip

@stefan @Larvitz running my main wifi and guest wifi since month #ipv6mostly
Family accepted. Only if I take the streaming devices the #IPv4 away, they break.
Home Assistant runs fine IPv6only. Wish that ESPhome could get rid of dual stack as well.

We need proper #IPv6 support in #lwip Anyone knowing how to support this?

Uvoks daily struggle.

"Huh?? Why does the LwIP stack send an ACK for a second incoming TCP connection?? I only accept one at a time!?!?"

Apparently, that's a "backlog", and it's suffering you can't turn off completely.
If I really want to only work with one client at a time, I probably have to accept and close the other sockets immediately?

(No, setting backlog to 0 on listen doesn't help)

#esp32 #lwip #networking

Accessing #lwip directly seems to work pretty ok already.

Now I'm trying to see how far I can implement rudimentary #Arduino framework compatibility (before losing interest in the tedium).

After some hours, the EthernetClient finally behaved enough for a simple TCP echo test :D

#WCH #CH32 #CH32V208

Progress of the night: Getting the essentials of the #lwip stack running on the #CH32V208.

Still need to clean it up _a lot_ and build the wrapping library, so it's actually useful.
But seeing lwip run at all is amazing.
(So I don't need to depend on the proprietary, closed source #WCHNET library)

Good night :D

#WCH #CH32

It's still got some issues, but looks like UDP/IP works for the most part. I've done a couple #CoAP requests, so that's cool.

There's a bit of into in the repo but this will need more detail and a larger writeup of the whole project(s), covering
#ESP32 #NetIF <> #ESPNow,
#LwIP over ESPNow
#Linux #TUNTAP <> #ESPNow

And that's all just been groundwork for what I really want to do (recap: CoAP like serverless #MQTT)

https://git.oit.cloud/morgan/ifnow.git

holy heck! I got #CoAP over #LoRa working! I had expected more issues with packet management, waiting for TX to complete specifically but one again it's 'just worked'. Admittedly with only two devices in a tame environment but still super cool. In addition I found the 223.0.blah broad address wasn't going to work without additional work but turns out CoAP with #LwIP will respond to requests on, 255.255.255.255.

I did a write up on my recent work with #ESP32 #ESP-NETIF #ESPNow #LwIP and #CoAP

CoAP over Everything:
https://oit.cloud/posts/2023-12-30-coap-over-everything/

This is going to be a bit of a living post, serving as my memory and progress report on this exploration.

And why not another #ESP32 component...
`esp_ifnet_lora` #LwIP binding for #LoRa again using ESP-IFNET.

https://git.oit.cloud/morgan/esp_netif_lora

oh hai #LwIP over #LoRa

and thrr we have it, first pass at `esp_netif_now`, #LwIP interface over #ESPNow. Surprisingly capable for pretty minimal code.

I'm really excited to experiment with this for projects I'd normally use #MQTT on #esp32

https://git.oit.cloud/morgan/esp_netif_now

Very happy with progress of getting #CoAP over #ESPNow going. Basically works but is a pile of hack. Single file composed of various bits of #espidf example, driver and test code. So I'm going to spend today rewriting it, as at least 2 distinct components. One will be `esp-netif-now`, binding ESP-Now to #LwIP. The other part would be a more abstract, "what does serverless MQTT look like?". I'll continue posting my stream of conciseness here and if I can figure out audio issues, I'll also stream.

It's like #LwIP should be binding a listener to the source port it sends the request to.... but is not.

Progress?! The #CoAP client side *is* connecting to the server, and the server *is* responding and I *think* I see the response packet coming back to the client side, but #LwIP just seems to.... stop.

huh, I might actually be a sprinkling of Semephores away from this actually working.

I got #LwIP over #ESPNow working, with basic UDP packets, LwIP seemingly taking care of ARP.

But if I enable the #CoAP server/client everything just seems to go to broadcast, like the increased traffic is breaking something.

Still mostly immobile so I'm still hacking on this. I'm especially excited for this route (using ESP-NETIF) because once I figure it out, it would be trivial to implement over #LoRa

I've been tinkering with this idea of #CoAP over [insert broadcastable media] for a while now.

It started largely with #LoRa but I slid down a #LwIP rabbit hole that derailed that experiment.

I'm now rethinking it in context of my #ESP32 based workshop dust collection remote. I'm trying to achieve faster startup times and connecting to WiFi is by far the biggest bottleneck.

0 / rambling on...

I trying to add #mldv2 ( #ipv6 #multicast ) support into #lwip
According RFC It looks that subscribers should always send report to query from router but I tried this with both Win and Linux an no OS is doing it.

Did I get it wrong?
current lwip with mldv1 seems to be ignoring any queries as well.

More details here: https://networkengineering.stackexchange.com/questions/84037/should-ipv6-multicast-subscribers-send-report-to-query

@cv Everything except #lwIP and the FatFS library. But i'm going to replace the FAT library with a driver that is able to handle asynchronous I/Os. Network is working super well tho, lwIP is very Zig-compatible.

All apps, kernel and so on is written in pure Zig, and it's very convenient