In the TinyCLR OS 2 have Automatic Private IP Addressing (APIPA)?
Only DHCP. Can it be implemented in your end? I am guessing it uses upd broadcast?
I want to use my device both on the local network (via the router) and directly (PC-Device).
But for AutoIP to work fully (without conflict of IP addresses) ARP support is required.
https://wiki.wireshark.org/APIPA
Added to issues, to be looked into Support AutoIP · Issue #577 · ghi-electronics/TinyCLR-Libraries · GitHub
Looking here, you can just assign the IP yourself What is Auto IP? we will look into ti in the future.
This is automatically supported and required by any TCP/IP stack. What am I missing here?
Show me how to send an ARP packet requesting a MAC address?
That is built in the system
AutoIP not vs DHCP. But as an addition, if there is no dhcp server in network
Show me, how to send an ARP packet?
You do not, it is internal and automatic. My understanding is that you simply need to set the system to a static IP of the range explained in the link I sent.
Maybe ARP is needed to check if there ip you selected is being used?
ARP is used for IP-to-MAC address resolution - in this case, it’s to check if the IP you randomly decide from the zeroconf range is used elsewhere. You decide to use 169.254.4.5 say, but before you allocate that you broadcast an ARP request saying “give me the MAC of 169.254.4.5” and when the local LAN responds and gives you a valid MAC, then you know you have a conflict and you redo your random selection of address and repeat the ARP request. So you need a way of, prior to assigning your random IP address to the interface, of issuing and receiving an ARP packet.
1 Like
Got it. This means we have to implement on our end as ARP is not exposed for user consumption.
RFC 3927 page 11, section 2.2.1 in http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt is the best reference I’ve seen, although almost word for word same as RFC 5227 https://www.ietf.org/rfc/rfc5227.txt
2 Likes
Maybe you implement API for
?
IMHO the complexity of zeroconf warrants staying away from user-level code.
the PC-like experience is that if after the DHCP requests time out it still hasn’t resolved an address, the device moves into zeroconf / APIPA mode and does all this for you. You end up with a valid “DHCP-like” address, and access to the connected network.
Once a device comes up on a zeroconf network address, it still needs to find a communication partner; not sure what device discovery protocol you were going to implement that to connect between your PC and your device? That becomes a different question!
2 Likes
Definitely agree with Brett - AutoIP belongs at the firmware level.
There’s a real balancing act here though. Memory (flash and static) on these devices is precious - adding every feature in a one-size-for-all attempt isn’t a winning strategy, and you’re already carrying the cost of features in firmware (like signal gen, etc) that you may never use in your particular app.
What’s really needed here is a firmware-level native-code shared-library (.dll/.so) model so that what you use in application code pulls in the right relocatable native code modules. That’s a non-trivial bit of engineering, but definitely doable. That would make TinyCLR a micro-kernel and increase the utility factor for memory (mem consumed vs mem actually utilized by your app).
A native module strategy would mean that you could pull in sig gen, wifi onboarding, AutoIP, and maybe even higher-order stuff like Thing protocol, as-needed and at native-code performance. It would also allow users to create relocatable binary modules instead of having a fixed native-code extensibility reservation in memory.
2 Likes
I did not tell you this but TinyCLR OS internals are already prepped for dynamic loading of native code. Meaning, when you load SPI assembly, you will be loading both native and managed code and all get plugged in on the fly.
Why haven’t we enabled this? The chip we use has plenty of resources and this is more secure. However, what if we want to run TinyCLR on a $1 chip?
… anyway I did not speak of any of this!!!
3 Likes
Hello Gus. When are you planning to add support for AutoIP mode?
It doesn’t look like it is going to make it into 2.0 since we are about to release production. But it is still on the list for 2.1