From: Jeff D. <jd...@ka...> - 2001-05-10 15:05:54
|
ma...@pl... said: > If the ethertap driver is considered obsolete, why are we using it? Because it's not obsolete on 2.2. Jeff |
From: Jeff D. <jd...@ka...> - 2001-05-16 15:05:27
|
hn...@ma... said: > Why do you need to specify IP addresses? The TAP driver should not > care about IP's. The UML needs an IP address if it's going to talk to anything. > I seriously dislike the idea of having UML automatically configure the > TAP interface on the host. This is the responsibility of the host > administrator. At this point, the UML user is the administrator. At some later point, I'm going to introduce a config file which says exactly how users are allowed to network with the host. At that point, the UML helper may just read IP addresses from the config file, or it will check the ones it was given to see if they're allowed. What I'm trying to do with the helper is eliminate the networking setup nightmares that are a pretty regular occurrence with the current stuff. Jeff |
From: Henrik N. <hn...@ma...> - 2001-05-17 14:32:50
|
yes, but that IP you set with ifconfig within the UML, and the host ends IP address (and routing) you set with ifconfig on the host. What I questioned is why the TAP NIC driver needs to know the IP addresses. TAP is not concerned with IP addresses, it is only a software point-to-point ethernet connection. What you might want to be able to specify to TAP is the MAC address to use in the UML. For um_eth_serv TCP/IP communication you do need the IP and port of the server, but little more. -- Henrik Nordstrom MARA Systems Jeff Dike wrote: > hn...@ma... said: > > Why do you need to specify IP addresses? The TAP driver should not > > care about IP's. > > The UML needs an IP address if it's going to talk to anything. > > > I seriously dislike the idea of having UML automatically configure the > > TAP interface on the host. This is the responsibility of the host > > administrator. > > At this point, the UML user is the administrator. At some later point, I'm > going to introduce a config file which says exactly how users are allowed to > network with the host. At that point, the UML helper may just read IP > addresses from the config file, or it will check the ones it was given to see > if they're allowed. > > What I'm trying to do with the helper is eliminate the networking setup > nightmares that are a pretty regular occurrence with the current stuff. > > Jeff |
From: johan v. <joh...@pa...> - 2001-05-19 00:53:01
|
Henrik Nordstrom wrote: > > yes, but that IP you set with ifconfig within the UML, and the host ends > IP address (and routing) you set with ifconfig on the host. If I am not mistaken, this can be done automagically with the hotpluging package. (ip, routing AND HW address.) It would configure the host kernel interface as soon as it appears. (It should work for all netdevices). This way, everything is set up automatically in the host when UML boots without any provisions in UML and under control of the host adminitrator. It is definatly an argument to make the host ip address at least optional. I also don't understand why there are IP addresses there at all? This can all be handled by the UML system boot scripts as on normal kernels. Only the HW address as parameter should be sufficent. Just my .02 J. |
From: Jeff D. <jd...@ka...> - 2001-05-17 15:57:36
|
hn...@ma... said: > and the host ends IP address (and routing) you set with ifconfig on > the host. Right, which is exactly what happens. Except that ifconfig is run from the helper, which is invoked by the driver. The driver doesn't know anything about the host IP address except that it's a cookie to be passed to the helper. > What you might want to be able to specify to TAP is the MAC address to > use in the UML. Yeah, I'm probably going to add that at some point. Jeff |
From: Henrik N. <hn...@ma...> - 2001-05-18 08:08:18
|
Jeff Dike wrote: > hn...@ma... said: > > and the host ends IP address (and routing) you set with ifconfig on > > the host. > > Right, which is exactly what happens. Except that ifconfig is run from the > helper, which is invoked by the driver. The driver doesn't know anything > about the host IP address except that it's a cookie to be passed to the helper. The problem I am having is a conceptual one. NIC hardware and cabling does not usually care about IP addresses, why should the UML variant do? From a conceptual point of view the helper is part of the UML NIC hardware emulation. A TAP interface on the host is the equivalence of a crossed ethernet cable connecting the userspace application with a ethernet NIC on the host. The application (i.e. UML) may attach and detach this virtual cable to the host whenever it wants, similar to how you plug and unplug a cable in in the physical world.. If you were using the non persistent TUN/TAP device of 2.4 (without patching) then using a helper makes some sense as the host interface is truly lost when the application disconnects, and it is quite awkward to get it configured automatically, but not when using ETHERTAP or persistent TUN/TAP. What I see as being useful in a production UML is a more generic trigger interface that is called whenever a UML interface is brought up or down, passing the UML name, UML interface name and TAP device name and a kernel command line specified cookie as arguments, but it should not default to use a SUID helper for reconfiguring the host. It the administrator wants such a thing for some reason he/she can do it via the trigger. -- Henrik Nordstrom |
From: Jeff D. <jd...@ka...> - 2001-05-18 21:06:17
|
Joa...@lu... said: > We test the protocol by starting a few UML's, each UML has a virtual > eth i/f connected to a tap device on the host. On the host we bring > the different tap's into a bridge to simulate a small LAN. Wouldn't a truly virtual net (i.e. no connection to the host) be a better way go with that? In any case, having the helper automatically set everything up nicely is not going to be mandatory forever. I'm having it done by default because that's the common case. The helper isn't going away. It will probably become optional at some point for people who know what they're doing, though. > Question: Why not to let the virtual eth i/f open /dev/tapx directly > instead of having a helper app opening it? It can't. It doesn't have permission. Jeff |
From: Joakim T. <Joa...@lu...> - 2001-05-18 23:41:18
|
----- Original Message ----- "Jeff Dike" <jd...@ka...> > Joa...@lu... said: > > We test the protocol by starting a few UML's, each UML has a virtual > > eth i/f connected to a tap device on the host. On the host we bring > > the different tap's into a bridge to simulate a small LAN. > > Wouldn't a truly virtual net (i.e. no connection to the host) be a better way > go with that? No, you need a connection somewhere to get something useful. A basic tun/tap connection is the simplest connection I know. If none of the provided connection methods will do, you have to write a backend yourself anyway. > > In any case, having the helper automatically set everything up nicely is not > going to be mandatory forever. I'm having it done by default because that's > the common case. Perhaps a new option to uml to bypass the current default behaviour? > > The helper isn't going away. It will probably become optional at some point > for people who know what they're doing, though. Good, the sooner the better :-) > > > Question: Why not to let the virtual eth i/f open /dev/tapx directly > > instead of having a helper app opening it? > > It can't. It doesn't have permission. Yes, the ordinary user does not have permission, but if you want to do any development like we do, you need root permissions anyway. UML could try to open tap i/f's if asked to do so and fail if permissions don't allow it. Jocke > > Jeff |
From: David W. <dw...@in...> - 2001-05-19 16:18:59
|
jd...@ka... said: > > Question: Why not to let the virtual eth i/f open /dev/tapx directly > > instead of having a helper app opening it? > It can't. It doesn't have permission. This is absolutely the right way to do it, IMHBCO. And it used to work with the old Ethertap driver. ifconfig tap0 x.x.x.x pointopoint y.y.y.y ; chown dwmw2.dwmw2 /dev/tap0 -- dwmw2 |
From: Henrik N. <hn...@ma...> - 2001-05-19 21:06:11
|
In the 2.4 tuntap world you are a bit more restricted, only having one device node, and anyone who can open the device for writing will be allowed to create new dynamic but unconfigured TUN/TAP devices. In the persistent version of the driver you can preconfigure a number of interface names, and assign these to users. Persistent devices keep their configuration even when there is no application attached, and only the configured user are allowed to attach to the devicename (interfacename). TUN/TAP devices may be named anything by the application (for example "eth5" if you so like), but there may only exist one interface of a given name at a time, so a user cannot replace any existing interface (including persistent TUN/TAP interfaces) -- Henrik Nordstrom David Woodhouse wrote: > This is absolutely the right way to do it, IMHBCO. And it used to work with > the old Ethertap driver. > > ifconfig tap0 x.x.x.x pointopoint y.y.y.y ; chown dwmw2.dwmw2 /dev/tap0 > > -- > dwmw2 > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel |
From: Jeff D. <jd...@ka...> - 2001-05-19 01:57:49
|
Joa...@lu... said: > UML could try to open tap i/f's if asked to do so and fail if > permissions don't allow it. OK, how about 'eth0=ethertap,tap0,nosetup' on the command line means that UML will try to open tap0 all by itself, it will complain bitterly if it can't, and setting up the UML and host sides of the interface is completely up to you? Does that work for everyone? Jeff |
From: Joakim T. <Joa...@lu...> - 2001-05-19 13:22:59
|
Yes! How about the MAC addresses? Maybe it shold be possible to specify UML's mac address(and tap?) on the command line? What about the tuntap driver? The lastest version(which contain persistent tap's) has been sent to Linus. Maybe it should be possible to specify persisten yes/no on command line as well? Jocke > Joa...@lu... said: > > UML could try to open tap i/f's if asked to do so and fail if > > permissions don't allow it. > > OK, how about 'eth0=ethertap,tap0,nosetup' on the command line means that UML > will try to open tap0 all by itself, it will complain bitterly if it can't, > and setting up the UML and host sides of the interface is completely up to you? > > Does that work for everyone? > > Jeff > > |
From: Henrik N. <hn...@ma...> - 2001-05-19 13:41:25
|
Joakim Tjernlund wrote: > What about the tuntap driver? The lastest version(which contain persistent > tap's) > has been sent to Linus. Maybe it should be possible to specify persisten > yes/no on > command line as well? The persistent TUN/TAP driver does not need any specific support in the application (i.e. UML) other than the ability to specify the interface name to attach to. Using it is very similar to ETHERTAP. You first create a device on the host, then ask the application to attach to this interface. If you are using the helper approach for setting up the host interface, then this can easily be extended to make the interface persistent, but I fail to see the use of persistent interfaces if you select to have them automatically configured by UML when needed... -- Henrik Nordstrom MARA Systems h |
From: Joakim T. <Joa...@lu...> - 2001-05-19 22:01:30
|
> If you are using the helper approach for setting up the host interface, then > this can easily be extended to make the interface persistent, but I fail to see > the use of persistent interfaces if you select to have them automatically > configured by UML when needed... You are probably right, I was thinking: Let UML create(if needed) the interfaces(persistent) but not configure them. Then do all config in host once(IP/MAC addresses, bridges etc.), not every time you restart UML. Jocke > -- > Henrik Nordstrom > MARA Systems > h > |
From: Henrik N. <hn...@ma...> - 2001-05-19 23:26:00
|
Joakim Tjernlund wrote: > You are probably right, I was thinking: Let UML create(if needed) the > interfaces(persistent) but not configure them. Then do all config > in host once(IP/MAC addresses, bridges etc.), not every time you restart > UML. Why not set up the persistent interface before you start the UML the first time? You need to tell UML which TAP interface to use anyway if you are using persistent tuntap devices or it won't know which persistent device to attach to. -- Henrik Nordstrom MARA Systems |
From: Joakim T. <Joa...@lu...> - 2001-05-20 10:09:51
|
> > You are probably right, I was thinking: Let UML create(if needed) the > > interfaces(persistent) but not configure them. Then do all config > > in host once(IP/MAC addresses, bridges etc.), not every time you restart > > UML. > > Why not set up the persistent interface before you start the UML the first > time? You need to tell UML which TAP interface to use anyway if you are using > persistent tuntap devices or it won't know which persistent device to attach > to. That's why I wrote "You are probably right" above :-) The "nosetup" option will force UML not to mess with the tap's configuration I guess? Jocke > > -- > Henrik Nordstrom > MARA Systems > |
From: Henrik N. <hn...@ma...> - 2001-05-19 13:37:24
|
Jeff Dike wrote: > Joa...@lu... said: > > UML could try to open tap i/f's if asked to do so and fail if > > permissions don't allow it. > > OK, how about 'eth0=ethertap,tap0,nosetup' on the command line means that UML > will try to open tap0 all by itself, it will complain bitterly if it can't, > and setting up the UML and host sides of the interface is completely up to you? > > Does that work for everyone? Fine by me. -- Henrik |
From: Jeff D. <jd...@ka...> - 2001-05-19 01:57:56
|
joh...@pa... said: > I also don't understand why there are IP addresses there at all? This > can all be handled by the UML system boot scripts as on normal > kernels. The system startup scripts can't set up the host side of the tap device. The reason I'm putting both IP addresses on the command line is that we don't want nasty users to be able to ifconfig the ethernet device with any IP address they want. So the plan is that everything that's specified on the command line will be hardwired and can't be changed from inside UML. Further plans are for all this stuff to be moved to a config file. So, the driver or helper will read it to see what devices and addresses are allowed to be used. > If I am not mistaken, this can be done automagically with the > hotpluging package. (ip, routing AND HW address.) It would configure > the host kernel interface as soon as it appears. (It should work for > all netdevices). Fine, I'll look into that. But that would be one more thing the hapless UML networking newbie has to do in order to get up and running. The immediate plan is to make setting up UML networking as little work and as failsafe as possible. What I want the procedure to look like is this: Set up the command line Run UML ifconfig the device add a route to the outside and you can talk to the whole world and it can talk to you. I want the 12-step HOWTO to disappear and never come back. Lots of people tried to set up UML networking using it and failed. In the meantime, everyone who knows what they're doing can drop /bin/true on top of ethertap_helper and set up the devices themselves. Jeff |
From: Henrik N. <hn...@ma...> - 2001-05-19 13:37:31
|
Jeff Dike wrote: > The reason I'm putting both IP addresses on the command line is that we don't > want nasty users to be able to ifconfig the ethernet device with any IP > address they want. So the plan is that everything that's specified on the > command line will be hardwired and can't be changed from inside UML. This (restricting address selection in the UML) you better solve with firewalling on the host. Not the task of UML. In fact doing so would seriously restrict what you can use UML for. Another note: There may well be other protocols than IP in use on the interface. -- Henrik Nordstrom MARA Systems |
From: Jeff D. <jd...@ka...> - 2001-05-19 14:46:58
|
hn...@ma... said: > This (restricting address selection in the UML) you better solve with > firewalling on the host. Not the task of UML. OK, that's something I hadn't thought about. That takes one IP address off the command line. Are there any problems with locking the mac address by putting it on the command line? Jeff |
From: Lennert B. <bu...@gn...> - 2001-05-19 18:28:42
|
On Sat, May 19, 2001 at 11:00:26AM -0500, Jeff Dike wrote: > > This (restricting address selection in the UML) you better solve with > > firewalling on the host. Not the task of UML. > > OK, that's something I hadn't thought about. That takes one IP address off > the command line. > > Are there any problems with locking the mac address by putting it on the > command line? Well, you can obviously still spoof the MAC address by opening a raw socket and sending raw frames out, if that's what you mean. cheers, Lennert |
From: Henrik N. <hn...@ma...> - 2001-05-19 21:06:04
|
Jeff Dike wrote: > OK, that's something I hadn't thought about. That takes one IP address off > the command line. Fine. And the other (the host IP) should be optional, as part of the argument definiton to the "generic interface change trigger program". > Are there any problems with locking the mac address by putting it on the > command line? Should be optional, and being able to specify the MAC is mostly a convenience thing if the automatic MAC selection is not sufficient. From a security it is not very important as in most cases the MAC will only be visible between the host and the UML. MAC addresses are local to a ethernet LAN segment, and in case of a normal TAP device a "lan segment" contains at most two stations (the host and the UML). The exception is when you start bridging several host interfaces together, widening the logical ethernet segment.. If you are not bridging then the UML MAC addresses are of no concern as the TAP device is essentially a point-to-point communication using ethernet frames as the frame protocol.. -- Henrik Nordstrom MARA Systems |
From: johan v. <joh...@pa...> - 2001-05-20 18:50:02
|
Jeff Dike wrote: > > hn...@ma... said: > > This (restricting address selection in the UML) you better solve with > > firewalling on the host. Not the task of UML. > > OK, that's something I hadn't thought about. That takes one IP address off > the command line. kewl. Not specifying the uml-side address also means you won't have any problems trying to prevent multiple ipaddresses being assigned to your ethertap device. J. |
From: Jeff D. <jd...@ka...> - 2001-05-19 14:44:01
|
Joa...@lu... said: > How about the MAC addresses? Maybe it shold be possible to specify > UML's mac address(and tap?) on the command line? I'm planning on that. > What about the tuntap driver? It's coming. I'm going to do the routing daemon next, then the TUN/TAP interface. > The lastest version(which contain > persistent tap's) has been sent to Linus. Cool. If you're keeping an eye on that, can you let me know when Linus releases it? Jeff |
From: Joakim T. <Joa...@lu...> - 2001-05-19 22:05:24
|
> Joa...@lu... said: > > How about the MAC addresses? Maybe it shold be possible to specify > > UML's mac address(and tap?) on the command line? > > I'm planning on that. Thanks :-) > > > What about the tuntap driver? > > It's coming. I'm going to do the routing daemon next, then the TUN/TAP > interface. I would wote for TUN/TAP first :-) > Cool. If you're keeping an eye on that, can you let me know when Linus > releases it? Sure, if I manage to spot it before you do:-) Jocke > > Jeff |