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.

I'm trying to get DDNS setup on the free version of dynu Having what appear to be timeout errors on SSL.

141720       : ************ ************** ************** **************
 141720  note : PID '31208' started at 2017-11-13 14:17
 141720       : ddns version  : 2.7.6-20
 141720       : uci configuration:
ddns.myddns_ipv4.cacert='/etc/ssl/certs'
ddns.myddns_ipv4.domain='xxxx. freeddns. org'
ddns.myddns_ipv4.enabled='1'
ddns.myddns_ipv4.interface='wan'
ddns.myddns_ipv4.ip_network='wan'
ddns.myddns_ipv4.ip_source='network'
ddns.myddns_ipv4.lookup_host='xxxx. freeddns. org'
ddns.myddns_ipv4.password='xxxxxxxxxxxxx'
ddns.myddns_ipv4.service_name='dynu. com'
ddns.myddns_ipv4.use_ htt ps ='1'
ddns.myddns_ipv4.username='xxxx'
ddns.myddns_ipv4=service
 141720       : verbose mode  : 0 - run normal, NO console output
 141720       : check interval: 600 seconds
 141720       : force interval: 259200 seconds
 141720       : retry interval: 60 seconds
 141720       : retry counter : 0 times
 141720       : No old process
 141720       : last update: never
 141720       : Detect registered/public IP
 141720       : #> /usr/bin/nslookup xxxx. freeddns. org  >/var/run/ddns/myddns_ipv4. dat 2>/var/run/ddns/myddns_ipv4. err
 141720       : Registered IP 'x.x.x.x' detected
 141720  info : Starting main loop at 2017-11-13 14:17
 141720       : Detect local IP on 'network'
 141720       : Local IP 'x.x.x. x' detected on network 'wan'
 141720       : Forced Update - L: 'x.x.x. x' == R: 'x.x.x. x'
 141720       : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/myddns_ipv4.dat -o /var/run/ddns/myddns_ipv4.err --ca-directory=/etc/ssl/certs --no-proxy 'ht tp s:// api.dynu. com/nic/update?hostname=xxxx.freeddns.=org&myip=x.x.x. x&username=xxxx&password=xxxxx'
 141720 ERROR : GNU Wget Error: '4'
 141720       : OpenSSL: error:0606C06E:lib(6):func(108):reason(110)
OpenSSL: error:1408D07B:lib(20):func(141):reason(123)
Unable to establish SSL connection.
 141720  WARN : Transfer failed - retry 1/0 in 60 seconds

Excuse the extra spaces I inserted in anything resembling a weblink to overcome the "zero links" warning I get when trying to post.

Any ideas on how to get this working?

davidc502 wrote:
listerwrt wrote:
davidc502 wrote:

I've tried 4 different kernel 4.4 builds, on 2 different machines, and each failed for the same reason... Something to do with clearfog which deals with Marvel Armada.

There was probably a change that inadvertently broke building kernel 4.4 for our particular hardware. Considering the developers tried to move away from 4.4 months ago, I don't know what the chances are of getting it fixed.

I'm glad someone else noticed, I thought it was just me. 4.9 compiles just fine but changing to 4.4 results in what sounds like the exact same error.

I came to the same conclusion about it being inadvertent... Do you think it's worth creating a ticket? thegabe hinted in the reboot issue thread that trying to fix it now was pointless with 4.14 'bring-up' just over the horizon.

Feel free to bring it up, and see what the developers say.


On the WRT1900 v1 flashed the r5297 build kernel 4.9.58...we'll see if the reboot issue persists... smile

Edit: Random reboot after about 19 minutes.  Maybe kernel 4.14 will be kinder?


Cheers and many thanks for your ongoing efforts!

(Last edited by hancor on 13 Nov 2017, 22:24)

famg wrote:
davidc502 wrote:
famg wrote:

I just tested, but I still have the same problem. I don't know how to solve it.

I have edited sysfixtime, but I don't think this is not a clean solution.

Well, that's not good news...  I wonder where it is getting its time then? Have you tried delaying when syslog starts in the boot process?

No I did not tried it.

I did some tests, and it gets time from here (/etc/init.d/sysfixtime):

boot() {
    start && exit 0

    local maxtime="$(maxtime)"
    local curtime="$(date +%s)" #<--------- gets time here
    [ $curtime -lt $maxtime ] && date -s @$maxtime
}

Tomorrow I will rollback and see if the prior version has the same behavior.

I read at FS#831they are saying it exits in the first line (start && exit 0).

I'll let you know! Thanks David!

Regards,


I did a rollback to r5201 and the behavior changed indeed: r5201 exits at the first line (start && exit 0) of /etc/init.d/sysfixtime

So the new compiling parameters changed the behavior, but not solved the problem. Now the ˜error˜ getting date/time happens in another point (local curtime="$(date +%s)").

I'll get back to r5297 and try to dig more, then I'll let you know.

Thanks for all your support David!

Regards,

Does anyone here know, if using multiple instances of dnscrypt with the /etc/resolv-crypt.conf file for timeout, whether dnsmasq should have

option noresolv 1 

in combination with

option resolvfile '/etc/resolv-crypt.conf'

My understanding is that if you're using the /etc/resolv-crypt.conf file then option noresolv 1 should be commented out (or set to 0), however if you have dnscrypt set to sync your settings to the dnsmasq config, it sets BOTH option noresolv 1 AND option resolvfile '/etc/resolv-crypt.conf', even though per the OpenWRT wiki, these options should be mutually exclusive.

Anyone have insight on this? What's the "correct" configuration?

anymouse617 wrote:

Does anyone here know, if using multiple instances of dnscrypt with the /etc/resolv-crypt.conf file for timeout, whether dnsmasq should have

option noresolv 1 

in combination with

option resolvfile '/etc/resolv-crypt.conf'

My understanding is that if you're using the /etc/resolv-crypt.conf file then option noresolv 1 should be commented out (or set to 0), however if you have dnscrypt set to sync your settings to the dnsmasq config, it sets BOTH option noresolv 1 AND option resolvfile '/etc/resolv-crypt.conf', even though per the OpenWRT wiki, these options should be mutually exclusive.

Anyone have insight on this? What's the "correct" configuration?

I use only 1 instance, so I haven't run into this before. You might try the LEDE forum and see if someone there has experience.

davidc502 wrote:
anymouse617 wrote:

Does anyone here know, if using multiple instances of dnscrypt with the /etc/resolv-crypt.conf file for timeout, whether dnsmasq should have

option noresolv 1 

in combination with

option resolvfile '/etc/resolv-crypt.conf'

My understanding is that if you're using the /etc/resolv-crypt.conf file then option noresolv 1 should be commented out (or set to 0), however if you have dnscrypt set to sync your settings to the dnsmasq config, it sets BOTH option noresolv 1 AND option resolvfile '/etc/resolv-crypt.conf', even though per the OpenWRT wiki, these options should be mutually exclusive.

Anyone have insight on this? What's the "correct" configuration?

I use only 1 instance, so I haven't run into this before. You might try the LEDE forum and see if someone there has experience.

Thanks I posed the question to the package maintainer as well. I’ll share anything I learn.

famg wrote:
famg wrote:
davidc502 wrote:

Well, that's not good news...  I wonder where it is getting its time then? Have you tried delaying when syslog starts in the boot process?

No I did not tried it.

I did some tests, and it gets time from here (/etc/init.d/sysfixtime):

boot() {
    start && exit 0

    local maxtime="$(maxtime)"
    local curtime="$(date +%s)" #<--------- gets time here
    [ $curtime -lt $maxtime ] && date -s @$maxtime
}

Tomorrow I will rollback and see if the prior version has the same behavior.

I read at FS#831they are saying it exits in the first line (start && exit 0).

I'll let you know! Thanks David!

Regards,


I did a rollback to r5201 and the behavior changed indeed: r5201 exits at the first line (start && exit 0) of /etc/init.d/sysfixtime

So the new compiling parameters changed the behavior, but not solved the problem. Now the ˜error˜ getting date/time happens in another point (local curtime="$(date +%s)").

I'll get back to r5297 and try to dig more, then I'll let you know.

Thanks for all your support David!

Regards,

So, if it's getting its time from "date", then there should be no problem, providing it is returning a value which it seems at the time of boot is not.

Go into the init.d script and change the "START" to 99, and reboot.  This would be on image r5297

shuttleman58 wrote:

I'm trying to get DDNS setup on the free version of dynu Having what appear to be timeout errors on SSL.

141720       : ************ ************** ************** **************
 141720  note : PID '31208' started at 2017-11-13 14:17
 141720       : ddns version  : 2.7.6-20
 141720       : uci configuration:
ddns.myddns_ipv4.cacert='/etc/ssl/certs'
ddns.myddns_ipv4.domain='xxxx. freeddns. org'
ddns.myddns_ipv4.enabled='1'
ddns.myddns_ipv4.interface='wan'
ddns.myddns_ipv4.ip_network='wan'
ddns.myddns_ipv4.ip_source='network'
ddns.myddns_ipv4.lookup_host='xxxx. freeddns. org'
ddns.myddns_ipv4.password='xxxxxxxxxxxxx'
ddns.myddns_ipv4.service_name='dynu. com'
ddns.myddns_ipv4.use_ htt ps ='1'
ddns.myddns_ipv4.username='xxxx'
ddns.myddns_ipv4=service
 141720       : verbose mode  : 0 - run normal, NO console output
 141720       : check interval: 600 seconds
 141720       : force interval: 259200 seconds
 141720       : retry interval: 60 seconds
 141720       : retry counter : 0 times
 141720       : No old process
 141720       : last update: never
 141720       : Detect registered/public IP
 141720       : #> /usr/bin/nslookup xxxx. freeddns. org  >/var/run/ddns/myddns_ipv4. dat 2>/var/run/ddns/myddns_ipv4. err
 141720       : Registered IP 'x.x.x.x' detected
 141720  info : Starting main loop at 2017-11-13 14:17
 141720       : Detect local IP on 'network'
 141720       : Local IP 'x.x.x. x' detected on network 'wan'
 141720       : Forced Update - L: 'x.x.x. x' == R: 'x.x.x. x'
 141720       : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/myddns_ipv4.dat -o /var/run/ddns/myddns_ipv4.err --ca-directory=/etc/ssl/certs --no-proxy 'ht tp s:// api.dynu. com/nic/update?hostname=xxxx.freeddns.=org&myip=x.x.x. x&username=xxxx&password=xxxxx'
 141720 ERROR : GNU Wget Error: '4'
 141720       : OpenSSL: error:0606C06E:lib(6):func(108):reason(110)
OpenSSL: error:1408D07B:lib(20):func(141):reason(123)
Unable to establish SSL connection.
 141720  WARN : Transfer failed - retry 1/0 in 60 seconds

Excuse the extra spaces I inserted in anything resembling a weblink to overcome the "zero links" warning I get when trying to post.

Any ideas on how to get this working?

I don't have any experience using freedns... But I use "ChangeIP" which is a free service, and have no issues with SSL, so you might try it.  I'll be happy to give you my configuration for it.

https://www.changeip.com/

*EDIT*

Please run the following command and copy the output.

wget https://davidc502sis.dynamic-dns.net/re … onfig.seed

(Last edited by davidc502 on 14 Nov 2017, 00:18)

For 3200ACM Owners... This is dealing with the "Host command timeout" issue.  The potential fix comes from yuhhaurlin -->  https://drive.google.com/file/d/1sEUvE_ … P295V/view

Download the firmware found in the link above. You will want to rename the original firmware to something like 88W8964.bin.OLD first, and then copy the new firmware to the directory in its place, and reboot.

The directory should look something like this.  Anyhow, please report back your findings.

