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.

Page 368 of 598

Post #9176

nyt

23 Dec 2015, 03:57

fixed qos/tc issue by building iproute2-4.3.0

Post #9177

doITright

23 Dec 2015, 04:01

wrtpat wrote:

doITright wrote:
...
Does any one have issues with the 5GHz radio on 4.4rc5 with .15 driver?
Not staying up and logs don't show anything....
Could you explain in more detail, what "Not staying up" means?
- Are you able to successfully connect a 5Ghz client after initially booting the router up? What is the client?
- When you disconnect that client, can you reconnect that same client?
- Are there other 5Ghz clients concurrently connected/connecting at the time? What are they?
- Once connected, does the client stay connected only for a time, and then disconnects? Or does it stay connected until you explicitly disconnect?
Just trying to get a sense for what "Not staying up" means here.
BTW, I'm on a similar config and I have zero issues with clients connecting, staying connected, disconnecting/reconnecting, etc.... all good here.

sorry... should have been more specific....

it does not show up when in ac mode via luci.... with n only mode is set in luci it is fine, and I can connect....

the config below is with the setting (in luci) set to N...

notice that hwmode is 11a just like earlier while in ac... very weird....

config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/00
option country 'CA'
option hwmode '11a'
option channel '161'
option htmode 'HT40'
option txpower '24'

config wifi-iface
option device 'radio1'
option mode 'ap'
option network 'lan'
option encryption 'psk2'
option key 'xxxxxxxxxxxxx'
option ssid 'WRT1900AC-P5GHz'

So the question is what should the hwmode be set to for ac?

Cheers

(Last edited by doITright on 23 Dec 2015, 04:02)

Post #9178

nyt

23 Dec 2015, 04:05

doITright wrote:

wrtpat wrote:
doITright wrote:
...
Does any one have issues with the 5GHz radio on 4.4rc5 with .15 driver?
Not staying up and logs don't show anything....
Could you explain in more detail, what "Not staying up" means?
- Are you able to successfully connect a 5Ghz client after initially booting the router up? What is the client?
- When you disconnect that client, can you reconnect that same client?
- Are there other 5Ghz clients concurrently connected/connecting at the time? What are they?
- Once connected, does the client stay connected only for a time, and then disconnects? Or does it stay connected until you explicitly disconnect?
Just trying to get a sense for what "Not staying up" means here.
BTW, I'm on a similar config and I have zero issues with clients connecting, staying connected, disconnecting/reconnecting, etc.... all good here.
sorry... should have been more specific....
it does not show up when in ac mode via luci.... with n only mode is set in luci it is fine, and I can connect....
the config below is with the setting (in luci) set to N...
notice that hwmode is 11a just like earlier while in ac... very weird....
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/00
option country 'CA'
option hwmode '11a'
option channel '161'
option htmode 'HT40'
option txpower '24'
config wifi-iface
option device 'radio1'
option mode 'ap'
option network 'lan'
option encryption 'psk2'
option key 'xxxxxxxxxxxxx'
option ssid 'WRT1900AC-P5GHz'
So the question is what should the hwmode be set to for ac?
Cheers

11a

Post #9179

doITright

23 Dec 2015, 04:10

lol...

I just set it back to ac (from n) in luci and now it works....

hwmode is still 11a.... I guess it was just a gremlin eh?

Cheers

Post #9180

nyt

23 Dec 2015, 05:31

uploaded patch for qos-scripts tc issue (iproute2 updated)

https://dev.openwrt.org/ticket/21374

Post #9181

wrtpat

23 Dec 2015, 06:08

wrtpat wrote:

kirkgbr wrote:
@wrtpat, looks like the fixed the missing dependencies for thermal_sys.ko.
https://dev.openwrt.org/ticket/21430
@kirkgbr, thanks for the heads-up....
Yes, I saw that. I was just git cloning a fresh build root, to give it a try.

Nope, my build still fails.
Looks like they fixed the dependency for the hwmon-gpiofan kernel module. But not the hwmon-pwmfan kernel module.
We don't require/build the gpiofan module on the wrt1900ac, do we? So, why would we config it 'on' and build it.
Upon initial 'make menuconfig', when we set Target System = Marvell Armada 37x/38x/XP and Target Profile = Linksys WRT1900AC (Mamba), it causes the following kernel module dependencies to be turned on (or selected);
kmod-hwmon-core
kmod-hwmon-pwmfan
kmod-hwmon-tmp421

kmod-hwmon-gpiofan is NOT selected. Nor do I see a need for it.... or am I missing something.

Bottom line, I think the same fix that was implemented in ticket 21430 (for the gpiofan kmod) should also be implemented for the pwmfan kmod.

Thus... this section of package/kernel/linux/modules/hwmon.mk

define KernelPackage/hwmon-pwmfan
  TITLE:=Generic PWM FAN support
  KCONFIG:=CONFIG_SENSORS_PWM_FAN
  FILES:=$(LINUX_DIR)/drivers/hwmon/pwm-fan.ko
  AUTOLOAD:=$(call AutoLoad,60,pwm-fan)
  $(call AddDepends/hwmon,)
endef

should become

define KernelPackage/hwmon-pwmfan
  TITLE:=Generic PWM FAN support
  KCONFIG:=CONFIG_SENSORS_PWM_FAN
  FILES:=$(LINUX_DIR)/drivers/hwmon/pwm-fan.ko
  AUTOLOAD:=$(call AutoLoad,60,pwm-fan)
  $(call AddDepends/hwmon,+PACKAGE_kmod-thermal:kmod-thermal)
endef

After making that change, my build completes successfully.

(Last edited by wrtpat on 23 Dec 2015, 06:11)

Post #9182

nitroshift

23 Dec 2015, 06:32

@wrtpat

+kmod-thermal will do instead of +PACKAGE_kmod-thermal:kmod-thermal

nitroshift

Post #9183

kirkgbr

23 Dec 2015, 06:51

nitroshift wrote:

@wrtpat
+kmod-thermal will do instead of +PACKAGE_kmod-thermal:kmod-thermal
nitroshift

Well something is still wrong, at least for my latest build. Even after making those mods to the "package/kernel/linux/modules/hwmon.mk" file, my build completes but when flashed, neither the provided "/sbin/fan_ctrl.sh" or gufus's fan scripts are working. Seems the path's for temps and pwm are wrong, different, or missing.

Back to the drawing board...

Post #9184

trustno1foxm

23 Dec 2015, 08:30

@muronghan would you be so kind and take apart: https://github.com/kaloz/mwlwifi/issues/54

I don't want to be the only one with the weird problem

thx!

so long

Post #9185

johan81

23 Dec 2015, 10:11

I just bought myself a Linksys WRT1200AC and am verry happy with it, what a performance! Though I have a question about flashing firmwares.
In the Wiki it states to always revert back to stock before upgrading, if it is really a wise thing to do, I will, but I wanted to know if people with the WRT1200AC/WRT1900AC have experiences to counter this "rule".

Post #9186

nyt

23 Dec 2015, 10:31

I've never flashed back to stock

Post #9187

HomerSp

23 Dec 2015, 11:45

johan81 wrote:

I just bought myself a Linksys WRT1200AC and am verry happy with it, what a performance! Though I have a question about flashing firmwares.
In the Wiki it states to always revert back to stock before upgrading, if it is really a wise thing to do, I will, but I wanted to know if people with the WRT1200AC/WRT1900AC have experiences to counter this "rule".

Flashing back to stock before flashing openwrt is not required, but doing so will make sure the backup firmware always contains stock, so in case there are any problems you can always revert to stock. Of course if you have ssh access in openwrt you can always write to kernel1 and kernel2 using mtd, that will make sure both the primary and backup firmware are the same.

Post #9188

nitroshift

23 Dec 2015, 12:47

For those who have build failures due to the hwom-pwmfan module:

https://dev.openwrt.org/changeset/47968

nitroshift

Post #9189

wrtpat

23 Dec 2015, 13:34

kirkgbr wrote:

nitroshift wrote:
@wrtpat
+kmod-thermal will do instead of +PACKAGE_kmod-thermal:kmod-thermal
nitroshift
Well something is still wrong, at least for my latest build. Even after making those mods to the "package/kernel/linux/modules/hwmon.mk" file, my build completes but when flashed, neither the provided "/sbin/fan_ctrl.sh" or gufus's fan scripts are working. Seems the path's for temps and pwm are wrong, different, or missing.
Back to the drawing board...

Right, there were pathing changes in 4.x kernels. The out-of-box fan_ctrl.sh script was updated to deal with old & new kernels.
If you're using a fan control script from an image based on an older kernel, you may need to fix it up.
I'm on DD R47197 w/ kernel 4.4 rc5. My fan_ctrl.sh script is working fine.

/sbin/fan_ctrl.sh

#!/bin/sh

CPU_TEMP=`cut -c1-2 /sys/class/hwmon/hwmon2/temp1_input`
DDR_TEMP=`cut -c1-2 /sys/class/hwmon/hwmon1/temp1_input`
WIFI_TEMP=`cut -c1-2 /sys/class/hwmon/hwmon1/temp2_input`

CPU_LOW=60
CPU_HIGH=65
DDR_LOW=65
DDR_HIGH=75
WIFI_LOW=100
WIFI_HIGH=115

if [ -d /sys/devices/pwm_fan ];then
    FAN_CTRL=/sys/devices/pwm_fan/hwmon/hwmon0/pwm1
elif [ -d /sys/devices/platform/pwm_fan ];then
    FAN_CTRL=/sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1
else
    exit 0
fi

if [ "$CPU_TEMP" -ge "$CPU_HIGH" -o "$DDR_TEMP" -ge "$DDR_HIGH" -o "$WIFI_TEMP" -ge "$WIFI_HIGH" ];then
    echo "255" > $FAN_CTRL
elif [ "$CPU_TEMP" -ge "$CPU_LOW" -o "$DDR_TEMP" -ge "$DDR_LOW" -o "$WIFI_TEMP" -ge "$WIFI_LOW" ];then
    echo "100" > $FAN_CTRL
else
    echo "0" > $FAN_CTRL
fi

Post #9190

wrtpat

23 Dec 2015, 13:34

nitroshift wrote:

For those who have build failures due to the hwom-pwmfan module:
https://dev.openwrt.org/changeset/47968
nitroshift

Thanks for doing that

Post #9191

kirkgbr

23 Dec 2015, 15:23

Well, I may have bricked my 1900ac... <argh>

Already tried the 3 power off/on thing and it wont return to previous firmware. All I get is the slow blinking power light.

Post #9192

wrtpat

23 Dec 2015, 15:55

kirkgbr wrote:

Well, I may have bricked my 1900ac... <argh>
Already tried the 3 power off/on thing and it wont return to previous firmware. All I get is the slow blinking power light.

Sorry to hear this.
I bricked mine whilst performing science experiments, trying to understand the nand timeout issues. So had to break out the TTL cable.
Unfortunately, It's one of those "It's a matter of when, not if" things. If you wanna play with bleeding edge, you're gonna need a TTL cable at some point.
You do have one.... right?

(Last edited by wrtpat on 23 Dec 2015, 15:56)

Post #9193

doITright

23 Dec 2015, 16:01

doITright wrote:

davidc502 wrote:
Thanks -- and be sure to report back ping times for wireless.
Seems I have some good news at least.... 4.4rc5 (r47961) @ .15 from 20151215
This is via my wireless bridge! pc -> WRT54GS -> bridge 2.4 GHz -> WRT1900AC -> NAS
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Pinging 192.168.1.20 with 32 bytes of data:
Reply from 192.168.1.20: bytes=32 time=3ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=4ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Granted... last time I tried this it was over the 5GHz bridge using two 1900ACs... so not apples to apples but beats 20 + ms
Cheers

Well.... got my 5GHz bridge back up and the results are not promising...

pc -> WRT1900AC (stock) -> bridge 5.0 GHz -> WRT1900AC (4.4rc5) -> NAS

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=25ms TTL=64
Reply from 192.168.1.1: bytes=32 time=22ms TTL=64
Reply from 192.168.1.1: bytes=32 time=26ms TTL=64
Reply from 192.168.1.1: bytes=32 time=30ms TTL=64
Reply from 192.168.1.1: bytes=32 time=15ms TTL=64
Reply from 192.168.1.1: bytes=32 time=19ms TTL=64
Reply from 192.168.1.1: bytes=32 time=23ms TTL=64
Reply from 192.168.1.1: bytes=32 time=28ms TTL=64

Pinging 192.168.1.20 with 32 bytes of data:
Reply from 192.168.1.20: bytes=32 time=52ms TTL=64
Reply from 192.168.1.20: bytes=32 time=18ms TTL=64
Reply from 192.168.1.20: bytes=32 time=23ms TTL=64
Reply from 192.168.1.20: bytes=32 time=27ms TTL=64
Reply from 192.168.1.20: bytes=32 time=11ms TTL=64
Reply from 192.168.1.20: bytes=32 time=16ms TTL=64
Reply from 192.168.1.20: bytes=32 time=20ms TTL=64
Reply from 192.168.1.20: bytes=32 time=24ms TTL=64

