OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

kirkgbr wrote:

If you don't mind me asking, what utility do you use to measure your speeds?

For the wireless number I'm just using the reported file transfer rate from Windows 7.  I have a media center bridged with another WRT1900AC-V1, and that's transferring a video file.  Every machine I have running Linux is wired, so no iperf.

I may set up a test with the routers in the same room -- in this case they're one floor apart and half a house away.

dpdurst wrote:
jmschu02 wrote:
dpdurst wrote:

Ok so this is strange I have the CC software loaded and its kind of working. However in the wireless network interfaces it has a password of the router and not my password for the wireless. I can change it but once I save it, it reverts back to the password for the router and won't keep the actual wireless pass. Is there a way to clear this out or clear the configuration files? I have tried several times to reflash and not save settings but still the password does not remove itself

I should clarify just in case, the key for the wireless security won't take

This shows up in the logs over and over for all my wireless connections

an  6 00:02:34 2015 daemon.info hostapd: wlan0: STA e8:ab:fa:02:83:65 IEEE 802.11: deauthenticated due to local deauth request
Tue Jan  6 00:02:35 2015 daemon.info hostapd: wlan0: STA e8:ab:fa:02:83:65 IEEE 802.11: associated (aid 3)
Tue Jan  6 00:02:37 2015 daemon.info hostapd: wlan0: STA e8:ab:fa:0b:42:32 IEEE 802.11: associated (aid 1)
Tue Jan  6 00:02:37 2015 daemon.info hostapd: wlan0: STA 9c:2a:70:06:b8:66 IEEE 802.11: deauthenticated due to local deauth request
Tue Jan  6 00:02:38 2015 daemon.info hostapd: wlan0: STA e8:ab:fa:02:83:65 IEEE 802.11: disassociated
Tue Jan  6 00:02:39 2015 daemon.info hostapd: wlan0: STA e8:ab:fa:0d:eb:3b IEEE 802.11: associated (aid 4)
Tue Jan  6 00:02:39 2015 daemon.info hostapd: wlan0: STA 9c:b6:54:9d:d5:2a IEEE 802.11: deauthenticated due to local deauth request
Tue Jan  6 00:02:41 2015 daemon.info hostapd: wlan0: STA 9c:b6:54:9d:d5:2a IEEE 802.11: associated (aid 2)

SSH into the router and then type "vi /etc/config/wireless"
then hit "i" to edit it change the passphrase to anything you want.

Then hit "ESC" then "ZZ"
Now type "wifi" this will reload the wifi config, enjoy

Well while you were replying I loaded up AA and then reloaded CC with without saving settings the password takes now and the wireless devices are online. Viewing the config file shows the right password, however in Luci she still shows the login password to the router. Something is still not exactly correct. It would be nice to find a way to default all config files to make sure.

The WiFi key being set to the device's login password for me too. I'm really confused by this behaviour. I think that I was able to use the scripts to do a get of the configuration values and it says the correct key. However (Android) devices can only connect using the device password and not the key.

To add further confusion I have a second TP-Link TL-WDR3600 running a similar level of software that seems to be working fine. That caused no end of confusion with devices failing to connect for a while due to authentication problems then hopping back to the unit they could work with. Once I'd tried disabling both 5Ghz and WMM Mode to try and get things to connect happily I finally turned off a unit and worked out that only 1 of them is taking Connections!

Sorry, long rambling post. Did this get worked out somewhere? I've not spotted a suggestion of what I should try next.

hello,

i have a problem with laggy internet with surface pro 4. with a surface 2 the ping avg. ms are about 5ms, with the surface pro 4 about 330ms. whats wrong?
all other devices (android) don't have that lags. any ideas?

thx & so long

ps: wrt1200ac with 15.05 final and .16 wifi driver

To confirm performance issues aren't related to the spinlock to mutex change try the below driver for comparison:
McDebian mwlwifi

You should be able to backup your existing mwlwifi.ko to mwlwifi.ko.bak and copy the McDebian driver in for comparison testing.

Make sure AC is disabled on the 2.4Ghz

(Last edited by Chadster766 on 16 Jan 2016, 17:51)

Chadster766 wrote:

To confirm performance issues aren't related to the spinlock to mutex change try the below driver for comparison:
McDebian mwlwifi

You should be able to backup your existing mwlwifi.ko to mwlwifi.ko.bak and copy the McDebian driver in for comparison testing.

Make sure AC is disabled on the 2.4Ghz

thx! but i have kernel 3.18.20?
can i test .13, too? is there spinlock mode?

thx!

so long

edit: .13 wifi driver fixed it... puh hmm I am getting mad with that router hmm

(Last edited by trustno1foxm on 16 Jan 2016, 18:10)

Stupid question, but I have to ask...  If I want to build DD with the 4.4 FINAL kernel, do I need to modify 'include/kernel-version.mk' ?  Or, do I leave it as is and modify 'target/linux/mvebu/Makefile' to build 4.4 ?  Thanks.

Mike

@mmcneil

Just leave it as it is.

nitroshift

(Last edited by nitroshift on 16 Jan 2016, 18:46)

trustno1foxm wrote:
Chadster766 wrote:

To confirm performance issues aren't related to the spinlock to mutex change try the below driver for comparison:
McDebian mwlwifi

You should be able to backup your existing mwlwifi.ko to mwlwifi.ko.bak and copy the McDebian driver in for comparison testing.

Make sure AC is disabled on the 2.4Ghz

thx! but i have kernel 3.18.20?
can i test .13, too? is there spinlock mode?

thx!

so long

edit: .13 wifi driver fixed it... puh hmm I am getting mad with that router hmm

The mutex change was commited with driver version 10.3.0.15

(Last edited by Chadster766 on 16 Jan 2016, 18:59)

ok thx, .15 i haven't ever tried. what can I do? hmm

I can live with .13 but I need a second ssid on a radio, but this bug hasn't been fixed yet. I can't use newer drivers becaus of mutex? hmm

(Last edited by trustno1foxm on 16 Jan 2016, 19:00)

trustno1foxm wrote:

ok thx, .15 i haven't ever tried. what can I do? hmm

Update your OpenWRT to the latest version and then you can test with the .16 McDebian driver if you like.

Keep in mind that the mutex change might not be the issue and the testing I'm suggesting be done is for a confirmation.

(Last edited by Chadster766 on 16 Jan 2016, 19:03)

@Chadster766

r48251 @ 4.4.0 with .16

5GHz @ channel 153 and VHT80

iperf3 -c 192.168.1.1 -P6 -t 600

[SUM]   0.00-600.00 sec  21.0 GBytes   300 Mbits/sec                  sender
[SUM]   0.00-600.00 sec  21.0 GBytes   300 Mbits/sec                  receiver

Cheers

doITright wrote:

@Chadster766

r48251 @ 4.4.0 with .16

5GHz @ channel 153 and VHT80

iperf3 -c 192.168.1.1 -P6 -t 600

[SUM]   0.00-600.00 sec  21.0 GBytes   300 Mbits/sec                  sender
[SUM]   0.00-600.00 sec  21.0 GBytes   300 Mbits/sec                  receiver

Cheers

That's pretty good speeds but unless I'm mistaken others are posting performance issues with .16

AFAIK a CPU thread locking delay (mutex vs spinlock) would appear only with more connected clients and possibly they need to be on both frequencies.

(Last edited by Chadster766 on 16 Jan 2016, 19:12)

Ping latency/jitters are still an issue for me as well....

Severity seems to be totally device/client dependent... 

Can be cleared for a bit by bouncing wifi but comes back....

Cheers

doITright wrote:

Ping latency/jitters are still an issue for me as well....

Severity seems to be totally device/client dependent... 

Can be cleared for a bit by bouncing wifi but comes back....

Cheers

Can you test as outlined below:
https://forum.openwrt.org/viewtopic.php … 54#p307854

r48259 / .16 4.4.0 5ghz
root@OpenWrt:~# iperf3 -c 192.168.1.131 -P6 -t 60
Connecting to host 192.168.1.131, port 5201
[SUM]   0.00-60.01  sec  2.55 GBytes   365 Mbits/sec   67             sender
[SUM]   0.00-60.01  sec  2.54 GBytes   364 Mbits/sec                  receiver

root@OpenWrt:~# iperf3 -c 192.168.1.131 -P6 -t 60 -R
Connecting to host 192.168.1.131, port 5201
[SUM]   0.00-60.01  sec  3.02 GBytes   432 Mbits/sec                  sender
[SUM]   0.00-60.01  sec  3.02 GBytes   432 Mbits/sec                  receiver

.13 is FUBARED on 4.4. mac80211?

