Modify

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#12720 closed defect (fixed)

atheros bridged client mode bug (relayd)

Reported by: cchhat01@… Owned by: developers
Priority: highest Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: wifi, atheros, ar71xx, client, bridge, sta Cc: cchhat01@…

Description

I've got three different ar71xx based routers (2 buffalo wzr-hp-ag300h and 1 netgear wndr3700v2).

I've set up one of the buffalo routers as the main router and it broadcasts on both 2.4 Ghz and 5Ghz channels (40mhz bandwidth noscan option enabled).
I then went ahead and configured the 2nd router (netgear wndr3700v2) based on the pseudobridge method described here:

http://wiki.openwrt.org/doc/recipes/relayclient

I've enabled "repeater" functionality as well on the netgear by adding "AP" mode which basically rebroadcasts the same SSIDs on both the 2.4ghz and 5Ghz channels, respectively. The 2ndary router also has the noscan options enabled and 40Mhz bandwidth selected.

Does this work? YES. Does this work correctly? Probably not.

Problem:
When the secondary router connects to the upstream/main router, the bandwidth on one of the legs (TX or RX its hard to decipher), is halved. Basically, one of the TX/RX legs will connect at full 40Mhz bandwidth, the 2nd leg will always connect at "20Mhz". As a consequence, all devices which connect to the "bridged" secondary router will not be able to connect beyond 150Mbps max rate.
Also, scanning using inSSIDer shows that the secondary router doesn't broadcast at 40Mhz width (it won't show the primary + secondary channel, it shows only the primary channel).

However, if a wireless client connects directly to the main router, it can connect beyond 150Mbps, generally in the 216-300mbps range on both legs (TX/RX).

At first, I thought this was a problem with using different model routers. I then tried it out with a 2nd buffalo router (of the same model), and the result was the same...

Is this a bug? Is this normal behaviour?

Please help me getting to the bottom of this problem.

Thanks,
Chirag

Attachments (1)

fix_wpa_supplicant_hostapd_ctrl.patch (4.6 KB) - added by FurryFur 4 years ago.

Download all attachments as: .zip

Change History (44)

comment:1 Changed 5 years ago by anonymous

This happens in WDS too between two ar71xx routers here (both tp-link wdr4300).

The device configured to be the WDS AP here always transmits in 40MHz. The WDS CLIENT on the other hand can only transmit in 20MHz to the AP.

On the WDS AP status page (Associated Stations) it looks like this;
RX Rate
216.7 Mbit/s, MCS 23, 20MHz

TX Rate
450.0 Mbit/s, MCS 23, 40MHz

And on the WDS client of course the other way around..

The problem remains with or without any "standard" clients connecting to the AP.

comment:2 Changed 5 years ago by anonymous

Taking a look at /var/run/wpa_supplicant-wlan1.conf on the WDS CLIENT, it looks a bit strange with lots of emtpy lines between parameters. Something wrong here?

ctrl_interface=/var/run/wpa_supplicant-wlan1

network={

        scan_ssid=1
        ssid="xxxxxxxx"

        key_mgmt=WPA-PSK
        proto=RSN

        fixed_freq=1





        psk="xxxxxxxx"















}

comment:3 follow-up: Changed 5 years ago by bjhemm@…

I have/had the same problem using a wndr3700v1(client) and wndr3700v2(ap) in WDS.

At first when using channel 149(ht40+) TX rate never went above 150Mbps/20MHz on the WDS client. And the same for RX on the AP.

However when changing to channel 153(ht40-) on the AP, the WDS client TX is working as expected. This hasn't been an issue before, but I can't remember in which build it became a problem, I only noticed it a week ago.

For me this only happens in WDS mode, regular clients connect at 40MHz on RX/TX just fine.

Anyway, it might be worth trying to switch channels/ht40+/ht40-.

comment:4 in reply to: ↑ 3 Changed 5 years ago by anonymous

Following above post my WDS CLIENT can now also use 40MHz channel width on TX leg.

Changed the AP channel to 48 with HT40- and things works great.

Before I was using channel 36 and HT40+, then WDS CLIENT will not use 40MHz channel width for TX.

comment:5 Changed 5 years ago by cchhat01@…

Okay with the recommendations from above, I was able to successfully connect the Client Router in 40Mhz mode on both TX and RX leg to the AP. My config is using Channel 153 with HT40-.

However, I cannot for the life of me get the same result on any of the 2.4 GHz channels.
In fact, WDS mode really screws up the max bandwidth (it barely reaches 130 Mbps on each of the RX/TX legs on either the AP or Client). Non-WDS works better for me on 2.4 GHz.

Also, the fact that the issue "DOES" occurs in HT40+ modes is a PROBLEM. Unless someone tells me that the drivers inherently don't support AP/CLient combination in 40Mhz modes for HT40+, I would like to see this fixed. I'm sure everyone else does as well.

My problem is that a majority of my wifi clients (non-routers) are on the 802.11g band. Which is why connecting using HT40+/HT40- means more to me here than it does on the 5 Ghz band.

Also my Barrier Breaker build is r34812. Not sure what build others are running here.

Please help.

Thanks,
cchhat01

comment:6 follow-up: Changed 5 years ago by anonymous

@cchhat01: to see 40MHz channel width in 2.4GHz spectrum usually you will need to add noscan parameter to wifi config. IIRC, this is needed for the AP to allow using 40MHz channel width even though the frequencies will overlap with other AP's around you (it also breaks 802.11n specifications).

replace X with radio; uci set wireless.radioX.noscan=1
uci commit
wifi up

http://wiki.openwrt.org/doc/uci/wireless

comment:7 in reply to: ↑ 6 ; follow-up: Changed 5 years ago by anonymous

Replying to anonymous:

@cchhat01: to see 40MHz channel width in 2.4GHz spectrum usually you will need to add noscan parameter to wifi config. IIRC, this is needed for the AP to allow using 40MHz channel width even though the frequencies will overlap with other AP's around you (it also breaks 802.11n specifications).

replace X with radio; uci set wireless.radioX.noscan=1
uci commit
wifi up

http://wiki.openwrt.org/doc/uci/wireless

noscan was already on. There's no way I could have done 40MHz on channel 153 (802.11an) without it.
I finally found that channel 7 with HT40- works in 40MHz mode between AP and Client Router where both TX/RX legs of AP and Client are connected at 40Mhz.

In all this time, I was always following the legitimate pairings which allow HT40+/- using this link: http://en.wikipedia.org/wiki/IEEE_802.11n-2009#40.C2.A0MHz_in_2.4.C2.A0GHz

The point is it should work without fail. I'm just here trying to point out that HT40+ certainly has problems with respect to the routed client wireless mode (relayd).

Thanks,
C

comment:8 in reply to: ↑ 7 Changed 5 years ago by anonymous

Replying to anonymous:

Replying to anonymous:

@cchhat01: to see 40MHz channel width in 2.4GHz spectrum usually you will need to add noscan parameter to wifi config. IIRC, this is needed for the AP to allow using 40MHz channel width even though the frequencies will overlap with other AP's around you (it also breaks 802.11n specifications).

replace X with radio; uci set wireless.radioX.noscan=1
uci commit
wifi up

http://wiki.openwrt.org/doc/uci/wireless

noscan was already on. There's no way I could have done 40MHz on channel 153 (802.11an) without it.
I finally found that channel 7 with HT40- works in 40MHz mode between AP and Client Router where both TX/RX legs of AP and Client are connected at 40Mhz.

In all this time, I was always following the legitimate pairings which allow HT40+/- using this link: http://en.wikipedia.org/wiki/IEEE_802.11n-2009#40.C2.A0MHz_in_2.4.C2.A0GHz

The point is it should work without fail. I'm just here trying to point out that HT40+ certainly has problems with respect to the routed client wireless mode (relayd).

Thanks,
C

Agreed.

After some more tests with HT40+ it really seems to be something wrong in the drivers or possibly wpa_supplicant (from wpad-mini in my case).

This problem has showed up recently, I'm certain I was running my old routers with 40MHz channel width, HT40+ on 2.4GHz channel 1, without any problems. If I were to make a guess this problem showed up around 1 to 2 months ago.

comment:9 Changed 5 years ago by anonymous

After installing r35120, it seems the problem is gone. Can you confirm?

comment:10 Changed 5 years ago by nbd

  • Resolution set to worksforme
  • Status changed from new to closed

