I have been complaining about the "difference" in Rx vs Tx for moths... 

I may be wrong but I think this goes back to at least .13

My current setup is ACv1 to ACv1 over 5GHz @ 80 MHz, both running LEDE r870 with 10.3.0.17-2016-0617

Would love to see us get to the root cause/fix for this and agree with @InkblotAdmirer 100 %,  that this may be one of the last gremlins on this platform

Cheers

Since I've become more familiar with DokuWiki, I can now add more information to the wiki without muddling it up. 

If users could please post the following so I can add it to the wiki, I'd be extremely appreciative

Things Needed:

1. Boot logs for LEDE, OEM, & OpenWRT
   

   • WRT1200: All

   • WRT1900 v1: LEDE Only

   • WRT1900 v2: All

   • WRT1900ACS: All

2. Serial flash output for all except the WRT1900 v1

(Last edited by JW0914 on 11 Jul 2016, 06:29)

I don't know if it's a typo or he wants it like that, but in the Wiki, mrfrezee is shown as mrfreeze. My apologies if it's already been discussed.

Anyway, the Wiki looks really great and helpful.

Regards.

Don't use a feature because you can but because it makes sense. We now already have a duplication of information in the wireless section (kaloz tab). This is a strong indication to reorganize that info. We have the source and community builds for stable (as named under firmware), not NemoAlex and Kaloz for CC only and Kaloz for CC and DD.

On that note LEDE is yet another community build.

@JW0914
WRT1900acv1 LEDE r930 boot log
http://pastebin.com/3ydmkcMK

Thanks for catching that =]    It's been corrected.

Thanks! =]

I respect your perspectives, however it would help immensely if you were to take a look at the raw code for a wiki page to understand what can and cannot be done, of which dictates how information is laid out within the wiki.  It's not logical to comment on formatting if one does not understand how the formatting occurs and must be applied.

Most don't take the time to understand how the formatting must be applied, of which is why many wiki pages are not aesthetically pleasing, are muddled with information that does not have clear separations from other information, both of which make navigating them more difficult and time consuming than should be required.  In fact, this is the whole reason why I began to make massive changes to the formatting of the WRT1900AC wiki about a year ago.

• In order to link to a section in the wiki, it must have a heading style of 3 or more (i.e. === head3 === ; ==== head4 ==== , etc), with  everything in the Wiki beginning with the Table of Contents, formatted specifically for the Table of Contents.
  

  • Every heading style of 3 or more is added to the table of contents, thereby allowing one to link to it; however,  everything less than 3, as well as normal text, is unable to be linked to.
    

    • If one looks at the table of contents, one will see:
      

      • A Main Section furthest to the left [heading 5].

      • A Subsection of the Main Section mildly indented [heading 4].

      • A Subsection  of the Main Section's Subsection indented furthest to the right [heading 3].

  • One could utilize headings of 3 or more for every sub subject, however wiki navigation at that point would be impossible for anyone to utilize.

• WiFi Driver Section
  

  • I could simply put Kaloz's section only in CC Only, however that defeats the purpose of a CC Only section.

  • I could add NemoAlex's section to DD, however it's not a DD driver and would therefor be in the incorrect location.
    

    • I cannot simply add a link to DD stating "please see [[link]]", as the only thing I could link to would be the CC Only section, which would obviously create a bit of confusion for an everyday user.

  • I could do away with the CC Only and DD sections altogether, however then these sections are no longer listed in the Table of Contents.

• Since the Table of Contents is meant to be a convenience to allow users to quickly and efficiently navigate to the proper section, it is necessary to differentiate information efficiently for dissemination.

Information redundancy should be avoided, however I don't believe all 4 routers have the same boot log output (please correct this logical assumption if it's incorrect).  Since this is a wiki for all WRT1X00AC/S Series routers, it should contain accurate information regarding all WRT1X00AC/S routers.

• I've not added these logs previously due to space constraints and lack of efficient navigation for these.  Now that I'm quite familiar with all DokuWiki plugins, I can utilize one of the tab plugins to create separate tabs for each boot log.

Perhaps you can elaborate on why you believe a wiki for all WRT1X00AC/S Series routers should only contain relevant information for only one of the series' routers.

I do intend to separate LEDE out into it's own section under Community Builds, however I simply ran out of time (I spent most of Sat & Sun working on the wiki and learning how to properly utilize DokuWiki plugins).  I wanted to at least get LEDE's links added, even though they're currently under Trunk's section (davidc502's LEDE builds have been added to his section as well).

(Last edited by JW0914 on 11 Jul 2016, 17:10)

@JW0914 - Re: Wiki

I only wish that kind of info was available before I danced on the top of my WRT1900ACv1 in frustration many months ago, and had to buy a WRT1900ACv2..........lol..................(don't regret the dual 1.6 though ! ).

I was reading the thread and thought I would have a look at the WIKI. I found it logical, clear and concise.
I tip my hat to you in appreciation, as the time. planning and effort, clearly shows through.

Thanks very much for putting all that together !

@JW0914

I feel like prosa would work best. Plain English rather than tabs, trees or tables for the wireless section. Use those if the information fits those structures naturally. I can't remember the exact wording but dlang described the whole issues in a few sentences in this thread very well.

Also primary consumers of that section are stable users using luci for administration. So it should tell stable users to update the driver and how to do that. The link to the source is for those who know what they are doing and as such the link alone is probably enough.

The bootlog from a current or differently configured kernel will look more different than the different models or that of a slightly altered userland. There is some value for users who want to buy one of those devices in those boot logs. So adding one from one of the armada-385 based devices could make sense. The rest is noise. They are anyway different from what you are going to see.

@mojolacerator  Thanks! =]

If other members concur with this perspective, it should be changed back; however, I disagree with this perspective for two reasons:

1. It [tab layouts] consolidates information into relevant tabs and buttons, thereby shortening the length of the wiki, and the respectable sections, which makes it far more convenient for users utilizing devices with less than 15" monitors. It [tabs] allows for a substantial amount of information to be enclosed within a very small footprint.  For example, OpenWrt Builds & Community Builds have been drastically shrunk and now have an extremely clean look.
   

   • I purposefully did not utilize the tab plugin under certain sections, as the use of tabs would have served as a hinderance, such as under the Firmware Synopsis, as well as under topics with instructional sets. 
     

     • The one exception to this is the Firmware Flashing section, as the steps for each type of flash contained two separate actions, 1st Backup, 2nd Install.
       

       • I utilized tabs here as it offers a clear distinction between two entirely different actions.  Due to how DokuWiki works, it creates a hindrance when trying to format in a specific manner, specifically with indenting and bullet type lists. For example, indenting is locked to one tab width only, and one tab width to the right cannot be exceeded; More than one space is recognized as a maximum of one space; Indents cannot be utilized within bullets (i.e. new paragraph under an existing bullet, but not a bullet itself).

2. It standardizes the information layout from one section to the next, resulting in a view of cohesiveness for an end user when disseminating the information contained therein
   

   • For example, compare link buttons to bulleted links before... it's a night and day difference, offering a far more cohesive, and cleaner, look.

The point I'm making is I view all edits to the wiki with all users in mind, always contemplating how the information will appear to a user on a desktop, a laptop, or a mobile device. 

• For example, if one maximizes, then halves, the screen, all wiki information moves accordingly, resizing to proper relative proportions.  (While it took a lot of testing, I was finally able to narrow down the proper em wrap values.)

• Take a look at the page as you scroll continually from top to bottom - all tab boxes are aligned and the same length across the board; this same proportionality is maintained with screen resizes.

I don't make edits to the wiki to simply make edits.  Each edit is viewed and tested by me at a minimum of 5x prior to being saved.  My adherence to ensuring the wiki functions for all users is why each major edit requires hours to get to a completed state (I easily spent 16 hours working on the Wiki between Sat & Sun).  I don't simply make a formatting change on a whim, or simply because I prefer one thing over another - I make changes with everyone in mind, which comes back to my first sentence... If other members echo your perspective, the formatting should be changed back, however I believe the wiki in it's current state is laid out more cohesively for all members than it was without tabs.

Great point, will get that added today or tomorrow.

Great point as well. 

Would you recommend against having a log for each default kernel?  I only ask because because CC has been on 3.18.23 for quite sometime, and prior to the OpenWrt git restructure, default kernel was 4.1.something for quite some time as well.  I'm not sure if the default Trunk kernel will be updated faster now or not, however is there any benefit to having one each of log output for k3.18.23 on CC?

(Last edited by JW0914 on 11 Jul 2016, 19:38)

I'm talking about the wireless section here. There are places where you made good use of that feature, so you won't hear complaints from me It's sort of like the use of colour at one point.

I simply can't imagine right now how to pack the information meaningfully into the current structure of the wireless section.

A more recent one from mamba and one from the others (all three are basically the same) does suffice. You won't get anything new by adding more logs.

I completely misinterpreted your other reply then; sorry about that =]

I should have time to work on the wireless section tonight, however if not, definitely tomorrow. 

As always, thank you for providing critical feedback and constructive criticism =]

So I clean up a bit yesterday and wrote down some notes that might be helpful for eventual users/testers:

So the patch series is on top of openwrt github and uses kernel 4.7-rc7
tarball: https://gpldr.in/v/1QfrfTNxHp/n8Pa3C65ZInbl2nr
sha256sum: 3dcc2ccdb306d03d69a0ceb9ddbfa017010998553e1701755c92f862ff8966eb

And the notes:

== UBIFS

Needs to support overlayfs

Currently, any installation has the core utility mv broken, a bad joke for a
distro.

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

* jffs portion, not relevant to us, no upstream report found
    110-jffs2-use-.rename2-and-add-RENAME_WHITEOUT-support.patch
    111-jffs2-add-RENAME_EXCHANGE-support.patch

* ubifs still missing, no upstream report found

-------------------------------------------------------------------------------

== mwlwifi

* build failure with CONFIG_THERMAL=m
    fix included

* hostapd: WPA: group state machine entering state FATAL_FAILURE
    hack from compat-wireless package imported as band-aid
    quite possibly the same root cause as #55


== available mwlwifi packages

* kmod-mwlwifi
    The one from trunk, uses wireless-compat which doesn't support 4.7 yet.

* kmod-mwlwifi-nocompat (default)
    Uses kernel provided cfg80211 and mac80211

* kmod-net-mwlwifi
    Can be used to test what it would be like if the driver were upstreamed.

* mwlwifi-firmware
    Firmware belongs into linux-firmware or a separate package.

== hostapd-vanilla

Was a great help debugging wireless, included so it may help others.

== crda

unhealthy build host dependencies, also builds on uevents, how are they
best handled in openwrt?

As built-in reg-db is officially supported use it like comapat-wireless does
in openwrt.

-------------------------------------------------------------------------------

== Bug fixes

Looks like a valid bug with fix, no clue why it wasn't simply upstreamed

551-ubifs-fix-default-compression-selection.patch

can be ignored as support for both is enabled anyway

-------------------------------------------------------------------------------

== I broke

* kmod-button-hotplug kmod-gpio-button-hotplug depend on

910-kobject_uevent.patch
911-kobject_add_broadcast_uevent.patch

no interest in fixing right now

* kmod-ledtrig-usb depends on

820-usb_add_usb_find_device_by_name.patch

Would be nice to have it working. Though the one openwrt offers isn't handling
the second led for usb3 anyway. What is it supposed to signal in the first
place? Checking the linksys sources to see what they are doing might be an
option to figure that out.

* kmod-ledtrig-libata dropped

Requires changes to libata, fine as user patch, sure you can ifdef it but fact
remains linux can control multiple leds per disk out of the box (usecase nas).

-------------------------------------------------------------------------------

== Initramfs

As a replacement for a dozen hacks to support dual firmware setups.

Build ubi as module so we can create a block device using module parameter until
busybox supports ubiblock.

Well, a C version thereof probably would be tiny, but there is plenty space on
the kernel partition for busybox, which makes it easy for users to write a
custom init, even dracut might be an idea.

The buildroot support is crude but works fine as a proof of concept.
Suggestions on how to improve it are welcome.

-------------------------------------------------------------------------------

== traffic contol

no pre-setup, use tc or one of those qos scripts available if you need to, the
defaults appear to work well for me so far.

-------------------------------------------------------------------------------

== sysupgrade

* may flash active rootfs
* no need to shut down anything for flashing, procd can't do it properly anyway
* potentially the reason for what happened to david

Maybe I write a replacement utility which is less dangerous

-------------------------------------------------------------------------------

== patches in generic and mvebu

What is left converted to format patches, for easy rebasing on future kernels
as well as reviewing them in the first place. Also running off to a big linux
distro is easy that way ;)

Some of the dropped ones are actually harmful. Stuff like lsusb from busybox or
ss work again for example, netdata shows a few extra gauges as well. Others are
still sitting broken in noltaris staging tree. The price a distro has to pay
for so much baggage isn't little.

== files in generic and mvebu

To much abuse so use banned. Also more review friendly.

-------------------------------------------------------------------------------

== Support

All 4 linksys wrt models.

Tested and working fine on shelby.

No binaries from me. If someone else wants to feel free to do so.

Create new issue on kaloz wifi driver github.:-)

It's actually not as bad as you are making it out to be.

the devices talking the newer protocols (N, AC) first broadcast a G protocol header saying that they will be broadcasting X amount of data where X covers the time that they will actually be broadcasting N/AC data. The other stations on the network then ignore the rest of the data that they can't understand, but they knwo not to try broadcasting in that time.

Teh bigger problem is that the slower station will eat up a lot more airtime that it's share. There is some experimental work landing for ath9kthat does a lot of work to solve this (and it increases throughput as well as decreasing latency, win-win), but it will be a while before it's ready to be integrated into the marvel drivers (which have a bunch of work needed first anyway)

@dlang  I wasn't aware of that =]

(Last edited by JW0914 on 12 Jul 2016, 00:03)

In the switch config section, it may be worth saying that the eth0/eth1 ports on the CPU are not directly exposed to the outside world, they just connect to the switch.

I would also note that the LAN/WAN rows are VLANs (and possibly add the VLAN ID)

Great suggestion =]

Do you by chance know the VLAN id of each?  Also what is the command to garnish that information?

How does WRT1X00AC sort packets in WMM categories?
There are some related docs (e.g. https://www.bintec-elmeg.com/portal/dow … _wmm.html) says DSCP bits in the IP-header maps to WMM categories. I did some experiments using
"iptables -t mangle -I POSTROUTING -p icmp -j DSCP --set-dscp 0x38".
It works on the stock linksys firmware, ping packets has much lower delay(from ~200ms to ~50ms) over background tcp streams of iperf.
It does not work on openwrt, the ping is still getting high delay as the background data congested.

@JW0914
Thanks for the effort you have put into the wiki for the WRT1x00acx routers. Lots of work has gone into the info and formatting. I like the layout you have chosen. Everything is right there and links to more info if wanted/needed.
Keep up the great work. Much needed.
--bill

@bill1228  Thanks! =]

1st
Does anyone utilize the full version of dnsmasq (dnsmasq-full) without odhcpd installed on OpenWrt; If so, is there any modifications that need to be done to ensure it works properly?

For example:

• Does it still utilize /etc/config/dhcp or does it require the use of /etc/dnsmasq.conf?
  

  • I'm aware of how to configure dnsmasq.conf, but I'm not sure if the full version of dnsmasq requires the use of dnsmasq.conf in lieu of the dnsmasq section in /etc/config/dhcp

The reason I'm asking is I need to verify if my advice in the wiki regarding a possible issue with kernel 4.4.x and odhcpd is correct or if it's incomplete.

2nd
Also, for the WRT1200AC, is platform required in /etc/config/wireless for path

Radio0

option  path    'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'

OR

option  path    'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'

3rd

EDIT: Please disregard, will be linking to bootloader sources

4th
Does anyone know what kernel version OEM firmware for each model uses?  I'm not sure where to look on the web for that information, and while I tried a few different search terms, all referred to opensource firmware discussions.

5th

@sera Is there any benefit to listing OEM bootlogs for anything other than the WRT1900 v1? 

• I should have better articulated why I've been asking about the bootlogs... I believe everything after Starting kernel... is the same, or extremely similar, across all versions; however, do "headers" (any information preceeding the kernel start) offer dissimilar information, unique to each build?  The "header" of the bootlog is what I'm mainly interested in listing, with only one of the versions listing the complete bootlog output.

(Last edited by JW0914 on 13 Jul 2016, 08:39)

@JW0914
I have dnsmasq-full installed and no odhc* packages installed.
It uses /etc/config/dhcp. Everything seems working fine. But maybe odhc is needed to obtain ipv6 ip from dhcp (wan for example)

2. Both paths working fine. But default is without platform. wifi detect also gives path without platform.

@JW0914

Linksys firmware is based on kernel 3.2.40.

nitroshift

(Last edited by nitroshift on 13 Jul 2016, 05:40)

The former overrides the options in the latter, not all is exposed in /etc/config/dhcp. You can use one or both.

The issue is unrelated to 4.4, as I have seen it on 4.1
The issue is almost certainly unrelated to this device family (have seen similar in the forum for others)

It's the same sort of differences. If you have seen one you have seen them all. Nitroshift mentioned the availability of the bootloader sources, link them instead, so you cover the topic for real.

@shm0 @nitroshift @sera. Thanks! =]

i have an wrt1200ac with mcfrezee and i added platform... without it was almost impossible to get bothradios work... buggy and slow...

adding it made it work but still i think it's a little bit buggy... maybe someone can confirm that..