Bill Shannon writes: > James Carlson wrote: > > Is there still a problem here in the networking component itself > > (other than the GUI)? If so, I'd like to help solve it. > > No, after configuring it all by hand, networking is working fine. > The question is, why didn't the GUI find the interface? Is it > something about this interface on this machine? Or is this version > of the GUI broken? I know, this is not the place to ask these > questions.
Honestly, I don't know anything about how the GUI works internally. Yes, this isn't the right place. Maybe Darren Kenny (one of the leads on JDS) is lurking, but I doubt it, as this is a mailing list with a very low S/N ratio. > > It should not take much cleverness to make this happen. Unless the > > DHCP server is broken or the address space is overcommitted, you > > should get the same IP address every single time. That's by design. > > That hasn't been my experience. It often happens, but not always. > Maybe it only changes if the machine has been down for awhile. I guess I don't know how to help with that. It's certainly been my experience, but, then, I discard or disable equipment that doesn't work right. Sun's DHCP server does a fine job with this -- you can leave a machine off for years and, as long as the server hasn't run out of addresses and been forced to reassign that one, it'll give you the same address back. > > And if you really want a specific one, then nailing that address to a > > specific MAC address or client ID is pretty easy with most decent > > servers. It's usually just one command. > > I was able to do that with a newer Linksys router, but the one I'm using > now is older and it doesn't seem to have that capability. Oh. > $ ifconfig -a > lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 > index 1 > inet 127.0.0.1 netmask ff000000 > iprb0: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 > index 2 > inet 192.168.1.10 netmask ffffff00 broadcast 192.168.1.255 > lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 > index 1 > inet6 ::1/128 There's nothing too surprising there. Bill Shannon writes: > James Carlson wrote: > >> I am *so* sorry I upgrade to snv_98... > > > > I don't see how that relates to the previous poster's note about > > snv_100. > > I had snv_86 working quite well on two machines and I was very happy > with it. Since upgrading those machines and installing snv_98 on > another machine (the one that started this thread), I've found quite > a few things that are worse than snv_86. When I point out the problems, > they're all expected to be fixed in snv_100 or snv_101 or snv_102. I > just feel like I upgraded too soon. For what it's worth, I update on every single build. There are things that do break, but this is a low-breakage area. (High-breakage, at least for me, are X Window System fonts. Maybe I'm just unlucky with them, but they seem to be random.) > I just tried the GUI on another of my snv_98 machines and it seems to > be working fine. At least, it finds the interface. So maybe it's > something peculiar about the original machine or the interface on that > machine that's causing the problem? > > You don't suppose it's confused because the interface name is 4 characters > (iprb) instead of three (nge)? Looking through the truss output on /usr/bin/network-admin, it appears that it invokes '/usr/sbin/dladm show-link -p'. I think that means it may have been broken by the integration of CR 6722523 in snv_96. I don't know why that hasn't been addressed in GNOME. (The output format of that command changed incompatibly in that fix.) The RE on that CR might know more about the issue. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
