Fedora 16 MAC Address

[Mick Farmer]

Dear GLLUGers,

I'm running on a Dell Inspiron N5030. I obtain my IP address via DHCP
from my router. Here's the output either side of a reboot.

$ ifconfig
eth0 Link encap:Ethernet HWaddr 8E:30:4D:34:6F:DE
inet addr:192.168.7.30 Bcast:192.168.7.255
Mask:255.255.255.0
inet6 addr: fe80::8c30:4dff:fe34:6fde/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34 errors:0 dropped:0 overruns:0 frame:0
TX packets:72 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:4336 (4.2 KiB) TX bytes:11499 (11.2 KiB)
Interrupt:47

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:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:980 (980.0 b) TX bytes:980 (980.0 b)

$ reboot
...

$ ifconfig
eth0 Link encap:Ethernet HWaddr 9E:8F:2E:02:71:B7
inet addr:192.168.7.31 Bcast:192.168.7.255
Mask:255.255.255.0
inet6 addr: fe80::9c8f:2eff:fe02:71b7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:4186 (4.0 KiB) TX bytes:11122 (10.8 KiB)
Interrupt:47

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:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:564 (564.0 b) TX bytes:564 (564.0 b)

$

When booting I get the message

Loading initial ramdisk ...

Could this be causing the problem?

Regards,

Mick

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[t.clarke]

Looks like the DHCP server is assigning the next IP address available,
presumably because the 'old' address has not yet expired and been released
back to the pool !

Tim
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Stuart Sears]

Post by t.clarke
Looks like the DHCP server is assigning the next IP address available,
presumably because the 'old' address has not yet expired and been released
back to the pool !

I don't think that's the point here.

It'd be this...
$ ifconfig
eth0 Link encap:Ethernet HWaddr 8E:30:4D:34:6F:DE

which then changes to:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 9E:8F:2E:02:71:B7

after a reboot.

Mick, can we see the output of lspci and any network stuff in
/var/log/dmesg ?

Stuart

[Mick Farmer]

Dear Stuart, and others,

Here is the output from running lspci.

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 3 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller
(rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller
(rev 03)
09:00.0 Ethernet controller: Atheros Communications AR8152 v2.0 Fast
Ethernet (rev c1)
0c:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)

I couldn't find anything network-related in the output from dmesg.

Regards,

Mick

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Chris Bell]

Post by Mick Farmer
Dear Stuart, and others,
Here is the output from running lspci.

What happens if you

disconnect the ethernet cable, then reboot
log in as root and enter "ifconfig"
reconnect the cable and then enter "ifconfig"

?

[Mick Farmer]

Dear Chris and others,

After disconnecting Ethernet and rebooting.

$ ifconfig
eth0 Link encap:Ethernet HWaddr 2E:E7:60:8C:3A:F7
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:47

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:196 errors:0 dropped:0 overruns:0 frame:0
TX packets:196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15792 (15.4 KiB) TX bytes:15792 (15.4 KiB)

After reconnecting Ethernet and rebooting.

$ifconfig
eth0 Link encap:Ethernet HWaddr 12:85:C1:CD:88:70
inet addr:192.168.7.33 Bcast:192.168.7.255
Mask:255.255.255.0
inet6 addr: fe80::1085:c1ff:fecd:8870/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:4336 (4.2 KiB) TX bytes:8053 (7.8 KiB)
Interrupt:47

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:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5748 (5.6 KiB) TX bytes:5748 (5.6 KiB)

Many thanks for your help with this.

Regards,

Mick

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Chris Bell]

Post by Mick Farmer
Dear Chris and others,
After disconnecting Ethernet and rebooting.
$ ifconfig
eth0 Link encap:Ethernet HWaddr 2E:E7:60:8C:3A:F7
After reconnecting Ethernet and rebooting.
$ifconfig
eth0 Link encap:Ethernet HWaddr 12:85:C1:CD:88:70
inet addr:192.168.7.33 Bcast:192.168.7.255

What happens if you reboot with the cable disconnected and check again,
then without rebooting reconnect the cable and recheck. Does the code change
when just reconnecting the cable? Do any of the values match what you think
it should be?

[Mick Farmer]

Dear Chris and others,

When I boot using the wireless interface the MAC address is always
00:1B:B1:44:17:6D.

Should this also be the wired MAC address?

Regards,

Mick

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Alain Williams]

Post by Mick Farmer
Dear Chris and others,
When I boot using the wireless interface the MAC address is always
00:1B:B1:44:17:6D.
Should this also be the wired MAC address?

No -- they are different devices and so should have their own MAC addresses;
just as if your machine had 2 wired ethernet interfaces.

[Chris Bell]

