Pandaboard chooses a new IP address on each boot

Bug #673504 reported by BernardB
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux-ti-omap4 (Ubuntu)
Fix Released
High
Tim Gardner
Maverick
Fix Released
High
Tim Gardner
Natty
Fix Released
High
Tim Gardner

Bug Description

The smsc95xx driver used on the Pandaboard currently generates a new random MAC address every time the interface is brought up. This makes it impossible to override using the standard `ifconfig hw ether` approach or through /etc/network/interface.

As a result, the board gets a new IP address on each boot from DHCP, and confuses dynamic DNS setups linked to DHCP.

There is an upstreamed patch (merged in 2.6.37-rc1) at http://marc.info/?l=linux-omap&m=128744421925804&w=2 which enables the user to set their MAC address using the standard tools. Please consider pulling this into the stable kernel.

tags: added: armel
Changed in linux-ti-omap4 (Ubuntu):
status: New → Confirmed
assignee: nobody → Ricardo Salveti (rsalveti)
Revision history for this message
Sebastien JAN (sebjan) wrote :

Thanks for pointing this out.

One work-around for this issue was added to the omap4 kernel (see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=10f38b455e75b85f72e98786e5518cf7b0324634).

So you can force a MAC address at boot-time by adding the smsc95xx.macaddr=xx:xx:xx:xx:xx:xx parameter to the kernel command line.

However, it does not prevent from using your patch that offers a smarter (and as you say more accepted) solution.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

There's a patch already that makes it possible to stick with only one mac address: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=10f38b455e75b85f72e98786e5518cf7b0324634;hp=f62e143182cc123fdfdf9bb88952a938af7d86e8

If you set smsc95xx.macaddr at the kernel cmdline, it should work already with the current kernel.

The problem I see here, that your patch helps solving, is that the mac address is regenerated on every ifdown/ifup when you don't explicit set it up at the kernel cmdline. This also makes it consistent with other drivers, and let people set the proper mac address with current known methods.

As it's also upstream, I don't see a reason not to take it. Will generate a new kernel deb file with the patch included, so we can test it before sending the SRU.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

Kernel compiled with the pointed patch:
http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35-903-omap4_2.6.35-903.18rsalveti1_armel.deb

Please test and let us know if it did work for you. Will then forward to the kernel team with a SRU.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

Tested here and did work as expected. After giving ifconfig usb0 down/up the mac address didn't change and was also able to change the mac address with "ifconfig usb0 hw ether <mac>".

Revision history for this message
BernardB (b-launchpad) wrote :

Ack. Tested and works here too. Also verified that it doesn't interfere with the smsc95xx.macaddr= kernel cmdline parameter.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :
Tim Gardner (timg-tpi)
Changed in linux-ti-omap4 (Ubuntu):
assignee: Ricardo Salveti (rsalveti) → Tim Gardner (timg-tpi)
importance: Undecided → High
milestone: none → maverick-updates
status: Confirmed → Fix Committed
Revision history for this message
Tim Gardner (timg-tpi) wrote :

SRU Justification:

Impact: The smsc95xx driver generates a new random MAC address on every
ifdown/up instead of only one during driver's init, and doesn't let the user to
set up the mac address using known methods like ifconfig usb0 hw ether <mac>.

Fix: Just move the init_mac_address function to bind instead of reset.

Testcase: The interface should keep the same generated mac address even when
giving ifdown/up, and the user should be able to set up the mac address using
'ifconfig usb0 hw ether <mac>.

Patch is already upstream as f4e8ab7, and is tested already with a compiled
kernel deb with the fix included.

Revision history for this message
Colin Watson (cjwatson) wrote : Please test proposed package

Accepted linux-ti-omap4 into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in linux-ti-omap4 (Ubuntu Maverick):
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Tim Gardner (timg-tpi)
milestone: none → maverick-updates
Changed in linux-ti-omap4 (Ubuntu):
milestone: maverick-updates → none
status: Fix Committed → Triaged
tags: added: verification-needed
Revision history for this message
Tobin Davis (gruemaster) wrote :

Wrote this test script to take the specified network port up and down in a loop. Ran it repeatedly on the proposed kernel without issue (script takes specified interface up & down 10 times). dmesg output shows network interface stop/start for each iteration within the script and no errors. Calling this a success.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted linux into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: removed: verification-done
tags: added: verification-needed
Brad Figg (brad-figg)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Tim Gardner (timg-tpi) wrote :

Martin - I'm confused. linux-ti-omap4 2.6.35-902.19 has already been verified to fix this bug (see comment #9).

Revision history for this message
Brad Figg (brad-figg) wrote :

This has been tested several times and is working just fine.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux-ti-omap4 - 2.6.35-903.19

---------------
linux-ti-omap4 (2.6.35-903.19) maverick-proposed; urgency=low

  [ Upstream Kernel Changes ]

  * smsc95xx: generate random MAC address once, not every ifup
    - LP: #673504, #673509
 -- Tim Gardner <email address hidden> Tue, 16 Nov 2010 18:28:52 -0700

Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Revision history for this message
Tobin Davis (gruemaster) wrote :

While this fixes Maverick, Natty currently uses the previous kernel, 2.6.35-903.17. Could this be published for Natty as well?

Revision history for this message
Tim Gardner (timg-tpi) wrote :

We're working on it. There is a compile problem with the Natty toolchain.

Tim Gardner (timg-tpi)
Changed in linux-ti-omap4 (Ubuntu Natty):
status: Triaged → Fix Committed
tags: added: omap4 panda
Revision history for this message
Floyd42 (axelheider) wrote :

Seems someone came up with another way to solving this.
See: http://patchwork.openembedded.org/patch/3441/

Actually, using a platform ID is a smart way to get a fixed MAC. In my opinion much better than using a random MAC as fall back.

Revision history for this message
Tobin Davis (gruemaster) wrote :

Tim's fix is in the current kernel (2.6.35-1101.4). Marking as fix released, although I hope Floyd42's fix gets in mainstream.

Changed in linux-ti-omap4 (Ubuntu Natty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.