Florian Kulzer wrote:
Udev is responsible for managing the device nodes in /dev and the names
of the network devices. More information is here:
/usr/share/doc/udev/writing_udev_rules/index.html
Thank you. I'll have a look.
The two bugzilla links above suggest that this chip will show up as two
network interfaces when using the new driver, one is the interface that
you will use normally and the other one is some sort of "master" (maybe
related to this sbb bus?).
So in my system is only the MASTER, the SSB part being recognized and
activated?
Udev tries to ensure correct and persistent naming of network devices:
Whenever a network device with an unknown hardware address (and a
working associated driver) is detected during boot, udev will add a rule
for this new HW address to the
/etc/udev/rules.d/z25_persistent-net.rules file. Udev makes an "educated
guess" about the best name for the new device, and this name will stick
with the device from then on.
The problem with the broadcom chip appears to be that the firmware is
not present at the first boot of a Debian system, so only the master
device is detected and added to z25_persistent-net.rules. This seems
somehow to block correct name assignment for the "real" (usable) device
(later, when the firmware has been installed).
How can I see, whether the FIRMWARE has been loaded or not?
"ndiswrapper" uses a different firmware
<http://h10025.www1.hp.com/ewfrf/wc/genericSoftwareDownloadIndex?softwareitem=ob-46095-1&cc=us&lc=en&dlc=en&dlc=en&lang=en>,
than the "b43-fwcutter" or "bcm43xx-fwcutter" thingy, which install a
different versions by default. The versions, used by "ndiswrapper" are
having wrong checksums.
The bugzilla links suggest that you can simply delete or rename the
persistent-net.rules file and reboot. With the firmware present udev
obviously creates the rules for the two interfaces at once and
correctly.
If this does not work then we need to see the content of the rules file
(after its re-creation with the firmware present during boot)
# cat z25_persistent-net.rules:
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x10de:0x0269 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:24:aa:41:9d",
NAME="eth0"
-------------------------------------------------
That is all.
and the
full output of "/sbin/ifconfig"
# /sbin/ifconfig:
eth0 Link encap:Ethernet HWaddr 00:1b:24:aa:41:9d
inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:24ff:feaa:419d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:297462 errors:0 dropped:0 overruns:0 frame:0
TX packets:238028 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:330173317 (314.8 MiB) TX bytes:27482563 (26.2 MiB)
Interrupt:19 Base address:0x6000
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:4380 errors:0 dropped:0 overruns:0 frame:0
TX packets:4380 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1023435 (999.4 KiB) TX bytes:1023435 (999.4 KiB)
------------------------------------------------------
just the cable, no Wireless LAN interface up.
and "dmesg|grep b43".
-----------------------------------------------------
nothing, no output. Even searching through /var/log for a string "b43"
delivers only results connected with "aptitude".
Hugo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
