Nekonomicon - What's the skinny on 'licensed' o3400+ routers

2ndadamdick
Who joined Oct. 9, 2007, 12:14 p.m.

Wrote the following at April 27, 2008, 8:16 a.m...

I remember reading that SGI kind of did a nasty FU license scheme on their R-Bricks

Apparently when you first install a R-Brick it trys to figure out which 03400+ you are and then locks the configuration in the R-Brick and you can't use it for other systems

I also remember reading about a clear routing to put the R-Brick's back to factory state

Can anybody shed some light on this ??

Thanks, Adam

ShadeOfBlue
Moderator
From Europe
Who joined Nov. 25, 2003, 12:09 p.m.

Wrote the following at April 27, 2008, 5:20 p.m...

According to this document (thanks, Ian!), the SSN (system serial number) located in the NVRAM of the brick's L1 controller has to be set to L0000000 for the brick to obtain a new SSN from the neighbouring bricks.

SGI doc #108-0240-002 wrote: When an R brick needs to be added to a system or moved to a different system, SGI
authorized personnel can clear the SSN that is stored in the L1 controller’s NVRAM.
[...]

To clear the SSN, SGI authorized personnel use a temporary authenticator generation
software program, which is located on a secure Web server that can be accessed via
WebSAFE (use your SGI login and password). Using the brick serial number, this software
generates an authenticator (four alphanumeric fields [total of 18 characters]) that is based
on the brick public key and the current date and time.

The SGI authorized personnel input this authenticator into the L1 controller
validation/serial number change software. The L1 controller software compares the
authenticator to the brick public key. When the authenticator matches the brick public key
and it has not expired, the L1 controller software clears the brick SSN. When the
authenticator does not match the public key or if the authenticator has expired, the L1
controller software does not change the SSN.

However, according to the same document, the L1 controller's NVRAM chip is socketed, so if the SSN is stored in cleartext, it could be rewritten without much trouble, hypothetically speaking.

2ndadamdick
Who joined Oct. 9, 2007, 12:14 p.m.

Wrote the following at April 27, 2008, 8:21 p.m...

ShadeOfBlue wrote: According to this document (thanks, Ian!), the SSN (system serial number) located in the NVRAM of the brick's L1 controller has to be set to L0000000 for the brick to obtain a new SSN from the neighbouring bricks.

SGI doc #108-0240-002 wrote: When an R brick needs to be added to a system or moved to a different system, SGI
authorized personnel can clear the SSN that is stored in the L1 controller’s NVRAM.
[...]

To clear the SSN, SGI authorized personnel use a temporary authenticator generation
software program, which is located on a secure Web server that can be accessed via
WebSAFE (use your SGI login and password). Using the brick serial number, this software
generates an authenticator (four alphanumeric fields [total of 18 characters]) that is based
on the brick public key and the current date and time.

The SGI authorized personnel input this authenticator into the L1 controller
validation/serial number change software. The L1 controller software compares the
authenticator to the brick public key. When the authenticator matches the brick public key
and it has not expired, the L1 controller software clears the brick SSN. When the
authenticator does not match the public key or if the authenticator has expired, the L1
controller software does not change the SSN.

However, according to the same document, the L1 controller's NVRAM chip is socketed, so if the SSN is stored in cleartext, it could be rewritten without much trouble, hypothetically speaking.

I remember reading about a back door into clearing - has anybody heard of this ??

WTF reason in the world would case SGI intergrate asym crypto keying for the B-Ricks ?????

SAQ
From Renton, WA
Who joined July 19, 2006, 8:37 a.m.

Wrote the following at April 27, 2008, 9:20 p.m...

(a) prevent people from monkeying with system IDs.

(b) "You want to change your O3400 config? That must be done by SGI service - we'll have them send you a quote. Have you ever considered a service contract?"

.

Hopefully they'll release the codes when the O(3*10^X) series hits end-of-support and they won't make any more money from service.

"Brakes??? What Brakes???"

:Indigo:

(single-CM)

ShadeOfBlue
Moderator
From Europe
Who joined Nov. 25, 2003, 12:09 p.m.

Wrote the following at April 28, 2008, 3:40 a.m...

2ndadamdick wrote: I remember reading about a back door into clearing - has anybody heard of this ??

Yes, but it seems this refers to the generated authenticator from the other document:

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_EndUser/Origin_3K_OG/sgi_html/apb.html wrote: Use serial <str> <str> <str> <str> to reassign the SSN for a brick. The variable <str> <str> <str> <str> is the value of a security key that is provided only to SGI employees.

Use serial security on to enable the SSN security.

SAQ wrote: Hopefully they'll release the codes when the O(3*10^X) series hits end-of-support and they won't make any more money from service.

*fingers crossed*

nekonoko
Site Admin
From Pleasanton, California
Who joined Jan. 23, 2003, 1:31 a.m.

Wrote the following at April 28, 2008, 3:44 a.m...

SAQ wrote: Hopefully they'll release the codes when the O(3*10^X) series hits end-of-support and they won't make any more money from service.

