Hi, I am trying to run the ISC dhcp relay agent in a zone with vnics, but I get the following error message: Can''t open DLPI device for router3: No such file or directory The interfaces work, as far as I can tell (ping). Does crossbow not support DLPI at all, or is the ISC dhcp just incompatible with it? Thanks, Marcus -- This message posted from opensolaris.org
Asking Google, I found this thread:
http://forums.sun.com/thread.jspa?threadID=5236367
which describes a similar problem, though with real devices.
I noticed now that my interfaces are living in /dev/net. Hacking the code of the
application, I noticed it was looking for the "main" device
("router" not "router[1-3]") instead of the individual
instance, I modified it to directly open the instances, which seems to work ok.
At least it starts now, but I still have to do further tests.
Is there any clean way to provide interface access via DLPI? Symlinks in /dev
would only solve the first issue, but not the second one.
Marcus
--
This message posted from opensolaris.org
Marcus Goller writes:> which describes a similar problem, though with real devices. > I noticed now that my interfaces are living in /dev/net. Hacking the code of the application, I noticed it was looking for the "main" device ("router" not "router[1-3]") instead of the individual instance, I modified it to directly open the instances, which seems to work ok. At least it starts now, but I still have to do further tests.The /dev/net entries are part of Clearview''s "vanity naming" feature. Applications that support vanity-named DLPI instances need to be modified to look in /dev/net first before looking in /dev for the DLPI node. For most applications, it''s a very simple change. Applications that don''t support this must stick with the old (pre-Clearview) names for interfaces. (If you have something that appears only in /dev/net, then you''re probably stuck unless you can modify the application.)> Is there any clean way to provide interface access via DLPI? Symlinks in /dev would only solve the first issue, but not the second one.Yes; update the application to support Clearview''s /dev/net. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Marcus Goller writes:> Thank you (and Garrett) for clarifying that the first issue is > actually Clearview, not Crossbow. As this is an open source software, > changing it to support /dev/net is not the problem. > I am more wondering about the fact that it is not trying to open the > interface instance, but /dev/(net)/router by default. I am not > familiar with using DLPI, is this a common way of accessing the > interfaces or a special implementation in this case? That approach > does not work here of course, because I only have > /dev/net/router[1-3].It sounds like you''re describing the difference between DLPI Style 1 and DLPI Style 2. Both are used on Solaris (and all DLPI) machines, but /dev/net is Style 1 only. Style 1 has a node for each individual device, so you''ll have /dev/foo0 and /dev/foo1, for example. Style 2 has a single node for the whole driver (/dev/foo to continue the example), and the application must use DL_ATTACH_REQ to select the instance desired (0 or 1 in this case) after opening the node. Once the stream is established, there''s no significant difference between them. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Marcus Goller writes:> Ok, that starts to make sense now. The application is indeed using > DL_ATTACH_REQ to choose the instance, so it is following style 2. > If /dev/foo is now the hardware driver and I can only create interface > instances with Crossbow (if I understood that and the vanity naming > convention correctly), how would I be able to use applications, which > use style 2 in zones with virtualized network interfaces? That would > require the existence of a device called /dev/foo or /dev/net/foo, > wouldn''t it?No. Just have the application open the Style 1 node in /dev/net and skip over the DL_ATTACH_REQ. That''s all there is to it -- everything past that point will work fine. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
> Applications that don''t support this must stick with the old> (pre-Clearview) names for interfaces. (If you have something that > appears only in /dev/net, then you''re probably stuck unless you can > modify the application.) In a number of cases we''ve seen, you can get the application to work by specifying the name relative to /dev -- e.g., if you''d usually do "-I vnic0" then "-I net/vnic0" will work. However, in this case, it seems the application has more serious problems as it''s assuming that all DLPI devices are style-2. -- meem
Yup, We have the same problem here, and checking waht the ISC dlpi interface
does, is opening an interface /dev/{drivername} that in case of a vnic, just
doesn''t exist...
open("/dev/vnica", O_RDWR) Err#2 ENOENT
while the interface was created with
dladm create-vnic -l e1000g0 -v 1003 vnica1
ifconfig vnica1 plumb 172.22.2.125/25 up
defining a subnet in the dhcp server for this vnic makes the server not restart
any more
--
This message posted from opensolaris.org
> Yup, We have the same problem here, and checking waht > the ISC dlpi interface does, is opening an interface > /dev/{drivername} that in case of a vnic, just > doesn''t exist... > > open("/dev/vnica", O_RDWR) Err#2 > ENOENT > > > while the interface was created with > dladm create-vnic -l e1000g0 -v 1003 vnica1 > ifconfig vnica1 plumb 172.22.2.125/25 up > > defining a subnet in the dhcp server for this vnic > makes the server not restart any moreCorrection: As we''re using VNICS as IP alias interfaces for the DHCP server, I''ve commented the faulty code for stripping the aliases from the NIC out of the ISC DHCP (common/dlpi.c) and set search path (DLPI_DEVDIR to "/dev/net/") and things start to work automagically ;-) When I have more time, I''ll adapt the code to correctly strip the :x aliases from the interfaces. --- dhcp-4.1.0/common/dlpi.c 2008-03-01 00:57:56.000000000 +0100 +++ ../dhcp-4.1.0/common/dlpi.c 2008-12-29 15:25:46.618603806 +0100 @@ -128,7 +128,7 @@ #define DLPI_MAXDLBUF 8192 /* Buffer size */ #define DLPI_MAXDLADDR 1024 /* Max address size */ -#define DLPI_DEVDIR "/dev/" /* Device directory */ +#define DLPI_DEVDIR "/dev/net/" /* Device directory */ static int dlpiopen(const char *ifname); static int dlpiunit PROTO ((char *ifname)); @@ -785,9 +785,11 @@ ep = cp = ifname; while (*ep) ep++; +#if 0 /* And back up to the first digit (unit number) */ while ((*(ep - 1) >= ''0'' && *(ep - 1) <= ''9'') || *(ep - 1) == '':'') ep--; +#endif /* Copy everything up to the unit number */ while (cp < ep) { -- This message posted from opensolaris.org
> As we''re using VNICS as IP alias interfaces for the DHCP server, I''ve> commented the faulty code for stripping the aliases from the NIC out of > the ISC DHCP (common/dlpi.c) and set search path (DLPI_DEVDIR to > "/dev/net/") and things start to work automagically ;-) Great. For OpenSolaris, the best thing to do is change the code to just call dlpi_open(3DLPI). -- meem