On Wed, Oct 13, 2010 at 2:19 PM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
I just tried a full powerdown with NTP deactivated. The system came up, the time is fine.
Not that the time on the motherboard should necessarily affect the MAC on an expansion card, but that was a good test nonetheless.
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest of the card may be perfect. Using it long-term might require no more than a manual edit of the init script for it adding something to this effect 'if MAC == zeros; then set MAC to 00:0a:cd:1a:c1:71 fi'. This will fix this card without clobbering it's successor down the road.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Brian,
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:19 PM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
I just tried a full powerdown with NTP deactivated. The system came up, the time is fine.
Not that the time on the motherboard should necessarily affect the MAC on an expansion card, but that was a good test nonetheless.
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest of the card may be perfect. Using it long-term might require no more than a manual edit of the init script for it adding something to this effect 'if MAC == zeros; then set MAC to 00:0a:cd:1a:c1:71 fi'. This will fix this card without clobbering it's successor down the road.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Brian,
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
Well, you can set new mac address also manually on ifcfg-ethX script .. or ifconfig ..
-- Eero
On Wed, Oct 13, 2010 at 2:55 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:19 PM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
I just tried a full powerdown with NTP deactivated. The system came up, the time is fine.
Not that the time on the motherboard should necessarily affect the MAC on an expansion card, but that was a good test nonetheless.
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest of the card may be perfect. Using it long-term might require no more than a manual edit of the init script for it adding something to this effect 'if MAC == zeros; then set MAC to 00:0a:cd:1a:c1:71 fi'. This will fix this card without clobbering it's successor down the road.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Brian,
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
Well, you can set new mac address also manually on ifcfg-ethX script .. or ifconfig ..
-- Eero _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
OK... how do I set it? Or, more importantly, how do I find out what MAC the card currently thinks it has?
Boris.
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:55 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:19 PM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
I just tried a full powerdown with NTP deactivated. The system came up, the time is fine.
Not that the time on the motherboard should necessarily affect the MAC on an expansion card, but that was a good test nonetheless.
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest of the card may be perfect. Using it long-term might require no more than a manual edit of the init script for it adding something to this effect 'if MAC == zeros; then set MAC to 00:0a:cd:1a:c1:71 fi'. This will fix this card without clobbering it's successor down the road.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Brian,
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
Well, you can set new mac address also manually on ifcfg-ethX script .. or ifconfig ..
-- Eero _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
OK... how do I set it? Or, more importantly, how do I find out what MAC the card currently thinks it has?
Well, ifconfig?
It really doesn't matter, just generate random one..
edit /etc/sysconfig/network-scripts/ifcfg-ethX
Remove HWADDR=00:00:00:00:00:00 add MACADDR=WH:AT:YO:UW:AN:T0
It should work this way and then just service network restart ..
-- Eero
-- Eero
Eero Volotinen wrote:
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:55 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
2010/10/13 Boris Epstein borepstein@gmail.com:
On Wed, Oct 13, 2010 at 2:19 PM, Brunner, Brian T. BBrunner@gai-tronics.com wrote:
<snip>
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest
<snip>
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
I'd start worrying about the m/b slot. Have you tried a different one, if one's available?
Well, you can set new mac address also manually on ifcfg-ethX script .. or ifconfig ..
OK... how do I set it? Or, more importantly, how do I find out what MAC the card currently thinks it has?
Well, ifconfig?
It really doesn't matter, just generate random one..
edit /etc/sysconfig/network-scripts/ifcfg-ethX
Remove HWADDR=00:00:00:00:00:00 add MACADDR=WH:AT:YO:UW:AN:T0
It should work this way and then just service network restart ..
I think I'd leave the first three octets alone - that's just the manufacturer's code. Oh, and I doubt any non-hex chars would work....
mark
On 10/13/2010 1:55 PM, Eero Volotinen wrote:
I just tried a full powerdown with NTP deactivated. The system came up, the time is fine.
Not that the time on the motherboard should necessarily affect the MAC on an expansion card, but that was a good test nonetheless.
I'm suspicious (as others have suggested) the card itself is bad. I think to suspect the flash chip that stores the MAC addr. The rest of the card may be perfect. Using it long-term might require no more than a manual edit of the init script for it adding something to this effect 'if MAC == zeros; then set MAC to 00:0a:cd:1a:c1:71 fi'. This will fix this card without clobbering it's successor down the road.
While those suspicions were well justified I am not sure your guess is correct in this particular case as I just swapped the NIC I had for a different one and I seem to be getting the same sort of errors again. What's the likelihood that two NICs in a row have a faulty flash?
Well, you can set new mac address also manually on ifcfg-ethX script .. or ifconfig ..
But the ifcfg-ethX scripts don't run if the HWADDR entry doesn't match the NIC MAC. How do you get the right name connected to the right nic so you can even run ifconfig sensibly?
On 10/13/2010 1:11 PM, Les Mikesell wrote:
But the ifcfg-ethX scripts don't run if the HWADDR entry doesn't match the NIC MAC. How do you get the right name connected to the right nic so you can even run ifconfig sensibly?
You don't *have* to use HWADDR in the ifcfg-* file. Just comment it out on the NIC that is having problems.
On 10/13/2010 3:16 PM, Jerry Franz wrote:
On 10/13/2010 1:11 PM, Les Mikesell wrote:
But the ifcfg-ethX scripts don't run if the HWADDR entry doesn't match the NIC MAC. How do you get the right name connected to the right nic so you can even run ifconfig sensibly?
You don't *have* to use HWADDR in the ifcfg-* file. Just comment it out on the NIC that is having problems.
Whenever I've done that on machines with multiple NICs, they've all been renamed with a .bak extension and ignored, including the one I needed to be able to reach the machine at all. Could be that there were other changes at the same time contributing to this and maybe it will work if only one doesn't match.