dhcp server defaults to gateway for filtering when unset

[Ian Wells]

network/model.py converts new-style models to old ones.

When it's trying to identify the IP address of a DHCP server, it uses the DHCP server address, if set, and the gateway if not. DHCP filtering is only turned off completely (i.e. all DHCP packets are denied) if neither a DHCP server nor a gateway are set.

There's no documentation of this functionality in the code, so I don't know why it's there. However, I believe the DHCP server address should always be set to the correct address and, if it's unset, then there is no DHCP server - so the fallback should be removed from the code. (I'd appreciate someone confirming that.)

This bug will affect the libvirt driver (which at present uses legacy()-style models) and anything that uses virt/firewall.py (which converts new models to legacy form).

[Russell Bryant (russellb)]

The line of code you reference was added in this commit, which isn't specific to adding the gateway fallback:

commit 345439f86a9ac8bd95cc7f382a3890d86f794b62
Author: Trey Morris <email address hidden>
Date: Fri Mar 30 10:14:08 2012 -0500

    update xen to use network_model

    blueprint xenapi-network-info-model

    updated xenapi to use the new network info models

    also:
    updated virt firewall to handle both old version and new hotness
    made a few minor changes to the network info model
    moved the legacy converstion shim from compute/utils to the model itself
    wharrgarbl'd a few of the tests

    NOTE: no unittests were skipped during the creation of this patch

    Change-Id: Ib77dd2bf4f0a525b73800441f19013e842c77f98

The fallback does seem kind of odd to me at first glance, but I haven't dug into in great detail. I'll confirm the bug since this does seem worth looking into and determining whether it is really desirable.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY