I wonder what the official LL response would be if you gave a randomly generated MAC in these situations, or some kind of hash from other aspects of the hardware -any lindens wish to comment?
The other thing of course is defining what "this computer" means for those of us who like to fiddle with our hardware. Personally i'm often swapping components out of my desktop including harddrives and ethernet cards. On Thu, Feb 25, 2010 at 1:28 PM, Henri Beauchamp <sl...@free.fr> wrote: > On Wed, 24 Feb 2010 05:49:01 -0600, Argent Stonecutter wrote: > >> On 2010-02-23, at 15:43, Robin Cornelius wrote: >> > Also any one using mono with libomv has an issue as that cannot get >> > the adaptor mac address and passes a NULL mac address, in the past LL >> > have allowed a null mac address as they knew of this problem, clearly >> > now though thats a breach of 2c part i. >> >> Not to mention that any device using SLIP or PPP, (and probably other >> point-to-point protocols that don't require an address at the physical >> layer) may not have a MAC address or ANY analogous hardware layer >> address (even a PSTN). TCP/IP does not imply Ethernet. >> >> Admittedly this is not likely to be a common scenario, but the whole >> idea that a MAC address is a unique identifier for a device is based >> on a deep-seated confusion about the network stack. > > And today, LL seems to have pulled the plug off already for clients not > prociding the MAC address on connection. Here is a copy of the ticket I > just opened (I propose that everyone on this list using a text client > opens the same kind of ticket): > > Summary: I cannot login any more using Mono-based, text only clients > > Details: > > Today I cannot connect any more when using text only "viewers" (clients) > which are written in C# (Mono), such as OMV-light and Radegast. > > I get the following error: > "Second Life cannot be accessed from this computer." > but I can still connect from the same computer using either an official > or full fledged third parties viewer. > > I therefore deduce, that you just disallowed the connection for clients > not transmitting the MAC address of the Ethernet card the viewers are > connected through (Mono/C# won't allow to retrieve such info). > While LL has the right to change their policy about which client can > connect or not to their service, I think it would be only normal to let > a reasonable amount of time for the developers of third parties > viewers/clients to adapt their software and make it compliant before such > a policy is enforced. > > Seeing how the TPV policy was published only a couple of days ago, I don't > see how OMV-light and Radegast developers could adapt fast enough ! > > Please note also that not all network interfaces got a MAC address (for > example, an USB ADSL MODEM could or could not have such an address, > depending entirely on its driver, and PPP links via MODEMs don't have a > MAC address either), so basically, you are denying connection to SL to > any resident not using a Ethernet card to connect to Internet !... > This is pretty unreasonable too... > > Please, allow again the connection via text only clients (the only way to > stay in contact all day long with your customers without having to run a > viewer which eats up half of your memory and CPU power !). > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > -- “Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.” - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges