Re: [foxboro] Changing AW51B MAC address
- From: "Sweetman, Ian F" <ian.sweetman@xxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 19 Jan 2011 09:55:17 +0800
I know the feeling, it took me a while to remember what a 51B was :-)
Its actually the Sun default for the MAC address to be derived from the
system i.e. hostid.
The eeprom parameter is local-mac-address? I went and looked it up :-)
and is set to false by default, Foxboro doesn't change this setting.
Foxboro does however change a bunch of eeprom settings in the start up
scripts, mainly in S19FOXBORO to try and maintain compliance with the
configuration settings they rely on, of course they don't take affect
until the next reboot.
It was one of these settings that used to ensure that the screen stayed
disabled on an AP even when you enabled it.
The two settings that used to give the most grief were -
sbus-probe-list :- if this was wrong and you had multiple monitors
and/or network cards it screws up the discovery order and therefore such
things as which monitor is the primary and the addressing of the network
cards.
Diag-switch? :- was the other one that used to create havoc, as the
machine can disappear into an endless diagnostic loop, not so bad on an
AW or WP but insanely painful on an AP.
Having been bitten with flat batteries on the nvram chips and machines
that wouldn't boot as a result I always keep a couple of spares handy
along with the instructions on how to reprogram.
Regards
Ian
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of William C Ricker
Sent: Wednesday, 19 January 2011 10:18 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Changing AW51B MAC address
HOSTID to MAC or MAC to HOSTID ; I used to have a working memory, but
I can't remember when.
MAC address from card or from NVRAM; I was not aware there was an
option.
Assumedly Foxboro always sets up for NVRAM, yes?
Yes, reprogramming an NVRAM is straightforward, but I have displayed the
uncanny ability to 'brick' NVRAMs, and on more than one occasion. I've
done more of them om 51D's and only a couple of them on 51B's. Maybe
the D is more tender? Who can say. Still good to have another one
available, though.
Regards,
William C Ricker
FeedForward, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Sweetman, Ian F
Sent: Tuesday, January 18, 2011 6:49 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Changing AW51B MAC address
For the MAC address its actually the other way round William,
The HOSTID is configured in the NVRAM and the MAC address is derived
from this as default.
The HOSTID is printed on the label on top of the NVRAM chip.
On a Sun box there is an NVRAM parameter that allows you to choose
between the hostid version of the mac address or the cards id. Can't
remember the setting at the moment and I'm not in front of a Sun box to
check.
You can use the hostid to order a new NVRAM chip with the same hostid or
in a lot of cases pop the old one and put it in the new box if it isn't
the cause of the problem and it's the same type of nvram in the new box
else reprogram it.
Reprogramming NVRAM is very straight forward if you follow the
instructions.
I've reprogrammed a number over the years and for a number of different
models of Sun box.
I have run into trouble with typo's a couple of times but when all else
fails, reboot the box and reset the NVRAM to defaults.
I have a script that I run once in a while and it goes out and collects
all of the hardware configuration of the Sun boxes including the NVRAM
data. As well as keeping this electronically I keep a paper copy so as
to be able to rebuild NVRAM etc when batteries go flat.
Btw this is also how we get around the license issue if we have to
replace a box.
Ian
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of William C Ricker
Sent: Wednesday, 19 January 2011 8:30 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Changing AW51B MAC address
1) MAC Address.
"MAC address on the Ethernet Card" If it's nodebus, there is no separate
Ethernet card; Ethernet is on the motherboard. The motherboard has no
specific MAC address; the Ethernet address is programmed into the NVRAM
(and BTW, the HOST ID is derived from this Ethernet address)
A second or third Ethernet interface is on a card, but not the Nodebus
interface
The MAC address is not a problem for what you describe. If your system
is older than V 6.2 you will find that FBMs will not reload because the
request to reload is sent to the MAC address from which the CP image was
loaded. There is a way to manually change that in 4.2.? systems and
up. At V 6.2, the problem was rectified. This, however, does not get
in the way of the OM communications.
2) To see the old MAC for the AW.
If the CP which last booted from the old AW has not been adjusted for
the new one yet, then you can use 'cp_utl' to get the value of
<CPLBUG>_STA:STATION.APPSAP
The 14th byte of the printed value is the first byte of the Ethernet
address the CP was booted from.
That value is updated during the bootup process of the replacement
AW; CPs are updated by the AW based on the letterbug of the AW and the
CP stations it hosts.
3) NVRAM Reprogramming
Instructions are still available on the Net:
http://www.squirrel.com/sun-nvram-hostid.faq.html
or
http://lib.ru/TXT/faqsunnvram.txt
It's not for the faint of heart. Always have an extra NVRAM available
because any of a number of slipups can make the chip essentially a
small brick of plastic with no discernable function.
Also, after programming the chip it is necessary to add the Foxboro
settings to it. We find that this is most easily done by running the
'ia_install' part of a Day 0 installation on the box. There are more
details about AWPROM for this part, but I don't remember them just now.
4) So, what's his problem ?
If you get pings to other Nodebus stations to work, I'd be thinking
software as the prime suspect. Somebody mentioned the 'install
status' on the commit disk. It's a good place to start.
Can local variables be read? If it is an AW, can he omget the
variable <AWNAME>PICK1
What does he get with 'gloff' either to the local machine or the
CP ?
Is his machine name correct ? It is rewritten on bootup with the
letterbug in the DNBI, so if that is wrong, the change will be to
a station name the commit disk won't list.
And so on ...
Good luck,
William C Ricker
FeedForward, Inc.
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
