User-mode Linux kernel port

Email Archive: user-mode-linux-user (read-only)

Re: [uml-user] networking

From: Jeff Dike <jdike@ka...> - 2000-12-27 14:42

noel@... said:
> There are 2 possible networking methods with uml. 
> 1. slip 
> 2. ethernet 

Yup.

> Both doesn't support ip aliasing. So I cant give them a official IP
> adress to make virtual shell hosting.

> Or I'm wrong? 

What do you mean by virtual ip aliasing?  You have to give them an official IP 
address or they won't work.  And once you've done that, they're accessible 
from the outside assuming you and routes set up correctly.

> BTW: Why isn't there a link in the menu of the homepage to the
> mailinglist archiv. I found the mailingliste via the download page. 

There are links on the main page and also on one or two other pages to the 
mailing list pages.

				Jeff

Thread View

Thread	Author	Date
Re: [uml-user] networking	Jeff Dike <jdike@ka...>

Re: [uml-user] networking

From: Myrtle Meep <xrynx@ho...> - 2000-12-28 21:02

>From: Noel Koethe <noel@...>
>To: user-mode-linux-user@...
>Subject: [uml-user] networking
>Date: Wed, 27 Dec 2000 13:40:37 +0100 (CET)
>
>Hello,
>
>I want to be sure to understand uml networking correctly:
>
>There are 2 possible networking methods with uml.
>1. slip
>2. ethernet
>
Hi!
I've managed to get UML to run ppp as well. Following is a short UML-PPP 
Howto:
Apply the following patch to the uml sources:
===============BEGIN PATCH==============
--- linux-2.4.0-test12/arch/um/config.in  Tue Dec 19 20:50:45 2000
+++ linux/arch/um/config.in     Sat Nov 18 03:31:24 2000
@@ -68,6 +68,18 @@
       fi
    fi
    bool 'Old slip-based network device' CONFIG_NET_UMN
+   tristate 'PPP (point-to-point protocol) support' CONFIG_PPP
+   if [ ! "$CONFIG_PPP" = "n" ]; then
+      dep_bool '  PPP multilink support (EXPERIMENTAL)' 
CONFIG_PPP_MULTILINK $CONFIG_EXPERIMENTAL
+      dep_tristate '  PPP support for async serial ports' CONFIG_PPP_ASYNC 
$CONFIG_PPP
+      dep_tristate '  PPP support for sync tty ports' CONFIG_PPP_SYNC_TTY 
$CONFIG_PPP
+      dep_tristate '  PPP Deflate compression' CONFIG_PPP_DEFLATE 
$CONFIG_PPP
+      dep_tristate '  PPP BSD-Compress compression' CONFIG_PPP_BSDCOMP 
$CONFIG_PPP
+      if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+         dep_tristate '  PPP over Ethernet (EXPERIMENTAL)' CONFIG_PPPOE 
$CONFIG_PPP
+      fi
+   fi
+
    endmenu
