Howdy!

I have first to thank everyone involved in the developping process of OpenWRT that I've used for some time now... you're really doing a great job

Well... I have been running a routed-bridged WPA2/PSK link between two WRT54GS 1.1 using WhiteRussian 0.9 (and occasionally with X-WRT, ssh-ing a few to make it happen), which ran pretty well, except for a few hangs when I was doing large NFSv3 transfers (didn't see it happen with NFSv4, though)... I could get around 1.1MB/s, which was totally enough for my wireless stations.

Having seen that Kamikaze was officially released, I installed 7.07, standard downloaded image with a 2.4 kernel (bcm43xx-mac80211 on a 2.6 kernel having seemingly an interface problem at the time) and mips version, on two of my WRTs, and went on setting it up to have my routed-bridge again... Must say I love config through /etc ... much clearer and less hacking-like than through NVRAM

So I managed to configure it all and it works totally OK (fast ping and 1.5MB/1.1MB transfers), without encryption or with WEP... it also works with WPA (tested with psk and psk2 options), but with a lot of instability (client router ends up rebooting in a few minutes of use) and really very slowly (around 500-1500ms of ping, and an horrible and unworkable 1-5kB/s "local" download through the wireless bridge)...

I have seen that this is yet the second official release of Kamikaze, and that bump notes from 7.06 to 7.07 mention "WPA related bugfixes in the wifi scripts for Broadcom and Atheros"... Is the case I experience something already known (I have searched the forum but have not really found something really related to my case... WPA2/PSK access point works totally OK with my laptop, my Squeezebox and my Wii... only the client WRT seems unstable until now)...? Should I use custom build from the latest SVN trunk, until 7.08 is released (I'd prefer to stay to the tagged released for daily use and use latest trunk for tests only)?

Just so to say, there was X-WRT on these two routers and I flashed them through the TRX image via X-WRT web interface... any possiblity of still having NVRAM datas from previous installation that are bugging Kamikaze?

To give a few piece of information, I only modified /etc/config/network on the AP WRT (PPOE and static route to the subnet on the other side of the routed-bridge) :

#### VLAN configuration 
config switch eth0
        option vlan0    "1 2 3 4 5*"
        option vlan1    "0 5"


#### Loopback configuration
config interface loopback
        option ifname   "lo"
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0


#### LAN configuration
config interface lan
        option type     bridge
        option ifname   "eth0.0"
        option proto    static
        option ipaddr   192.168.2.1
        option netmask  255.255.255.0
        option dns      192.168.2.1
        option gateway  192.168.2.1

#### WAN configuration
config interface        wan
        option ifname   "eth0.1"
        option proto    pppoe
        option username "MY_PPOE_ID_:p"
        option password "MY_PPOE_PASS_:p"
        option keepalive 5

config route saloon
        option interface lan
        option target   192.168.3.0
        option netmask  255.255.255.0
        option gateway  192.168.2.2

as the one on the client AP (deactivated the WAN for now, manual IP for the wifi card, as I want everything without DHCP):

#### VLAN configuration 
config switch eth0
        option vlan0    "1 2 3 4 5*"
        option vlan1    "0 5"


#### Loopback configuration
config interface loopback
        option ifname   "lo"
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0


#### LAN configuration
config interface lan
#       option type     bridge
        option ifname   "eth0.0"
        option proto    static
        option ipaddr   192.168.3.1
        option netmask  255.255.255.0
        option gateway  192.168.2.2
        option dns      192.168.2.1

config interface wlan
        option ifname   "wl0"
        option proto    static
        option ipaddr   192.168.2.2
        option netmask  255.255.255.0
        option gateway  192.168.2.1

I also modified /etc/config/wireless on the AP :

config wifi-device  wl0
        option type     broadcom
#       option channel  5
        # REMOVE THIS LINE TO ENABLE WIFI:
#       option disabled 1

config wifi-iface
        option device   wl0
        option network  lan
        option mode     ap
        option ssid     "MY_SSID_:p"
        option encryption psk
#        option encryption psk2
        option key "MY_PSK_:p"

and of course the one on the routed-bridged client :

config wifi-device  wl0
        option type     broadcom
#       option channel  5

        # REMOVE THIS LINE TO ENABLE WIFI:
#       option disabled 1

config wifi-iface
        option device   wl0
#       option network  lan
        option mode     sta
        option ssid     "MY_SSID_:p"
        option encryption psk
#        option encryption psk2
        option key "MY_PSK_:p"

I also did a "chmod -x" on /etc/init.d/firewall and on /etc/init.d/dnsmasq on the client router (only switching off the firewall is mandatory to make it work at once, but the fact I only use the DNS bouncer from the AP router made me deactivate dnsmasq on the client one)...

I haven't installed anything special (except for nano to edit the files... don't really like vi) through ipkg... old docs for WhiteRussian (Wiki howto) mentionned libpthread needed to be installed, but having done it doesn't change the instability and slowliness in my case... what is the real use for that anyway?

If anyone had a fix or an idea for this quite broken WPA routed-bridge...

Why is the wireless channel commented out?

Also, why, in the last config, is the "network lan" commented out?

For the question about the wifi channel, I tried to comment it out just to see if wlc could indicate me if this was a mandatory option... if I leave this blank, it seems the channel 1 is used by default (as "wlc channel" indicates it)... setting it to a common and declared value sadly doesn't change my problem, though...

For the commenting out of "network lan" on the client router, it seems the good way to break the bridge between the lan and the wlan... which is needed because I do not try to do a real bridge with one subnet for everything (trickier from the experience I have of this) but a routed link through a wireless connection... I inspired myself from a Kamikaze client mode howto from the wiki, based on Atheros chipset (which I don't have, as WRT54GS are based on broadcom wifi chips)...

If I leave this on, the wireless interface on the client router doesn't get its own IP on the same subnet as the one from the AP it tries to associate to, but instead gets included in the subnet of the client switch (hope I am clear enough)... thus, if I leave this, the bridge is not broken... and I need it to be.

After my writing of the first post, I remembered that the scripts calling nas (the nasty hellish blob that is needed for broadcom based wifi, which we will hopefully soon be able to burry deep underground) usually used the "-l" parameter (lan interface name), which is obviously out of purpose if one tries to break the bridge...

WhiteRussian howto I linked on the first post mentionned that it should be deleted from the scripts that called nas, which I tried to do since I began writing on this topic... it appears that the Kamikaze script that effectively calls nas is /lib/wifi/broadcom.sh, but deleting it from this script did'nt do the trick... still unstable and slow... painfully...

So I also remembered that the supplicant included in nas was weak... or something like this ... and that wpasupplicant with the external driver way to call it was prefered... I think I am going to try to use it, but I think I have read some posts in the forums that said nas would not work with wpasupplicant in Kamikaze (like said on the last post of this topic... does it also applies to the use of wpasupplicant with the -Dwext parameter (I think it is the way to call for external drivers)?

(Last edited by Aefron on 30 Aug 2007, 22:38)

Just so to say... wpa_supplicant with a wpa_supplicant.conf put in /etc/ and launched manually like "wpa_supplicant -Dwext -iwl0 -c/etc/wpa_supplicant.conf" works OK...

Though it is a bit hacky-like... one needs to put ssid, password, authentication type, pid file and such in a file that seems to come out of /etc/config/wireless scope, because no script seems to refer to wpa_supplicant on the install I made... quite filthy in some way... though /lib/wifi/broadcom.sh doesn"t rely on it, would it only be exclusively for WPA client mode, while it uses the totally unworkable call to nas, which it is strange at most... I understand that WPA may be less resource-consuming using so-called optimized routines than using software only method... but when the so-called proprietary optimized routines work so badly (if one may call this working) in WPA...

So, I guess my question is : how is wpa_supplicant launched on atheros-based platforms? Howtos about atheros wifi config seem to suggest the scripts on atheros-based platforms call it automatically, relying on the /etc/config/wireless settings...

Would it be possible to publish in the wiki or the forum the equivalent of broadcom.sh (atheros.sh?) so one could hack the WPA client part of it (and eg the creation of a wpa_supplicant.conf on the fly, based on /etc/network/wireless preferences, that may be done in this atheros.sh) into broadcom.sh? It would prevent from having to do all the work from scratch and may help better integration of this feature...

... well, until brcm43xx-mac80211 is usable on mips... which I pray for it to come as soon as possible, ooohhh-yeeaah

(Last edited by Aefron on 31 Aug 2007, 12:44)

Sorry... I was actually connected to another router with an atheros chip when I was successfully and manually issuing the wpa_supplicant... on the WRT54GS, it is still a failure... ... the only way it can connect using WPA is with nas, and it is very unstable, though it worked ok with WhiteRussian and X-WRT... if nobody has an hint, I guess I will go back to this on this machine, at least until brcm43xx-mac80211 gets usable...

http://forum.openwrt.org/viewtopic.php?pid=52716#p52716

Well, thanks for the link... but I am not using WDS... just sta (ie client) mode... I used WDS a long time ago, but it had too much throughput problems in my home...

Anyway, those problems with the blob driver and WPA just show how painful and unmanageable blobs are... no big surprise... just have to wait until problems with the PCI interface get solved for bcm43xx-mac80211 can be used...

Best of luck and encouragements to those who are working to make this possible... In the meantime, I'll go back to WhiteRussian on the client router and hope that will work with the Kamikaze AP with WPA and routed wifi link...

(Last edited by Aefron on 2 Sep 2007, 14:05)