Too lazy to run a cable and willing to live with it in exchange for the higher xfer rates of 5 GHz.

My 2.4 GHz connected pc clients (win 7 and 10) are now seeing 1 to 3 ms consistently vs 20 to 30 ms before.

Cheers

Post #9194

kirkgbr

23 Dec 2015, 16:14

wrtpat wrote:

kirkgbr wrote:
Well, I may have bricked my 1900ac... <argh>
Already tried the 3 power off/on thing and it wont return to previous firmware. All I get is the slow blinking power light.
Sorry to hear this.
I bricked mine whilst performing science experiments, trying to understand the nand timeout issues. So had to break out the TTL cable.
Unfortunately, It's one of those "It's a matter of when, not if" things. If you wanna play with bleeding edge, you're gonna need a TTL cable at some point.
You do have one.... right?

Yep, and never opened it after purchase until now. It's time to find that elusive TFTP recovery page

(Last edited by kirkgbr on 23 Dec 2015, 16:15)

Post #9195

anomeome

23 Dec 2015, 17:11

Had similar occurrence where just connecting the ttl was enough to get the tri-power cycle to work. If not you can also get there by stopping the boot and running:
run (alt)nandboot
depending on where your last good image was.

Post #9196

johan81

23 Dec 2015, 17:28

HomerSp wrote:

johan81 wrote:
I just bought myself a Linksys WRT1200AC and am verry happy with it, what a performance! Though I have a question about flashing firmwares.
In the Wiki it states to always revert back to stock before upgrading, if it is really a wise thing to do, I will, but I wanted to know if people with the WRT1200AC/WRT1900AC have experiences to counter this "rule".
Flashing back to stock before flashing openwrt is not required, but doing so will make sure the backup firmware always contains stock, so in case there are any problems you can always revert to stock. Of course if you have ssh access in openwrt you can always write to kernel1 and kernel2 using mtd, that will make sure both the primary and backup firmware are the same.

I understand and that sounds interesting, would you mind giving me a link to where I can find out how I can flash the secondary backup? I searched, but couldn't find any useful information on it. Thanks!

(Last edited by johan81 on 23 Dec 2015, 17:28)

Post #9197

kirkgbr

23 Dec 2015, 17:52

anomeome wrote:

Had similar occurrence where just connecting the ttl was enough to get the tri-power cycle to work. If not you can also get there by stopping the boot and running:
run (alt)nandboot
depending on where your last good image was.

I always revert to my backup(Linksys) factory image before flashing a new Openwrt build so that Linksys "should" be intact.

I have the router all disassembled but I appear to have the wrong TTL cable. Anyone have a link to a working cable?

Post #9198

anomeome

23 Dec 2015, 18:01

Cable or driver? Any of the cheap ebay 2303 clones should work. But the driver may be an issue, if so:
http://www.ifamilysoftware.com/news37.html
May solve your problem. Also if you have a SoC with a GPIO header that may get you there.

Post #9199

kirkgbr

23 Dec 2015, 18:11

anomeome wrote:

Cable or driver? Any of the cheap ebay 2303 clones should work. But the driver may be an issue, if so:
http://www.ifamilysoftware.com/news37.html
May solve your problem. Also if you have a SoC with a GPIO header that may get you there.

Thanks for the driver link.. I will give it a shot.

Here is the cable i purchased back in June

JBtek® WINDOWS 8 Supported Debug Cable for Raspberry Pi USB Programming USB to TTL Serial Cable

Post #9200

wrtpat

23 Dec 2015, 18:57

kirkgbr wrote:

anomeome wrote:
Cable or driver? Any of the cheap ebay 2303 clones should work. But the driver may be an issue, if so:
http://www.ifamilysoftware.com/news37.html
May solve your problem. Also if you have a SoC with a GPIO header that may get you there.
Thanks for the driver link.. I will give it a shot.
Here is the cable i purchased back in June
JBtek® WINDOWS 8 Supported Debug Cable for Raspberry Pi USB Programming USB to TTL Serial Cable

That should work just fine.
Indeed there are a number of customer testimonials near the bottom of the Amazon page you linked, stating that they've used it to flash the Linksys wrt1900ac. One reviewer even provides a photo showing the TTL cable's connections to the router's serial header.

(Last edited by wrtpat on 23 Dec 2015, 19:12)

Page 368 of 598