NetworkManager does not detect eth0 on armel

You simply don't have an entry for this in /etc/network/interfaces
we don't create them by default

/etc/network/interfaces is exactly the same as on my laptop:
auto lo
iface lo inet loopback

Yet as an example, ifup eth0 works on my laptop, as does connman. Why would this be required on one and not another?

On Mon, 2009-04-06 at 20:29 +0000, Paul Larson wrote:

> /etc/network/interfaces is exactly the same as on my laptop:
> auto lo
> iface lo inet loopback
>
> Yet as an example, ifup eth0 works on my laptop, as does connman. Why
> would this be required on one and not another?
>
The ifstate entry is created by NetworkManager when that brings the
interface up.

Scott
--
Scott James Remnant
<email address hidden>

Scott James Remnant wrote:
> On Mon, 2009-04-06 at 20:29 +0000, Paul Larson wrote:
>
>> /etc/network/interfaces is exactly the same as on my laptop:
>> auto lo
>> iface lo inet loopback
>>
>> Yet as an example, ifup eth0 works on my laptop, as does connman. Why
>> would this be required on one and not another?
>>
> The ifstate entry is created by NetworkManager when that brings the
> interface up.
>
> Scott
So are you saying this should be a bug against NetworkManager instead of
udev? NetworkManager does not see the interface either.

cat /proc/net/dev shows eth0 is existing

sudo ifconfig eth0 up && sudo dhclient eth0
get the interface up properly and assign a dhcp IP ...

if its just networkmanager/connman not recognizing this as a wired net device, please post your lshal output.

above is the lshal output, i'd like to notice that NM works fine with any wired USB NIC i attach.
it used to work before with the onboard card (sadly i cant say since when it changed, there were issues with the payload stability of the onboard driver so i used USB NICs since a while)

The problem is:

info.parent = '/org/freedesktop/Hal/devices/computer' (string)

which is a bit of a problem. Isnt this a pci device and should have a different parent?

ARM boards dont expose a PCI bus (if they even have one) (lscpci on arm is usually a no-op) so the parent is right here ...
and as i said, it used to work before ...

the testing here additionally exposed bug 356975

rebuilding NM with the lp199140_dont_manage_virtual_devices.patch unapplied makes it work

putting on release team radar.

This is a regression from lp199140_dont_manage_virtual_devices.patch which blacklists all virtual devices; unfortunately armel doesn't expose any bus, so their network devices are virtual too.

Hackish workaround would be to disable the blacklisting from above patch on armel arch.

When using 2.6.26 kernel provided by Freescale, NM detects the network device just fine. While they do compile the network driver into the kernel. Maybe that info can help some.

did you use the same NM version with the mentioned patch included to verify that.
can you please attach more data if you make such assumptions...
if the device is not attached to the computer device in hal, where and how is it attached in the monolithic 2.6.26 kernel ?

Checked into this a little more. Guys from Freescale tried it out with our latest build. It's broken for that case now too.

It seems that what I said is no longer true with the newest builds. It was this way till around early March with the monolithic Freescale kernel. Now this is nolonger the case, and network manager isn't picking it up anymore.

Now it also demostrates the same behavior

This bug was fixed in the package network-manager - 0.7.1~rc4.1.cf199a964-0ubuntu2

---------------
network-manager (0.7.1~rc4.1.cf199a964-0ubuntu2) jaunty; urgency=low

  * fix LP: #356517 - NetworkManager does not detect eth0 on armel; on armel
    network devices have no visible bus and hence appear similar to virtual
    devices that got blacklisted by the fix for LP: #199140; for jaunty
    we workaround the issue by explicitly disabling the virtual device
    blacklisting on __ARMEL__
    - add patches/lp356517_manage_virtual_devices_on_armel.patch
    - update patches/series

 -- Alexander Sack <email address hidden> Tue, 14 Apr 2009 13:53:20 +0200

Confirmed fix

This fix also sorts out bug #356517 which I guess is a similar problem when using the ndiswrapper for wireless drives it must see it as virtual device and not use it at least with my particular drivers anyway.