Re: [Qemu-discuss] Network problems with qemu-system-arm and u-boot

[Jakob Bohm]

On 5/12/2013 1:46 AM, pietrushnic wrote:
> Hi all,
> I'm trying to obtain IP address in u-boot using qemu-system-arm 1.4.91 
> (commit:38ebb39). Unfortunately u-boot is unable to retrieve packets 
> until I add '-net dump,file=/tmp/dump.pcap' to qemu command line.
> I'm using bridged tap interface as it was described here: 
> http://toast.djw.org.uk/qemu.html <http://toast.djw.org.uk/qemu.html>.
>
> I tried ARM testing image from 
> http://wiki.qemu.org/download/arm-test-0.2.tar.gz to verify my network 
> configuration and it works fine without additional traffic dump, so it 
> looks like it is not configuration issue.
> I'm running in to this issue on Ubuntu 12.04, but previously tested on 
> Debian wheezy and there was no problem with obtaining packets by u-boot.
>
> So my question is, if someone heard about such anomaly ?
> How it is possible that packets cannot get through interface without 
> additional dump (delay ?) and magically pass through if dump command 
> was added ?
> Any thoughts how it could be debugged from qemu side ?
>
> If you need additional information about configuration, just let me 
> know what can help.
What happens (on the affected system) if you try each of the
following experiments:

1. Do not pass the dump option to qemu, but run tcpdump on the bridge
  interface in promiscous mode.

2. Do not pass the dump option to qemu, but run tcpdump on the bridge
  interface in non-promiscous mode.

3. Grab the kernel from the working wheezy configuration and install
  it on Ubuntu, does this make it work, and if so, what are the
  version numbers and config differences of those two kernels.

My suspicions, which these tests are about, is that u-boot may be
relying on the network card receiving more packets not specifically
addressed to it than the regular dhcp client does.  Somehow the virtual
nic emulated by qemu does not understand or pass on the i/o request
to receive those packets from the network.

There are many modes in which a real world NIC can be put to receive
packets not addressed to its official hardware MAC, and some of those
modes may not be exercised by other guest code.

Some of the modes I can think of are:

A. Promiscous mode (obvious).

B. Receiving multicast packets without going through the niceties of
  announcing interest in specific multicast MACs done by modern OS
  kernels.

C. Using the NIC with a different MAC address than specified by the
  qemu options (like what happens when u-boot starts on a hardware
  board where the official MAC of the board is stored in general NV
  memory not read by U-boot).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded