I can't say how to do this through luci, but messing with the command line

the following examples are from my wndr3800 routers I'm running at the scale conference.

try doing something like:

/etc/config/wireless
config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11ng'
        option path 'pci0000:00/0000:00:11.0'
        option htmode 'HT20'
        option txpower '8'
        option country 'US'
        option channel '1'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'test'
        option network 'testname'

in /etc/config/network

config interface 'testname'
        option ifname 'eth0'
        option type 'bridge'

with no references to any firewall rules in the network config

this brings up a wired interface, a wifi interface, and bridges them together

disable all dhcp, etc

in luci, it's something like

define a new wifi interface
define a new interface, make it a bridge, and select your wired and wifi interface. make sure that dhcp is disabled on this bridge interface.

davidc502, thank you very much for kernel modules packages, all works correctly.

Just for reference, my bandwidth tests for WRT1900ACv1, r48158 (David's build .16), TCP 1 MB window.
LAN ↔ LAN, 1 Gpbs link: 941 Mbps.
LAN → WAN, 1 Gbps link: 931 Mbps, 75-80% CPU load.
WAN → LAN, (same link): 651 Mbps, 68-73% CPU load.
WLAN → LAN (5 GHz, 802.11n, 40 MHz, 300 Mbps): 220 Mbps, 64-66% CPU load.
LAN → WLAN (same link): 160 Mbps, 53-55% CPU load.
WLAN → LAN (2.4 GHz, 802.11n, 40 MHz, 300 Mbps): 174 Mbps, 48-56% CPU load.
LAN → WLAN (same link): 91 Mbps, 40-46% CPU load.
Wireless 80 MHz width 866.5 Mbps not tested yet, but I expect same as my old results.

(Last edited by Vanav on 23 Jan 2016, 02:19)

Just compiled the latest snapshot of trunk, that includes the updated Luci....  5Ghz wifi won't come up.. The following is in the log.

Fri Jan 22 18:46:04 2016 daemon.notice netifd: radio1 (9736): Interface 0 setup failed: INVALID_WPA_PSK
Fri Jan 22 18:46:04 2016 daemon.notice netifd: radio1 (9736): WARNING: Variable 'interfaces' does not exist or is not an array/object

I've tried several times to type and save the PSK, but it won't save.

This is the wifi config for radio1. I've tried to manually add the option key, but when I restart wifi, it gets erased.

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11a'
        option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option country 'US'
        option frag '2346'
        option rts '500'
        option txpower '23'
        option channel '48'
        option htmode 'VHT80'

config wifi-iface
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'TDSFiberOptics_5GHz'
        option encryption 'psk2+ccmp'
        option macaddr '94:10:3e:8c:f4:95'
        option bssid 'root'
        option eap_type 'tls'
        option auth 'PAP'
        option key '1'

EDIT -- The interface will come up if I set to No Encryption.
Deleted, and re-added but not change.

(Last edited by davidc502 on 23 Jan 2016, 02:14)

wpa encryption keys must be 8 characters, so '1' doesn't work :-)

I learned this last year when we planned a 7 character password for Scale, printed a few hundred shirts, and a couple thousand programs and then learned that it requires 8 characters. We modified the shirts and every program, and so everyone involved is _very_ aware of the 8 character minimum.

My wifi password is well over 8 characters. I can enter the password and save, and when I check the config, nothing shows up. I go back to the interface, and the password is always blank.

I've tried varying lengths of passwords, and nothing will take.

Is showing like this....

root@OpenWrt:~# uci show wireless |grep key
wireless.@wifi-iface[0].key='omitted'
wireless.@wifi-iface[1].key='1'

Another look

root@OpenWrt:~# cat /var/run/hostapd-phy1.conf |grep wpa_passphrase
root@OpenWrt:~# cat /var/run/hostapd-phy0.conf |grep wpa_passphrase
wpa_passphrase=omitted

(Last edited by davidc502 on 23 Jan 2016, 03:19)

from my config for the scale conference

wireless.@wifi-iface[1]=wifi-iface
wireless.@wifi-iface[1].device='radio1'
wireless.@wifi-iface[1].mode='ap'
wireless.@wifi-iface[1].ssid='SCALE14x-fast'
wireless.@wifi-iface[1].network='scale5'
wireless.@wifi-iface[1].encryption='psk-mixed'
wireless.@wifi-iface[1].key='pasadena'
wireless.@wifi-iface[1].isolate='1'
wireless.@wifi-iface[1].maxassoc='512'
wireless.@wifi-iface[1].dtim_period='4'

see how the key entry contains the password. In your case, key is a single character. I learned last year that if the value of key is <8 characters long, the interface will not startup.

is this where you are putting the password you are saying you've tried multiple lengths of?

correct -- In Luci, I've tried from 8 characters to 20.

LuCi will not allow you to put less than 8 characters (the dots are red in color until more than 7 are typed). If you try to save the form with less than 8, it will not save, and a pop up message says "Some fields are invalid, cannot save values".

for some reason, when the form is saved with a password 8 characters or longer, when you go back and check, it never actually saved, and of course the interface doesn't come up either.

(Last edited by davidc502 on 23 Jan 2016, 04:05)

but all of this is with option key '1' in the file correct?

try editing the file and chaange it to an 8 character key in the file and then try to set it via luci

@David, what build number are you on? i'm currently running r48455 (and latest feed updates) without any issues? not sure when they changed Luci?

just running this:

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'MY_SSID'
        option network 'lan'
        option encryption 'psk2+ccmp'
        option key 'S0meth1ngComplex!'
        option macaddr 'aa:bb:cc:dd:ee:ff'

(Last edited by JohnnySL on 23 Jan 2016, 13:48)

Can someone else can try this snapshot, and see if they have the same problem? V1 hardware

http://personalpages.tds.net/~davidc502 … %20r48456/

You can see that wireless security section is a lot different now (Included Radius authentication).. It's poorly implemented in a sense of where everything is, and didn't know where to put the PSK until I looked at 2.4Ghz configuration which works. So, you put the PSK where it says "Key". Not very helpful with all the extra Radius noise.

http://personalpages.tds.net/~davidc502 … apture.JPG

Initially when the router was flashed 5Ghz was up, and had connections.. It wasn't until I changed channels (was testing DFS), that it stopped working.

(Last edited by davidc502 on 23 Jan 2016, 15:50)

If I'm bridging wired clients across an existing wireless network, wouldn't I want 'sta'mode for the wireless interface?

And no gateway/dns options will be required, those should get pulled across when the wireless attaches I'm guessing.

i would try it i you had a V2 image.

I've gone ahead and nuked the feed... make clean, make dirclean, and deleted the openwrt directory.

Started over, and begun compiling again. Hopefully it's just a glitch, and this next build will be fine. Time will tell.

I just built trunk "DESIGNATED DRIVER (Bleeding Edge, r48458)"

And I don't see any of that Radius auth stuff shown in your image above.

(Last edited by kirkgbr on 23 Jan 2016, 17:17)

Makes me wonder if I didn't accidentally add stuff I didn't want.

yes, if you are needing to connect to an existing wifi network it would end up as a client instead of an AP, the key thing is stripping out everything else. that defines the different firewall zones, etc. put the wireless and the wired interfaces (or the two wifi interfaces on separate radios) on the same network, and have that network defined as a bridge.

when you connect as a client you will get dns/dhcp/ntp for the AP, but you don't provide any of these to the network.

To get 5Ghz working, I had to compile without LuCi, and install without keeping settings. Then opkg install luci, and then restore settings from backup.

I haven't been able to get any DFS channels working still

@davidc502: Can you explain "not working"? Chosing a dfs channel will keep the interface down for 1 minute, while it reads for possible radar traffic. It should come online after that.

(Last edited by JohnnySL on 23 Jan 2016, 22:02)

Strange behavior.....  I waited 5 minutes for it to come up. It appeared to be listening, but the wifi analyzer said nothing was being broadcasted. Walked over to the iphone, and it sees 5Ghz, but on another channel. I had originally set it for channel 120, but it actually started broadcasting on 36.

Was this because it found other signals, and went to 36? Wouldn't think so since I'm probably 15 or more miles for a airport.

Initially the Android couldn't see the broadcasts, but the iphone could. So, I tried channel 100, and after about 60 seconds it came up on channel 100. Both Android and iphones could join no problem.

So, I don't know why it is working now when it wasn't the last 2 times I tried. It might be a little buggy still?

(Last edited by davidc502 on 23 Jan 2016, 23:17)

The wrong signal is a known issue. according to standards the wireless channel should be changed if it sees radar. The problem with the current driver is that it (eventually) *always* sees radar and then usually switches to channel 36 (lowest non DFS channel).

So what you see is all known and (im)proper behavior.
(tracked here: https://github.com/kaloz/mwlwifi/issues/57)

I've currently build my own rather blunt work-around, which keeps the channel where i want it to be.

(Last edited by JohnnySL on 24 Jan 2016, 00:09)

Hey everyone, quick question..  Can I still build / patch version .13 of the mwlwifi driver to work with the latest trunk snapshots?  I "thought" read some pages back that .13 is fubar'd.  I'm asking because I'm seeing degraded performance with the .16 driver, so needless to say, .13 still seems to give the best results.

Thanks,

Mike

You can still build it(.13)  but from my experience, it doesn't perform nearly as well as it used to.  I don't know what changed but something affects it negatively with latest trunk.

Just a observations about the latest trunk snapshot -- I'm wondering if beamforming is working correctly. Last night I had 5 devices downstairs, and 1 upstairs, all on 5Ghz. Downstairs all 5 devices were getting degraded service, but upstairs speeds were great (router is downstairs). Tested downstairs, and was getting 20mbps, and walked upstairs near the other device, and had no problems pulling in 100mbps.

Has anyone run across this type of problem before?

(Last edited by davidc502 on 24 Jan 2016, 15:42)