PPP is part of "network", the WAN section.

My username is just my Mac address, but is actually not even checked by the provider, I could use any username, and as a revert to a slightly older build fixes it, it must be something else.

I guess i just have to check out the build per day, and see at which day it stops working, but that is quite a lengthy debugging process.

This is my wan section:

config interface 'wan'                                                
 option ifname 'eth0.6'                                         
 option _orig_ifname 'eth0'                                     
 option _orig_bridge 'false'                                    
 option proto 'pppoe'                                           
 option password 'xxx'                                          
 option peerdns '0'                                             
 option username 'A1-B2-C3-D4-E5-F7@some-thing'                
 option dns 'xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy'                       
 option ipv6 '1'

(Last edited by JohnnySL on 21 Aug 2016, 05:29)

It's coming back to me now. This is a long standing issue with OpenWRT.

All you should have to do is:

uci set network.wan.proto=pppoe
uci set network.wan.username='your username'
uci set network.wan.password='your password'
uci commit network
ifup wan

The pppoe interface just keeps cycling up and down.

(Last edited by Chadster766 on 22 Aug 2016, 16:05)

What is the proper way to do a multi-wan setup with 3 wan IPs.... mwan, vlans via swconfig, or something else all together?  I've installed mwan and looked at the wiki for it, however it seems like it's more for failover, whereas I'd like to use the 3 incoming WAN lines  to increase overall wan speed (similar to how cable modems run 8, 16, or 32 channels at ~40mbps each brdiged into a single interface... however, It's also possible I'm looking at this from the wrong perspective

Network layout would be 3 incoming WAN lines with 3 individual wan IPs going to a bridged wan, lan1, & lan2, with lan3, lan4, and WiFi bridged for LAN.

(Last edited by JW0914 on 21 Aug 2016, 15:31)

You can only load balance the multiple WAN connections.

@sera
Re. Building to the 4.7.2 patch-set. kmod-mwlwifi-nocompat is not building for me. It is in the .config and selected "=y", but does not manifest.

As you appear to be trying to cover the gamut, "fs exfat" breaks.

@Villeneuve

Wrt. kmod-fs-exfat, see https://github.com/dorimanx/exfat-nofus … 5c647fe55a

It's probably as easy as http://bpaste.net/show/ba56b25b4fa7

As for kmod-mwlwifi-nocompat, have to look into it.

Thanks for the reports.

@Villeneuve
thanks for clearing this up:)

How'd I miss this?

The patch / version bump is indeed all that is needed for kmod-fs-exfat. If there is anyone who never contributed but wants to experience doing so, grab the patch. It's trivial, not copyrightable, you don't even have to ask. Contributing for the first time is difficult so a no-brainer like this is ideal to get involved.

As for mwlwifi, if nothing in your package list sets USE_RFKILL it will silently not build. Fixed it and fired a build with all the other changes from earlier this day. Will postpone the next series to tomorrow so I can include the bump to 4.8-rc3 which already contains the timer fix.

Covering base works as that still builds in reasonable time. As for packages in feeds it depends on what gets reported, no liberoffice for instance

Whether there is a need for forking the feed packages to carry fixes time will tell.

Regarding the nand time-out issue, there are talks within the kernel team to completely rewrite the driver, getting rid of data transfer in IRQ handler and replace it with {read,write}_buf in the context of the calling process that asks data to be read / written.

nitroshift

Good news.

The housing is in 2 parts. Separate the bottom from the Top, but do it very slowly. Just start separating at the opening and work your way around.

@guitarman Once you get all the tabs popped loose, you'll want to turn it upside down and push on the inside of the rear feet (you'll see the tongue in groove split of the bottom half (farthest outward portion of the foot) from the upper half (furthest inward portion of the foot).

• I always recommend a pair of mechanics gloves when you break the feet loose for the first time, as it takes a considerable amount of pressure, and once it pops, if you're not careful, it'll gouge a nice piece of skin out of one of your hands.

Linksys at least learned how inconveniently placed the serial header was on the 1900v1 and on the Armada 385's moved in forward quite a bit so it's accessible simply by removing the front blue fascia.  You may want to consider installing a 3.5mm female jack in the side of the router for flashing with a USB-TTL AJ [audio jack] cable, as it makes serial flashing far more convenient.

(Last edited by JW0914 on 23 Aug 2016, 04:21)

Todays mwlwifi release apparently wasn't even compile tested

@sera raise a ticket pal

@Sera, that is a very simpel fix. He builds against an older kernel.
just replace IEEE with NL

Edit: David fixed it already for me.

(Last edited by JohnnySL on 23 Aug 2016, 11:19)

@Nihilanth

Already sent a patch for this and another build failure with CONFIG_THERMAL=m that I had kept for a while. So consider it reported.

@JohnnySL

Must be compat-wireless, on an old enough vanilla kernel for this one to compile a lot else would fail.

---

Doesn't fix N performance for me. Linksys should have called the device WRT54ACS

Hi guys,

can anyone give me a short summary on the reliability of the WRT1900ACSv1/v2 currently? I remember when this came out, there was a lot of hype but it turned out not to be fully open sourced. Has this changed now?

I used to run a WRT54GS back in the day, looking to get a new router but seeing a lot of bad reports on reliability. Assume this is just down to crappy OEM FW and that OWRT will cure any issues?

TIA.

(Last edited by nedge2k on 23 Aug 2016, 11:42)

My n-performance on 5ghz is fine. 2.4ghz is totally crap, but it has been since forever. on what band do you have your issues?

The platform is well supported. The WRT1900ACSv1 is very stable for me, that includes wireless. Just, I only get bg/a speeds for the sole client I half way care.

@JohnnySL

Band, channel, encryption - nothing seems to affect performance. The various output suggests nothing to be amiss.

Looking at the driver doesn't help as everything ends with a call into the firmware around the first corner, so will just have to patiently wait for a fix to magically appear one day.

Just found out, after recent upgrade, WAN interface only supports 1000bastT, that makes my 1900acs can not get connected to a 100baseT uplink.
Any thoughts?

ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  1000baseT/Full 
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

The driver was recently updated to add support for the WRT1900ACSv2, there's another thread titled "Linksys WRT1200AC v2 / WRT1900ACS v2 support" (sorry I can't post a link).

I'm running Kaloz's image linked there on my v2, seems to be working fine so far but I'm not an expert and haven't tested everything.

Eth0 is the link between the cpu and the Switch, not the real external connection, so this is normal.

I think we may finally have a long-term-capable test build.  Kernel 4.4.19 with mwlwifi-10.3.0.18-20160823-1.

My last issue was with bi-directional speed on 5G network and now I'm getting better than 30MB/s in both directions.

Finally.