Hello,
Thomas Huth, on mer. 07 mars 2018 07:30:29 +0100, wrote:
> On 07.03.2018 04:39, Alexey Kardashevskiy wrote:
> > On 08/02/18 15:29, Alexey Kardashevskiy wrote:
> >> On 01/02/18 20:36, Alexey Kardashevskiy wrote:
> >>> If we run QEMU with -netdev user,id=USER0,hostfwd=tcp::2222-:22, it starts
> >>> a DHCP server and starts allocating client IPs from 10.0.2.15 so
> >>> this is what the guest normally receives. Since QEMU automatically adds
> >>> the DHCP starting address into the forwarding table, everything works.
> >>> This is the table before guest started:
> >>>
> >>> (qemu) info usernet
> >>> VLAN -1 (USER0):
> >>> Protocol[State] FD Source Address Port Dest. Address Port RecvQ
> >>> SendQ
> >>> TCP[HOST_FORWARD] 11 * 2222 10.0.2.15 22 0
> >>> 0
> >>>
> >>> However if the guest happens to have DHCP lease (for example, 10.0.2.16),
> >>> the forwarding stops working. The guest can still reach the outer world
> >>> (which is expected).
> >>>
> >>> This updates the forwarding table when QEMU confirms the requested IP
> >>> to the guest.
> >>>
> >>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
> >>> ---
> >>>
> >>> Does this look any useful?
> >
> > Ping, anyone?
>
> Maybe you should make sure to put the SLIRP maintainer on CC: ?
That would work much better to catch my attention indeed :)
I'm afraid this will be a nack. What you basically propose is "the last
DHCP lease wins". There can be setups where it is expected that it's the
first DHCP lease which should get the forward, as documented actually
("If guestaddr is not specified, its value is x.x.x.15"). In your case,
you can always set to hostfwd=tcp::2222-10.0.2.16:22. If your guest
doesn't have predictable DHCP behavior, better use a static IP
assignment rather than introducing into qemu something which looks
rather undefined to me ("last DHCP lease wins").
Samuel
