root@OpenWrt:~# echo 255 > /sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1
-ash: can't create /sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1: nonexistent directory
root@OpenWrt:~# echo 0 > /sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1
-ash: can't create /sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1: nonexistent directory
root@OpenWrt:~#
crooked rose firmware ?!

(Last edited by Armik on 27 Dec 2015, 19:32)

I'm sorry to hear that, and it's one of the reasons why FCC has proposed to lock down all router firmware, from the factory.  It's unknown if hardware manufacturers will be able to create wifi hardware which will keep opensource firmware from being able to circumvent regulations. If they can't, then that will be the end of OpenWrt/DDT/Tomato etc on Wifi Routers. However, it may be possible for Opensource to remain on Non Wifi devices.

(Last edited by davidc502 on 27 Dec 2015, 19:35)

Personally I don't give a rat's behind about FCC regulations, as i'm from Europe. That doesn't mean i agree with breaking the law either. That is why i'm still waiting for a fix Marvell. It seems to be another "low priority" one though

@Armik
On a 4.4 build that would be the expected location of the fan device. What does the tree look like? Is pwm1 to be found? What build did you flash? The default fan script has the two known locations and it test for which to use.

the fan does not work, even when booting, firmware compiled himself

@Armik, could you please cut/paste output from running each of the following commands on your router;

uname -a
cat /etc/openwrt_release
cat /tmp/sysinfo/board_name
cat /tmp/sysinfo/model
opkg list | grep hwmon

The fan is working perfectly on my build of DD R47968 with kernel 4.4rc5, running on WRT1900AC V1 hardware
Here is what the output looks like from my router.

uname -a

root@OpenWrt:~# uname -a
Linux OpenWrt 4.4.0-rc5 #3 SMP Thu Dec 24 06:51:02 MST 2015 armv7l GNU/Linux

cat /etc/openwrt_release

root@OpenWrt:~# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r47968'
DISTRIB_CODENAME='designated_driver'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Designated Driver r47968'
DISTRIB_TAINTS='no-all busybox'

cat /tmp/sysinfo/board_name

root@OpenWrt:~# cat /tmp/sysinfo/board_name 
armada-xp-linksys-mamba

cat /tmp/sysinfo/model

root@OpenWrt:~# cat /tmp/sysinfo/model
Linksys WRT1900AC

opkg list | grep hwmon

root@OpenWrt:~# opkg list | grep hwmon
kmod-hwmon-core - 4.4-rc5-1
kmod-hwmon-pwmfan - 4.4-rc5-1
kmod-hwmon-tmp421 - 4.4-rc5-1

(Last edited by wrtpat on 27 Dec 2015, 21:29)

root@OpenWrt:~# uname -a
Linux OpenWrt 4.4.0-rc5 #1 SMP Sat Dec 26 15:15:23 MSK 2015 armv7l GNU/Linux

root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r48005'
DISTRIB_CODENAME='designated_driver'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Designated Driver r48005'
DISTRIB_TAINTS='no-all'

root@OpenWrt:~# cat /tmp/sysinfo/board_name
armada-xp-linksys-mamba

root@OpenWrt:~# cat /tmp/sysinfo/model
Linksys WRT1900AC

root@OpenWrt:~# opkg list | grep hwmon
kmod-hwmon-core - 4.4-rc5-1
kmod-hwmon-tmp421 - 4.4-rc5-1

You're missing the pwmfan module from your build.

Now he saw all thanks

What he said

What are the chances of getting the NAND timeout fix integrated into trunk?

Does the trunk build from December 10th for the 1900acs (shelby) include the patch?

Needing to know if it's best to compile trunk with the patch then flash when I get my router Tuesday.

It would cure a lot of peoples' ills...

Patchset is not in DD, but probably a bigger issue is that the mvebu builds have been failing and do not have the latest mwlwifi from 151216. If you want the 990 patch and latest mwlwifi you will have to byo.

Are the un-updated mwlwifi and absence of the 990 patch in the latest builedbot build the only major issues?

