Etch and unstable Belkin wireless problem
 

Hi.

I installed Etch on a HP Pavilion ZE4900 in June 2008, and have since
'upgraded' to unstable. However, from the beginning there has been a
glitch configuring my wireless card. It's a Belkin F5D7010 (RaLink
RT2500).

If I boot, wait for the login prompt and then insert the card all
works as expected. However, if I boot with the card inserted the
transmission led turns on and that's it. Trying to bring the card
down then up produces the following error messages:

ifdown eth1:
eth1: unknown hardware address type 801
eth1: unknown hardware address type 801
Listening on LPF/eth1/
Sending on LPF/eth1/
Sending on Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.1 port 67
SIOCSIFFLAGS: Operation not supported
Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device eth1 ; Operation not supported.

ifup eth1:
eth1: unknown hardware address type 801
SIOCSIFFLAGS: Operation not supported
SIOCSIFFLAGS: Operation not supported
eth1: unknown hardware address type 801
Listening on LPF/eth1/
Sending on LPF/eth1/
Sending on Socket/fallback
receive_packet failed on eth1: Network is down
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
send_packet: Network is down
...<elided for brevity>...
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

And, in case it may be relevant, a snippet (booting with card
inserted) from syslog:
[ 14.470973] Yenta: CardBus bridge found at 0000:01:05.0 [103c:3084]
[ 14.476260] PCI: Bus 2, cardbus bridge: 0000:01:05.0
[ 14.483224] IO window: 0x00003400-0x000034ff
[ 14.489332] IO window: 0x00003800-0x000038ff
[ 14.495523] PREFETCH window: 0x40400000-0x407fffff
[ 14.501473] MEM window: 0x44000000-0x47ffffff
[ 14.507480] Yenta: Using CSCINT to route CSC interrupts to PCI
[ 14.513455] Yenta: Routing CardBus interrupts to PCI
[ 14.519535] Yenta TI: socket 0000:01:05.0, mfunc 0x01111112, devctl 0x64
[ 14.752889] Yenta: ISA IRQ mask 0x00d8, PCI irq 11
[ 14.759013] Socket status: 30000020
[ 14.766578] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
[ 14.772526] cs: IO port probe 0x3000-0x3fff: clean.
[ 14.778751] pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff
[ 15.420029] pccard: CardBus card inserted into slot 0
[ 15.523119] cs: IO port probe 0x100-0x3af: clean.
[ 15.530752] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
[ 15.538750] cs: IO port probe 0x820-0x8ff: clean.
[ 15.544998] cs: IO port probe 0xc00-0xcf7: clean.
[ 15.549761] cs: IO port probe 0xa00-0xaff: clean.
[ 15.905270] rt2500pci 0000:02:00.0: enabling device (0000 -> 0002)
[ 15.910626] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKE] -> GSI 11 (level, low) -> IRQ 11
[ 15.922632] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 15.939418] phy0: Selected rate control algorithm 'pid'
[ 16.075655] Registered led device: rt2500pci-phy0:radio
[ 16.117934] udev: renamed network interface wmaster0 to eth1

Removing and re-inserting the card makes no difference but removing
the card, manually unloading the modules (rt2500, rt2500pci and
friends), doing a modprobe rt2500 and only then re-inserting the card,
works.

I suspect a module loading problem but have been unable to identify
it. Does anybody have any idea where I should be looking? I've
Googled 'til I can't Google anymore...

Thanks, in hope

Joe


--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn"
don't you understand?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

On 2009-01-14 19:41 +0100, Joe Dennigan wrote:

> I installed Etch on a HP Pavilion ZE4900 in June 2008, and have since
> 'upgraded' to unstable. However, from the beginning there has been a
> glitch configuring my wireless card. It's a Belkin F5D7010 (RaLink
> RT2500).
>
> If I boot, wait for the login prompt and then insert the card all
> works as expected. However, if I boot with the card inserted the
> transmission led turns on and that's it. Trying to bring the card
> down then up produces the following error messages:
>
> ifdown eth1:
> eth1: unknown hardware address type 801
> eth1: unknown hardware address type 801
> [...]
> [ 16.117934] udev: renamed network interface wmaster0 to eth1