I'll bet the Altix series uses the same codes so the EOL may be a long time in coming.

Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

jan-jaap
Donor
From Wijchen, The Netherlands
Who joined June 17, 2004, 11:35 a.m.

Wrote the following at April 28, 2008, 3:58 a.m...

SAQ wrote: (a) prevent people from monkeying with system IDs.

(b) "You want to change your O3400 config? That must be done by SGI service - we'll have them send you a quote. Have you ever considered a service contract?" .

(c) To stop 3rd world countries with nuclear ambitions from evading the export restrictions by buying a couple of small systems and merging them into a large configuration. These days, with PC clusters, this argument has become irrelevant.

Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

maxsleg
From Stuttgart
Who joined April 3, 2007, 11:56 p.m.

Wrote the following at April 28, 2008, 4:12 a.m...

(c) To stop 3rd world countries with nuclear ambitions from evading the export restrictions by buying a couple of small systems and merging them into a large configuration. These days, with PC clusters, this argument has become irrelevant.

That is the reason I have seen on documentation - the US still has very strong export controls on certain areas of technology (even limiting some countries limit to Windows 98 based products..)

I believe you can hack a router - have seen some notes regarding this

ShadeOfBlue
Moderator
From Europe
Who joined Nov. 25, 2003, 12:09 p.m.

Wrote the following at April 28, 2008, 5:59 a.m...

nekonoko wrote: I'll bet the Altix series uses the same codes so the EOL may be a long time in coming.

I just checked the Altix docs on Techpubs -- you're right:

serial <str> <str> <str> <str>

Erases and reassigns the device's SSN. The variable <str> <str> <str> <str> is the value of a security key that is provided only to SGI employees.

This document also has an explanation of the "serial security on" command:

Enables the system serial number (SSN) security. When this feature is enabled, it will not allow bricks or enclosures to power up if their SSN does not match those of neighboring bricks or enclosures. To change the SSN on a brick or enclosure, you need a key that can be obtained through a service request to SGI.

It seems this particular command doesn't need any special keys, so if you could do "serial security off", the bricks would boot normally (although they would probably whine about the mismatched SSN).
I'm probably being too optimistic here

tjsgifan
From Hampshire, UK
Who joined Sept. 14, 2004, 3:03 a.m.

Wrote the following at April 28, 2008, 8:23 a.m...

The frustrating thing was also that some of the very early bricks shipped with this Security feature disabled, but this was automatically enabled if you updated the firmware on the L1 (which most people did when firmware updates were released by SGI ie with IRIX updates), only to find they had nobbled the machine unexpectedly.

If there is anyone out there with old versions of L1's that are still running the PROM version that was current in IRIX 6.5.13 say (l1 revision less than 1.3 something I think), I know some people that would pay very good money for them

In order of use at the moment..... :Fuel:

Currently looking to buy good :Fuel:

and

machine.

nekonoko
Site Admin
From Pleasanton, California
Who joined Jan. 23, 2003, 1:31 a.m.

Wrote the following at May 1, 2008, 10:29 p.m...

ShadeOfBlue wrote: It seems this particular command doesn't need any special keys, so if you could do "serial security off", the bricks would boot normally (although they would probably whine about the mismatched SSN).
I'm probably being too optimistic here

It depends on the brick type I guess. I've NUMAlinked two O300s and two O350s so far - each had separate serial numbers and would not power on when cabled together (System Serial Number mismatch message on L1 display and red lamp).

The solution in my case was to enter the L1 of the brick I wanted to update and enter "serial clear". The brick then wiped its local serial, looked over the NUMAlink for the serial in the other brick, grabbed it and reprogrammed itself to this new number (so if you have nodelocked software on one of the bricks make sure you clear the right one).

Maybe it's due to my L1 versions:

Code: Select all


   # l2cmd "l1 version"
   

   001c01:
   

   L1 1.22.6 (Image B), Built 08/07/2003 12:57:04    [2MB image]
   

   001c02:
   

   L1 1.22.6 (Image A), Built 08/07/2003 12:57:04    [2MB image]

recondas
Moderator
From NC - USA
Who joined June 6, 2004, 5:55 p.m.

Wrote the following at May 27, 2008, 6:32 p.m...

tjsgifan wrote: The frustrating thing was also that some of the very early bricks shipped with this Security feature disabled, but this was automatically enabled if you updated the firmware on the L1 (which most people did when firmware updates were released by SGI ie with IRIX updates), only to find they had nobbled the machine unexpectedly.
.......(l1 revision less than 1.3 something I think)

I ran across an indirect mention of this in the Origin 3000 Series L3 Controller 1.4 Update Guide :

L1 Firmware
Note: This version of L1 firmware (version 1.6.0) enables the Router
Port security and System Serial Number security features (if not already
enabled by previously installing a 1.4.x version of L1 firmware). If your
system is not configured properly, these features can cause your R-bricks
not to power up or boot.

***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

SGI: Hardware

What's the skinny on 'licensed' o3400+ routers