comment:11 Changed 5 years ago by cchhat01@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

nbd this does NOT work.
I've got my main router on r35181 and the relayd bridge on r35121.

ANY devices which connect to the relayd bridge via wifi cannot connect after than 65mbps.
I have a macbook which I can see connect only at the max of 65 mbps and its supports a max of 450mbps. It connects to my main router at around 270mbps (which is HT40+/- mode).

The relayd bridge connects to the main router in 40Mhz mode (2 spatial streams 40MHz mode). However wifi client devices that connect to the relayd bridge do not cross 65mbps EVER.

I can post my wifi config.

comment:12 Changed 5 years ago by Chirag Chhatriwala <cchhat01@…>

Guys this is still an issue.
I've got both my devices on r35473.

Any device that connects to the repeater via wifi gets half of its potential speed.
Example: My Dads's HP Notebook, with an AR9285 is capable of 150mbps in 20Mhz. When connecting to the repeater only gets 65 mbps max. When connecting to the main router gets 150mbps connection speeds.
My google tv stb connects to my main router at 270mbps in 40mhz. it is only able to connect to the repeater at 120-150mbps speeds in 20mhz.

In all this, I can see that the repeater does connect to the main router in its full 40mhz bandwidth. data rates between the two routers is also good (ranging between 240-300mbps).

inSSIDer running on my windows machine shows that both routers (main router and repeater) are capable to 300Mbps max range speeds however connecting to the repeater is essentially halving the max connection speeds.

Does any one have any thoughts as to WHY this is happening?

comment:13 follow-up: Changed 5 years ago by salvo2002

Just so I am understanding this correctly: main router connects to AP on 5HGz, you connect devices to the main router on 2.4GHz with expected rate, you connect devices to the AP at 2.4GHz at half the expected rate.

What other scenarios have you tired? i.e. connect a device to the AP while no devices are connected to the main router (with the obvious link from the main to AP connected) etc.?

Sorry if this seems trivial, I'm just trying to fully understand the situation.

comment:14 in reply to: ↑ 13 Changed 5 years ago by Chirag Chhatriwala <cchhat01@…>

Replying to salvo2002:

Just so I am understanding this correctly: main router connects to AP on 5HGz, you connect devices to the main router on 2.4GHz with expected rate, you connect devices to the AP at 2.4GHz at half the expected rate.

What other scenarios have you tired? i.e. connect a device to the AP while no devices are connected to the main router (with the obvious link from the main to AP connected) etc.?

Sorry if this seems trivial, I'm just trying to fully understand the situation.

Main Router (Buffalo WZR-HP-AG300H runs openwrt trunk, broadcasts 2.4 and 5GHz in WDS+AP mode at 40Mhz on their respective channels). Any client that connects to this AP (either 2.4 GHz or 5 GHz) connects at 40Mhz if the client supports it.

The Pseudo Bridge Router (Netgear WNDR3700v2) connects to the MAIN router and is configured to connect to both the 2.4Ghz and 5Ghz channels (all at 40Mhz bandwidth).
This much works great.

Any Wifi client which connects to the Netgear, connects at halved bandwidth. The Netgear shows up on inSSIDer as being able to support upto 300mbps rates however it is not broadcasting in 40Mhz mode (channel 3 and HT40+ mode on 2.4 GHz and 149 HT40+ on 5GHz).
Any Wifi Client connecting to the main router will see its full potential.

I have tried running the main router with WDS+AP mode and the pseudo bridge on WDS+AP+Client mode.
I have tried running the main router with AP mode and the pseudo bridge on AP+Client mode.
All still results in half bandwidth when connecting to the Netgear and full bandwidth when connecting to the Buffalo.
Switching the router's roles makes ZERO difference.

Is this clear enough?

comment:15 Changed 4 years ago by cchhat01@…

This is still not fixed as of build r36940.
Does anyone have ANY IDEA why this is happening?

comment:16 Changed 4 years ago by razvan.savin@…

I have the same problem on Arokh's r37518 running on WNDR3700v1.

I used relayd to set up a pseudobridge between WNDR3700 and a Time Capsule. The router connects fine to the Time Capsule using 2.4 ghz and 5 ghz 40mhz frequency at around 150+ mbits tx/rx.

However, any wireless client connected to the WNDR3700 cannot get more than 130mbit if connected on the 5Ghz band, and 78-100 mbit speed if connected to the 2.4 ghz band. Also, the band width at which they are connecting at is 20mhz, even if WNDR3700 is set to 40mhz.

I appears that any client connecting to WNDR3700 has it's bandwidth halved.

Any ideas?

comment:17 Changed 4 years ago by rod@…

Problem still exists on 12.09
Monitoring bandwidth from WDS AP on WR703N shows initial bw on interface change/reset is 40MHz but after a few seconds switches back to 20MHz. Difficult to test if bandwidth change is coincident with connection as WDS client.
Have compared AP configuration between Primary WDS AP ( WR842N ) and WDS client and AP and can't find any difference.
Output from iw dev on WR703N indicates it should be configured for 40MHz BW.
root@SageAP2:~# iw dev
phy#0

Interface wlan0-1

ifindex 10
wdev 0x6
addr 16:e6:e4:e7:6c:13
type managed
channel 1 (2412 MHz) HT40+

Interface wlan0

ifindex 9
wdev 0x5
addr 14:e6:e4:e7:6c:12
type AP
channel 1 (2412 MHz) HT40+

comment:18 Changed 4 years ago by anonymous

After update to kernel 3.10.13 my Reapeter (tp-link wa901nd v.2) wont work protertly

The setting are:

wlan0 - client WDS -> main AP WDS
wlan0-2 - access point (briged with wlan0), so i have a client and ap mode on one phy wifi interface (ethernet dont use) its all working on 13th channel (with patch)

now both wlans is shown client mode (settings of one is AP mode) and if the both working i have no connection to main AP, before i shut wlan0-2. And the if i swith on wlan0-2 my Reapeter has no reply (web and ssh)

comment:19 Changed 4 years ago by anonymous

I've loaded the tplink mr3020 ( English ) firmware into my wr703n router and configured it to operate as a wds repeater with 40MHz bandwidth in as close a config as my openwrt test above and it displays the same behaviour. Initial boot the AP comes up as 40MHz then switches to 20MHz within a few seconds of boot up.
Not sure where this leaves things but both software versions behave the same.

comment:20 Changed 4 years ago by rod@…

The wr3020 firmware test was done by me.

comment:21 Changed 4 years ago by anonymous

Did you guys test this without relayd? I'm asking because I have had this problem for a while now, but today I've tried setting up my WL830RE(v1) as a repeater WITHOUT relayd and I'm still having the same issue (see https://forum.openwrt.org/viewtopic.php?pid=228262 this thread).

comment:22 Changed 4 years ago by furryfur1@…

Here is a temporary fix. Put this in your start up script:

killall -9 hostapd
hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
exit 0

This fixes the issue for me unless I change some settings which cause networking to restart, then the issue comes back again. It appears to be caused when wpa_supplicant starts after hostapd. I inserted some sleep events into the network start-up scripts and monitored with inSSIDer in order to determine exactly when my interface was getting locked back to 20MHz. The interface locks to 20MHz exactly as wpa_supplicant starts. It seems like wpa_supplicant is somehow changing the radio settings back to 20MHz but I couldn't track down the exact cause of this.

I am running OpenWrt Attitude Adjustment 12.09 Final on a TL-WR842ND V1.0
I have my routers configured with two virtual wireless interfaces, one in Access Point (WDS) mode and the second in Client (WDS) modes. I have several routers setup in the network like this however the behavior exhibits itself even with just two routers. The condition for triggering this bug seems to be to have your router configured in both client and access point mode i.e. you have wpa_supplicant (client connection) starting after hostapd (access point managment) has started. It was awhile ago since I tested this so I'm not sure if the same behavior occurs when the router is configured in Client Mode only (could be caused by wpa_supplicant alone?) but I have a feeling that it does not.

comment:23 Changed 4 years ago by rod@…

Tried the temporary fix from furryfur1 on my wr703n and insider shows the repeater now transmitting with 40MHz bw. Also confirmed 40MHz bw from connected client and status on wr703N.

comment:24 Changed 4 years ago by cchhat01@…

Okay this got me excited.
However, on my setup, the moment i decide to kill hostapd on the WDS Client, things just go haywire and the device is no longer pingable from the Main Router.
My setup is two WD MyNet N750 routers acting as WDS AP and WDS Client+AP. I am no longer using relayd, it is simply plain old WDS system.

I've placed my startup script as commands part of the "startup" in /etc/rc.local. I had to modify mine to make things come up properly because I've got two radio interfaces which I am using.

killall -9 hostapd
hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
hostapd -P /var/run/wifi-phy1.pid -B /var/run/hostapd-phy1.conf
exit 0

Why would this work in one case and not the other? Should I have this script run as a startup script which is accessible from "startup" tab under LuCI? I am using Openwrt trunk r39555.

Technically, if I kill hostapd, it should have a process ID higher than that of wpa_supplicant but the act of killing hostapd may be killing wpa_supplicant as well (Is this what's happening?)

I'm all ears.

Thanks,
cchhat01

comment:25 follow-up: Changed 4 years ago by gvalkov@…

Thanks for your temporary fix, furryfur1!
I found a way to keep the BW at 40 MHz even after changing settings or restarting the wireless with the wifi command. In file: /lib/wifi/mac80211.sh, add the following code at the end of function enable_mac80211()

	sleep 2
	killall -9 hostapd
	hostapd -P /var/run/wifi-$phy.pid -B /var/run/hostapd-$phy.conf || {
		echo "Failed to start hostapd for $phy"
		return
	}

It will be nice if someone fixes this issue! BTW there is an alternative to WDS called mesh. The cons of mesh are that I couldn't set it using the web interface so I used a startup script. The other con is that if for some reason it disconnects, I have to restart the routers to reconnect them or write some code to monitor the connection and restore it, if it drops. Can anyone help me to setup a mesh so that it works automatically and reconnects by itself? The advantage is that when I started the mesh, it didn't suffer from the 20 MHz mode that we face here with WDS. My mesh worked at 40 MHz, 300 Mbit/s and all clients on both routers connected at that speed. The other advantage of mesh is that if the main router goes offline, the other keeps it's clients connected. While a WMS client would shutdown it's AP until it reconnects. Is there a way around this?

comment:26 in reply to: ↑ 25 Changed 4 years ago by cchhat01@…

Replying to gvalkov@…:

Thanks for your temporary fix, furryfur1!
I found a way to keep the BW at 40 MHz even after changing settings or restarting the wireless with the wifi command. In file: /lib/wifi/mac80211.sh, add the following code at the end of function enable_mac80211()

	sleep 2
	killall -9 hostapd
	hostapd -P /var/run/wifi-$phy.pid -B /var/run/hostapd-$phy.conf || {
		echo "Failed to start hostapd for $phy"
		return
	}

It will be nice if someone fixes this issue! BTW there is an alternative to WDS called mesh. The cons of mesh are that I couldn't set it using the web interface so I used a startup script. The other con is that if for some reason it disconnects, I have to restart the routers to reconnect them or write some code to monitor the connection and restore it, if it drops. Can anyone help me to setup a mesh so that it works automatically and reconnects by itself? The advantage is that when I started the mesh, it didn't suffer from the 20 MHz mode that we face here with WDS. My mesh worked at 40 MHz, 300 Mbit/s and all clients on both routers connected at that speed. The other advantage of mesh is that if the main router goes offline, the other keeps it's clients connected. While a WMS client would shutdown it's AP until it reconnects. Is there a way around this?

This function doesn't exist in r39555. What version of OpenWRT are you running?
Please let us know. There are a lot of promising fixes but apparently the version of OpenWRT trunk doesn't seem to work well with these fixes.

comment:27 follow-up: Changed 4 years ago by gvalkov@…

Hello cchhat01,
My WDS client router is TL-WR1043ND v1.8 and is running Backfire (10.03.x Snapshot, r33081). It's the only stable version of OpenWRT for v1.8, which I found:
https://dev.openwrt.org/ticket/9654#comment:479

The fix I offered applies to it. When I searched for a function to patch, the idea was to find some place that is used to start both hostapd and wpa_supplicant one after another. So I tried to change the order, but the wi-fi didn't start and I didn't have time to play with it, so I just added this to the end: sleep, kill and restart hostapd. And it worked.

My main router (WDS AP) is TL-WR1043ND v2.1 and is running BARRIER BREAKER (Bleeding Edge, r40449). I didn't need to use the fix there. I just looked there and the function I patched is missing. I can't investigate this now, as I won't be home for the holiday until Tuesday. Try to find it by your self! Follow the idea I used above and see if you may find the function that starts both hostapd and wpa_supplicant. Good luck! :)

comment:28 Changed 4 years ago by anonymous

Are there any News ?

comment:29 in reply to: ↑ 27 Changed 4 years ago by cchhat01@…

Replying to gvalkov@…:

Hello cchhat01,
My WDS client router is TL-WR1043ND v1.8 and is running Backfire (10.03.x Snapshot, r33081). It's the only stable version of OpenWRT for v1.8, which I found:
https://dev.openwrt.org/ticket/9654#comment:479

The fix I offered applies to it. When I searched for a function to patch, the idea was to find some place that is used to start both hostapd and wpa_supplicant one after another. So I tried to change the order, but the wi-fi didn't start and I didn't have time to play with it, so I just added this to the end: sleep, kill and restart hostapd. And it worked.

My main router (WDS AP) is TL-WR1043ND v2.1 and is running BARRIER BREAKER (Bleeding Edge, r40449). I didn't need to use the fix there. I just looked there and the function I patched is missing. I can't investigate this now, as I won't be home for the holiday until Tuesday. Try to find it by your self! Follow the idea I used above and see if you may find the function that starts both hostapd and wpa_supplicant. Good luck! :)

Hello gvalkov,
In BARRIER BREAKER, the function which you have modified is significantly changed. Infact, the code is moved from /lib/wifi/mac80211.sh to /lib/netifd/wireless/mac80211.sh.
I suspect the function that needs modification is drv_mac80211_setup however, all attempts to modify the code to make it similar to what you've published results in a breaking wireless altogether on my WDS Client. As soon as I the hostapd process is killed, wireless just dies.
Hope that you can help in making this work.

thanks,
cchhat01

comment:30 Changed 4 years ago by FurryFur

Thanks cchhat01, gvalkov for your input. I've upgraded to the latest trunk recently to try and solve my wireless disconnect issues and this problem also reapeared for me so I started looking into this issue again. It is caused because someone hardcoded the secondary channel offset to 0 in the source code for a patch (patch #170 for wpa_supplicant if I remember right, I'm trying on my tablet atm) that lets wpa_supplicant control hostapd through a unix socket. I have patched the code and will try to figure out how to submit my changes to openwrt, probably this weekend and will also post the patch here. The temp fix for now is to remove look for a line in /lib/netifd/wireless/mac80211.sh that looks like this "wpa_supplicant_run {$hostapd_ctrl:+-H $hostapd_ctrl}" and remove the part in curly braces. This basically unlinks wpa_supplicant and hostapd. There is one more change to make so that the radio comes online once hostapd starts, find the line that checks the value of "staidx" and sets the "start_disabled" (I thinks that's what the variable was called) variable to 1 and change it to 0. What the line normally does is check if there is 1 or more stations (client mode, controlled by wpa_supplicant) and if there are then start hostapd disabled as it will be restarted with radio parameters from wpa_supplicant anyway. Sorry if there are any errors here, as I say I'm typing this on my tablet so this is all from memory.

comment:31 follow-up: Changed 4 years ago by FurryFur

Argh, sorry for the bad grammar. This fix should work similarly for all versions of Openwrt. You shouldn't have to worry about the staidx check that starts hostapd disabled in AA or ealier, I think that's new. In AA you have to modify the mac80211.sh file in the old location (/lib/wifi/mac80211.sh) just find the line where the $hostapd_ctrl variable gets passed to wpa_supplicant and remove it. As far as I can tell this shouldn't do anything bad. The patch that links wpa_supplicant to hostapd just seems to be there in order to ensure that the radio parameters remain the same between both AP and client i.e. You can't set the AP to have a different channel to the client, they are on the same radio after all, so it basically sets the client as the master controller for radio parameters.

comment:32 in reply to: ↑ 31 Changed 4 years ago by cchhat01@…

Replying to FurryFur:

Argh, sorry for the bad grammar...

Hello @FurryFur,

Your fix has finally solved the 18 month old bug. I currently have a WDS setup (not relayd), and the issue is gone. I figured it was somehow linked to the way how wpa_supplicant and hostapd were being brought up, it did not occur to me to completely delete the arguments within the {} to wpa_supplicant_run. Nice catch.

Are you holding back on submitting a patch due to potential pitfalls and/or do you think it breaks something else?

comment:33 Changed 4 years ago by FurryFur

No I'm just really lazy... I'll try to get to it today but I might get called into work and I have to do my tax return ASAP so I might still not get to it today but I'll try. I'm kinda surprised nobody else managed to fix this before I did. I mean I'm no expert here or anything, I know how to program but I've never programmed router software before. I had to spend hours trawling through code just to figure out how I could get the channel offset in the particular part of the code I needed it. I'm sure someone else who knew what they were doing would have been able to fix this a lot faster.

Changed 4 years ago by FurryFur

comment:34 Changed 4 years ago by FurryFur

I uploaded the patch as an attachment above. I'll try to figure out who to send it to and how to send it, so it doesn't get mangled, for submission later.

comment:35 follow-up: Changed 4 years ago by Klaus.Voigt@…

Hello FurryFur, i have applied your patch with success. Now my clients are using the full 40 Mhz bandwith. Good Job !
Now we should try to submit the patch to openwrt...

comment:36 in reply to: ↑ 35 Changed 4 years ago by FurryFur

Replying to Klaus.Voigt@…:

Hello FurryFur, i have applied your patch with success. Now my clients are using the full 40 Mhz bandwith. Good Job !
Now we should try to submit the patch to openwrt...

Thanks for testing Klaus, I've submitted the patch to the package maintainer and openwrt devel mailing list so hopefully it will show up in an official build soon :)

comment:37 Changed 4 years ago by anonymous

Great work, REALLY THANKS!

comment:38 Changed 4 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

fix committed in r41019

comment:39 Changed 4 years ago by gvalkov

Thank you for the patch, FurryFur! Today I tested the changes on Backfire and it works there too. Here is a link to my build of Backfire r33081 for TL-WR1043ND v1.8:
https://www.dropbox.com/sh/o9frztawoe2ef78/AADqsBrZiVkm2j3VnCDfthwta

A slightly modified version of the patch is also available there inside
https://www.dropbox.com/s/uubnt0xprsxpg1k/fix_wpa_supplicant_hostapd_ctrl.backfire.gz

This is my first attempt to create a patch file and mine seems to use a different format, so I also provided the original files a/ and the patched b/. What is the proper way to generate it? I used this command:

diff -crB a b >fix_wpa_supplicant_hostapd_ctrl.backfire.patch

Hey nbd, can you please integrate this into the Backfire tree? (if it is possible) :)

comment:41 Changed 4 years ago by gvalkov

Here's my backport of FurryFur's patch to Backfire. What should I do next?
How do I commit it to the official Backfire repository or who may I ask to do this?
https://www.dropbox.com/s/gjyvq70z3wgdrzm/g.Fixed-wpa_supplicant-locking-hostapd-to-20MHz-12720.patch

comment:42 Changed 4 years ago by FurryFur

I just read through this and used the relevant parts, it tells you where you should send the patch to as well as how it should be formatted in the email: https://dev.openwrt.org/wiki/SubmittingPatches. I recommend using git git-send-email to send the patch so that it doesn't get mangled.

Your patch has a duplicate macro that might stop it from being accepted; HT_INFO_HT_PARAM_STA_CHNL_WIDTH is called HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH in earlier revisions so you shouldn't make a duplicate macro in ieee802_11_defs.h, you should just replace the HT_INFO_HT_PARAM_STA_CHNL_WIDTH part with HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH for your patch instead. Don't try to modify the patch file directly you will need to recreate it.

comment:43 Changed 4 years ago by gvalkov

Hi FurryFur and thank you for helping me learn this!
It was so much easier now that I know how to use quilt. :)
I tried to send the patch to nbd and the mailing lists, eventuality the mailing lists rejected it as I had not registered, but hopefully nbd will receive and apply the patch.

I corrected the issue you mentioned. The link from my previous message now points to a corrected version of the patch.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.