Why is wmaster0 renamed to eth1? And what about wlan0?

Please show your /etc/network/interfaces and
/etc/udev/rules.d/70-persistent-net.rules.

> Removing and re-inserting the card makes no difference but removing
> the card, manually unloading the modules (rt2500, rt2500pci and
> friends), doing a modprobe rt2500 and only then re-inserting the card,
> works.

It seems you have both the module in the kernel (rt2500pci) and the one
from rt2500-source (rt2500) loaded, this is probably bad. Can you
blacklist the rt2500 module and see if that helps?

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

Sven Joachim <svenjoac@gmx.de> writes:

> On 2009-01-14 19:41 +0100, Joe Dennigan wrote:
>
>> I installed Etch on a HP Pavilion ZE4900 in June 2008, and have since
>> 'upgraded' to unstable. However, from the beginning there has been a
>> glitch configuring my wireless card. It's a Belkin F5D7010 (RaLink
>> RT2500).
>>
>> If I boot, wait for the login prompt and then insert the card all
>> works as expected. However, if I boot with the card inserted the
>> transmission led turns on and that's it. Trying to bring the card
>> down then up produces the following error messages:
>>
>> ifdown eth1:
>> eth1: unknown hardware address type 801
>> eth1: unknown hardware address type 801
>> [...]
>> [ 16.117934] udev: renamed network interface wmaster0 to eth1
>
> Why is wmaster0 renamed to eth1? And what about wlan0?

Eth0 is the onboard Realtek ethernet. Don't Know why wmaster0 is
renamed. The configuration is the Debian default setup, except for
one modification to /etc/network/interfaces - see below - and I really
don't know about wlan0. If I boot from a Mepis live cd the Belkin
card does show up as wlan0.

> Please show your /etc/network/interfaces and
:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
allow-hotplug eth1

iface eth1 inet dhcp
wireless-essid TalkTalkcbejc
wireless-key <deleted for security reasons>

auto eth1

iface eth0 inet dhcp

# I don't use eth0 often enough to make this worthwhile
#auto eth0

> /etc/udev/rules.d/70-persistent-net.rules.

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:c0:9f:45:a6:0f", NAME="eth0"

# PCI device 0x1814:0x0201 (rt2500)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:50:65:9d:75", NAME="eth1"


> It seems you have both the module in the kernel (rt2500pci) and the one
> from rt2500-source (rt2500) loaded, this is probably bad. Can you
> blacklist the rt2500 module and see if that helps?

Blacklisting rt2500 had no effect when booting with the card
inserted. Lsmod showed it was still loaded, along with rt2500pci et
al, and the same problems persisted. Booting with the card unplugged
disabled the card completely. No network at all.

All most perplexing.

Joe


--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't
you understand?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

On 2009-01-14 21:31 +0100, Joe wrote:

> Sven Joachim <svenjoac@gmx.de> writes:
>
>> Why is wmaster0 renamed to eth1? And what about wlan0?
>
> Eth0 is the onboard Realtek ethernet. Don't Know why wmaster0 is
> renamed. The configuration is the Debian default setup, except for
> one modification to /etc/network/interfaces - see below - and I really
> don't know about wlan0. If I boot from a Mepis live cd the Belkin
> card does show up as wlan0.
>
>> Please show your /etc/network/interfaces and
> :
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> allow-hotplug eth1
>
> iface eth1 inet dhcp
> wireless-essid TalkTalkcbejc
> wireless-key <deleted for security reasons>

Which type of encryption (if any) do you use?

>> /etc/udev/rules.d/70-persistent-net.rules.
>
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, probably run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
> # MAC addresses must be written in lowercase.
>
> # PCI device 0x10ec:0x8139 (8139too)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:c0:9f:45:a6:0f", NAME="eth0"
>
> # PCI device 0x1814:0x0201 (rt2500)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:50:65:9d:75", NAME="eth1"

This is bad, but it seems to be a common problem when upgrading from
etch. You need to add

, ATTRS{type}=="1"