Post by Mick Farmer
Dear Chris and others,
When I boot using the wireless interface the MAC address is always
00:1B:B1:44:17:6D.
Should this also be the wired MAC address?

I think they are usually totally different hardware, with a standard
plug-in card carrying the wireless system. I would always expect them to
have different MAC addresses. I noticed that the ethernet hardware showed a
MAC address before the ethernet cable was connected, but is that always
consistent? Does it change when the cable is connected?

[Jason Clifford]

Post by Chris Bell
I noticed that the ethernet hardware showed a
MAC address before the ethernet cable was connected, but is that always
consistent? Does it change when the cable is connected?

There is no reason it should. The MAC has nothing to do with the
connectivity status of the interface. It's just the physical layer
address. That it changes means there is either a firmware bug or a bug
in the driver.

I'd recommend checking the Dell support site to see if there are any
firmware updates for the laptop and apply the latest if there are.


--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Chris Bell]

Post by Jason Clifford

Post by Chris Bell
I noticed that the ethernet hardware showed a
MAC address before the ethernet cable was connected, but is that always
consistent? Does it change when the cable is connected?

There is no reason it should. The MAC has nothing to do with the
connectivity status of the interface. It's just the physical layer
address. That it changes means there is either a firmware bug or a bug
in the driver.
I'd recommend checking the Dell support site to see if there are any
firmware updates for the laptop and apply the latest if there are.

Agreed, I was just trying to ascertain when it was going wrong.

[James Courtier-Dutton]

Post by Stuart Sears

Post by t.clarke
Looks like the DHCP server is assigning the next IP address available,
presumably because the 'old' address has not yet expired and been released
back to the pool !

I don't think that's the point here.
It'd be this...
$ ifconfig
eth0      Link encap:Ethernet  HWaddr 8E:30:4D:34:6F:DE
$ ifconfig
eth0      Link encap:Ethernet  HWaddr 9E:8F:2E:02:71:B7
after a reboot.

Ok, that is just broken.
The ethernet driver in the Linux kernel is not able to talk to the EEPROM.
The EEPROM should hold the MAC address.
As a limp mode, it is using a random MAC address, but at least being
careful to make sure it is a unicast address and locally administered.
It would be a good idea to go into the BIOS and try to get it to netboot.
It should then display on the screen what the MAC address should be.
If this MAC address is different on each boot, the hardware is faulty.
If the BIOS MAC address is the same each time, there is a bug in the
linux kernel device driver.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[t.clarke]

A google search reveals that you can release the old IP address as part of
the shutdown procedure by running dhclient -r !!

You will therefore need to modify one of the rc0 sctipts (I think)

Tim
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Nix]

Post by Mick Farmer
Dear GLLUGers,
I'm running on a Dell Inspiron N5030.

That doesn't tell us what network card you've got. lsmod would be more
useful. A little googling suggests it may be an Atheros AR8151.

Post by Mick Farmer
eth0 Link encap:Ethernet HWaddr 8E:30:4D:34:6F:DE

One MAC address...

Post by Mick Farmer
eth0 Link encap:Ethernet HWaddr 9E:8F:2E:02:71:B7

... another MAC address. The MAC has changed, and changed drastically
(even the manufacturer OUI in the first three fields has changed).
This is going to be problematic.

Obviously, neither of these addresses appear in the OUI database.
Even more disturbingly, while the first address is a valid locally
administered address, the second is not (unless I messed up my
hex-to-binary conversion). Something is very wrong here.

The Atheros AR8151 appears to be driven by atl1c.ko.

If this driver cannot get a valid MAC address off the card's EEPROM, it
grabs a random one using random_ether_addr(), which always sets the
locally administered address bit. (Before v2.6.36 the driver did not do
this, but this is redundant because F16 definitely uses a later kernel
than that). It also sets a bit to indicate that this address was
randomly assigned. If this was so, you should find that
'cat /sys/class/net/{interface name}/addr_assign_type' prints '1'
(whereas for permanent hardware addresses it would print '0').

Another possibility is that the MAC on your device is being correctly
set, but something in the boot scripts is overwriting it before the
machine finishes booting (which Linux allows if you're running as root).
I don't know of a way to diagnose this case. (I also don't know of a way
to diagnose the case that the EEPROM is simply buggy, and I don't have
the hardware spec sheets so I can't tell if the driver is looking in the
right place in the EEPROM for the MAC address.)

[Daniel P. Berrange]