fi
===============END PATCH==============
Then "make ARCH=um xconfig" and enable the PPP options  in the network 
device menu. I haven't tested it as a module, so that may not work. You also 
have to install pppd in the rootfs image (for the debian image, at least, 
you can do this easily by booting it up with some other networking option 
and running "apt-get install ppp"). You also have to make sure that the 
virtual serial line isn't being used for getty (comment out the line 
containing serial/0 in /etc/inittab)/ To get ppp running, you have to run 
pppd both inside and outside the UML (make sure your host kernel also 
supports ppp. When you boot the UML check the messages to find which pty it 
allocated for its virtual serial line (it should read something like: 
"serial line 0 assigned pty /dev/ptyp0"). On the host machine run (as root):
"pppd /dev/ttyp0 noauth passive local  nodefaultroute 
<local_IP_address>:<remote_IP_address>"
(You'll have to use for the tty the one that was allocated for the UML's 
virtual serial line). On the UML run:
"pppd /dev/serial/0 noauth local defaultroute".
Both the UML and the host machine should now have a "ppp0" network 
interface. If IP forwarding is enabled on the host, the UML will be able to 
connect to the external network as well. The advantage of using ppp is that 
you can connect two UML virtual machines without having root access to the 
host machine; This would require writing a small program that simply moves 
bits between two ttys.

Wish List Items (are any of them already possible?):
1. Allow allocation of more than one virtual serial line
2. A kernel switch that would allow the user to specify in advance which 
pty(s) should be used for the virtual serial line(s)
3. Allow the UML to use a tty directly, instead of a pty (thus bypassing the 
need for an additional program to connect two ttys)
4. Allow the virtual serial line to be a TCP connection (i.e. allow the UML 
to function as a virtual "terminal server"). This would be very useful, 
since you could then use a remote server to connect a UML to the network, 
without requiring root privileges on the server actually running the UML.
5. Integrate the PPP code in a similar manner to the SLIP code (so that from 
inside the UML the ppp device would appear to be a regular network device).


   -Tal


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [uml-user] networking

From: Jeff Dike <jdike@ka...> - 2000-12-29 01:23

xrynx@... said:
> Wish List Items (are any of them already possible?): 
> 1. Allow allocation of more than one virtual serial line 

Not yet.

> 2. A kernel switch that would allow the user to specify in advance
> which  pty(s) should be used for the virtual serial line(s) 

Not yet.  The same thing would be useful for the consoles and slip device as 
well.

> 3. Allow the UML to use a tty directly, instead of a pty (thus
> bypassing the  need for an additional program to connect two ttys) 

So, you'd hook it up to an unused console on the host, switch to that console, 
and you'd see the UML login?

> 4. Allow the virtual serial line to be a TCP connection (i.e. allow
> the UML  to function as a virtual "terminal server"). This would be
> very useful,  since you could then use a remote server to connect a
> UML to the network,  without requiring root privileges on the server
> actually running the UML. 

This would be done by running PPP on both sides of the connection, I take it?  
That's an interesting idea.

> 5. Integrate the PPP code in a similar manner to the SLIP code (so
> that from  inside the UML the ppp device would appear to be a regular
> network device). 

I looked at ppp before deciding to use slip.  I think the reason was that I 
couldn't see how to get access to a ppp device from userspace, although I 
guess that pppd manages it fine.

				Jeff

Re: [uml-user] networking

From: Jeff Dike <jdike@ka...> - 2000-12-30 02:47

xrynx@... said:
>  I was thinking about having  one UML use a pty, and a second UML use
> the corresponding tty - that way it  would appear that they are
> connected via a serial line.

That's a cute idea.

> On the host side  of the connection, you'd get a tty to which you can
> connect pppd (i.e. The  exact same thing you get when you actually run
> pppd inside the UML on the  virtual serial line). Since you're not
> actually creating an interface on the  host side, you don't need root
> permissions.

Are you sure about this?  It is my impression that anything that wants to get 
raw packets in and out of the kernel needs to set up an interface, and that 
requires root (or CAP_NET_ADMIN).

I've started generalizing the console and serial line interface to the outside 
world to make this all possible.  If you're on the devel list, you saw the 
first installment of this yesterday with the modernization of the serial line 
driver.

My current plans are to allow the consoles and serial lines to connect to the 
outside world via:
	pre-setup file descriptors
	xterms
	ptys (and pts devices)
	ttys
	sockets (including successive connections to the socket getting successive 
uml devices)

I especially like the idea of having uml consoles/serial lines accessible via 
'telnet umlhost nnnnn'.

Am I missing anything interesting?

				Jeff

Re: [uml-user] networking

From: Myrtle Meep <xrynx@ho...> - 2000-12-30 02:47

>
> > 3. Allow the UML to use a tty directly, instead of a pty (thus
> > bypassing the  need for an additional program to connect two ttys)
>
>So, you'd hook it up to an unused console on the host, switch to that 
>console,
>and you'd see the UML login?
>
I didn't think of that, but it's a great idea. I was thinking about having 
one UML use a pty, and a second UML use the corresponding tty - that way it 
would appear that they are connected via a serial line.

> > 4. Allow the virtual serial line to be a TCP connection (i.e. allow
> > the UML  to function as a virtual "terminal server"). This would be
> > very useful,  since you could then use a remote server to connect a
> > UML to the network,  without requiring root privileges on the server
> > actually running the UML.
>
>This would be done by running PPP on both sides of the connection, I take 
>it?
>That's an interesting idea.
>
Yes.

> > 5. Integrate the PPP code in a similar manner to the SLIP code (so
> > that from  inside the UML the ppp device would appear to be a regular
> > network device).
>
>I looked at ppp before deciding to use slip.  I think the reason was that I
>couldn't see how to get access to a ppp device from userspace, although I
>guess that pppd manages it fine.
>
I don't understand exactly why you need to access the ppp device from 
userspace. What I'm thinking about is something like this: On the host side 
of the connection, you'd get a tty to which you can connect pppd (i.e. The 
exact same thing you get when you actually run pppd inside the UML on the 
virtual serial line). Since you're not actually creating an interface on the 
host side, you don't need root permissions. On the UML side, you'll appear 
to have an "eth0" device but it will actually be a "hidden" instance of 
pppd, with a thin translating layer (to allow emulation of an actual 
ethernet device).
Another possibility is have the host half of the ppp connection be pptp or 
PPPoE (AFAIK existing linux clients actually run pppd). This would allow you 
to connect multiple UMLs in a virtual network using a remote pptp or PPPoE 
server.
     -Tal

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com