root@lede:/lib/firmware/mwlwifi# ls -l
-rwxr-xr-x    1 root     root        118776 Nov 10 07:53 88W8864.bin
-rwxr-xr-x    1 root     root        489932 Nov 10 07:53 88W8897.bin
-rwxr-xr-x    1 root     root        449304 Nov 13 16:45 88W8964.bin     <<< This is the new firmware copied over
-rwxr-xr-x    1 root     root        447616 Nov 10 07:53 88W8964.bin.OLD
-rw-r--r--    1 root     root          2140 Nov 10 07:53 Marvell_license.txt

@davidc502

changes made, no issues so far.

@David the parameters looks like they are working as they should, but now it always set jan 19 2038 as a initial date. And there are plenty of files (at /sys, /dev, etc), dated jan 19 2038.

The main problem is the future date at boot time (corrected after a while by NTP). OpenVPN and collectd are not able to handle that.

long shot here: the environment where you compile/recompile, has a date set prior download/compile sources? Could you check if are there any files at the .img/.bin dated jan 19 2038?

Thanks!

(Last edited by famg on 14 Nov 2017, 07:12)

Hi there,

Ive found performance issues with specificially wlan <--> wan on the wrt1900ac (v1). While lan <--> wan and wlan <--> lan both seem, within reasonable performance range of the stock firmware.

for example, running a speedtest.net on stock firmware, to an intel 7260 client at less than 10 meters gets 300+mbps.

on lede, this client is unable to pass 130mbps, yet samba shares transfer at 30+MBps, which is in range of the stock firmware. While clients connected via ethernet achieve 600+mbps.

any ideas why wlan <--> wan has such a drop in performance?

davidc502 wrote:
adri wrote:
Villeneuve wrote:

@famg, do you have a link for:

where they discuss. This seems an ill-advised idea. If there is an issue, then I would say it lies in sysfixtime, not resolving via removal of RTC support.

I have never witnessed the described problem, after a reboot and before NTP catches things up the clock is/can be wrong, but it is short lived.

@davidc502,

I installed r5297 yesterday on my WRT1900ACS v1 and noticed the clock didn't get set properly.
It was running 81 minutes behind and probably this was too much for ntp to correct automatically, so I had to manually update the date&time.
This never happened on build r5201 or before, so it might have something to do the the recent change for the hwclock?

Thanks for an otherwise great build,

Adri.

There isn't a battery on the unit, so removing hwclock shouldn't have an effect, and the reason being that it was always wrong. Even if the hwclock was set, the next reboot would wipe the time out.

When the router is rebooted, is the time kept using NTP?

After a reboot, the time was 81 minutes slow and NTP didn't correct the time, probably because the error was too great.
After I manually set the correct time, NTP seems to keep the clock correctly.
This NEVER happened before. With r5201 and before, the time would be off after a reboot and quickly get reset to the right time & date.
I will monitor the time & date, next time I reboot/install.

adri wrote:
davidc502 wrote:
adri wrote:

@davidc502,

I installed r5297 yesterday on my WRT1900ACS v1 and noticed the clock didn't get set properly.
It was running 81 minutes behind and probably this was too much for ntp to correct automatically, so I had to manually update the date&time.
This never happened on build r5201 or before, so it might have something to do the the recent change for the hwclock?

Thanks for an otherwise great build,

Adri.

There isn't a battery on the unit, so removing hwclock shouldn't have an effect, and the reason being that it was always wrong. Even if the hwclock was set, the next reboot would wipe the time out.

When the router is rebooted, is the time kept using NTP?

After a reboot, the time was 81 minutes slow and NTP didn't correct the time, probably because the error was too great.
After I manually set the correct time, NTP seems to keep the clock correctly.
This NEVER happened before. With r5201 and before, the time would be off after a reboot and quickly get reset to the right time & date.
I will monitor the time & date, next time I reboot/install.

NTP corrects time difference no mater how great is the difference. Mine was corrected from jan 19 2038 to today.

But it still could be a side effect.

Try to SSH and run NTP manually (ntpd), with no deamon and verbose parameters set, so we can see what is happening. It is very odd to be exactly 81 min behind.

