• AVR Freaks

AnsweredHot!H3 Link-local Zeroconf module never announces its new IP address

Author
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
2020/09/16 14:10:21 (permalink)
0

H3 Link-local Zeroconf module never announces its new IP address

I'm trying out the LLZC module in Harmony 3, which from what I can tell is pretty much exactly the same as the module in Harmony 2, and I can see in the MPLAB X debugger that the CPU (ATSAME54P20A on the SAME54 XPro board) is stepping through the state machine in TCPIP_ZCLL_Process() correctly. I see it do the proper calls to TCPIP_ZCLL_ARPAction() to probe for an IP address PROBE_NUM (3) times in the SM_ADDR_PROBE state and later call that same function in the SM_ADDR_CLAIM state ANNOUNCE_NUM (2) times to send out announcement ARPs. This matches up with Section 2 of RFC3927 and that's good.
 
The problem is that, despite the state machine in TCPIP_ZCLL_Process() doing the presumably correct thing, the announcement ARPs are never actually sent. I see the 3 probe ARPs in Wireshark just fine, but zero announcement ARPs. This makes me think there's something going on with the ARP module that is stopping the announcements from getting sent. The TCPIP_ZCLL_ARPAction() function just calls TCPIP_ARP_Probe(), which itself calls _ARPProbeAddress(). That function just seems to return ARP_RES_ENTRY_QUEUED instead of doing anything. I presume that means that the given ARP request should be sent later, but later never comes.
 
I did also notice that the SM_ADDR_PROBE state in TCPIP_ZCLL_Process() calls the TCPIP_ARP_IsResolved() function, but no other states do. Is that the issue?
 
I can ping the board with the probed-for address, so it does claim successfully, but I would assume you probably want the announcement ARPs to go out. The ARP module and ZCLL module settings in the Harmony 3 Configurator are all at their defaults.
#1
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/16 14:12:41 (permalink)
0
Here's a simple Wireshark capture to show what I am seeing. Notice that there 3 ARP probes, but no announcements. Also notice at the end that the firmware responds to only 1 of 4 ARP requests from my PC.
#2
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/21 10:46:34 (permalink)
0
I think I fixed the announcement issue. It turns out that you can force an ARP to be sent by using the ARP_OPERATION_PROBE_ONLY flag. Given that we're just announcing rather than probing at this stage it seems safe to do this.
 
I updated the SM_ADDR_CLAIM state in TCPIP_ZCLL_Process() like so:
 

if ( hZcll->bDefaultIPTried < ANNOUNCE_NUM )
{
    TCPIP_ZCLL_ARPAction(pNetIf,&hZcll->temp_IP_addr,&hZcll->temp_IP_addr, ARP_OPERATION_REQ | ARP_OPERATION_CONFIGURE | ARP_OPERATION_PROBE_ONLY, ZCLL_ARP_CLAIM);
    (hZcll->bDefaultIPTried)++;
 
    printf("Sending ANNOUNCEMENT [%d]\r\n", hZcll->bDefaultIPTried);
    DEBUG0_ZCLL_MESG(zeroconf_dbg_msg, "Sending ANNOUNCEMENT [%d]\r\n", hZcll->bDefaultIPTried);
    DEBUG0_ZCLL_PRINT((char *)zeroconf_dbg_msg);
}

 
Is there any issue with doing this? Should I also add this flag to the SM_ADDR_DEFEND state?
#3
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/22 13:13:14 (permalink)
4 (1)
I noticed that, according to Wireshark, ARPs requested by the ZCLL module were not getting sent out in a timely fashion by the ARP module. I suspect this is because the ARP module will enqueue and handle sending ARPs on its own, but for ZCLL I think we just want the module to send the ARPs immediately in order to best comply with the random time intervals in RFC3927. I also don't think we care about storing the address of any responders (we just care that there are or are no responders), so I added the ARP_OPERATION_PROBE_ONLY flag to every call to TCPIP_ZCLL_ARPAction(). TCPIP_ARP_Process() will still notify the ZCLL module of incoming ARPs via _ARPProcessRxPkt(). I have only one board running with ZCLL at the moment, so I'll need to do more testing with other boards networked, but from looking at the code things should work okay.
#4
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/22 14:06:16 (permalink)
0
Also, what's going on with this snippet from the SM_ADDR_PROBE state at about line 735 in zero_conf_link_local.c?
 


                    if(!hZcll->bDefaultIPTried)

                    {

                        // First probe, and the default IP is a valid IPV4_SOFTAP_LLBASE address.

                        if (((!hZcll->bDefaultIPTried)          &&
                                    (pNetIf->DefaultIPAddr.v[0] != 169)) ||

                                ((pNetIf->DefaultIPAddr.v[1] != 254) &&

                                 (pNetIf->DefaultIPAddr.v[2] != 0)   &&

                                 (pNetIf->DefaultIPAddr.v[3] != 255)))

                        {

                             //...default address is NOT a valid link-local address

                        }

                    }

 
