So, basically even though the user has specified a static IP, the unit DHCP's anyway. Considering that a well-behaved DHCP server will probe the active addresses, it's *guaranteed* that not even by accident will the NSLU2 get the static IP that the user set. Hence the device is "lost on the ether".
Debugging this situation is difficult for the novice. First, the user set a static IP -- there's no reason for them to go check their router to see if it issued a DHCP IP in the first place; they're not expecting that to happen. Secondly, many routers don't even provide a means to check what DHCP has done, so the user can't discover the IP even if a wiki or document told them to do so (I believe that Linksys, one of the most common routers in this area, is one such vendor). Personally, I find this behavior of the installer to be wrong, in the same way that I would be angry if my automobile took it upon itself to turn the steering wheel for me, because I happened to leave the turn-signal activated for too long. But I'm not a Debian user (I just happen to frequent the #nslu2-general IRC channel where this issue has become so commonly asked). IMO, if this behavior is retained, it needs a gigantic red box (flashing, preferably) on the web pages describing the installation process. Many of the users I encounter on that IRC channel are truely novices, so the text also should not just limit itself to outlining the behavior, but the implications of it as well (that the unit will DHCP and that many users may not have routers that offer the ability to see what the DHCP IP might have been, resulting in an NLSU2 on the network that is well and truely lost). And, no, running nmap to find it is not an option for most of these users! Regards, Mike (mwester) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
