[Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Christopher Nehren]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

I've been banging my head against a wall trying to get Qemu to support
any type of networking with a FreeBSD host, and haven't had any success
-- and for once, Google isn't of much use either. When trying to access
the card with user-mode networking via (Open|Net)BSD, I get the error
'ne1: device timeout'. I can't get FreeSBIE to recognize the card at
all, and haven't gotten a Windows installation far enough to be able to
see whether it sees it or not. Any help would be greatly appreciated.

-- 
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".  -- Ken Thompson
-
Unix is user friendly. However, it isn't idiot friendly.

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Alexander E. Patrakov]

Christopher Nehren wrote:
> I've been banging my head against a wall trying to get Qemu to support
> any type of networking with a FreeBSD host, and haven't had any success
> -- and for once, Google isn't of much use either. When trying to access
> the card with user-mode networking via (Open|Net)BSD, I get the error
> 'ne1: device timeout'. I can't get FreeSBIE to recognize the card at
> all, and haven't gotten a Windows installation far enough to be able to
> see whether it sees it or not. Any help would be greatly appreciated.

./configure --prefix=/usr --enable-slirp
make CC="gcc -fno-strict-aliasing"
make install

-- 
Alexander E. Patrakov

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Antony T Curtis]

On Sun, 2004-06-13 at 06:28, Christopher Nehren wrote:
> I've been banging my head against a wall trying to get Qemu to support
> any type of networking with a FreeBSD host, and haven't had any success
> -- and for once, Google isn't of much use either. When trying to access
> the card with user-mode networking via (Open|Net)BSD, I get the error
> 'ne1: device timeout'. I can't get FreeSBIE to recognize the card at
> all, and haven't gotten a Windows installation far enough to be able to
> see whether it sees it or not. Any help would be greatly appreciated.

It works fine for me with my own patches... I am using the if_tap with
ng_bridge to allow the QEMU install to connect to the LAN and a change
to /usr/src/sys/net/if_tap.c to remove the suser() check so a non-root
account can open a tap device.

The only problem I have is that it has a relatively high packet loss and
appears to lose interrupts- so it stalls on occasion.

-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Bartosz Fabianowski]

I am using "normal" networking (that is, not slirp) with FreeBSD as 
host. My guest operating systems are various versions of Windows and 
none of them have any problems with networking whatsoever. Here's my 
configuration. Maybe it can help you to fix your installation:

* I compile QEMU from CVS with the patches from the port. Apart from a 
--prefix, I pass no special arguments to configure.

* In my /etc/rc.conf, I have set FreeBSD to work as a gateway by setting 
gateway_enable="YES".

* My guest uses the IP 192.168.1.7 on the emulated network card, the tap 
device on the host has IP 192.168.1.1. The only problem here is that I 
have been too lazy to write a network script so it's just a no-op and I 
always run "ifconfig tapX inet 192.168.1.1" manually whenever QEMU 
starts and allocates a new tap device (why is it by the way that QEMU 
always opens a new tap device?).

With those few steps, it all works very nicely. I should note, however, 
that to go on the Internet with the guest operating system, its IP must 
be NAT-ed somewhere on the way, which is handled by another FreeBSD box 
in my case.

- Bartosz

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Bakul Shah]

I am using /dev/tap based networking, not the usermode one.
It all works fine (thanks to some help from Juergen Lock).
BTW, I am using the latest FreeBSD port &
Freebsd-5.2-current.

- when using the tap device you need to ifconfig the interface.
  You can do this manually or via a script.  Either copy this
  script to /etc/qemu-ifup or run it from the command line.
  Something like

	echo ifconfig $1 192.168.0.1	> /etc/qemu-ifup
	chmod +x /etc/qemu-ifup

  This needs to be done on the *host*.

- make sure you are using -pci option (I needed this for
  a FreeBSD guest -- do not know why).

- You may wish to use the linux-test image from the qemu
  site, for debugging all this.  Give the *guest OS* an
  address like 192.168.0.2 or something in the same subnet as
  the tap interface.  Once the OS is up and its interface
  configured, you should be able to ping the this address
  from the host FreeBSD.  If this step works, you have a
  working connection between the guest and the host; the
  remaining work is all networking related, nothing to do
  with qemu per se.

- Networking related changes: you will have to enable
  forwarding on the host.  You will likely need to add static
  routes or update your NAT rules or both.  You may have to
  run dhcp proxy on the host....  Someone should come up with
  a script that figures out the right thing to do based on
  your setup.

Some random thoughts:

