On 05/04/2012 11:58 AM, Eric Blake wrote:
Even with ACK, I will wait to push this until I have verification that it does not break lldpad<-->libvirtd communication (if it does, I may need to use the nl_handle allocated during virNetlinkStartup() for virNetlinkEventServiceStart()).
On Thu, 2012-05-03 at 11:10 -0400, Laine Stump wrote: libvirtd->lldpad communication is still working, but lldpad->libvirtd not anymore (CONNECTION_REFUSED). On the surface, that makes it sound like lldpad has the same bug as
On 05/04/2012 06:58 AM, Gerhard Stenzel wrote: libnl, of blindly assuming that it knows which address will be bound, rather than realizing that netlink sockets might be used elsewhere and thus the bound address is not guaranteed. Is it something that can be fixed quickly in lldpad?
Actually it turns out that lldpad is just using the address send as the source nl_pid in messages it receives from libvirtd, and virNetlinkCommand has that field hardcoded to be set to getpid(). I've just made a set of patches that (I hope) remedies that: https://www.redhat.com/archives/libvir-list/2012-May/msg00340.html and also made some builds for Gerhard to test (since he's lucky enough to have access to the proper hardware :-) (Roopa, you may also want to take a look and make sure that I didn't mess up any of the non-lldpad netlink communications - I don't have the hardware to test those either...)