OpenWrt Forum Archive

Topic: TRENDnet AC2600 (TEW-827DRU)

The content of this topic has been archived between 25 Mar 2018 and 29 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.

dissent wrote:

Check this as well for your mac-address issue

https://github.com/dissent1/r7800/commi … c1a2176f80

Apply the same changes to your dts

Updated url


I was using ifconfig to set them in preinit, which is the old method I've seen used with other devices that have MAC address problems. It is working fine, but I'll test with putting them in the device tree like you demonstrated. Thanks. I appreciate you coming to share this stuff.

(Last edited by jmomo on 16 Nov 2016, 13:18)

jmomo wrote:
dissent wrote:

Check this as well for your mac-address issue

https://github.com/dissent1/r7800/commi … c1a2176f80

Apply the same changes to your dts

Updated url


I was using ifconfig to set them in preinit, which is the old method I've seen used with other devices that have MAC address problems. It is working fine, but I'll test with putting them in the device tree like you demonstrated. Thanks. I appreciate you coming to share this stuff.

Yeps, but this way should help you merging your changes into lede. As far as I remember this was the key problem, right?

I am working on a new build.

What a pain in the ass. I've wasted at least six hours on this so far.

First I had to rebase and fix all of my patches/changes. Expected, no big deal.

Then I find out that I can't build on my Debian unstable workstation anymore because OpenSSL 1.1 isn't supported yet.

So I have to set up a whole new VM just for this.

Spend an hour or so setting up a new system, installing packages, etc etc.

Then I spend another hour on stupid stuff because I forgot to distclean when I rsync'ed the build files over.

The the build breaks because of f2fs-tools is broken in packages. Known issue, it's been broken for a couple of WEEKS apparently.

Then I run into this:  https://www.mail-archive.com/lede-dev@l … 03150.html

Fucking hell

My old uptime on that system was 64 days with no stability issues or interesting syslog messages.

I have a new build booted at head commit d2b79e4d808add264d22e284fa21dfa155e52f05.

I need to do more investigation. I'm seeing some new interesting error messages on boot, but nothing serious.

The bad news is that USB3 is still broken. However, some of the boot log messages look different. I need to look at this further.

The system looks okay so far. I'll play with it more over the next couple of days. I won't be able to play with this for long, and then it will be a month or two before I can likely get back to it again.

--

Boot time is now up to 45 seconds, entirely due to the 802.11 radio firmware/driver. The main system is up in about 17 seconds, but then it sits for another 15-20 seconds waiting on the ath10k driver to finish. The OEM driver takes a long time too, so this isn't just ath10k.

We don't see power LED blink until about 7 seconds into linux kernel time.

Reboot takes 4-5 seconds to kick in. This seems like a long time. I blame UBI.

(Last edited by jmomo on 25 Nov 2016, 02:29)

Things have changed for the USB3 problem. One of my three USB3 flash drives now works after boot, but the other two are still broken.

    SanDisk Ultra Fit 16GB (USB3)        =    WORKS
    Patriot Tab Series 32GB (USB3)        =    broke
    Silicon Power 32GB (USB3)            =    broke

I tested this with five reboots on the SanDisk drive, and at least two reboots on each of the others.

This is different from before. However, the SanDisk flash drive always behaved differently from the other two.

I'll go hunt down whoever did the recent patches to this USB driver and see if they are interested at looking into this.

The USB LED now works correctly. It will light up if any USB device is plugged into either of the two USB ports.

If you don't already have something like this in your /etc/config/system file, add it:

config led 'led_usb'
        option name 'USB'
        option sysfs 'tew827dru:blue:usb'
        option trigger 'usbport'
        list port 'usb1-port1'
        list port 'usb2-port1'
        list port 'usb3-port1'
        list port 'usb4-port1'
jmomo wrote:
dissent wrote:

Check this as well for your mac-address issue

https://github.com/dissent1/r7800/commi … c1a2176f80

Apply the same changes to your dts

Updated url

I was using ifconfig to set them in preinit, which is the old method I've seen used with other devices that have MAC address problems. It is working fine, but I'll test with putting them in the device tree like you demonstrated. Thanks. I appreciate you coming to share this stuff.

If I knew how, I think I might rather set the ethernet MAC address in the DTS, like you demonstrate. The problem is that on the tew827dru, they are stored in the uboot environment. We can't assume that the byte location is always going to be the same. For example, I've added some env variables to my uboot for testing, which has altered the byte location of the MACs from their OEM defaults.

I've read that MACs might also be written into the qfprom. If/when I get access to that, I'll dump it out and see if they are in there.

jmomo wrote:
jmomo wrote:
dissent wrote:

Check this as well for your mac-address issue

https://github.com/dissent1/r7800/commi … c1a2176f80

Apply the same changes to your dts

Updated url

I was using ifconfig to set them in preinit, which is the old method I've seen used with other devices that have MAC address problems. It is working fine, but I'll test with putting them in the device tree like you demonstrated. Thanks. I appreciate you coming to share this stuff.

If I knew how, I think I might rather set the ethernet MAC address in the DTS, like you demonstrate. The problem is that on the tew827dru, they are stored in the uboot environment. We can't assume that the byte location is always going to be the same. For example, I've added some env variables to my uboot for testing, which has altered the byte location of the MACs from their OEM defaults.

I've read that MACs might also be written into the qfprom. If/when I get access to that, I'll dump it out and see if they are in there.

So the u-boot may automatically patch local-mac-address with the above change... or might not, worths a try.

Considering USB, you may try to put this property into snps,dwc3 node:

- snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy.

https://www.kernel.org/doc/Documentatio … b/dwc3.txt

I doubt that my patches will ever get merged into LEDE. I don't know why, but there seems to be bias against me personally or something in the patch set that the project maintainers don't want to directly address.

Alternatively, the project is just so dysfunctional that they are incapable of working with me.

I don't know WTF the problem is.

Nearly all of the communications from LEDE team members have been passive-aggressive and petty. Mathias Kresin in particular seems upset that I touched his stapler or something.

The first point of contention came with the preinit script to fix up the ethernet MAC addresses. The argument against allowing this was nonsensical and no better alternative was suggested. It's hard to take this objection seriously since this is already supported by a number of other devices, and this is exactly the kind of thing that preinit is for.

When that argument fell flat, Mathias moved on to questioning the Build/cameo-sig target, which appends the byte-aligned signature to the factory image. His argument was that he was unable to comprehend a 13-line makefile that used variable declarations, parameter expansion, and 5th grade arithmetic. He's either incredibly stupid, or just fucking with me for giggles. Maybe both. Again his arguments were so nonsensical that I'm convinced he either wasn't reading the code or just doing this on purpose.

His arguments against the Cameo-sig portion is particularly unbelievable because mailing list history shows he's reviewed devices and code that work with them before. I think he's just fucking with me to pad his ego or something.... or he really is just stupid and doesn't remember his own prior work. Whatever.

So I wrote a mail to the lede-adm mailing list asking them to contact me so that we could work this out. I don't what my first course of action to be making an ugly scene of the mailing list, so I figure I'll work it out quietly. Maybe I'm doing something wrong that they have not made clear.

But no, instead of replying to my email directly (I received no private reply), someone else on the LEDE Dev team starts going after something entirely new that wasn't an issue before. Five revisions in, they suddenly decide that the ITS-maker script I wrote to produce the FIT image is a problem, and they don't want it!

I don't know WTF their problem is but I give up.

(Last edited by jmomo on 15 Dec 2016, 02:02)

I got a reply regarding my message on the lede-adm mailing list. It basically said "So I had a private conversation with the other guy who you were apparently were having a problem with. He says there's no problem, so I decided that there was no problem."

They didn't even ask me for input.

Anyway, development on this device is done for me.

Thankfully, people can read the cached exchange on lede-dev list and form their own opinions as to what really happened.

stangri wrote:

Thankfully, people can read the cached exchange on lede-dev list and form their own opinions as to what really happened.

Ha ha! I had not seen this before. This must be someone's sock from lede-dev.

What kind of juvenile mentality appeases themselves by coming to taunt me further on a thread that nobody reads?

I wasn't interested in coddling their emotional needs to get those patches pushed through. They didn't want them, so fine. Someone else can do it some day if they really want.

Anyway, I just put up some builds based on the LEDE v17.01.0 release and updated the top post.

My devices have been up for months and are working great, minus known issues.

(Last edited by jmomo on 20 Mar 2017, 13:00)

jmomo, just wanted to chime in here and say thanks for all the hard work. Not going to comment on the mail list exchanges directly as there's no point (did read through a few of them out of curiosity though), but do want to say that it seems sad that there's not more effort from the project's side to help bring new hardware into the support fold. My general understanding was that individual targets were supported by devs or contributors anyway, not necessarily the main project people, so why code like yours couldn't be added and just marked as "experimental" or "maintained sole by" is strange to me... it's not like you've violated international law and caused the build system to create a nuclear weapon or something...
Anyway, thanks for your hard work!

Is it possible to install Samba on that Trendnet? Having troubles to locate package for the integration with LUCI.

(Last edited by percy on 21 Apr 2017, 14:01)

I must admin I gave up. Everything looks promising however network reliability is not in par with OEM firmware. Made two tests (via copper):
- With DNS queries (Internet server) where every 3-4 query gets response in 10x longer time.
- Similar hiccups with voice. Skype connection quality is deteriorating from time to time.
After returning to stock firmware network works better. So for me thank you but no.

PS. In syslog there are repeating following messages. Not sure if that is anything related.
Apr 21 10:18:33 tn kernel: [39429.820737] ath10k_warn: 12 callbacks suppressed
Apr 21 10:18:33 tn kernel: [39429.820796] ath10k_pci 0001:01:00.0: SWBA overrun on vdev 0, skipped old beacon
Apr 21 10:18:33 tn kernel: [39429.824479] ath10k_pci 0001:01:00.0: SWBA overrun on vdev 0, skipped old beacon
Apr 21 10:18:33 tn kernel: [39429.831628] ath10k_pci 0001:01:00.0: SWBA overrun on vdev 0, skipped old beacon

Ethernet stats look good to me maybe except of filtered frames:

root@td:~# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
        enable_mirror_rx: 0
        enable_mirror_tx: 0
        mirror_monitor_port: 0
        mirror_source_port: 0
        arl_age_time: 300
        arl_table: ???
        igmp_snooping: 0
        igmp_v3: 0

...

Port 5:
        mib: MIB counters
RxBroad     : 60
RxPause     : 0
RxMulti     : 20568
RxFcsErr    : 0
RxAlignErr  : 0
RxRunt      : 0
RxFragment  : 0
Rx64Byte    : 2020
Rx128Byte   : 345227
Rx256Byte   : 299346
Rx512Byte   : 156214
Rx1024Byte  : 76688
Rx1518Byte  : 741555
RxMaxByte   : 0
RxTooLong   : 0
RxGoodByte  : 1307023249 (1.2 GiB)
RxBadByte   : 0
RxOverFlow  : 0
Filtered    : 42
TxBroad     : 3
TxPause     : 0
TxMulti     : 516
TxUnderRun  : 0
Tx64Byte    : 486525
Tx128Byte   : 307150
Tx256Byte   : 82255
Tx512Byte   : 127695
Tx1024Byte  : 59338
Tx1518Byte  : 145476
TxMaxByte   : 0
TxOverSize  : 0
TxByte      : 371268410 (354.0 MiB)
TxCollision : 0
TxAbortCol  : 0
TxMultiCol  : 0
TxSingleCol : 0
TxExcDefer  : 0
TxDefer     : 0
TxLateCol   : 0

        enable_eee: 0
        igmp_snooping: 0
        pvid: 2
        link: port:5 link:up speed:1000baseT full-duplex txflow rxflow auto

(Last edited by percy on 22 Apr 2017, 07:32)

Hi....
How is it possible to flash firmware with u-boot through tftp.
What are the commands?
Thanks.

The discussion might have continued from here.