* When qemu opens the tap device, it always returns a new
  device.  You can change this behavior by patching vl.c.  On
  line 1104 change the `for' loop to start at 0 instead of -1
  -- line # as per the patched sources in the FreeBSD port.
  This loop first tries /dev/tap and then /dev/tap0,
  /dev/tap1 and so on.  The change skips /dev/tap.

* I am not sure if removing suser() test in if_tap.c is the
  right thing to do from a security perspective so I left this
  alone.

* I don't see why /dev/tap is an exclusive open device.  If
  multiple opens were allowed, a number of VMs can be on the
  same simulated network.  That is, qemu for each guest can
  open the same device and they will all *see* each other as
  well as the host!

* I first thought qemu should also have a qemu-ifdown script
  but may be it is better to wrap qemu in a shell script that
  does the initial setup and final cleanup.

* It would be nice if qemu exited only on a power down
  event instead of a reboot.  May be as an option.

Overall this is a very impressive emulator!  So far I have
brought up Linux, FreeBSD-5.2.1 and a trial version of Window
2003.  Kudos to Fabrice Bellard and the other wizardly
programmers!

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Brad Watson]

I believe that the messagethat you are receiving
suggest that FreeBSD is not seeing the NIC card
interrupt.

If you don't start qemu w/the -pci option (i.e. you
use the emulated isa NIC cards,) FreeBSD will try to
use an IRQ for the ne* card different from the one
that qemu is using.

Some other workarounds (besides starting qemu w/the
-pci option) include remapping the interrupts for the
ne* cards in the qemu/hw/pc.c file, and recompiling
qemu, or possibly, switching the interrupt on the fly
that FreeBSD uses for the NIC w/the sysctl command (I
haven't tried that.)

Good luck,

RBW

--- Christopher Nehren <apeiron@comcast.net> wrote:
> I've been banging my head against a wall trying to
> get Qemu to support
> any type of networking with a FreeBSD host, and
> haven't had any success
> -- and for once, Google isn't of much use either.
> When trying to access
> the card with user-mode networking via
> (Open|Net)BSD, I get the error
> 'ne1: device timeout'. I can't get FreeSBIE to
> recognize the card at
> all, and haven't gotten a Windows installation far
> enough to be able to
> see whether it sees it or not. Any help would be
> greatly appreciated.
> 
> -- 
> I abhor a system designed for the "user", if that
> word is a coded
> pejorative meaning "stupid and unsophisticated".  --
> Ken Thompson
> -
> Unix is user friendly. However, it isn't idiot
> friendly.
> 

> ATTACHMENT part 1.2 application/pgp-signature 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Christopher Nehren]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Sun, Jun 13, 2004 at 16:17:06 EDT, Brad Watson scribbled these
curious markings:
> I believe that the messagethat you are receiving
> suggest that FreeBSD is not seeing the NIC card
> interrupt.
> 
> If you don't start qemu w/the -pci option (i.e. you
> use the emulated isa NIC cards,) FreeBSD will try to
> use an IRQ for the ne* card different from the one
> that qemu is using.

Ooh, undocumented options. We hatessss them, my precioussss. I do
believe that it would be wise to write something about this option, and
what it does. This will at least prevent _some_ users from asking
questions (unfortunately, only those users who read the docs).

> Some other workarounds (besides starting qemu w/the
> -pci option) include remapping the interrupts for the
> ne* cards in the qemu/hw/pc.c file, and recompiling
> qemu, or possibly, switching the interrupt on the fly
> that FreeBSD uses for the NIC w/the sysctl command (I
> haven't tried that.)

Thanks for the information; I will try this suggestion in tandem with
the other suggestions that I've received.

-- 
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".  -- Ken Thompson
-
Unix is user friendly. However, it isn't idiot friendly.

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Bartosz Fabianowski]

> Ooh, undocumented options. We hatessss them, my precioussss.

Just run the following in QEMU's source code directory and you might be 
surprised to find that there are a few more undocumented options:

egrep "^    QEMU_OPTION_" vl.c


- Bartosz

Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?

[Christopher Nehren]

[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]

On Sun, Jun 13, 2004 at 14:59:26 EDT, Bakul Shah scribbled these
curious markings:
> I am using /dev/tap based networking, not the usermode one.
> It all works fine (thanks to some help from Juergen Lock).
> BTW, I am using the latest FreeBSD port &
> Freebsd-5.2-current.

Okay, I got mine working. :)

> - when using the tap device you need to ifconfig the interface.
>   You can do this manually or via a script.  Either copy this
>   script to /etc/qemu-ifup or run it from the command line.
>   Something like
> 
> 	echo ifconfig $1 192.168.0.1	> /etc/qemu-ifup
> 	chmod +x /etc/qemu-ifup
> 
>   This needs to be done on the *host*.

Right, got that.

> - make sure you are using -pci option (I needed this for
>   a FreeBSD guest -- do not know why).

This option (the undocumented one, sigh) was the one that I needed. With
it, I can get both tap and user-mode networking to function. :) For why 
it's needed, read Brat Watson's later message to this thread,
message ID <20040613201706.25684.qmail@web51809.mail.yahoo.com>.

> - You may wish to use the linux-test image from the qemu
>   site, for debugging all this.  Give the *guest OS* an
>   address like 192.168.0.2 or something in the same subnet as
>   the tap interface.  Once the OS is up and its interface
>   configured, you should be able to ping the this address
>   from the host FreeBSD.  If this step works, you have a
>   working connection between the guest and the host; the
>   remaining work is all networking related, nothing to do
>   with qemu per se.

I already had NetBSD 1.6.2 fully installed using the i386cd.iso image,
so I tested with that.

> - Networking related changes: you will have to enable
>   forwarding on the host.  You will likely need to add static
>   routes or update your NAT rules or both.  You may have to
>   run dhcp proxy on the host....  Someone should come up with
>   a script that figures out the right thing to do based on
>   your setup.

Right; I have PF set up to do that. I love PF. With user-mode
networking, though, you don't need this.

> Some random thoughts:
> 
> * When qemu opens the tap device, it always returns a new
>   device.  You can change this behavior by patching vl.c.  On
>   line 1104 change the `for' loop to start at 0 instead of -1
>   -- line # as per the patched sources in the FreeBSD port.
>   This loop first tries /dev/tap and then /dev/tap0,
>   /dev/tap1 and so on.  The change skips /dev/tap.