Regards,

(Last edited by famg on 14 Nov 2017, 16:35)

@davidc502, FYI nbd has a IRQ Affinity patch to test reboot on mamba with 4.9 kernel.

A note on the HW RTC issue:
Since

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

are on, the kernel is to take current time from userspace(NTP) if available, and update HW RTC every 11 minutes. But since, at least with my test on a rango, I cannot update the RTC

hwclock -w

I assume the kernel to be using the same facility, and it appears to fail silently. There is a hint in FS#831 about resetting the date facility in uboot, but I do not have a serial connected to my rango. so currently cannot test if that is the issue.

Villeneuve wrote:

@davidc502, FYI nbd has a IRQ Affinity patch to test reboot on mamba with 4.9 kernel.

A note on the HW RTC issue:
Since

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

are on, the kernel is to take current time from userspace(NTP) if available, and update HW RTC every 11 minutes. But since, at least with my test on a rango, I cannot update the RTC

hwclock -w

I assume the kernel to be using the same facility, and it appears to fail silently. There is a hint in FS#831 about resetting the date facility in uboot, but I do not have a serial connected to my rango. so currently cannot test if that is the issue.

@davidc502,

Even if the hwclock doesn't have a battery to keep time,when the router is switched off, it will be updated by the kernel.
After a reboot, without loosing power, the hwclock will be correct in setting the time.
Perhaps it would be better to leave the hwclock device configured and enabled?
I think it doesn't make a difference when the router is cold started, but will be better when the router is rebooted.
What do you think?

Hi David I've been trying to solve a problem where any client connected to WiFi stays connected permanently even if it drops out of range for quite a while. I posted the problem on the LEDE forum and Its been suggested I should ask  your advice .

https://forum.lede-project.org/t/associ … esent/8312

I use my router in conjunction with openhab home automation for presence detection it works perfectly on build r4707 and this is the build I have to keep returning to.
I noticed that from build r5032 onwards hostapd was updated could this  be the cause of clients not being cleared when they drop out of range for Tue required time ?

Thank you for your help in advance.

(Last edited by timothyharrison2007 on 14 Nov 2017, 23:57)

timothyharrison2007 wrote:

Hi David I've been trying to solve a problem where any client connected to WiFi stays connected permanently even if it drops out of range for quite a while. I posted the problem on the LEDE forum and Its been suggested I should ask  your advice .

https://forum.lede-project.org/t/associ … esent/8312

I use my router in conjunction with openhab home automation for presence detection it works perfectly on build r4707 and this is the build I have to keep returning to.
I noticed that from build r5032 onwards hostapd was updated could this  be the cause of clients not being cleared when they drop out of range for Tue required time ?

Thank you for your help in advance.

As a test, I associated/authenticated my android with Wifi, and then just pulled the battery out, and sure enough the phone still shows as being associated. So far it has been 15 minutes, and the station hasn't disassociated or deauthenticated due to inactivity, so I'm just waiting to see how long it takes. What's interesting is there have been two poll's that have come back as "ok" after the battery was pulled.

root@lede:~# logread -f |grep AndroidMACAddy

TEST Deauthentication 
Tue Nov 14 19:00:45 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED AndroidMACAddy
Tue Nov 14 19:00:45 2017 daemon.info hostapd: wlan0: STA AndroidMACAddy IEEE 802.11: disassociated
Tue Nov 14 19:00:46 2017 daemon.info hostapd: wlan0: STA AndroidMACAddy IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Authentication
Tue Nov 14 19:00:51 2017 daemon.info hostapd: wlan0: STA AndroidMACAddy IEEE 802.11: associated (aid 6)
Tue Nov 14 19:00:51 2017 daemon.notice hostapd: wlan0: AP-STA-CONNECTED AndroidMACAddy
Tue Nov 14 19:00:51 2017 daemon.info hostapd: wlan0: STA AndroidMACAddy WPA: pairwise key handshake completed (RSN)
Tue Nov 14 19:00:52 2017 daemon.info dnsmasq-dhcp[2890]: DHCPREQUEST(br-lan) MYIP  AndroidMACAddy
Tue Nov 14 19:00:52 2017 daemon.info dnsmasq-dhcp[2890]: DHCPACK(br-lan) MYIP AndroidMACAddy android-c4c68c639ca8efd0
Tue Nov 14 19:00:52 2017 daemon.info hostapd: wlan0: STA AndroidMACAddy IEEE 802.11: authenticated

