Re: [Qemu-devel] [PATCH 2/2] Fix slirp mac address init

[Jason Wessel]

I figured most people do not have kgdboe as a built-in, and the qemu
patch is definitely against an edge case.  The problem is better
described by the case where no packets have been transmitted by the qemu
target and you desire to have the first communication occur externally.

The edge case can happen if you do something like use kgdboe before the
kernel is booted up.  The OS will configure the ethernet interface to
listen and wait for the debugger to attach, and in this case the MAC
address is not set in the slirp because no packets have ever been
transmitted yet.

You would have do something like:

qemu-redir udp:4445::6443 -append "console=ttyS0
address@hidden/,@10.0.2.2/ kgdbwait"

Then you would connect gdb with "target remote udp:localhost:4445".  I
will gladly provide you with a kernel that has kgdboe built in and some
exact boot arguments if you would like to see the problem first hand.

Jason.

Aurelien Jarno wrote:
> On Wed, Apr 09, 2008 at 11:22:23PM -0500, Jason Wessel wrote:
>   
>> It is not possible to communicate to a qemu instance via a slirp
>> redirected udp port until the OS running in qemu has executed a dhcp
>> request.  This is because the internal qemu dhcp server populates the
>>     
>
> Could you please more details? I am unable to reproduce the problem. A
> simple netcat listening on a UDP port in the guest, and another netcat
> in the host to send data works here.
>
>   
>> slirp mac address.  Until the dhcp request is processed the translated
>> mac address is zeroed out and the packets bound for the target OS will
>> not correctly get the mac address of the qemu ethernet adapter.
>>
>> The solution is to initialize the slirp mac address when the qemu
>> network adapter client is initialized.  This allows the use
>> bi-directional udp redirection with a static IP address configured on
>> the qemu ethernet adapter.
>>