-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More mDNSPosix Fixes #6
Conversation
The __block qualifier is not used in Linux builds. Signed-off-by: Nate Karstens <nate.karstens@garmin.com>
Moves functionality for cleaning the list of recent interfaces into its own subroutine. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Creates a subroutine for tearing down an interface. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Tracks the socket family associated with the interface. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Tells the mDNS core if an interface is a loopback interface, similar to AddInterfaceToList() in the MacOS implementation. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Uses a linked list to store the index of changed network interfaces instead of a bitfield. This allows for network interfaces with an index greater than 31 (an index of 36 was seen on Android). Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Change-Id: Ibeab0ec68ca0d21da8384d4362e59afd2951f138
The POSIX implementation currently clears all network interfaces when netlink indicates that there has been a change. This causes the following problems: 1) Applications are informed that all of the services they are tracking have been removed. 2) Increases network load because the client must re-query for all records it is interested in. This changes netlink notification handling by: 1) Always comparing with the latest interface list returned by the OS. 2) Confirming that the interface has been changed in a way that we care about. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Netlink notification handling ignores messages for deleted links, RTM_DELLINK. It does handle RTM_GETLINK. According to libnl docu- mentation (http://www.infradead.org/~tgr/libnl/doc/route.html) RTM_DELLINK can be sent by the kernel, but RTM_GETLINK cannot. There was likely a mixup in the original implementation, so this change replaces handling for RTM_GETLINK with RTM_DELLINK. Testing and Verification Instructions: 1. Use ip-link to add and remove a VLAN interface and verify that mDNSResponder handles the deleted link. Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Adds handling for socket() or read() returning a negative value (indicating an error has occurred). Upstream-Status: Submitted [dts@apple.com] Signed-off-by: Nate Karstens <nate.karstens@garmin.com> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
It seems that certain interface types may have `ifa_addr` set to null. Handle this case gracefully. Signed-off-by: Stefan Agner <stefan@agner.ch>
@agners Thanks for finding that. To make it easier for the maintainers, would you mind instead if we bring that into #2 and close this PR? Three ways I can think of doing that:
What is your preference? |
@nkarstens thanks for your work!
Either way works for me, I think the simplest would be if you just cherry-pick my change (so 1). I've noticed that the latest version (1807.101.2) doesn't seem to have a working POSIX implementation at all? 😕
|
It pretty much has no source at all...
|
Yes, it appears to be a merge botch where much of the project is lost, so there'd be nothing relevant left to apply changes to. There doesn't seem to be any means of communicating this I can see other than via PRs like this one, since I can find no bug reporting contact details, nor is issue reporting enabled for this project. (This is relevant in my case as this is the upstream source for integration into NetBSD, which we're, well, lagging behind on.) |
Close in favor of #2. |
This builds on #2, but contains an additional fix to address a
SIGSEGV
.