C:\iperf3>iperf3 -c 192.168.1.1 -P6 -t 60
Connecting to host 192.168.1.1, port 5201
[SUM]   0.00-60.01  sec  2.43 GBytes   348 Mbits/sec                  sender
[SUM]   0.00-60.01  sec  2.43 GBytes   348 Mbits/sec                  receiver
C:\iperf3>iperf3 -c 192.168.1.1 -P6 -t 60 -R
Connecting to host 192.168.1.1, port 5201
[SUM]   0.00-60.00  sec  2.73 GBytes   390 Mbits/sec   31             sender
[SUM]   0.00-60.00  sec  2.72 GBytes   390 Mbits/sec                  receiver

(Last edited by northbound on 17 Jan 2016, 03:47)

Chadster766 wrote:
doITright wrote:
Chadster766 wrote:

Can you test as outlined below:
https://forum.openwrt.org/viewtopic.php … 54#p307854

Will do and will advise

Cheers

Thanks smile

Not bad at all.... 4.4.0 @ r48251 with the McDebian mwlwifi

1. latency/jitter is still there
2. Tx is better than Rx @ 5GHz (300 Mbits/s vs 200 Mbits/s) not sure why...  will test further
3. @ 2.4 GHz with an N client, I managed to transfer a file at ave 11 MB/s (a new record with peak north of 12.5 MB/s)

Why is the McDebian mwlwifi.ko so much larger @ 1.6 MB?

Cheers

doITright wrote:

Not bad at all.... 4.4.0 @ r48251 with the McDebian mwlwifi

1. latency/jitter is still there
2. Tx is better than Rx @ 5GHz (300 Mbits/s vs 200 Mbits/s) not sure why...  will test further
3. @ 2.4 GHz with an N client, I managed to transfer a file at ave 11 MB/s (a new record with peak north of 12.5 MB/s)

Why is the McDebian mwlwifi.ko so much larger @ 1.6 MB?

Cheers

Thanks for testing it. Odd about the file size. I will look into it.

Hello. I've install OpenWrt Chaos Calmer 15.05/LuCI (git-15.248.30277-3836b45), kernel 3.18.20.
On the basis of the article http://wiki.openwrt.org/ru/doc/howto/pr … ver-p910nd the  printer HP LJ 1020 was successfully installed.
However there is a cyclic printing of the first document. What's the problem?

Core Log:
[637577.140104] usb 2-2: new high-speed USB device number 2 using xhci_hcd
[637577.318276] usblp 2-2:1.0: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
[637931.250806] usblp0: nonzero read bulk status received: -71
[637931.256429] usblp0: nonzero write bulk status received: -71
[637931.263984] usb 2-2: USB disconnect, device number 2
[637931.269406] usblp0: removed
[637935.555202] usb 2-2: new high-speed USB device number 3 using xhci_hcd
[637935.720082] usblp 2-2:1.0: usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
[637995.897892] usb 2-2: USB disconnect, device number 3
[637995.903658] usblp0: removed
[637997.936103] usb 2-2: new high-speed USB device number 4 using xhci_hcd
[637998.101805] usblp 2-2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
[638052.155045] usb 2-2: USB disconnect, device number 4
[638052.160436] usblp0: removed

System Log:
Sun Jan 17 19:49:38 2016 lpr.notice p9100d[1070]: Connection from 192.168.1.2 port 51181 accepted
Sun Jan 17 19:49:38 2016 lpr.err p9100d[1070]: read: Connection reset by peer
Sun Jan 17 19:49:38 2016 lpr.notice p9100d[1070]: Finished job: 38353/38353 bytes sent to printer
Sun Jan 17 19:49:38 2016 lpr.err p9100d[1070]: copy_stream: Connection reset by peer
Sun Jan 17 19:49:48 2016 kern.info kernel: [637995.897892] usb 2-2: USB disconnect, device number 3
Sun Jan 17 19:49:48 2016 kern.info kernel: [637995.903658] usblp0: removed
Sun Jan 17 19:49:50 2016 kern.info kernel: [637997.936103] usb 2-2: new high-speed USB device number 4 using xhci_hcd
Sun Jan 17 19:49:50 2016 kern.info kernel: [637998.101805] usblp 2-2:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
Sun Jan 17 19:50:00 2016 cron.info crond[1041]: USER root pid 16405 cmd /sbin/fan_ctrl.sh
Sun Jan 17 19:50:26 2016 lpr.notice p9100d[1070]: Connection from 192.168.1.2 port 51480 accepted
Sun Jan 17 19:50:33 2016 lpr.notice p9100d[1070]: Connection from 192.168.1.2 port 51543 accepted
Sun Jan 17 19:50:33 2016 lpr.err p9100d[1070]: read: Connection reset by peer
Sun Jan 17 19:50:33 2016 lpr.notice p9100d[1070]: Finished job: 29609/29609 bytes sent to printer
Sun Jan 17 19:50:33 2016 lpr.err p9100d[1070]: copy_stream: Connection reset by peer
Sun Jan 17 19:50:33 2016 lpr.notice p9100d[1070]: Connection from 192.168.1.2 port 51544 accepted
Sun Jan 17 19:50:34 2016 lpr.err p9100d[1070]: read: Connection reset by peer
Sun Jan 17 19:50:34 2016 lpr.notice p9100d[1070]: Finished job: 29609/29609 bytes sent to printer
Sun Jan 17 19:50:34 2016 lpr.err p9100d[1070]: copy_stream: Connection reset by peer
Sun Jan 17 19:50:34 2016 lpr.notice p9100d[1070]: Connection from 192.168.1.2 port 51552 accepted
Sun Jan 17 19:50:34 2016 lpr.err p9100d[1070]: read: Connection reset by peer
Sun Jan 17 19:50:34 2016 lpr.notice p9100d[1070]: Finished job: 4193/4193 bytes sent to printer
Sun Jan 17 19:50:34 2016 lpr.err p9100d[1070]: copy_stream: Connection reset by peer

Thanks for your support.

RickStep wrote:

Perhaps I am missing something.

First my comments are NOT about speciality business or university services to get access to the Internet; but using "off the shelf retail providers".

The country where modem is and the service provider for that modem WILL be known to anything below it; router, access point and moved along with every router and switch added.

The only exception to that will be if there is NO modem in the setup.

As far as Netflix is concerned; IF I tunnel into the US to access a US server; Netflix sees the US server and the server transfers the movie to me in Canada.  However my WRT1900AC v1 MUST go through the Bell modem to the first stop which is a Bell server, in Canada. The chances of spoofing that first leg is zero; at which point the game is up.

I have access to Bell Canada and Cogeco Cable and many re-sellers from each. All of those re-sellers MUST go through Bell or Cogeco, and I can't see either of them allowing any re-seller to pretend that they are from a different country.  The only other options are Cell networks or Satellite, neither of which are economical. Cell is trackable; Satellite may be the easiest to spoof.

So unless you can remove Canadian hardware from the loop, any router could have the capability built in to determine the country where you reside; Satellite excepted; if there is a modem in the loop.

You are missing something

1. Only the modem knows what IP address the ISP gave it

1a. some ISPs give out 10.x or 192.168.x IP addresses

2. Trying to find out what IP address you have by connecting to a server on the Internet and asking it what IP address you connected from can be subverted via VPN setups.

So trying to enforce country codes based on what IP address you think you have on your WAN connection will not prevent people from lying to the AP if they think it will benefit them. I may make it harder, but it won't prevent them.

Your rant about having Canadian hardware in the loop is meaningless, the AP is not asking that hardware what IP addresses it has, and even if there was a standard way to figure out who to ask and how to ask, nothing would prevent some other equipment from responding instead of the Canadian hardware and lying to you.

Chadster766 wrote:
doITright wrote:

Not bad at all.... 4.4.0 @ r48251 with the McDebian mwlwifi

1. latency/jitter is still there
2. Tx is better than Rx @ 5GHz (300 Mbits/s vs 200 Mbits/s) not sure why...  will test further
3. @ 2.4 GHz with an N client, I managed to transfer a file at ave 11 MB/s (a new record with peak north of 12.5 MB/s)

Why is the McDebian mwlwifi.ko so much larger @ 1.6 MB?

Cheers

Thanks for testing it. Odd about the file size. I will look into it.

The file size difference is only because I haven't stripped the debugging symbols from the module.

It's actually a pretty good day wink

Just a observation... after about 5 days of uptime, I noticed wifi speeds drop off significantly. Example: Android S5 on 5Ghz had no issues pulling 100mbps on the ookla speed test. However after about 5 days, it was hard just to get 30mbps on the speedtest.

After a quick reboot, tests showed fast speeds like they were before.

This is on r48158 with .16 wifi driver.

Anyone else noticing this?  BTW -- Nothing in the logs to indicate any problems.