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.

Thanks for your hard work.

Over WiFi, when uploading to a hard drive attached to the router itself, I get speeds of around 600-700KB/s. This is the case whether it's SSH, FTP, or AFP. I'm running the December 28th LEDE build for my WRT1200ac. This is quite the improvement over OpenWRT CC, which just crashes. Over ethernet I'll hit a couple MB/s, which is what I'd expect.

Two questions I have:
* Does this relatively slow speed surprise anyone, or is it just a consequence of the wireless drivers being under active development?
* Does anyone have insight on whether this might get better soon?


I'm saving security camera footage to a USB2 hard drive attached to the router, and it's not really a workable solution as the slow speed makes reviewing the video (over wifi) impossible.


Thanks!

WRT1900AC v1 just to report/confirm r3025 login without https.

(Last edited by apvm on 20 Jan 2017, 07:09)

apvm wrote:

WRT1900AC v1 just to report/confirm r3025 login without https.

Thanks for the report -- 

On ACS, it re-directs me to https. No option to use http though luci-ssl is not installed. It works fine after accepting the cert, but is unexpected.

I will be doing some testing, and a rebuild Saturday.

davidc502 wrote:
apvm wrote:

WRT1900AC v1 just to report/confirm r3025 login without https.

Thanks for the report -- 

On ACS, it re-directs me to https. No option to use http though luci-ssl is not installed. It works fine after accepting the cert, but is unexpected.

I will be doing some testing, and a rebuild Saturday.

Chrome just reported it as an unsecured site and won't let me log in unless I clicked the "proceed to unsafe site".  No big deal.  r3025 is working fine.

I am investigating if overheat is the problem that had my wrt1900ac v1 self reboot.

Both kong's ddwrt and Gargoyle will reboot by itself within 24-48 hours, shortest is within 3 hours.  While Lede r2695 lasted 17 days before it reboot by itself.

Fan never turn on except during boot time.  Would like to know if others with the v1 has the same problem.  Tia

(Last edited by apvm on 20 Jan 2017, 17:10)

apvm wrote:
davidc502 wrote:
apvm wrote:

WRT1900AC v1 just to report/confirm r3025 login without https.

Thanks for the report -- 

On ACS, it re-directs me to https. No option to use http though luci-ssl is not installed. It works fine after accepting the cert, but is unexpected.

I will be doing some testing, and a rebuild Saturday.

Chrome just reported it as an unsecured site and won't let me log in unless I clicked the "proceed to unsafe site".  No big deal.  r3025 is working fine.

I am investigating if overheat is the problem that had my wrt1900ac v1 self reboot.

Both kong's ddwrt and Gargoyle will reboot by itself within 24-48 hours, shortest is within 3 hours.  While Lede r2695 lasted 17 days before it reboot by itself.

Fan never turn on except during boot time.  Would like to know if others with the v1 has the same problem.  Tia

You would want to monitor CPU, and see if it's hitting the threshold.  You can take a look at what it's set to, and if the CPU's actually ever go above the threshold. 

For a test, lower the threshold, and see if the fan fires up.

(Last edited by davidc502 on 20 Jan 2017, 20:53)

davidc502 wrote:
apvm wrote:
davidc502 wrote:

Thanks for the report -- 

On ACS, it re-directs me to https. No option to use http though luci-ssl is not installed. It works fine after accepting the cert, but is unexpected.

I will be doing some testing, and a rebuild Saturday.

Chrome just reported it as an unsecured site and won't let me log in unless I clicked the "proceed to unsafe site".  No big deal.  r3025 is working fine.

I am investigating if overheat is the problem that had my wrt1900ac v1 self reboot.

Both kong's ddwrt and Gargoyle will reboot by itself within 24-48 hours, shortest is within 3 hours.  While Lede r2695 lasted 17 days before it reboot by itself.

Fan never turn on except during boot time.  Would like to know if others with the v1 has the same problem.  Tia

You would want to monitor CPU, and see if it's hitting the threshold.  You can take a look at what it's set to, and if the CPU's actually ever go above the threshold. 

For a test, lower the threshold, and see if the fan fires up.

Thanks for the tip but sadly my skill in Linux is so limited that the only thing I could do is ssh into the router and issue sensors, got 62.5 c for cpu temp which does not seems overheating at all.

By the way, it seems r3025 is very solid and wifi is faster than previous build.

(Last edited by apvm on 20 Jan 2017, 21:55)

@apvm

I decided to help you out by digging out the thermal data on your processor. Interestingly enough, Marvel seems to not want to be forthcoming with that information. Intel has always been very open about the thermal information on their processors. 62.5c doesn't seem hot but without the thermal data, we don't really know.

Anyone else stumble across the thermal data for the Marvel processors?

@davidc

Looking forward to the next builds. I hope you sort out the challenges you have recently ran into.

nick59 wrote:

@apvm

I decided to help you out by digging out the thermal data on your processor. Interestingly enough, Marvel seems to not want to be forthcoming with that information. Intel has always been very open about the thermal information on their processors. 62.5c doesn't seem hot but without the thermal data, we don't really know.

Anyone else stumble across the thermal data for the Marvel processors?

@davidc

Looking forward to the next builds. I hope you sort out the challenges you have recently ran into.

Thanks, I don't think it is heat.  Only David r2695 longest, 17 days.  r3025 crashed within 3 hours.  Kong ddwrt and Gargoyle crashed within 24-48 hours.

No idea, may be my 1900AC is dying.

Hi there,

I had issues (probably upgrading to a LEDE build and trying to keep settings, yes, I now know it doesn't work) with my WRT1200, and left it off for months.
I've now installed your latest image, davidc502, and after redoing all the config, I have to say I'm blown away by the 5GHz N wifi speed and also its stability ! Wow, last build from around september, never worked like this ...

One of my tests: streaming a game through steam from my gaming system to my laptop. At the same position as before, where no game was even playable, I can now play a FPS perfect with the latency counter from the streaming service as steady as it goes ...

Really neat build, many thanks !

apvm wrote:

@apvm

No idea, may be my 1900AC is dying.

Well, stuff does happen. Have you consider opening the case to check for loose connections or dust buildup?

Hi David,

Would you be able to include "ngx_http_ssl_module" when compiling NGINX package? It appears that ssl hasn't included in nginx by default. More details here http://nginx.org/en/docs/http/ngx_http_ssl_module.html (Citing: "This module is not built by default, it should be enabled with the --with-http_ssl_module configuration parameter.") and there also was a ticket some time ago https://github.com/openwrt/packages/issues/864

Many thanks.

(Last edited by Rafkat on 22 Jan 2017, 12:54)

apvm wrote:
nick59 wrote:

@apvm

I decided to help you out by digging out the thermal data on your processor. Interestingly enough, Marvel seems to not want to be forthcoming with that information. Intel has always been very open about the thermal information on their processors. 62.5c doesn't seem hot but without the thermal data, we don't really know.

Anyone else stumble across the thermal data for the Marvel processors?

@davidc

Looking forward to the next builds. I hope you sort out the challenges you have recently ran into.

Thanks, I don't think it is heat.  Only David r2695 longest, 17 days.  r3025 crashed within 3 hours.  Kong ddwrt and Gargoyle crashed within 24-48 hours.

No idea, may be my 1900AC is dying.

"r3025 crashed within 3 hours"
Same here ,and crash again within 1hours,so back to r2695,WRT1900AC V1

(Last edited by dobetter on 22 Jan 2017, 02:07)

ralfbergs wrote:

I suspect a routing issue. You might have to fiddle with your routing table.

It seems that your VPN might push a default route so that the default gateway is reached through the VPN. But the other zones seem to be unable to connect to that default gateway due to firewall rules, so this is why no internet for them?

@ralfbergs

Just thought I give you and everyone else an update, maybe this will help someone who has been trying to accomplish the same thing. I was finally able to properly configure the routing of my VPN tunnel (router is a client) so that it is on its own access point, separate from my routers default WAN/LAN. Thank you @ralfbergs again for the tip, you definitely pointed me in the right direction.

1. Essentially you should start by configuring your VPN connection to ensure it can connect the way it normally would in a simple vpn client setup, I wont get into detail on this part, there are plenty of how to's on the OpenWRT wiki pages.

2. Once you've ensured that you're router can connect as a client to your VPN server there are a few changes you will need to make to your client config, here's how my config looks

config openvpn 'usny1_server'
        option route_delay '2'
        option ifconfig_nowarn '1'
        option persist_key '1'
        option port '80'
        option auth_retry 'interact'
        option auth_user_pass '/etc/openvpn/userpass.txt'
        option mute '20'
        option client '1'
        option comp_lzo 'yes'
        option dev 'tun'
        option cipher 'AES-256-CBC'
        list remote 'usny1-ovpn-tcp.purevpn.net'
        option proto 'tcp-client'
        option verb '1'
        option persist_tun '1'
        option ca '/etc/openvpn/ca.crt'
        option tls_auth '/etc/openvpn/Wdc.key 1'
        option enabled '1'

#
# Below this point are the options I changed 
# for routing to work as described
#  
        
option route_noexec '1' #This tells openvpn NOT to add or delete routes 
                         automatically on your routing table, to instead 
                         look at a --route-up script

option route_nopull '1' #This option also prevents the server from making 
                         changes to your routing table

list route '0.0.0.0/0 vpn_gateway' #Default was '0.0.0.0 0.0.0.0', im not 
                                    certain this option is even needed since 
                                    route_nopull, and route_noexec should 
                                    essentially make it null

option route_up '/etc/openvpn/route-up.sh' #This script has the ip commands 
                                            that will create the route for the VPN.

option script_security '2' #This option was needed because of the --route_up 
                            script, otherwise it will kick out an error message 
                            and the VPN will not connect.

3. Next up edit /etc/iproute2/rt_tables, add a table for your vpn

Note: the value and name can be whatever you'd like
just as long as you have added a table for your vpn

#
# reserved values
#
128     prelocal
255     local
254     main
253     default
252     vpn
0       unspec
#
# local
#
#1      inr.ruhep

4. Last but not least the route-up script that will alter your routing table and add a new default route for your tunnel under the routing table vpn, this script assumes that you have separate interfaces for your vpn and lan network. In my case I have an interface setup that looks like this

LAN >> br-lan >> eth1, wlan0, wlan1

VAP >> br-vap >> wlan0-1, wlan1-1

VPN0 >> tun0

WAN >> eth0

WAN6 >> eth0

#!/bin/sh

# This script will automatically pull the interface names and associated ip address
# based on the interface setup described above. It also assumes you are making 
# the entire subnet (ie 10.1.0.0/24) available for the access point.
# You may add individual IP's manually just edit the ip commands removing the
# variables in place of your own specific IP and interface.

sleep 20;

vpn_ifname=$(uci -P/var/state get network.vpn0.ifname);
vpn_addr=$(ifconfig $vpn_ifname | sed -nr 's/.*P-t-P:([^ ]+).*/\1/p');
vap_ifname=$(uci -P/var/state get network.vap.ifname);
vap_addr=$(ifconfig $vap_ifname | sed -nr 's/.*addr:([^ ]+)([^ ]+)([^ ]+).*/\1/p');

ip rule add from $vap_addr.0/24 table vpn;
ip route add $vap_addr.0/24 dev $vap_ifname table vpn;
ip route add default via $vpn_addr dev $vpn_ifname table vpn;
ip route flush cache;

Also make sure you create the proper firewall zones for the VPN, mine looks like this

LAN >> WAN >> Input ACCEPT, Output ACCEPT, Forward ACCEPT

WAN >> Reject >> Input REJECT, Output ACCEPT, Forward REJECT Masq(x) MSS(x)

VAP  >> VPN >> Input ACCEPT, Output ACCEPT, Forward ACCEPT

VPN0  >> REJECT >> Input Reject, Output ACCEPT, Forward REJECT Masq(x) MSS(x)

You may also want to change your DNS servers as my VPN would not work unless I changed the DNS server. That's it I hope this helps someone else out, I know it took me a lot of research and digging to figure this out, had to scour multiple guides from different wikis and forums to include DDWRT forums, so you can see how it got very confusing fast.

(Last edited by jvquintero1021 on 22 Jan 2017, 02:47)

dobetter wrote:
apvm wrote:
nick59 wrote:

@apvm

I decided to help you out by digging out the thermal data on your processor. Interestingly enough, Marvel seems to not want to be forthcoming with that information. Intel has always been very open about the thermal information on their processors. 62.5c doesn't seem hot but without the thermal data, we don't really know.

Anyone else stumble across the thermal data for the Marvel processors?

@davidc

Looking forward to the next builds. I hope you sort out the challenges you have recently ran into.

Thanks, I don't think it is heat.  Only David r2695 longest, 17 days.  r3025 crashed within 3 hours.  Kong ddwrt and Gargoyle crashed within 24-48 hours.

No idea, may be my 1900AC is dying.

"r3025 crashed within 3 hours"
Same here ,and crash again within 1hours,so back to r2695,WRT1900AC V1

At least someone is in the same boat as me, mine is also AC v1.  I am testing cybrnook's build until David's new build comes out.

(Last edited by apvm on 22 Jan 2017, 04:11)

Sorry... newb question

Index of /mvebu/Shelby/lede_Shelby - is this version 2695 for the 1900ACS?

If I go to the archive I dont see 2695 ,.. but I do not see a version # on the current files here.
So just wondering   and want to get the right one.

thanks
haeffnkr

(Last edited by haeffnkr on 22 Jan 2017, 04:23)

haeffnkr wrote:

Sorry... newb question

Index of /mvebu/Shelby/lede_Shelby - is this version 2695 for the 1900ACS?

If I go to the archive I dont see 2695 ,.. but I do not see a version # on the current files here.
So just wondering   and want to get the right one.

2695 was posted on 2016-12-28 so the file you see is 2695. How do I know? I remember it being posted. I don't know the reason that file names don't include version numbers.

(Last edited by nick59 on 22 Jan 2017, 05:35)

2695 is the latest release, and is available in the download sections.  In case you're wondering about 3025, it was made available for testing. Once the new image is available, 3025 will be deleted, and 2695 archived.

Thanks,

r3063 is now available for download.

Slight kernel bump .39 to .43, and slightly changed wifi driver over build r2695.

The Luci SSL issue seems to remain, but it's not hurting anything, so we move forward.

Thanks,

davidc502 wrote:

r3063 is now available for download.

Slight kernel bump .39 to .43, and slightly changed wifi driver over build r2695.

The Luci SSL issue seems to remain, but it's not hurting anything, so we move forward.

Thanks,

Thanks for the hard work.

with the latest snapshot 3063, anyone noticing the WAN LED isn't turning on? This is my LED WAN config, which hasn't changed since I flashed. http://i.imgur.com/dGXw9AY.png

apvm wrote:
davidc502 wrote:

r3063 is now available for download.

Slight kernel bump .39 to .43, and slightly changed wifi driver over build r2695.

The Luci SSL issue seems to remain, but it's not hurting anything, so we move forward.

Thanks,

Thanks for the hard work.

I agree. Thanks for your efforts to provide the community with quality firmware.
--bill

bill1228 wrote:
apvm wrote:
davidc502 wrote:

r3063 is now available for download.

Slight kernel bump .39 to .43, and slightly changed wifi driver over build r2695.

The Luci SSL issue seems to remain, but it's not hurting anything, so we move forward.

Thanks,

Thanks for the hard work.

I agree. Thanks for your efforts to provide the community with quality firmware.
--bill

+1...downloading!

edit: Coming from your 2016-12-28 build, I assume keeping the settings will work?

(Last edited by floydburgermcdahm on 22 Jan 2017, 20:37)

anymouse617 wrote:

with the latest snapshot 3063, anyone noticing the WAN LED isn't turning on? This is my LED WAN config, which hasn't changed since I flashed. http://i.imgur.com/dGXw9AY.png

Try to toggle back and fourth between white and amber. That's what I did to get mine working again. Also do a reboot.


EDIT -- The problem may have something to do with the following change >   https://github.com/lede-project/source/ … da518a2eb8

(Last edited by davidc502 on 22 Jan 2017, 20:48)

anymouse617 wrote:

with the latest snapshot 3063, anyone noticing the WAN LED isn't turning on? This is my LED WAN config, which hasn't changed since I flashed. http://i.imgur.com/dGXw9AY.png

I noticed that too.  Reboot did not fix it.  I tuned off router for a minute or two and turned it back on and is working.

(Last edited by apvm on 22 Jan 2017, 21:35)

Sorry, posts 1001 to 1000 are missing from our archive.