APIPA (AutoIP)

TinyCLR OS
21

hopefully 2.1 is around the corner

22

When are you planning to add AutoIP?

23

We have been busy adding other more requested features and we didn’t get to it. Why not use DHCP?

24

DHCP requires a service. APIPA is serverless.

I think this has to be done at the firmware level unless the TinyCLR socket lib supports things like ETH_P_ARP at the C# level (haven’t investigated sending/receiving ARP packets myself).

25

I understand that. I am curious why this is the only time this has come up in over 10 years. I am always trying to learn and understand the end application and so I may ask too many questions :slight_smile:

1 Like
26

It would make it easier to configure a device that doesn’t have a UI. Once it has a valid IP it is much easier to find it on the network.
I guess it is possible to use a default IP like routers and wifi radios but then you usually have to fiddle with your PC IP settings to get it configured. Or in a worse case, as I have had, a Ubiquiti radio reset to default values. Its default IP address was the same as the PLC running the plant. Everything shut down until it could be figured out.

27

Which you can do with DHCP. What am I missing?

28

If you have a network of embedded devices then there is no DHCP server. (i.e. closed control networks, etc.)

29

Our devices can work in LAN without DHCP.
Or devices can be connected directly to the PC

30

Gus, if DHCP solved world hunger, why is APIPA even a thing?

Because there are many use cases, either device to device or secure/controlled environments where you will not get an IP address issued but you still need to communicate to other devices.

31

The previous post actually gave me a perfect example, 2 SITCore devices connected directly over ethernet can’t be done today (unless they are both static IP)… And we are going to fix that :grin:. AutoIP is getting investigated as of this morning.

5 Likes
32

AutoIP was just added and tested. Coming this week in preview2

6 Likes
33

I tested AutoIP today. It works incorrectly. Section 2.1 of RFC 3927 requires that the address be generated from a pseudo-random number generator initialized with a MAC address. Before assigning an address, you need to make sure that no one is using it. To do this, you need to send an ARP packet requesting “give me the MAC of 169.254.4.5”. If the MAC is found, then the ip address is already taken - generate a new random ip and repeat the ARP request.

34

Yes that is what we have. Please provide more info.

35

I connected my device to a PC. The IP address on the computer was 169.254.29.222 and on the device 169.254.1.0 (why 169.254.1.0 ?)

36

Then I assigned a static IP address on the computer to 169.254.1.0. Disconnected and reconnected the cable. On the device again, the ip address is 169.254.1.0 !!!

37

What is the MAC address of your device?

WiFi or ethernet?

38

I use enc28. MAC from example MacAddress = new byte[] { 0x00, 0x4, 0x00, 0x00, 0x00, 0x00 }

39

Then I connected the device to LAN with DHCP. device again with ip address 169.254.1.0 !!! After rebooting the device, it has a normal ip 192.168.0.220 from the DHCP server

40

Can you please tell me why you think this is wrong?