On Thu, 13 Nov 2008 13:45:31 +0200 Kalle Valo <[EMAIL PROTECTED]> wrote:
> Celejar <[EMAIL PROTECTED]> writes: > > > AP mode is listed as working > > (http://linuxwireless.org/en/users/Drivers/b43): > > > > Working > > > > ... > > > > # Access Point mode (not quite yet, blocked by proper support in mac80211 > > and hostapd) > > > > but I can't even put my 4318 into AP mode: > > > > ~# iwconfig eth0 mode master > > Error for wireless request "Set Mode" (8B06) : > > SET failed on device eth0 ; Invalid argument. > > > > The card works fine in managed and monitor mode. Am I doing something > > wrong, or is the webpage incorrect for the 4318? What does "not quite > > yet" mean anyway? > > You have to use hostapd. I have succesfully used b43 in Master mode > with latest wireless-testing and hostapd git trees. Thank you (and Artem). I've built hostapd, and it seems to be running fine, but I'm having trouble connecting to it with my client. I'm not sure whether the problem is on the hostapd box, or at the client end, since I'm experimenting with openwrt, and trying to use a wireless router as a client, something that I haven't tried before. This is the hostapd output: $ sudo ./hostapd hostapd.conf Configuration file: hostapd.conf Failed to update rate sets in kernel module Could not set passive scanning: Unknown error 4294967295 Mode: IEEE 802.11g Channel: 5 Frequency: 2432 MHz Failed to set CTS protect in kernel driver Failed to set Short Slot Time option in kernel driver Could not set preamble for kernel driver Using interface eth0 with hwaddr 3e:90:0e:0d:46:d0 and ssid 'test' Failed to set CTS protect in kernel driver Failed to set Short Slot Time option in kernel driver Could not set preamble for kernel driver eth0: STA 00:22:15:53:42:17 IEEE 802.11: authenticated eth0: STA 00:22:15:53:42:17 IEEE 802.11: associated (aid 1, accounting session 491CF261-00000000) Does this look right? The client scans and sees the AP, and it sends arp requests. Using tcpdump on the hostapd box, I see the incoming arp requests and outgoing replies, but they don't seem to be received on the client. On the hostapd box: 22:46:02.917415 arp who-has 192.168.4.2 tell 192.168.4.1 22:46:02.918551 CF +QoS arp reply 192.168.4.2 is-at 3e:90:0e:0d:46:d0 (oui Unknown) 22:46:04.118528 arp who-has 192.168.4.2 tell 192.168.4.1 22:46:04.118559 CF +QoS arp reply 192.168.4.2 is-at 3e:90:0e:0d:46:d0 (oui Unknown) 22:46:05.317371 arp who-has 192.168.4.2 tell 192.168.4.1 22:46:05.317403 CF +QoS arp reply 192.168.4.2 is-at 3e:90:0e:0d:46:d0 (oui Unknown) 22:46:06.517367 arp who-has 192.168.4.2 tell 192.168.4.1 22:46:06.517398 CF +QoS arp reply 192.168.4.2 is-at 3e:90:0e:0d:46:d0 (oui Unknown) etc ... On the client, I get no responses, and the arp table shows that the address of the hostapd box has not been resolved (it shows as all 0s), although ifconfig shows that some data is indeed passing through the interface (I don't yet have tcpdump installed on the router): wl0 Link encap:Ethernet HWaddr 00:22:15:53:42:17 inet addr:192.168.4.1 Bcast:192.168.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:391 errors:0 dropped:0 overruns:0 frame:23049 TX packets:231 errors:37 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:37339 (36.4 KiB) TX bytes:17514 (17.1 KiB) Interrupt:2 Base address:0x5000 [Incidentally, this is a Broadcom system with Broadcom wireless, but I haven't yet managed to boot a 2.6 version of openwrt, to test b43 on it.] I have no idea whether I'm doing something wrong on the hostapd box or at the client side. When I gain access to some more of my hardware, I'll try mixing and matching clients and aps to pin down the location of the problem. Any suggestions are of course appreciated. Thanks again. > Kalle Valo Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