Actually, I didn't see this. It kept using /dev/tap, but it was showing
up in ifconfig as tap0. Weird.

> * I am not sure if removing suser() test in if_tap.c is the
>   right thing to do from a security perspective so I left this
>   alone.

My _guess_ is that it would prevent any old user from creating 52k tap
devices, and the consequential resource starvation. I'm going to see if
I can't add a sysctl to control this; watch hackers@ and security@ for a
post by me in the near future.

> * I don't see why /dev/tap is an exclusive open device.  If
>   multiple opens were allowed, a number of VMs can be on the
>   same simulated network.  That is, qemu for each guest can
>   open the same device and they will all *see* each other as
>   well as the host!

Do you mean each /dev/tap interface being exclusive? Well, it _is_ bound
to the individual process, which may have something to do with it.
 
> * I first thought qemu should also have a qemu-ifdown script
>   but may be it is better to wrap qemu in a shell script that
>   does the initial setup and final cleanup.

Perhaps a good idea. It's more configurable that way, too.
 
> * It would be nice if qemu exited only on a power down
>   event instead of a reboot.  May be as an option.

Again, a good idea, at least IMO.
 
> Overall this is a very impressive emulator!  So far I have
> brought up Linux, FreeBSD-5.2.1 and a trial version of Window
> 2003.  Kudos to Fabrice Bellard and the other wizardly
> programmers!

Indeed. 't is quite wonderful.

-- 
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".  -- Ken Thompson
-
Unix is user friendly. However, it isn't idiot friendly.

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

port update (was: Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?)

[Juergen Lock]

In article <200406131859.i5DIxQOK098661@gate.bitblocks.com> you write:
>I am using /dev/tap based networking, not the usermode one.
>It all works fine (thanks to some help from Juergen Lock).
>BTW, I am using the latest FreeBSD port &
>Freebsd-5.2-current.
>...

>* When qemu opens the tap device, it always returns a new
>  device.  You can change this behavior by patching vl.c.  On
>  line 1104 change the `for' loop to start at 0 instead of -1
>  -- line # as per the patched sources in the FreeBSD port.
>  This loop first tries /dev/tap and then /dev/tap0,
>  /dev/tap1 and so on.  The change skips /dev/tap.

This seems to be new with -current (its not happening on 5.2.1),
anyway I have now changed the port, and updated it to yestarday's
snapshot.  Port update can be fetched at
	http://www.freebsd.org/cgi/query-pr.cgi?pr=67948&f=raw

>...
>* I don't see why /dev/tap is an exclusive open device.  If
>  multiple opens were allowed, a number of VMs can be on the
>  same simulated network.  That is, qemu for each guest can
>  open the same device and they will all *see* each other as
>  well as the host!
>
 Well that would require bigger changes to the if_tap code...

>* I first thought qemu should also have a qemu-ifdown script
>  but may be it is better to wrap qemu in a shell script that
>  does the initial setup and final cleanup.
>
 It seems to be downed at least here, this is after a qemu run
that had used tap0: (5.2.1)

tap0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::2bd:72ff:fe64:200%tap0 prefixlen 64 scopeid 0x4 
        ether 00:bd:72:64:02:00

 Hmm ok it still has an inet6 address...

	Juergen

Re: port update (was: Re: [Qemu-devel] Anyone have functioning networking with a FreeBSD host?)

[Juergen Lock]

In article <200406142049.i5EKnkm87423@saturn.kn-bremen.de> I write:

>...  Port update can be fetched at
>	http://www.freebsd.org/cgi/query-pr.cgi?pr=67948&f=raw

Superseded by
	http://www.freebsd.org/cgi/query-pr.cgi?pr=67950&f=raw

 (the old one doesnt even fetch anymore now, the port i mean...)

	Juergen