Thread: [Madwifi-users] Weird problem with AP and STA on the same card.
Status: Beta
Brought to you by:
otaku
From: Jose I. C. T. <ild...@gm...> - 2006-10-23 01:40:28
|
Hi! I have configured my minipci card to work as AP and STA at the same time. It was working great until today I had some connection issues on the STA interface. When I lost the connection on the STA interface, the AP interface seem to have problems too, ie: I lost the connection on my laptop.... even If I try to set the channel manually (iwconfig ath0 channel 7), I still had problems (ie, when the STA disconnected, and started to scan again, the AP interface just went out). Another issue is that, when I create the second interface (the STA interface), It goes to ath2 instead of ath1 :-S . I'm using madwifi 0.9.2 (release), and my card info from lspci : 02:07.0 Ethernet controller: Atheros Communications, Inc. AR5005G 802.11abg NIC (rev 01) I'm configuring the interfaces like this: /sbin/rmmod ath_pci /sbin/modprobe ath_pci autocreate=ap /usr/local/bin/wlanconfig ath create wlandev wifi0 wlanmode sta nosbeacon sleep 2 /usr/local/bin/athctrl -d 35000 /sbin/ifup ath0 sleep 1 /sbin/ifup ath2 Yes, ath2.... for some reason when wlanconfig creates the second interface, I get it on ath2, despite the fact the wlanconfig reports: ath1 :-S . ifup will use the interfaces file to setup the IP address, the ssid and channel for both interfaces, here it is: iface ath2 inet static address 192.168.7.7 netmask 255.255.255.0 wireless_essid lagalia wireless_txpower 17 wireless_channel 7 iface ath0 inet static address 192.168.10.1 netmask 255.255.255.0 wireless_essid prueba wireless_txpower 17 wireless_channel 7 Any ideas? Thanks in advance, Ildefonso Camargo |
From: kamyl <ka...@vi...> - 2006-10-26 07:37:22
|
Jose Ildefonso Camargo Tolosa wrote: > When I lost the connection on the STA interface, the AP interface seem > to have problems too, ie: I lost the connection on my laptop.... even > If I try to set the channel manually (iwconfig ath0 channel 7), I > still had problems (ie, when the STA disconnected, and started to scan > again, the AP interface just went out). I have exacly the same problem and setup. This behaviour is unacceptable so I had to switch back to Prism 2.5 based card and test madwifi-ng on non production box :( When STA loose connection with remote AP, local AP freeze and don't broadcast itself to the air anymore. Any ideas or help in setting madwifi-ng correctly highly appriciated :) > Yes, ath2.... for some reason when wlanconfig creates the second > interface, I get it on ath2, despite the fact the wlanconfig reports: > ath1 :-S . That't strange behaviour. Possible workaround would by issuing: `wlanconfig ath1 create wlandev wifi0 wlanmode sta nosbeacon` instead of command you type. This command should force wlanconfig to create ath1 device. It works that way on my box. -- Cheers, Kamil Jaroslawski |
From: Michael R. <ma...@no...> - 2006-10-26 09:53:04
|
> Jose Ildefonso Camargo Tolosa wrote: > I have exacly the same problem and setup. This behaviour is unacceptable > so I had to switch back to Prism 2.5 based card and test madwifi-ng on > non production box :( When STA loose connection with remote AP, local AP > freeze and don't broadcast itself to the air anymore. Any ideas or help > in setting madwifi-ng correctly highly appriciated :) Guys, you have just one radio, what other behaviour do you expect? If the STA VAP needs to scan, the underlaying physical WLAN device needs to switch to other channels. Of course this also affects all other VAPs that are bound to the same card. There is not much we could do here, at least not without making things quite difficult for the driver. >> Yes, ath2.... for some reason when wlanconfig creates the second >> interface, I get it on ath2, despite the fact the wlanconfig reports: >> ath1 :-S . > That't strange behaviour ... which probably is caused by some strange udev rules. Ticket #972 comes to my mind as being related, for example. See: http://madwifi.org/ticket/972 Bye, Mike |
From: kamyl <ka...@vi...> - 2006-10-26 15:37:05
|
Michael Renzmann napisał(a): > Guys, you have just one radio, what other behaviour do you expect? > > If the STA VAP needs to scan, the underlaying physical WLAN device needs > to switch to other channels. Of course this also affects all other VAPs > that are bound to the same card. There is not much we could do here, at > least not without making things quite difficult for the driver. I expected identical behaviour as in hostap-driver for Prism based cards. For example one can create AP, and plenty of WDS and if one WDS doesn't exist anymore or is turned off AP is still usable. I mean it doesn't scan on every possible channel and works as earlier. Can we prevent madwifi-ng with AP and STA in WDS mode on one card to scan on every possible channel and to act as hostap driver? Even forcing madwifi-ng (by using athchans) to use only one channel in one band on every VAPs don't work. This feature (fixed channel without scanning or with just passive scan) would be great in this situation. Maybe there is other workaround or I missed some iwpriv setting? I know I can buy more cards, but is this the only solution? -- Cheers, Kamil Jaroslawski |
From: Michael R. <ma...@no...> - 2006-10-27 04:03:01
|
Hi. kamyl wrote: >> If the STA VAP needs to scan, the underlaying physical WLAN device >> needs to switch to other channels. Of course this also affects all >> other VAPs that are bound to the same card. There is not much we >> could do here, at least not without making things quite difficult >> for the driver. > I expected identical behaviour as in hostap-driver for Prism based > cards. For example one can create AP, and plenty of WDS and if one > WDS doesn't exist anymore or is turned off AP is still usable. You describe a different situation here. A STA VAP differs from WDS VAPs in functionality and behaviour. > Can we prevent madwifi-ng with AP and STA in WDS mode on one card to > scan on every possible channel and to act as hostap driver? This is the only real issue I currently see in this situation. > Maybe there is other workaround or I missed some iwpriv setting? I > know I can buy more cards, but is this the only solution? Is dot11h enabled? If so, try disabling it and see if that helps - that's the only idea I have in this regard without looking at the code. Bye, Mike |
From: kamyl <ka...@vi...> - 2006-10-27 14:15:05
|
Michael Renzmann napisał(a): > You describe a different situation here. A STA VAP differs from WDS VAPs > in functionality and behaviour. You are right. I tried it with regular STA and with STA in WDS mode. I know what is the difference between these two modes but on madwifi wikipage which describes how to set WDS mode it's written that creating STA VAP followed by `iwpriv athX wds 1` is equal to creating WDS VAP and issuing `iwpriv athX wds_add xx:xx:xx:xx:xx:xx`. First option works like charm, and surprisingly the second option simply don't work for me. I tested it with two hardware AP set to work in AP+WDS mode (Edimax and Planet). I'm in need to set stable WDS or STA (regular client mode) link to remote WDS or AP and have local AP functionality with one card. > This is the only real issue I currently see in this situation. I think that this issue is very important. Power breaks, really bad weather, or any other thing can make AP not working because STA VAP is hopping over channels. That is why after tests I switched back to Prism 2.5 but I'm still dreaming about getting stable this 54 or 108Mb atheros based networks. I'd like to get stability I have currently with my old duo (Prism + hostap) plus ultra high speed given by atheros based cards. > Is dot11h enabled? If so, try disabling it and see if that helps - > that's the only idea I have in this regard without looking at the code. If You mean doth than yes, iwpriv said that it is enabled. I see more "doth" iwpriv options but I don't have idea on how to get current values of these options since there are no get_ functions. Maybe they are hidden in /proc or /sys ? :) I'll test my setup with disabled doth options. Thank You for hint! -- Cheers Kamil Jaroslawski |
From: Jose I. C. T. <ild...@gm...> - 2006-10-26 20:29:00
|
Hi! On 10/26/06, Michael Renzmann <ma...@no...> wrote: > > Jose Ildefonso Camargo Tolosa wrote: > > I have exacly the same problem and setup. This behaviour is unacceptable > > so I had to switch back to Prism 2.5 based card and test madwifi-ng on > > non production box :( When STA loose connection with remote AP, local AP > > freeze and don't broadcast itself to the air anymore. Any ideas or help > > in setting madwifi-ng correctly highly appriciated :) > > Guys, you have just one radio, what other behaviour do you expect? > > If the STA VAP needs to scan, the underlaying physical WLAN device needs > to switch to other channels. Of course this also affects all other VAPs > that are bound to the same card. There is not much we could do here, at > least not without making things quite difficult for the driver. I would expect it to keep on the same channel waiting for the connection to come back (yes, I know, but I KNOW where is my remote AP): yes, I expect it to not scan on all channels: just scan on the channel were I configured it (channel 7 in my case). This way, I would still have the AP working. Yes, I ran iwconfig ath0 channel 7 AND iwconfig ath2 channel 7 .... this *should* make the card STAY on channel 7.... but it doesn't, it starts to scan. Maybe an iwpriv to force the channel to be fixed would be good. > > >> Yes, ath2.... for some reason when wlanconfig creates the second > >> interface, I get it on ath2, despite the fact the wlanconfig reports: > >> ath1 :-S . > > That't strange behaviour > > ... which probably is caused by some strange udev rules. Ticket #972 comes > to my mind as being related, for example. See: > http://madwifi.org/ticket/972 > > Bye, Mike > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users > |
From: Michael R. <ma...@no...> - 2006-10-27 04:10:33
|
Hi. Jose Ildefonso Camargo Tolosa wrote: > I would expect it to keep on the same channel waiting for the > connection to come back (yes, I know, but I KNOW where is my remote > AP): FYI: http://madwifi.org/ticket/980 Feel free to add your comments to that ticket. Bye, Mike |
From: Jose I. C. T. <ild...@gm...> - 2006-11-12 01:17:42
|
Hi! I just saw that this ticket got "minor" priority. For me: it is a major problem. I can't make my network work correctly with this bug!. See, I have a long wireless link (almost 10 miles), wich isn't very reliable (because of power failures on the other side). I also have a client connected to my "atheros-based" AP. Anyway, the AP stops working becase the STA starts to scan when it lose the connection. I just need an option to make the channel change persist when done manually. I mean, I issue an: iwconfig ath2 channel 7 ath2 is the sta interface. But the driver still go and scan over all the channels. I tried to specify the AP as well, but it still tries to scan. I tried to set the channel on the AP interface, and it still scans. Anyway: it happends the same thing always. I also tried to turn off the bgscan, but It only helped me to improve the stability of my link a little, it still fails when the sta gets disconnected. Anyway, I don't find an option to change the priority of the bug: can you please consider changing the priority? Thanks in advance, Ildefonso Camargo On 10/27/06, Michael Renzmann <ma...@no...> wrote: > Hi. > > Jose Ildefonso Camargo Tolosa wrote: > > I would expect it to keep on the same channel waiting for the > > connection to come back (yes, I know, but I KNOW where is my remote > > AP): > > FYI: http://madwifi.org/ticket/980 > > Feel free to add your comments to that ticket. > > Bye, Mike > |