to these lines. Alternatively, rename it the file and reboot, then udev
will regenerate it (but your wireless card will probably named wlan0).

>> It seems you have both the module in the kernel (rt2500pci) and the one
>> from rt2500-source (rt2500) loaded, this is probably bad. Can you
>> blacklist the rt2500 module and see if that helps?
>
> Blacklisting rt2500 had no effect when booting with the card
> inserted. Lsmod showed it was still loaded, along with rt2500pci et
> al, and the same problems persisted.

That's probably because the rt2500 driver was loaded from initramfs.
You need to update that as well with update-initramfs(8). This is also
necessary if you change the /etc/udev/rules.d/70-persistent-net.rules,
since udev files are also copied to the initramfs.

> Booting with the card unplugged
> disabled the card completely. No network at all.

Does the card even show up then? You have to fix the udev rules first,
I think.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

Sven Joachim <svenjoac@gmx.de> writes:

>> Sven Joachim <svenjoac@gmx.de> writes:

>> # PCI device 0x10ec:0x8139 (8139too)
>> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:c0:9f:45:a6:0f", NAME="eth0"
>>
>> # PCI device 0x1814:0x0201 (rt2500)
>> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:50:65:9d:75", NAME="eth1"
>
> This is bad, but it seems to be a common problem when upgrading from
> etch. You need to add
>
> , ATTRS{type}=="1"
>
> to these lines. Alternatively, rename it the file and reboot, then udev
> will regenerate it (but your wireless card will probably named wlan0).

> That's probably because the rt2500 driver was loaded from initramfs.
> You need to update that as well with update-initramfs(8). This is also
> necessary if you change the /etc/udev/rules.d/70-persistent-net.rules,
> since udev files are also copied to the initramfs.

The modifications to 70-persistant-net.rules seem to have done the
trick! Once I saw that it worked I ran update-initramfs -u and
rebooted.

Syslog now shows 'udev: renamed network interface wlan0 to eth1' for
some reason but the wireless card works whether I boot with it
inserted or plug it in later. :-)

There are a couple of oddities still, but they don't seem to impact
performance or usability. The transmission LED works but the
'connected/power' one remains off and, strangely, module rt2500 still
seems to be required as if I boot with the card unplugged it is still
loaded.

Anyway, thanks for the help Sven. I know Running unstable is expected
to be glitchy but this was a real irritation that I just couldn't
solve.

All the best,

Joe


--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't
you understand?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

On Wed, 14 Jan 2009 22:32:43 +0100
Sven Joachim <svenjoac@gmx.de> wrote:

> On 2009-01-14 21:31 +0100, Joe wrote:
>
> > Sven Joachim <svenjoac@gmx.de> writes:

...

> >> /etc/udev/rules.d/70-persistent-net.rules.
> >
> > # This file was automatically generated by the /lib/udev/write_net_rules
> > # program, probably run by the persistent-net-generator.rules rules file.
> > #
> > # You can modify it, as long as you keep each rule on a single line.
> > # MAC addresses must be written in lowercase.
> >
> > # PCI device 0x10ec:0x8139 (8139too)
> > SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:c0:9f:45:a6:0f", NAME="eth0"
> >
> > # PCI device 0x1814:0x0201 (rt2500)
> > SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:50:65:9d:75", NAME="eth1"
>
> This is bad, but it seems to be a common problem when upgrading from
> etch. You need to add
>
> , ATTRS{type}=="1"
>
> to these lines. Alternatively, rename it the file and reboot, then udev
> will regenerate it (but your wireless card will probably named wlan0).

No need to reboot or to rename the file. Just comment out the line,
and then remove and reload the module. You'll see the line
automagically created.

> Sven

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Etch and unstable Belkin wireless problem
 

Just as a final note on this one:

Solving the wireless card (udev related) problem seems to have fixed
another glitch in the system.

About 20% of the time resuming from suspend resulted in 'no such
device' errors with an external USB drive, although it was still
listed in mtab and by df. Had to unmount, unplug, plug and remount
it. Now that is also working without problems.

Joe


--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't
you understand?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org