What problems would I have if I just flashed the December 10th build rather building trunk with the 990 patch?

I have the latest trunk as of yesterday, which includes the mwlwifi fix as of a week ago. Is that what you're talking about?

And what do you mean when you say the builds have been failing? That the buiilddbot fails to build mvebu?

(Last edited by WizKid on 28 Dec 2015, 00:53)

Yes, but if you byo it is in the current DD change set so you do not have to get it explicitly, other than have your build tree current.
Whatever the current issues are I suppose, minor stuff.
That is the date of the last mwlwifi change from the mwlwifi github;i.e. it is not a change set.
http://buildbot.openwrt.org:8010/
https://dev.openwrt.org/timeline
And if you're not there and so inclined try: irc #openwrt

(Last edited by anomeome on 28 Dec 2015, 00:57)

The nand patch wasn't included, in trunk, a few days ago, but might be now. I just compiled with the patch, and it fixed the issue.

You probably want to compile your own, but I did compile for shelby too. Let me know, and I can put up the .bin on the web.

(Last edited by davidc502 on 28 Dec 2015, 01:36)

So... just to reiterate, we shouldn't flash the latest trunk builds because its missing the 990 patch? Builldbot successfully built last night (Dec 28th r48005) and uploaded the images unlike the build a day or two before. I'm running the last successful build from before the 4.1.* kernel was merged (r47817).

I first compiled r48005 without the 990 nand patch, and the router booted just fine -- the first time   In my case it did boot back up after 3 tries, but the next time it never booted back up, and failed over to the secondary flash.

Since compiling with the 990 nand patch, there hasn't been any issues booting. I'd have to say that r48005 with the latest .15 driver has been good. Since RC3 came out, that has been my 'go to' image, but it looks like this version will take its place.

To answer your question, I don't recommend flashing without 990 nand patch.

(Last edited by davidc502 on 28 Dec 2015, 04:27)

Thanks David. I'll wait for a fix

r47817 has been running fine for me so I'm in no hurry.

BTW still no response to your ticket regarding this issue?

Edit: sorry that was someone else https://dev.openwrt.org/ticket/21404

(Last edited by listerwrt on 28 Dec 2015, 04:55)

Actually Kong has implemented DFS by himself in his more recent DD-WRT builds for the WRT1200AC / WRT1900AC / WRT1900ACv2 and WRT1900ACS.

Perhaps Kaloz should take a look at Kong's DFS implementation, and find a work around.

Hi Everyone,

I've noticed that my WRT1900AC V2's eth0 interface doesn't have a manufacture assigned MAC Address. This is causing issues with a new firmware\system I'm customising. I think this is causing eth0 get a new random MAC Address every reboot.

Can some with a WRT1900\1200 run the below command for comparison:

root@MCDEBIAN:~# ethtool -P eth0
Permanent address: 00:00:00:00:00:00

OpenWRT could also be effected check your u-boot console output:

mvneta f1034000.ethernet eth0: Using random mac address

(Last edited by Chadster766 on 28 Dec 2015, 16:30)

v1 output --   root@OpenWrt:~# ethtool -P eth0
Permanent address: 00:00:00:00:00:00

There is the override mac address for ethernet0. does it not work as expected?

(Last edited by davidc502 on 28 Dec 2015, 16:48)

I'm running Debian which wouldn't have any OpenWRT scripts. Just before your reply I found the OpenWRT script that sets the eth0 MAC Address from the Linksys devinfo MTD partition.

06_set_iface_mac

Thanks for the reply

That would be nice. Please upload, along with the config used.

I just downloaded today's prebuilt DD build, but am afraid to flash it for fear that it doesn't include the patch and the .15 driver.

Heck, I haven't even received the router yet (coming today, one day early )

(Last edited by WizKid on 28 Dec 2015, 19:47)

Where is the script, and how does one change the MAC address for ethic on the devinfo partition?

Isn't eth0 the WAN port?