Phone Battery has been pulled -- Waiting for a TimeOut or something....
Tue Nov 14 19:06:12 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK AndroidMACAddy    <<<< POLL OK????
Tue Nov 14 19:11:15 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK AndroidMACAddy    <<<< POLL OK????
Tue Nov 14 19:16:18 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK AndroidMACAddy   <<<< POLL OK????

Currently, I'm thinking this should go into flyspray..   

root@lede:~# opkg list-installed |grep hostapd
hostapd-common - 2017-08-24-c2d4f2eb-4

(Last edited by davidc502 on 15 Nov 2017, 02:25)

adri wrote:
Villeneuve wrote:

@davidc502, FYI nbd has a IRQ Affinity patch to test reboot on mamba with 4.9 kernel.

A note on the HW RTC issue:
Since

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

are on, the kernel is to take current time from userspace(NTP) if available, and update HW RTC every 11 minutes. But since, at least with my test on a rango, I cannot update the RTC

hwclock -w

I assume the kernel to be using the same facility, and it appears to fail silently. There is a hint in FS#831 about resetting the date facility in uboot, but I do not have a serial connected to my rango. so currently cannot test if that is the issue.

@davidc502,

Even if the hwclock doesn't have a battery to keep time,when the router is switched off, it will be updated by the kernel.
After a reboot, without loosing power, the hwclock will be correct in setting the time.
Perhaps it would be better to leave the hwclock device configured and enabled?
I think it doesn't make a difference when the router is cold started, but will be better when the router is rebooted.
What do you think?

I really haven't had a chance to really dive in.  This entire week isn't going to be good for me as I'm in training Mon-Fri all day.

However, I don't want to let this die on the vine as it's an interesting issue I would like to know more about.

adri wrote:

Even if the hwclock doesn't have a battery to keep time,when the router is switched off, it will be updated by the kernel.
After a reboot, without loosing power, the hwclock will be correct in setting the time.
Perhaps it would be better to leave the hwclock device configured and enabled?
I think it doesn't make a difference when the router is cold started, but will be better when the router is rebooted.
What do you think?

This is an interesting topic. I am inexperienced with the clock so ran a test on my WRT1200ACv1 with davidc502 v4901 before the recent changes:

root@LEDE:/# date
Tue Nov 14 17:38:32 PST 2017
root@LEDE:/bin# hwclock -r
Tue Nov 14 23:26:53 2017  0.000000 seconds
root@LEDE:/#

The hardware clock is working except not being updated and showing drift after 2 days uptime. (EDIT: and maybe a month since last losing power). I agree that the hwclock might still keep time across reboots until the router is unplugged from the power when the clock resets because of no battery backup. The hwclock can be set here:

root@LEDE:/# hwclock -h
hwclock: unrecognized option: h
BusyBox v1.27.2 () multi-call binary.

Usage: hwclock [-r] [-s] [-w] [-t] [-l] [-u] [-f FILE]

Query and set hardware clock (RTC)

        -r      Show hardware clock time
        -s      Set system time from hardware clock
        -w      Set hardware clock from system time
        -t      Set in-kernel timezone, correct system time
                if hardware clock is in local time
        -u      Assume hardware clock is kept in UTC
        -l      Assume hardware clock is kept in local time
        -f FILE Use specified device (e.g. /dev/rtc2)
root@LEDE:/# 

EDIT2: I just tried to update the hardware clock with these results. Note where the -wu is needed to update the clock.

