OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

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

Hi David,

Thanks the response to my earlier question about 1900ACS rebooting at HD I/Os. I will work on that later per your suggestion.

I got another issue that might be related to the new build: `fsck.hfsplus` from `hfsfsck` does not work. When I use your previous build, `fsck.hfsplus` works. However, after I upgrade to the current build (I also upgraded to kernel 4.9), `fsck.hfsplus` always return "Illegal instruction" on any of my HFS+ volumes.

Hi David and @kkowrt

Thanks for the reply. I upgraded to Kernal 4.9 and it seems like the problem disappears. I will post if it recurs.



davidc502 wrote:
wliao229 wrote:

Hi David,

My WRT1900ACS keeps rebooting when there are frequent HD I/O (e.g., remove or chmod many files). I have been using the previous build (before the current one), and I returned the 1900ACS because I thought it was a hardware defect. Now I got a new 1900ACS and installed the latest build, and the issue occurs again. Do you have any clue of it?

I have been using two different USB hard drive and using HFS+ volumes. the reboot issue typically occurs whenever I rm or chmod a large amount of files on either drives.

@wliao229,

Since this has happened with 2 different units, it appears to be either a bug or configuration issue.

The bug I'm about to mention has already been fixed, but wonder if it's happening again. When rm or chmod a large number of files, can you monitor the memory on the unit, and see what it does? Probably nothing, but just in case.

When doing file transfers does the speed slow down over time or stay consistent? What protocol is being used between clients and the HD?

If you want, there are two places to move this discussion.. 1. is to open up a discussion in the LEDE developers forum 2. would be to open up a case in flyspray once you know it is an existing bug.

(Last edited by wliao229 on 25 Apr 2017, 22:32)

Hi David , 18 hrs on the 4.9 with my WRT3200ACM, 5ghz still up and running .  Thanks for your work smile

By the way, am I the only one who changes the distribution feeds to point to the latest snapshot versions from the lede website to get the absolutest latest versions of packages between releases of @david's builds?

src/gz reboot_core https://downloads.lede-project.org/snapshots/targets/mvebu/generic/packages
src/gz reboot_base https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/base
src/gz reboot_luci https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/luci
src/gz reboot_packages https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/packages
src/gz reboot_routing https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/routing
src/gz reboot_telephony https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/telephony

The very first link will only work for those on Kernel 4.9, but the remaining ones (the ones in the arm_cortex-a9_vfpv3 directory) will work for everyone.

First make sure you do

opkg flag hold base-files

so you don't have to accidentally worry about upgrading base-files which could mess things up.

Then simply

opkg update

and

opkg list-upgradable

to see all the packages which can be upgraded.

To upgrade all of them in one go, simply type

opkg list-upgradable | awk -F ' - ' '{print $1}' | xargs opkg upgrade

This has never caused me any problems, and I always like to be on the absolutely latest versions, but of course do so at your own risk, minimal as it may be.  If you did happen to upgrade a package and it caused you issues, you could always simply remove the troublesome package, change the distro feeds to point back to @david's website, and install the working version again.

(Last edited by starcms on 26 Apr 2017, 10:56)

Hi people do not tell me how to properly install lede on mybooklive.sorry what's not on the topic.

starcms wrote:

This commit looks promising for those with a 3200ACM

https://github.com/kaloz/mwlwifi/commit … db864822ed

Recompiled the latest driver last night and stuck it on the 3200acm.... If there's a change I couldn't tell.

What worried me was the driver was the same size as what was already running on it, so I went back and did a make clean, and make dirclean, and recompiled, but the file size was the same again.  So, it might be operator error on my side.....

Oh yeah, I altered the "make file" to the latest commit, so I don't know what's going on in that regard.

Do you have a 3200 image I can test(or did you even bother since you found no change)?
Couldn't find it on your download links, although I can be blind sometimes......

(Last edited by mojolacerator on 26 Apr 2017, 13:51)

some issue with SSL\TLS. Openconnect won't connect to my company VPN server (from ubuntu and other router it's ok). The openconnect sent "Change Cipher Spec" towards server and server immediately close connection with Alert "Bad record MAC"
A very same error if I try connect to gmail:

gnutls-cli -p 443  gmail.com
Processed 519 CA certificate(s).
Resolving 'gmail.com:443'...
Connecting to '173.194.44.86:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=gmail.com,O=Google Inc,L=Mountain View,ST=California,C=US', issuer `CN=Google Internet Authority G2,O=Google Inc,C=US', serial 0x3eb815acc8bbbab8, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-04-12 14:15:45 UTC', expires `2017-07-05 13:28:00 UTC', key-ID `sha256:e5975377588b5b127d0e5810af5605bbd37ff28ca783de41797a4ed22dafdc33'
        Public Key ID:
                sha1:caf65d62d197df1bbd368217e00c7af7db0689e0
                sha256:e5975377588b5b127d0e5810af5605bbd37ff28ca783de41797a4ed22dafdc33
        Public key's random art:
                +--[ RSA 2048]----+
                |                 |
                |                 |
                |                 |
                |         o o   . |
                |        S * + +  |
                |     . o E * = .o|
                |      + . + + o.+|
                |     . . o + +.++|
                |        . . ..=+.|
                +-----------------+

- Certificate[1] info:
 - subject `CN=Google Internet Authority G2,O=Google Inc,C=US', issuer `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', serial 0x023a92, RSA key 2048 bits, signed using RSA-SHA256, activated `2015-04-01 00:00:00 UTC', expires `2017-12-31 23:59:59 UTC', key-ID `sha256:ec722969cb64200ab6638f68ac538e40abab5b19a6485661042a1061c4612776'
- Certificate[2] info:
 - subject `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', issuer `OU=Equifax Secure Certificate Authority,O=Equifax,C=US', serial 0x12bbe6, RSA key 2048 bits, signed using RSA-SHA1, activated `2002-05-21 04:00:00 UTC', expires `2018-08-21 04:00:00 UTC', key-ID `sha256:87af34d66fb3f2fdf36e09111e9aba2f6f44b207f3863f3d0b54b25023909aa5'
- Status: The certificate is trusted.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [20]: Bad record MAC
*** handshake has failed: A TLS fatal alert has been received.

(Last edited by AddRemover on 26 Apr 2017, 14:54)

AddRemover wrote:

some issue with SSL\TLS. Openconnect won't connect to my company VPN server (from ubuntu and other router it's ok). The openconnect sent "Change Cipher Spec" towards server and server immediately close connection with Alert "Bad record MAC"
A very same error if I try connect to gmail:

gnutls-cli -p 443  gmail.com
Processed 519 CA certificate(s).
Resolving 'gmail.com:443'...
Connecting to '173.194.44.86:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=gmail.com,O=Google Inc,L=Mountain View,ST=California,C=US', issuer `CN=Google Internet Authority G2,O=Google Inc,C=US', serial 0x3eb815acc8bbbab8, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-04-12 14:15:45 UTC', expires `2017-07-05 13:28:00 UTC', key-ID `sha256:e5975377588b5b127d0e5810af5605bbd37ff28ca783de41797a4ed22dafdc33'
        Public Key ID:
                sha1:caf65d62d197df1bbd368217e00c7af7db0689e0
                sha256:e5975377588b5b127d0e5810af5605bbd37ff28ca783de41797a4ed22dafdc33
        Public key's random art:
                +--[ RSA 2048]----+
                |                 |
                |                 |
                |                 |
                |         o o   . |
                |        S * + +  |
                |     . o E * = .o|
                |      + . + + o.+|
                |     . . o + +.++|
                |        . . ..=+.|
                +-----------------+

- Certificate[1] info:
 - subject `CN=Google Internet Authority G2,O=Google Inc,C=US', issuer `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', serial 0x023a92, RSA key 2048 bits, signed using RSA-SHA256, activated `2015-04-01 00:00:00 UTC', expires `2017-12-31 23:59:59 UTC', key-ID `sha256:ec722969cb64200ab6638f68ac538e40abab5b19a6485661042a1061c4612776'
- Certificate[2] info:
 - subject `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', issuer `OU=Equifax Secure Certificate Authority,O=Equifax,C=US', serial 0x12bbe6, RSA key 2048 bits, signed using RSA-SHA1, activated `2002-05-21 04:00:00 UTC', expires `2018-08-21 04:00:00 UTC', key-ID `sha256:87af34d66fb3f2fdf36e09111e9aba2f6f44b207f3863f3d0b54b25023909aa5'
- Status: The certificate is trusted.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [20]: Bad record MAC
*** handshake has failed: A TLS fatal alert has been received.

Looks to do something with the certificate that's used to encrypt the data and is sent back to the server to decrypt. Appears the server's trying to decrypt, but can't do it with the private key.

Can you see if this can be run?  #openssl s_client -connect theservername:443 -msg -debug

When I get home this evening I'll test openssl as I haven't done so with the new build yet.

(Last edited by davidc502 on 26 Apr 2017, 16:27)

mojolacerator wrote:

Do you have a 3200 image I can test(or did you even bother since you found no change)?
Couldn't find it on your download links, although I can be blind sometimes......

I pulled the driver from a very basic build, and scp'd it over to the router. That's where I noticed that the files looked identical in size.

If I can get what I believe is a good driver pull, I'll post it to the site for people to test with.

starcms wrote:

By the way, am I the only one who changes the distribution feeds to point to the latest snapshot versions from the lede website to get the absolutest latest versions of packages between releases of @david's builds?

Hey, @starcms,  I LOVED your idea. Thanks for the step-by-step instructions. I've implemented this...

I'm getting just one error

opkg install base-files

Upgrading base-files on root from 172-r3988-f66e7cb to 172-r4033-837285b...

Downloading https://downloads.lede-project.org/snapshots/targets/mvebu/generic/packages/base-files_172-r4033-837285b_arm_cortex-a9_vfpv3.ipk

Collected errors:
 * check_data_file_clashes: Package base-files wants to install file /etc/opkg/keys/b5043e70f9a75cde
        But that file is already provided by package  * lede-keyring
 * opkg_install_cmd: Cannot install package base-files.

I've used the flag to not change the base files... but this package still shows up, and gives me this error when trying to update.

Ideas?

@davidc502

sounds good

davidc502 wrote:

Can you see if this can be run?  #openssl s_client -connect theservername:443 -msg -debug

When I get home this evening I'll test openssl as I haven't done so with the new build yet.

yeah, this command works and I can connect to gmail.com or to my vpn server.

AddRemover wrote:
davidc502 wrote:

Can you see if this can be run?  #openssl s_client -connect theservername:443 -msg -debug

When I get home this evening I'll test openssl as I haven't done so with the new build yet.

yeah, this command works and I can connect to gmail.com or to my vpn server.

Tested OpenVPN to servers in Atlanta and Dallas, and there were no issues (Not to say you're not having any).

Please check to make sure all of the vpn configurations are where they are supposed to be including the certs/key/.pem files located in the /etc/openvpn directory.

mariano.silva wrote:
starcms wrote:

By the way, am I the only one who changes the distribution feeds to point to the latest snapshot versions from the lede website to get the absolutest latest versions of packages between releases of @david's builds?

Hey, @starcms,  I LOVED your idea. Thanks for the step-by-step instructions. I've implemented this...

I'm getting just one error

opkg install base-files

Upgrading base-files on root from 172-r3988-f66e7cb to 172-r4033-837285b...

Downloading https://downloads.lede-project.org/snapshots/targets/mvebu/generic/packages/base-files_172-r4033-837285b_arm_cortex-a9_vfpv3.ipk

Collected errors:
 * check_data_file_clashes: Package base-files wants to install file /etc/opkg/keys/b5043e70f9a75cde
        But that file is already provided by package  * lede-keyring
 * opkg_install_cmd: Cannot install package base-files.

I've used the flag to not change the base files... but this package still shows up, and gives me this error when trying to update.

Ideas?

Are you sure you did

opkg flag hold base-files

?

That should prevent it from trying to upgrade base-files when you run the command that upgrades all available packages.

To test it, do

opkg upgrade base-files --noaction

after doing

opkg update

and it should tell you

Not upgrading package base-files which is marked hold (flags=0x202).

Edit: Nevermind, I just noticed that you were using the install command instead of the upgrade command.

To upgrade packages to the latest version, be sure to use opkg upgrade, not opkg install.  And never try to install/upgrade base-files.  By setting it to hold, when you run the long command that upgrades all available packages, it will skip it

(Last edited by starcms on 27 Apr 2017, 02:50)

Currently testing 3200acm Wifi driver based from the commit  - 73e057d84263fd8524438036e3f7b52022c40c6b

*BIG EDIT*

Download to /tmp folder on the router and run #opkg install /tmp/kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk

Not 100 percent this over writes the current driver... still investigating.

https://davidc502sis.dynamic-dns.net/re … _vfpv3.ipk

Please let me know your findings.

(Last edited by davidc502 on 27 Apr 2017, 03:30)

davidc502 wrote:

Currently testing 3200acm Wifi firmware based from the commit  - 73e057d84263fd8524438036e3f7b52022c40c6b

Firmware is located here on your 3200acm router >    /lib/firmware/mwlwifi/

rename name the original 88W8964.bin to 88W8964.bin.old  and copy the new 88W8964.bin file into the /lib/firmware/mwlwifi/  directory and reboot.

https://davidc502sis.dynamic-dns.net/re … 8W8964.bin

Please let me know your findings.

@david, The drivers are in the mwlwifi.ko file. The firmware file (88W8964.bin) hasn't been updated in 3 months looking at the commits.  Maybe that is why your file sizes were the same?  Because you were looking at 88W8964.bin instead of mwlwifi.ko?

After you build, you would need to provide us mwlwifi.ko or kmod-mwlwifi_4.9.20+10.3.4.0-2017042X-1_arm_cortex-a9_vfpv3.ipk

Commit 73e057d84263fd8524438036e3f7b52022c40c6b and all other recent commits affect mwlwifi.ko

88W8964.bin = firmware file and is not dependent on kernel version

mwlwifi.ko = driver file, is dependent on kernel version, and needs to be built.  All commits at https://github.com/kaloz/mwlwifi/commits/master affect mwlwifi.ko.

(Last edited by starcms on 27 Apr 2017, 02:51)

starcms wrote:
davidc502 wrote:

Currently testing 3200acm Wifi firmware based from the commit  - 73e057d84263fd8524438036e3f7b52022c40c6b

Firmware is located here on your 3200acm router >    /lib/firmware/mwlwifi/

rename name the original 88W8964.bin to 88W8964.bin.old  and copy the new 88W8964.bin file into the /lib/firmware/mwlwifi/  directory and reboot.

https://davidc502sis.dynamic-dns.net/re … 8W8964.bin

Please let me know your findings.

@david, The drivers are in the mwlwifi.ko file. The firmware file (88W8964.bin) hasn't been updated in 3 months looking at the commits.  Maybe that is why your file sizes were the same?  Because you were looking at 88W8964.bin instead of mwlwifi.ko?

After you build, you would need to provide us mwlwifi.ko or kmod-mwlwifi_4.9.20+10.3.4.0-2017042X-1_arm_cortex-a9_vfpv3.ipk

Commit 73e057d84263fd8524438036e3f7b52022c40c6b and all other recent commits affect mwlwifi.ko

88W8964.bin = firmware file and is not dependent on kernel version

mwlwifi.ko = driver file, is dependent on kernel version, and needs to be built.  All commits at https://github.com/kaloz/mwlwifi/commits/master affect mwlwifi.ko.

Thanks for explaining the difference.. Yeah, I noticed the size wasn't changing so I thought something could be wrong.

I compiled the wifi driver as a module, so it was easy to get the .ipk and upload.

So, let's do this as a take 2.   kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk

https://davidc502sis.dynamic-dns.net/re … _vfpv3.ipk

*EDIT*

Important Note -- For 3200acm running the 4.9 kernel.

(Last edited by davidc502 on 27 Apr 2017, 04:03)

@starcms

root@lede:/tmp# opkg install /tmp/kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk
Package kmod-mwlwifi (4.9.20+10.3.4.0-20170421-1) installed in root is up to date.

Wasn't sure if it needed to be removed first?

(Last edited by davidc502 on 27 Apr 2017, 03:19)

davidc502 wrote:

@starcms

root@lede:/tmp# opkg install /tmp/kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk
Package kmod-mwlwifi (4.9.20+10.3.4.0-20170421-1) installed in root is up to date.

Wasn't sure if it needed to be removed first?

Maybe when you compile it, you could name it something other than 20170421, 20170426 seems appropriate.  But there should be a opkg command to force it to upgrade.  Let me see.  I wouldn't recommend uninstalling it.

Edit:

Got it. 

opkg install /tmp/kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk --force-reinstall

I'd still recommend rebuilding it with a newer version number, such as 20170426, so one can tell what version they actually have installed

Edit2:

An even easier way to install it would be

opkg install http://davidc502sis.dynamic-dns.net/releases/kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk --force-reinstall

  *for some reason if it's https://, it won't take it.

Edit3:

This can be used for those with any model WRT router, but you must be running @david's Kernel 4.9 build.

Edit4:

For some reason, this is apparently only safe to install on WRT3200ACM models.

(Last edited by starcms on 27 Apr 2017, 05:53)

davidc502 wrote:

@starcms

root@lede:/tmp# opkg install /tmp/
Package kmod-mwlwifi (4.9.20+10.3.4.0-20170421-1) installed in root is up to date.

Wasn't sure if it needed to be removed first?

Do a "opkg install --force-reinstall kmod-mwlwifi_4.9.20+10.3.4.0-20170421-1_arm_cortex-a9_vfpv3.ipk"
working fine here

@david,

After installing the upgraded radio driver package and rebooting, my wrt1200ac went into a reboot loop.  Has it worked sucessfully for anyone?

starcms wrote:

@david,

After installing the upgraded radio driver package and rebooting, my wrt1200ac went into a reboot loop.  Has it worked sucessfully for anyone?

for me but i am using wrt3200

garfo77 wrote:
starcms wrote:

@david,

After installing the upgraded radio driver package and rebooting, my wrt1200ac went into a reboot loop.  Has it worked sucessfully for anyone?

for me but i am using wrt3200

It shouldn't matter.  The mwlwifi driver is compatable with the entire WRT series.