Comments nearby and in the snippet suggest that this should check that the default IP address set in the Harmony 3 Configurator is a valid link-local address and will use that one if it is, but I'm not sure it's really doing that. Wouldn't you actually want something like this?
 


                    if(!hZcll->bDefaultIPTried)

                    {

                        // First probe, and the default IP is a valid IPV4_SOFTAP_LLBASE address.

                        if ((pNetIf->DefaultIPAddr.v[0] != 169) ||

                                (pNetIf->DefaultIPAddr.v[1] != 254) ||

                                (pNetIf->DefaultIPAddr.v[2] == 0) ||

                                 (pNetIf->DefaultIPAddr.v[2] == 255))

                        {

                             //...default address is NOT a valid link-local address

                        }

                    }
#5
rainad
Moderator
  • Total Posts : 1421
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/22 14:21:24 (permalink)
0
Hi jdeguire,
Sorry for the delay in replying to your post.
I'll have to look into some details to come up with the definitive answer.
I think that what you did makes sense.
I'll get back to you.
 
 
#6
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/23 08:50:19 (permalink)
3 (1)
No biggie, thanks the for response!
 
I'm still working on one last change and I'll post my updated file here. RFC3927 recommends using a pseudo-RNG to generate an IP address that is seeded with a per-device unique value such as a MAC address. This allows each device to pick the same address at each startup without needing persistent storage and while decreasing the chances of a conflict. I updated the _zcll_rand() function to use a Xorshift algorithm from Wikipedia and added an init function to seed it with the interface's MAC address. The current implementation just grabs the current value of the TCP/IP Stack's tick timer, which will probably not go well if lots of boards are connected and are powered up at once.
#7
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/24 08:00:13 (permalink)
0
Here are the modifications I made to the Link-local Zeroconf module. Plop the attached files into "Harmony3\net\tcpip\src" and re-generate your project or just stick them right in your project.
 
Here's the changes I made:
--The original "rand" algorithm just grabbed the current value of the TCP/IP Stack's millisecond timer, which is probably not good if a bunch of nodes are powered on at once as I suspect you'll get lots of conflicts. Instead, it now uses a simple Xorshift algorithm (thanks, Wikipedia!) that is seeded from the interface's MAC address. It will be seeded with the timer only if the MAC address is 0 for some reason. This allows nodes to not conflict while also letting them pick the same address every time without needing persistent storage. This is recommended by RFC3927.
--The "_zcll_rand()" function now takes a range in which to generate the random number and scaled the generated value to within that range. This cleans up code that uses the pRNG and supposedly scaling the number is better than using modulo.
--Exit early from the TCPIP_ZCLL_Process() function is the interface is not linked. This seems to prevent an issue in which the first ARP is not sent because the code starts the timer before the interface is linked.
--The "else if(zgzc_action == ZGZC_STARTED_WAITING)" condition near the top of the SM_ADDR_PROBE state of TCPIP_ZCLL_Process() is incorrect. It should actually check for "ZGZC_KEEP_WAITING".
--Make the changes I mentioned in previous posts with the check for the default IP address being a link-local address and the use of "ARP_OPERATION_PROBE_ONLY".
 
On another note, if you decide to use this with lots of nodes you will probably want to modify the default ZCLL task rate. The current default is 333ms, which does not give a lot of chances for devices to send their probes and so may cause "clustering" with enough nodes. Something like 100ms would probably do much better without using up much extra CPU time.
#8
rainad
Moderator
  • Total Posts : 1421
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/25 14:53:21 (permalink)
5 (1)
Thank you for your post.
I'm looking through it and I think that all the updates/changes make sense.
I'll be integrating this into the base code and to be part of the next release, if you're OK with that.
 
The task rate is a configurable parameter.
You're right, for a busy network it should be smaller.
Even the 100 ms won't mean much overhead, true, so probably I can change that default as well.
 
 
 
 
 
#9
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/28 05:13:53 (permalink)
0
Sounds good to me!
#10
rainad
Moderator
  • Total Posts : 1421
  • Reward points : 0
  • Joined: 2009/05/01 13:39:25
  • Location: 0
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/29 15:47:22 (permalink) ☼ Best Answerby jdeguire 2020/09/30 10:10:15
4.67 (3)
I've updated the code and also changed the task rate to 113 ms default value.
For the pseudo-random function I've used a LCG32 implementation as I'm not sure about Marsaglia/xorshift license, rights, etc.
It will be part of the next release - end of year.
Thank you for finding the issue, providing the fix and contributing to this.
 
 
 
#11
jdeguire
Super Member
  • Total Posts : 599
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: offline
Re: H3 Link-local Zeroconf module never announces its new IP address 2020/09/30 10:20:06 (permalink)
0
Cool beans! I hadn't thought about licensing and such, so I'll have to keep that in mind in the future. I don't know that much about pRNGs, but I'd imagine any simple one would do just fine here.
#12
Jump to:
© 2020 APG vNext Commercial Version 4.5