root@LEDE:/usr/bin# hwclock
Wed Nov 15 02:25:31 2017  0.000000 seconds
root@LEDE:/usr/bin# date
Tue Nov 14 18:28:36 PST 2017
root@LEDE:/usr/bin# hwclock -w
root@LEDE:/usr/bin# hwclock
Wed Nov 15 02:25:41 2017  0.000000 seconds
root@LEDE:/usr/bin# hwclock -wu
root@LEDE:/usr/bin# hwclock
Wed Nov 15 02:29:09 2017  0.000000 seconds
root@LEDE:/usr/bin# date
Tue Nov 14 18:30:01 PST 2017
root@LEDE:/usr/bin#

(Last edited by beginner67890 on 15 Nov 2017, 03:35)

davidc502 wrote:
timothyharrison2007 wrote:

Hi David I've been trying to solve a problem where any client connected to WiFi stays connected permanently even if it drops out of range for quite a while. I posted the problem on the LEDE forum and Its been suggested I should ask  your advice .

https://forum.lede-project.org/t/associ … esent/8312

I use my router in conjunction with openhab home automation for presence detection it works perfectly on build r4707 and this is the build I have to keep returning to.
I noticed that from build r5032 onwards hostapd was updated could this  be the cause of clients not being cleared when they drop out of range for Tue required time ?

Thank you for your help in advance.

As a test, I associated/authenticated my android with Wifi, and then just pulled the battery out, and sure enough the phone still shows as being associated. So far it has been 15 minutes, and the station hasn't disassociated or deauthenticated due to inactivity, so I'm just waiting to see how long it takes. What's interesting is there have been two poll's that have come back as "ok" after the battery was pulled.

I been have noticing this exactly same behavior since October 15th. I always have the last version of your building (a couple days delay to update sometimes), I don't remember exactly the version when I have noticed this, but should be the current version on the October 15th.

davidc502 wrote:
adri wrote:
Villeneuve wrote:

@davidc502, FYI nbd has a IRQ Affinity patch to test reboot on mamba with 4.9 kernel.

A note on the HW RTC issue:
Since

CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

are on, the kernel is to take current time from userspace(NTP) if available, and update HW RTC every 11 minutes. But since, at least with my test on a rango, I cannot update the RTC

hwclock -w

I assume the kernel to be using the same facility, and it appears to fail silently. There is a hint in FS#831 about resetting the date facility in uboot, but I do not have a serial connected to my rango. so currently cannot test if that is the issue.

@davidc502,

Even if the hwclock doesn't have a battery to keep time,when the router is switched off, it will be updated by the kernel.
After a reboot, without loosing power, the hwclock will be correct in setting the time.
Perhaps it would be better to leave the hwclock device configured and enabled?
I think it doesn't make a difference when the router is cold started, but will be better when the router is rebooted.
What do you think?

I really haven't had a chance to really dive in.  This entire week isn't going to be good for me as I'm in training Mon-Fri all day.

However, I don't want to let this die on the vine as it's an interesting issue I would like to know more about.

Have a look when you have the time. smile

davidc502 wrote:
S Pimenta wrote:

Just installed the lastest (2017-11-11 r5297) david502c build on my WRT3200ACM

Do I need to ENABLE the option "Enable key reinstallation (KRACK) countermeasures" or hostapd is already doing this?

Good Question... I thought the checking the option would do do the trick, but hostapd be doing something too...   Not sure of any specifics.

My understanding is that this enables extra measures/a workaround for clients that have not been or cannot be patched. It should be related to commit 2127425: https://github.com/lede-project/source/ … d9ea8944c5

Correct me if I'm wrong. It would also explain why it is disabled by default - it might cause interoperability issues.

(Last edited by floydburgermcdahm on 15 Nov 2017, 11:18)

Just to follow up with my above issue, it seems my wlan <--> wan performance issues were caused by masquerading , using SNAT instead seems to help alot on a gigabit line.

Opened thread Target mvebu RTC to try and solicit some input regarding the issue.

There appears to be a mwlwifi commit that may be relevant to the client (no)disconnect issue, but a comment in issue would indicate that perhaps it is meant to be used in conjunction with the BLOB link in thread; unclear.