We installed freebsd 10.0 on Hyper-V Windows Server 2012 R2. We would like to enable the CARP protocol but is still in a state of init. The error in dmessage is "ifa_del_loopback_route: deletion failed: 48". I've used both the adapter "Legacy Network" and "Network" but the result is the same.
Responsible Changed From-To: freebsd-ports-bugs->freebsd-emulation reclassify.
Responsible Changed From-To: freebsd-emulation->freebsd-emulation fix text.
Created attachment 151515 [details] fix the carp issue on hyper-v (In reply to Xin LI from comment #6) Thanks for the review. You are right, arp_ifinit is already done in ether_ioctl fucntion in the next invocation. I have removed that line of code and CARP works well. A new patch has been uploaded. Thanks.
Created attachment 152507 [details] Proposed patch Hi, Would you please review the attached patch? If it's reasonable, would you please test it and see if it solves the problem? Cheers,
Hi Xin, Your patch works well, but I doubt we should add back the following: case SIOCGIFADDR: (in Line 739) Like this: case SIOCSIFADDR: case SIOCGIFADDR: #ifdef INET .... Otherwise there may be issue.
Hi Xin, Your patch works well, but I doubt we should add back the following: case SIOCGIFADDR: (in Line 739) Like this: case SIOCSIFADDR: case SIOCGIFADDR: #ifdef INET .... Otherwise there may be issue.(In reply to Xin LI from comment #4)
(In reply to andy zhang from comment #6) Hi, Is there a specific use case for the possible issue if SIOCGIFADDR is not handled there? Actually this is a follow up of changeset 277103 [1] which is review request D1508 [2] and you may find additional information there. My main reasoning is that the SIOCGIFADDR (get interface address) is used to "observe" the interface object, or a "get" accessor, and semantically it shouldn't bump the interface, like triggering an ARP broadcast, etc. like SIOCSIFADDR (set interface address) does. If we do it for SIOCGIFADDR too, there may be some undesired behavior (e.g. an 'ifconfig' would cause the interface to announce its IP address). We can indeed add it back if there is good reason to do so, but I haven't yet see one... [1] https://svnweb.freebsd.org/base/head/sys/dev/xen/netfront/netfront.c?r1=276750&r2=277103 [2] https://reviews.freebsd.org/D1508
(In reply to Xin LI from comment #7) Hi Xin, your suspect is reasonable. In the early beginnng of fixing the CARP issue, I also doubted about that. The code writer of hyper-v may refer to the implementation of xen in the beginning. And I also tried with your suggested fix, it works well. So overall, I agree with your suggestion. Thanks for your effort.
A commit references this bug: Author: delphij Date: Mon Mar 9 20:11:17 UTC 2015 New revision: 279819 URL: https://svnweb.freebsd.org/changeset/base/279819 Log: Fix CARP when in use in a HyperV environment: - Bump link state when stopping or starting the interface; - Don't handle SIOCGIFADDR specially, similar to r277103. This change is based on a previous revision from Andy Zhang (Microsoft) who did the diagnostic work and many thanks to them for their help in supporting the HyperV work. PR: kern/187203 MFC after: 2 weeks Changes: head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
Hi, Andy, I've committed my version of patch and will MFC after 2 weeks so it would be available by 10.2-RELEASE. Please let me know if any adjustments would be needed and thanks for your work on this!
A commit references this bug: Author: delphij Date: Tue May 19 08:00:40 UTC 2015 New revision: 283100 URL: https://svnweb.freebsd.org/changeset/base/283100 Log: MFC r279819: Fix CARP when in use in a HyperV environment: - Bump link state when stopping or starting the interface; - Don't handle SIOCGIFADDR specially, similar to r277103. This change is based on a previous revision from Andy Zhang (Microsoft) who did the diagnostic work and many thanks to them for their help in supporting the HyperV work. PR: kern/187203 Changes: _U stable/10/ stable/10/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c