buglwIP - A Lightweight TCP/IP stack - Bugs: bug #58139, RFC5227 violation in acd module

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58139: RFC5227 violation in acd module

Submitter:  Jasper Verschueren <jasperv>
Submitted:  Wed 08 Apr 2020 08:37:11 AM UTC
   
 
Category:  IPv4 Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  git head

Jump to the original submission

Thu 04 Apr 2024 11:06:35 AM UTC, comment #6: 

Fully support to make the RFC behavior as default.


comment #4:

> For my specific use case, I'd much prefer to have the "official" RFC behavior.
>
> As I am currently adding configuration options for ACD, I've now added an option to select whether the IP address shall be considered valid after the first or the last announce. I would use the RFC behavior as a default, but if required someone could pick the "BCT" alternative from lwipopts.h.




Teddy Zhai <teddyzhai>
Sat 30 Mar 2024 05:07:37 PM UTC, comment #5: 

Yes, that would be a good option. OTOH, I'm not really familiar with why this difference exists or if it's simply a bug...?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 22 Mar 2024 03:18:55 PM UTC, comment #4: 

Hi all,

Since I am working on making the ACD implementation "configurable" (in order to support the specific requirements of the EtherNet/IP industrial protocol), I started writing unit tests for ACD. And while doing so, I noticed this issue.

For my specific use case, I'd much prefer to have the "official" RFC behavior.

As I am currently adding configuration options for ACD, I've now added an option to select whether the IP address shall be considered valid after the first or the last announce. I would use the RFC behavior as a default, but if required someone could pick the "BCT" alternative from lwipopts.h.

Would that be an acceptable solution? If so, I guess that issue could be closed if/when my patches are accepted.


Matthias Dietrich <matthiasdietrich>
Tue 12 May 2020 12:59:14 PM UTC, comment #3: 

Hi David,

It could indeed be that commit 05ffe144 was enough to fix the BCT failure.
From an RFC standpoint we need to revert this commit.

I'm not sure what the effort is to run the BCT on this, but could you verify if it still passes after the revert?

Kind regards,
Jasper

Jasper Verschueren <jasperv>
Thu 09 Apr 2020 09:53:11 AM UTC, comment #2: 

Hi Jasper and Simon,

I've made this change to allow our product to pass the Apple Bonjour Conformance Test (BCT).

May be the fix was incorrect, but it was the only one I found to be able to pass the BCT if some announce are lost because wifi connection.

I don't found exactly why this change was introduced one year ago in our tickets database. :-/

But according to my BCT logs at Jun 21 2019, before introducing this fix Jun 25 2119 in our GIT branch, I had the following errors:


Link-Local Address Allocation
-----------------------------
        PASSED: INITIAL PROBING
        PASSED: PROBING: RATE LIMITING
        PASSED: PROBING: CONFLICTING SIMULTANEOUS PROBES
        PASSED: PROBING: PROBE DENIALS
        PASSED: PROBING
        PASSED: PROBING COMPLETION
        WARNING: SUBSEQUENT CONFLICTS: RE-PROBE AFTER FIRST CONFLICT
        FAILED: SUBSEQUENT CONFLICTS: ANNOUNCEMENTS
        FAILED: SUBSEQUENT CONFLICTS
        ABORTED: CABLE CHANGE HANDLING
        PASSED: PREMATURE MDNS PROBING
FAILED with 2 failed subtest(s) and 1 aborted subtest(s) and 1 warning(s) and 0 skipped subtest(s).


May be this fix wasn't necessary and commit 05ffe144 is enough to fix BCT.

So, if this specific commit break conformance to the RFC, just revert it. If we need to update adn redo the BCT later, I'll take care of this.

Regards,
David

David GIRAULT <dgirault>
Thu 09 Apr 2020 07:40:32 AM UTC, comment #1: 

I've added David Girault to CC, since he did that commit

Simon Goldschmidt <goldsimon>
Group administrator
Wed 08 Apr 2020 08:37:11 AM UTC, original submission:  

According to RFC5227 section 2.3: The host may begin legitimately using the IP address immediately after sending the first of the two ARP Announcements; the sending of the second ARP Announcement may be completed asynchronously, concurrent with other networking operations the host may wish to perform.

This behavior is recently changed by commit 30d445bd acd: inform address is good only when going in ongoing state.
Currently we only let the acd user know that the address is good after all announce messages have been send.

So I request to revert this commit.




Jasper Verschueren <jasperv>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by teddyzhai (Posted a comment)
  • -email is unavailable- added by matthiasdietrich (Posted a comment)
  • -email is unavailable- added by dgirault (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by goldsimon
  • -email is unavailable- added by jasperv (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-04-09 goldsimon Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code