Hello Jiri, On 6/22/2006, "Jiri Benc" <[EMAIL PROTECTED]> wrote:
>Great work! I was even able to ping. (Tried only open system >authentication for now, it seems it works quite well.) Well, I use first version of this patch from the end of April, and had no problems so far, so, while it's probably cannot be really called "stable" yet, it's at least 'working somehow" ;-) >Or, if you don't want to patch hostapd (untested, but should work): > >iwpriv wlan0 param 1046 1 >ip link set wmgmt0 name wmaster0ap >hostapd /path/to/hostapd.conf >iwpriv wlan0 param 1046 0 Thanks for the information! This is easier way indeed ;-) >Hopefully we will convert the whole hostapd<->stack communication to >netlink in some near future ;-) Yes, it would be nice if things get a bit more settled & stable there ;-) >> 2) Insert modules (80211, rate_control and bcm43xx-d80211) > >modprobe bcm43xx-d80211 is enough, other modules will load >automatically. I just had no modprobe on my test system, that's why I listed all of them separately ;-) But yes, for "normal" usage modprobe is easier. >> 6) "iwconfig wlan0 essid <your-SSID-name>" (this also should not be >> required, but current combination of hostapd + dscape doesn't seem to >> generate config_interface callback when setting beacon, so this is >> required just to force call of config_interface). > >The stack currently has very limited support for cards with "beacon >templates". ieee80211_beacon_get function is not designed in a way it is >used in bcm43xx. Although this seems to be easy to fix now, we will run >into other problems later (with TIM elements mainly). >I need to look how PS mode works in bcm chipsets to find a correct >solution for this. Do you have any ideas? Well, current use of ieee80211_beacon_get in bcm43xx is plain wrong indeed, it just happens that it seems to work anyway ;-) As for the PS, the main problem currently seems to be the lack of hardware specifications: quite some things that are needed to make it work are unknown. The information/speculations I have so far (please note my understanding of 802.11 specs is very limited!!!): 1) TIM seems to be generated by software (I think it was confirmed by smb from specs group). 2) DTIM counter in beacons sent is updated by hardware (confirmed by specs group). 3) There is PS interrupt that in my experiments seemed to correlate with the beacon interval (one PS interrupt for one beacon sent?) My original idea was that it could be used to update beacon template, but specs group seemed to be sceptical about this idea saying that in original driver the beacon template was not updated in PS interrupt handler. Now I think that it's, probably, not necessary to update beacon template exactly before/after current beacon is sent, as the reason to update beacon is only change in TIM, and we can just update template as soon as TIM is changed (so, some sort of callback from dscape to the driver is needed). However, this PS interrupt could be used for sending broadcast packets (which, as far as I understood from 802.11 specs, should be sent after DTIM beacon). To use it for this purpose, we need the following information: a) Confirmation that PS interrupt is invoked exactly after current beacon is sent. b) The way to know whether current beacon was DTIM or not. I do not have answers to these questions so far :-( Yet another idea (which still should be checked) is that probably, PS interrupt is invoked not for every beacon, but for DTIM beacons only (I'm not sure that in my experiments I had DTIM interval larger than beacon interval, so it's possible every TIM was DTIM, that's why PS interrupt was called for every beacon). There's yet another interrupt that I currently don't fully understand - beacon update interrupt, I did not see it called at all so far, so I don't know where/how it could be used. All other PS things seem to be relatively OK - there's also some support in hardware for processing entering/exiting PS mode for STAs, but these packets seem to be passed to dscape layer also, and as they are already processed in dscape, it looks like there's no need to bother with using hardware for that. Currently I just have not enough time to finish the experiments with PS, and anyway I'm afraid some of these things can be a bit hard to find out by experimenting only :-( Good luck! Alexander - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