Post by Nix
Another possibility is that the MAC on your device is being correctly
set, but something in the boot scripts is overwriting it before the
machine finishes booting (which Linux allows if you're running as root).
I don't know of a way to diagnose this case.

He might have luck by enabling "Network boot" in the BIOS - if you very
lucky the PXE boot client in the BIOS will print the MAC addr of the NIC
it is using at boot time, or you can sniff the MAC addr from another host
using tcpdump Assuming a cold-boot this should avoid the effects of any
OS fubar-ness

Regards,
Daniel

[Chris Miles]

Post by Nix
If this driver cannot get a valid MAC address off the card's EEPROM, it
grabs a random one using random_ether_addr(), which always sets the
locally administered address bit.

This seems to be the core of the issue, all the addresses reported have
the top bit set, they are 'locally administered' and overwrite the
card's built in MAC.

ifconfig allow this locally-administered address to be configured, man
ifconfig gives:

"hw class address
"Set the hardware address of this interface, if the device driver
supports this operation. The keyword must be followed by the name of
the hardware class and the printable ASCII equivalent of the hardware
address. Hardware classes currently supported include ether (Ethernet),
ax25 (AMPR AX.25), ARCnet and netrom (AMPR NET/ROM)."

e.g.
ifconfig eth0 hw ether ascii-mac-address

So it looks as if something is auto-assigning a locally-administered MAC
address.
- a driver 'feature' that is 'on' when it should not be?


You can also use ethtool to examine and change the current state of an
interface
man ethtool

ethtool -i eth0
- shows details of driver, version, etc, e.g.

$ sudo ethtool -i eth0
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:03:00.0

HTH,
Chris

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Nix]

Post by Chris Miles
This seems to be the core of the issue, all the addresses reported have
the top bit set, they are 'locally administered' and overwrite the
card's built in MAC.

Uh, the locally administered bit is not the top bit. The locally
administered bit is the next-from-bottom bit of the top octet. See, e.g.
include/linux/etherdevice.h:random_ether_addr() in a recent Linux kernel
tree.

And (unless I've typoed) not all these addresses have that bit set.

Post by Chris Miles
ifconfig allow this locally-administered address to be configured, man

ifconfig is by now very obsolete and frequently misleading (though not
in this case). You want 'ip link set address'.

Post by Chris Miles
e.g.
ifconfig eth0 hw ether ascii-mac-address

ip link set address ascii-mac-address dev (device)

[James Courtier-Dutton]

Post by Nix

Post by Chris Miles
This seems to be the core of the issue, all the addresses reported have
the top bit set, they are 'locally administered' and overwrite the
card's built in MAC.

Uh, the locally administered bit is not the top bit. The locally
administered bit is the next-from-bottom bit of the top octet. See, e.g.
include/linux/etherdevice.h:random_ether_addr() in a recent Linux kernel
tree.
And (unless I've typoed) not all these addresses have that bit set.

Post by Chris Miles
ifconfig allow this locally-administered address to be configured, man

ifconfig is by now very obsolete and frequently misleading (though not
in this case). You want 'ip link set address'.

Post by Chris Miles
e.g.
ifconfig eth0 hw ether ascii-mac-address

ip link set address ascii-mac-address dev (device)

Note: Only change the MAC address of an interface when the interface is down.
Otherwise the network will think there are duplicate IP addresses.
I don't actually know if the "ip link set address ascii-mac-address
dev (device)" does an arp poison or not. I probably should.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[John Hearns]

Post by James Courtier-Dutton
Note: Only change the MAC address of an interface when the interface is down.
Otherwise the network will think there are duplicate IP addresses.
I don't actually know if the "ip link set address ascii-mac-address
dev (device)" does an arp poison or not. I probably should.

Oh do come on. Live dangerously. Its more fun that way.

ps. I'm only half joking. I once had to install a very expensive piece
of video special effects kit which could only be networked by setting
a permanent arp entry on the SGI workstation which wanted to talk to
it (ie you had to know the MAC address adn do an arp -s )
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Nix]

Post by James Courtier-Dutton
Note: Only change the MAC address of an interface when the interface is down.

I'd be very surprised if you were allowed to change it at other times.
(This does depend on the device though.)

[James Courtier-Dutton]

Mick,

Did you try to look and see if there is a MAC address reported in the
BIOS setup anywhere?
It might get shown if you try to PXE netboot.

This will then tell us if it is a hardware problem or a Linux kernel bug.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Mick Farmer]

Dear James,

No sign of a MAC address in the BIOS.

Regards,

Mick


--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[James Courtier-Dutton]

Post by Mick Farmer
Dear James,
No sign of a MAC address in the BIOS.

Ok, Well here is a fix to your problem, if you use ubuntu:
See attached file. Compare it with your existing one in
/etc/init/network-interface.conf

It basically sets your MAC address to a fixed value during boot.
My advice is to choose one of the random MAC addresses you already
see, and fix it to that.
The MAC address only has to be unique on the network subnet.
I.e. If you are at home, it is only a problem if someone else at your
home has the same MAC address.
If I have the same MAC address at my home, it is not a problem.

Kind Regards

James