Re: [libvirt] Reporting of IP detected by network filter

On 11/20/18 10:17 AM, Daniel P. Berrangé wrote: It would be kind of cool if it did, but alas it does not. As far as I can tell the variables/parameters in nwfilter rules are a one way street - stuff that's set automatically by the driver are not reflected back to the hypervisor for its dumpxml (nor to the nwfilter-bindings-dumpxml). It would be neat, but I don't know how much info it would actually give us (see below). That would: 1) only work when the domain is defined in qemu:///system (emphasis on the _system_ part), so in our future utopia where qemu:///session domains have access to all of the same networking as qemu:///system, this code would not work. 2) only work when the domain is defined in qemu:///system (emphasis on the _qemu_ part), so xen, libxl, etc, would left out in the cold. For those reasons, I think it would be better suited to network:///system or nwfilter:///system. Also, due to the extra overhead in having pcap examine every packet, we don't want to ever actually setup the pcap socket for this unless there is an nwfilter that uses it. Finally, we should look at the trustability of this information, and what are the cases that the info wouldn't be available from somewhere else: 1) in the case of nwfilter snooping ARP packets, the results of all of those can be found by examining the ARP cache on the host, and there is already a mode of virsh domifaddr that looks to the ARP cache ("virsh ifaddr --source arp"). 2) for guests that are doing DHCP on a libvirt virtual network, the results of that are already available from "virsh domifaddr --source leases". 3) for guests that are connected to a host bridge that's directly connected to the physical network, and getting a DHCP address from an external DHCP server, those results can also be seen in the ARP cache ("virsh domifaddr --source arp"). Agreed. Of course the info in the ARP cache can be poisoned with incorrect data, but so can the results that come from snooping the tap device for ARP packets (both of them in the same manner, actually). So (to get back to my suggestion above) I don't think it would be lowering security at all to use results from the ARP cache vs results from snooping dhcp/arp packets from the tap device.