Hi nieroster,

great, this matches my experience as well, so I believe we can assume r1442 to not be affected by the current issue then, next stop r1476

Best Regards
        M.

Quick update,

r1476 from August 31st also did not loose the radios over night... will continue the test for 24 hours, before testing r1497 again.

Best Regards
        M.

Okay, so r1476 survived for 24hours (including one scheduled reboot). I switched back to r1497 and lost both radios after around 1 hour 45 minutes of uptime. So I would say this indicates the changes between August 31st and September 4th as the most likely to have introduced the issue. I guess it is time to carry this over the the LEDE tracker...

It seems that moving one of the clients (a nexus 5X) into another room triggered the issue, so it might be related to changing or poor radio conditions and might not show up easily with all clients in good RF-visibility to the router's antennas...

Best Regards
       M.

I added a bug report for this issue under https://bugs.lede-project.org/index.php … ask_id=176

Best Regards
        M.

To help you to narrow down the regression range, I will re-compile the individual wifi commits into:
https://www.dropbox.com/sh/t52c02rm20y8 … debug?dl=0
r1480 is the base reference that should be equal to ok r1476. That build is just for narrowing down the changes, but you should likely skip that as r1476 is ok.

lede-r1480-20160901-4f40f22-Add_Issue_submission_template_(redirect_t
lede-r1481-20160902-1e72d1b-mac80211_add_a_powersave_handling_fix
lede-r1482-20160902-372d0fe-ath9k_add_a_bunch_of_powersave_handling
lede-r1483-20160902-a894a53-mac80211_add_fixes_for_dealing_with_unex
lede-r1491-20160902-dbc9ee5-ath9k_fix_regression_in_tx_queueing_patc

Please note that nbd added the commits at the same time, so they may intertwined, and the results from in-the-middle commits may be strage...

(Last edited by hnyman on 14 Sep 2016, 11:09)

Thank you very much, I will try r1481 tonight and if that should fail quickly also r1480 (I want to see at least around a full day of uptime without the issue occurring before declaring a build okay, so I will follow your advise to start with the most suspect first as failures typically show up over the course of a few hours).

Best Regards
        M.

So it took a bit longer, but now I am testing r1481 (after confirming that r1600 still has the issue). r1481 seems to be stable, at least it survives my "move a nexus5x to an area of bad reception" test that easily triggered the issue on r1600. I will continue this test for ~24 hours before switching to the next candidate, probably r1491 (I expect this to fail, but testing for failure is quicker than testing for working robustly...)

@hnyman: I keep posting here as we started the discussion here, but would it not be more appropriate to move the whole discussion over to https://bugs.lede-project.org/index.php … sk_id=176? If you wish I can also delete the "mis-placed" posts in your thread...

Best Regards & many thanks
        M.

Added 20160917:
It seems that lede-r1481-20160902-1e72d1b-mac80211_add_a_powersave_handling_fix was the last really stable one. r1482 failed after several hours of uptime (but then in relativ short intervals), r1483 failed in a few minutes if tested under bad wifi reception conditions. I am back at getting r1481 tested for longer than 24 hours, but my interim conclusion is that both/either of r1482 and r1483 are involved in my issue (maybe 1482 introducing the root cause and r1483 just making ir easier to toggle, but that is pure conjecture).

(Last edited by moeller0 on 17 Sep 2016, 21:45)

You can report here, but you might e.g. edit your last message to reflect the current status of the debugging effort instead of always writing a new message.

Right now the key is to identify the culprit commit and pass the info to nbd at #176. There should be nothing really build-specific except that WNDR3700 is a device affected by the bug. In that context, #176 is the better place to continue discussion.

lede-r1725-20160930 should fix a "disappearing wifi" regression that got introduced on 2016-09-02 in LEDE (which regression apparently affected just certain old ath9k devices like the WNDR3700 series).

(Last edited by hnyman on 30 Sep 2016, 10:41)

hi, hnyman, plz where might be prob with transmission in the latest builds?trunk,cc as well as lede-I use full root overlay (sda1=/), when i don't use swap i'm getting smth like low mem, transmission sacrifice child (and its restarted) , with swap 2GB i'm receiving write error 0000...plz help everything else seems working fine, but i 'need' :-) transmission - wndr3700

(Last edited by PhSnake on 3 Oct 2016, 15:33)

Sorry, but there is no Transmission package in my build and I have no experience with it.

Hi,

I'm having some trouble with DNAT, on WNDR3700v2 (LEDE build, r1298)
I've set the firewall to redirect some ports to a Debian machine on my local network, which have itself a firewall which distinguates "local" packets (basically 192.168.x.y) and "foreign" ones (everything else). Amongst redirected ports are smtp-related ports (25/465/587), and torrent port (custom port, 12345)

The logs on the Debian machine shows that some foreign packets seem to originate from my router.

I unfortunately can't reproduce this by hand, as this behaviour seems to be only triggered when a lot of packets arrive : I've seen it for Torrent connections (torrent clients are not reputed for their niceness), as well as spamming "relay" attempts.

I'm not sure this is related to hnyman's build, as I think I had the same behaviour with an old build from arokh.
It might also be WNDR3700-specific, or just a faulty unit on my side.

Did anyone encountered this ? Any ideas to investigate further ?

Sounds like nothing to do specifically with my build. There is nothing build-specific for routing or firewall.

My first guess is a torrent client believing in the values the opposite users claim. Likely some misconfigured torrent users (e.g. behind a double NAT) pass the NATted local private LAN address as their IP. And your torrent client tries to send packets to those "local" addresses.

(Last edited by hnyman on 5 Oct 2016, 09:58)

Indeed. I was just trying my luck here (apologies), as the LEDE-dev mailing list seemed a bit out of my league. Should I try there ?

That seems unlikely to me :
- my router has a not-so-common internal IP of 192.168.0.254. This is the IP I see in the log. No trace of the much more common 192.168.1.1 IP.
- the same goes for smtp connections (which in this case are not rejected, but only flagged and rate-limited by my mail server). While spammer clients might be mischievous about their source IP, it is highly unlikely that they used my router's internal address by blind luck.
- besides, if an packet with a "private" (RFC 1928) source IP arrives on the WAN port, shouldn't the router drop it ?

A new discussion thread with a descriptive title here at the forum might be the best option.

(Last edited by hnyman on 6 Oct 2016, 08:17)

Ok, will do. Thanks for the advise, and sorry for the noise !

Hnyman which version of Ubuntu do you use to create the Chaos Calmer release?

I have used Ubuntu 16.04.1 until this week. I upgraded this week to 16.10.

I have Ubuntu in a Virtualbox instance, so it is really easy transfer the build to a new system with the scripts that my build has.

(Last edited by hnyman on 16 Oct 2016, 08:36)

Thank you for your response I also used 16.04.1 in a VM and upgraded few days a go to 16.10.

After upgrading and doing a rebuild of the Chaos Calmer i noticed the revision is r49389 and not r49707. I''m not sure if that is coincidence or something is wrong with the source.

I just rebuild the environment with 16.04.1 so it seems to have something to do with the source. As it still give revision r39389 after a rebuild.

(Last edited by bladeoner on 16 Oct 2016, 11:27)

That is due to the partial brokenness of Openwrt's move to from svn.openwrt.org via git.openwrt.org to Github. The CC15.05 revision detection logic is broken as it still assumes that there are some SVN IDs "git-svn-id" to be used (even when the sources are pulled with git). Previously git.openwrt.org sources were mirroring the svn, while currently git.openwrt.org CC15.05 mirrors Github sources and there is is no link to SVN.

I noticed the same when I last built CC15.05 (from Github). I have already submitted a pull request to fix the issue, but so far the remaining devs in Openwrt have not committed it:
https://github.com/openwrt/openwrt/pull/125

The needed change is pretty simple. You need to modify three lines in the "try_git" function in include/getver.sh :

--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -17,9 +17,9 @@ try_svn() {
 }
 
 try_git() {
-    [ -e .git ] || return 1
-    REV="$(git log | grep -m 1 git-svn-id | awk '{ gsub(/.*@/, "", $0); print $1 }')"
-    REV="${REV:+r$REV}"
+    git rev-parse --git-dir >/dev/null 2>&1 || return 1
+    REV="$(git describe --tags | sed "s/v15.05.1-\([0-9]*\)-.*/\1/g")"
+    REV="${REV:+r$((REV+49254))}"
     [ -n "$REV" ]
 }
 

Note that after the move to Github, the revision numbers in trunk and in CC15.05 will not go in sync any more.

(Last edited by hnyman on 16 Oct 2016, 12:12)

Thank you Hnyman for clarifying that, I will use your patch for now until they fixed it.

Besides that I can also upgrade again to Ubuntu 16.10, since the problem lies in the source.

Just created a new firmware with your patch and it worked, it has revision r49465.

(Last edited by bladeoner on 16 Oct 2016, 17:26)

hi hnyman, thanks for the lede builds and i'm using r1476 in my wndr3700v2.  since your build already have the full wpad, i like to make a small request in your future builds to include authsae.  i have been testing 802.11s mesh since i have a few atheros based routers at my disposal.  thanks.

I will likely not include authsae, as I have no use for that.
Installing it via opkg works ok, so there is no absolute need to have it in the firmware itself:

root@lede:~# opkg install authsae
Installing authsae (2014-06-09-8531ab158910a525d4bcbb3ad02c08342f6987f2) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/authsae_2014-06-09-8531ab158910a525d4bcbb3ad02c08342f6987f2_mips_24kc.ipk.
Installing libconfig (1.5-1) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/libconfig_1.5-1_mips_24kc.ipk.
Configuring libconfig.
Configuring authsae.

no problem. i would normally perform the 'opkg install' following an 'opkg update' but i kept getting 'signature check failed' with opkg update.

BusyBox v1.24.2 () built-in shell (ash)

     _________
    / /\ _ ___ ___ ___
   / LE / \ | | | __| \| __|
  / DE / \ | |__| _|| |) | _|
 /________/ LE \ |____|___|___/|___| lede-project.org
 \ \ DE /
  \ LE \ / -----------------------------------------------------------
   \ DE \ / Reboot (HEAD, r1476)
    \________\/ -----------------------------------------------------------

root@lede:~# opkg update
Downloading http://downloads.lede-project.org/snapshots/targets/ar71xx/generic/p ackages/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/targets/ar71xx/generic/p ackages/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/telephony/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/telephony/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/routing/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/routing/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/Packages.gz.
Downloading http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/Packages.sig.
Signature check failed.
Remove wrong Signature file.
Collected errors:
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/targets/ar71xx/generic/packages/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/targets/ar71xx/generic/packages/Packages.sig, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/base/Packages.sig, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/telephony/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/telephony/Packages.sig, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/packages/Packages.sig, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/routing/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/routing/Packages.sig, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/Packages.gz, wget returned 4.
 * opkg_download: Failed to download http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/Packages.sig, wget returned 4.
root@lede:~#

if you check the errors closely, you can see that they are download errors from wget. Opkg itself works ok, but you have network/frewall problems.

You might need to manually download the ipk packages and install via opkg.

(And you might also update the firmware to a more current version, although that should not play a role here.)

(Last edited by hnyman on 30 Oct 2016, 09:27)