changed a motherboard and need to permanently change MAC Address.
Have added LLADDR=‘xx:xx:xx:xx:xx:xx’ to ifcfg-eth0 file, and server boots fine with new MAC address.
Can only ping same range 192.168.90.5 / 6 not 192.168.1.103, until I stop and restart the network service.
Need to automate this is there a way or even a script to do this after the server boots to login?
Not entirely clear about what you’ve done here. More definitive information concerning your configuration and IP addressing might be helpful to avoid speculation. Which version of openSUSE are you using?
Am Fri, 23 Dec 2016 21:36:01 GMT
schrieb ngac001 <ngac001@no-mx.forums.microfocus.com>:
> changed a motherboard and need to permanently change MAC Address.
> Have added LLADDR=‘xx:xx:xx:xx:xx:xx’ to ifcfg-eth0 file, and server
> boots fine with new MAC address.
> Can only ping same range 192.168.90.5 / 6 not 192.168.1.103, until I
> stop and restart the network service.
> Need to automate this is there a way or even a script to do this after
> the server boots to login?
>
>
Well, it would make sense to change the MAC as early as possible when system
boots up in order to avoid any problems for services to be started later.
So I would try a udev rule to set the MAC address when device gets
initialized, something like:
SUBSYSTEM==“net”, ACTION==“add|change”, <Add hardware specific attributes
here>, RUN+=“command to set MAC address”
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
First,
The timing concerns expressed by @Akoellh are non-existent.
Any applications or services that are network-dependent won’t be made accessible until after networking has started no matter when that might be, so there is no timing problem.
As for the above OP,
Your question is unclear. Are you saying that your machine is using a previous cached IP address?
And, you need to be more careful about your nomenclature… the slash after an IP address normally specifies the bits to be used for the network mask… Although I’m pretty sure you mean 192.168.90.5 and 192.168.90.6.
So, all things considered…
Considering how very little clear information exists, I’m still going to guess that your machine is somehow using stale cached IP address values, which would be surprising but if it really is happening should be very short-lived and not survive beyond a reboot.
So, no script should be needed, only a cold shutdown and reboot (Power off, count to 20 before powering back up).
IMO,
TSU
When you took the trouble to choose OTHER VERSION on creating this thread, you could at least also have taken the trouble to inform us what that other version is.
That choice was put there on purpose because many people forgot to provide that first and foremost piece of information to their potential helpers.
Hi Sorry for the omission
openSUSE 11.2 “Emerald” - Kernel 2.6.31.5-0.1 desktop (tty1)
Oops! How long is that ago?
I think this information is crucial to your potential helpers. Not many people will still have such a system at hand to try to re-create your situation.
You better try to answer the other questions above as good as possible. But that may be difficult. E.g. was udev already used in 11.2?
Am Fri, 30 Dec 2016 08:46:01 GMT
schrieb hcvv <hcvv@no-mx.forums.microfocus.com>:
>was udev already used in 11.2?
It certainly has been used in 11.2 (first version was 9.3 IIRC).
But personally, even although “use a udev rule for that” was my idea (and
that will work, I have been doing similar stuff on one of my own systems
for years), I am not in favor of trying to ride a dead horse to town, so count
me out for further comments here.
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
When you’re having your trouble, (not when your networking is working fine), you need to inspect your routing table (and maybe post the results
route print
You’ll also need to display your network configuration
ifconfig
and, whether you are running “Classic ifup/ifdown” or Network Manager.
Also, going back that far IIRC “mac=” was used,not “lladdr-” was used.
You do know that your kernel is one of the first kernels after the switch from monolithic to modular, right? All ancient kernels are to be discouraged, but the first one after a complete re-architecting even more so.
You’d be highly encouraged to backup your system (or buy a new hard drive) and install a current OS instead of making your current OS work because even after any success you’ll still be left with a system riddled with vulnerabilities running apps that are no longer supported. Unless you’re running some very original app you wrote yourself, it’s just a matter of time before you’ll experience a catastrophic and unrecoverable problem.
TSU
That’s good for a windows machine. For Linux use
/sbin/route
You do know that your kernel is one of the first kernels after the switch from monolithic to modular, right? All ancient kernels are to be discouraged, but the first one after a complete re-architecting even more so.
You’d be highly encouraged to backup your system (or buy a new hard drive) and install a current OS instead of making your current OS work because even after any success you’ll still be left with a system riddled with vulnerabilities running apps that are no longer supported. Unless you’re running some very original app you wrote yourself, it’s just a matter of time before you’ll experience a catastrophic and unrecoverable problem.
TSU
I agree with this in general, but also for reasons of security that a newer kernel/OS would bring.
Just a note after re-reading the OP,
When the motherboard was replaced, if the NIC is onboard it would already have a now, unique MAC address burned into its silicon (that’s a standard requirement, every NIC produced must be burned with a unique number).
Only if the NIC is a plugin card and re-installed from the old machine into the new machine would the silicon hold the same address.
So,
It’s possible the simplest solution and answer in this Forum Thread is to… Do nothing except remove all MAC address references from the interface file.
Yes, that is the normal setup, not to define a MAC address. Configuring a MAC address should only be done for a special reason.
TSU