Results 1 to 10 of 14
Need your help / ideas here...
I've noticed recently, that after I reboot my SuSe 10.2 machine, running kernel 2.6.18.8-0.7-default, the Mac Address changes, causing my router not to give ...
- 10-21-2007 #1Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
Mac Address changes after each reboot?
Need your help / ideas here...
I've noticed recently, that after I reboot my SuSe 10.2 machine, running kernel 2.6.18.8-0.7-default, the Mac Address changes, causing my router not to give the machine the reserved IP address, but instead give it the 'next-in-line' number, which in turn causes PuTTY not to find the machine.
Needless to say, this is quite annoying.
As I understand it (or at least, thought I did) the Mac Address is something that's fixed and generated out of the Eprom, so I'm at a loss as to why it changes?
I've read articles where one can deliberately spoof the Mac Address, but I want the opposite: just give me one and the same address so that the router, PuTTY (and I) don't get confused.
I've also noticed, though this may be unrelated, in boot.msg a message:
<6>eth0 renamed to eth9
This too confuses me... Why would is this happening? Obviously:
PKR-5:/etc # ifconfig eth0
eth0: error fetching interface information: Device not found
whereas
PKR-5:/etc # ifconfig eth9
returns the current information.
So basically I ask for your help with two issues:
1) why the MAC Address change and how to prevent it?
2) why the eth0 -> eth9 rename and how to fix it?
If you need add'l information or details, just let me know what and preferably the command to obtain it. Thanks a bunch!
- 10-22-2007 #2Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
I don't think it will shed any light on the issue, but here's the contents of:
# cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='dhcp'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME='HP 10/100VG PCLAN (ISA, EISA, PCI)'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
_nm_name='static-0'
- 10-23-2007 #3Just Joined!
- Join Date
- Oct 2007
- Posts
- 10
In some circumstances, the MAC address can be changed, for internal use.
only the last 3 octets can be changed, and only for locally administered PCs.
MAC address - Wikipedia, the free encyclopedia
- 10-23-2007 #4Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
WylieCoyoteUK: thanks for your input, but it seems you misinterpreted the original post.
I'm pretty sure I've seen an article describing what you mentioned, but that is not what I'm looking for, on the contrary.
Each time I (re)boot the machine, something generates (??) a different Mac Address and that is not what I want. I just want the address to remain the same across reboots. Now it's different each time and that's real annoying, mostly to my router, PuTTY, and the hosts file on my other computers.
More ideas and responses are most welcome!
- 10-24-2007 #5Just Joined!
- Join Date
- Oct 2007
- Posts
- 10
Sorry, just trying to help.
Is it more than the last 3 numbers that are changing?
Have you IPv6 enabled? -this apparently can cause odd problems, and an IPv6 address looks like a mac address.
It also sounds like the PC is redetecting the NIC every boot.
You could cut'npaste the output from ifconfig here.
Have a look at dmesg too.
- 10-24-2007 #6Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
Your help is much appreciated WylieCoyoteUK, don't get me wrong!
Output from a couple reboots:
PKR-5:~ # ifconfig
eth9 Link encap:Ethernet HWaddr 00:00:6C:8E:3A:25
inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
reboot...
PKR-5:~ # ifconfig
eth10 Link encap:Ethernet HWaddr 00:00:6C:B9:E5:87
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
reboot...
PKR-5:~ # ifconfig
eth11 Link encap:Ethernet HWaddr 00:00:6C:F5:CA:FA
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
reboot... (and as requested, the complete ifconfig output):
PKR-5:~ # ifconfig
eth12 Link encap:Ethernet HWaddr 00:00:6C:2B
0:F3
inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::200:6cff:fe2b:d0f3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:96 errors:0 dropped:0 overruns:0 frame:0
TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23480 (22.9 Kb) TX bytes:19110 (18.6 Kb)
Interrupt:10 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3740 (3.6 Kb) TX bytes:3740 (3.6 Kb)
Notice the eth9 -> eth10 -> eth11 -> eth12
So yes, it's only the last three numbers that are changing.
I believe that IPv6 is enabled ("ping6" works and that is indicative, correct?). If that is the culprit, how can I disable (or remove) it?
The command "dmesg" produces a lot of output, most of which means little or nothing to dummy here.
I'll past the last 20 or so lines:
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 288 bytes per conntrack
powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ processors (version 2.00.00)
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
audit(1193252743.505:3): audit_backlog_limit=256 old=64 by auid=4294967295
audit(1193252743.997:4): audit_pid=3021 old=0 by auid=4294967295
NET: Registered protocol family 17
NVRM: failed to register with the ACPI subsystem!
bootsplash: status on console 0 changed to on
SFW2-INext-ACC-TCP IN=eth12 OUT= MAC=00:00:6c:2b:d0:f3:00:07:e9:cf:6a:2f:08:00 SRC=192.168.1.2 DST=192.168.1.9 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=49883 DF PROTO=TCP SPT=2781 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)
eth12: no IPv6 routers present
Your continued help is most welcome...
- 10-25-2007 #7Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
I found an article describing how to disable IPv6 which I subsequently did.
Unfortunately after a reboot once again the box had a different HWaddr.
Even though the majority is gibberish (to me), I took another close look at the output from "dmesg", and found this section:
(...)
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
PCI: Setting latency timer of device 0000:00:07.0 to 64
forcedeth: using HIGHDMA
0000:00:07.0: Invalid Mac address detected: 13:ec:53:b9:1b:00
Please complain to your hardware vendor. Switching to a random MAC.
ieee1394: Initialized config rom entry `ip1394'
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
nvidia: module license 'NVIDIA' taints kernel.
eth0: forcedeth.c: subsystem: 0103c:2a61 bound to 0000:00:07.0
(...)
I'll try Google; hopefully I can find something that clarifies what's happening.
- 10-26-2007 #8Just Joined!
- Join Date
- Oct 2007
- Posts
- 10
If it is the last 3 octetes, it is "administrative management" MAC addresses.
The dmesg report means:
1) The NIC is defective- 13:ec:53 is a very suspect address (In fact, a search reveals no vendor with that code )
2) For some reason, the system is unable to correctly read the MAC address.This could be for a variety of reasons, IRQ conflict, similar ports like USB or firewire can cause a problem.
I would try removing any USB or Firewire devices, and see if that resolves the probblem.
- 10-26-2007 #9Just Joined!
- Join Date
- Oct 2007
- Posts
- 10
Also see if you can install an Nvidia Nforce driver, as the built-in one may not be working 100%.
In fact, I remember that rtl8139too worked for me with a similar chipset.
- 10-26-2007 #10Just Joined!
- Join Date
- Jul 2007
- Location
- Santa Clara, CA
- Posts
- 11
Once again, thnx for your input!!
As for the address being suspect, I've come across several articles on the web which discuss a bug in forcedeth.c, where the address is being read backwards... So it should be read as 00:1b:b9:53:ec:13. This bug is reportedly fixed in version 0.59 (or 0.60, articles differ on that), and the version I have is 0.56. Unfortunately no newer release seems to be available for my AMD64bit environment
There are no USB or Firewire devices connected to the box.
The driver currently in use is the latest and greatest which I downloaded from the NVIDIA site. Still, I'll look into your suggested driver.
If my assumption of a bug in forcedeth.c is correct, I may have no choice but 'live with it' until a fix becomes available, unless you have another suggestion.
I continue searching for an intermediate solution though... Again, thanks!


Reply With Quote