Custom firmware build for R9000/R8900 v. 1.0.4.40HF

[L&LD]

@smokebox unplug the router from the AC power adaptor and also fully from all other connections and USB devices you may have plugged in. Wait at least 2 minutes and then connect/plugin everything and power it up. Does that help?

 

[smokebox]

@smokebox unplug the router from the AC power adaptor and also fully from all other connections and USB devices you may have plugged in. Wait at least 2 minutes and then connect/plugin everything and power it up. Does that help?

Hey dude, thanks for the suggestion. I've already tried that though. I also found that the 1-2 port aggregation was enabled somehow but disabling that didn't help either. Even telnet'd in and did an nvram erase and still no love. Very weird

 

[smokebox]

@smokebox unplug the router from the AC power adaptor and also fully from all other connections and USB devices you may have plugged in. Wait at least 2 minutes and then connect/plugin everything and power it up. Does that help?

Well, I unplugged and let it sit 10mins while config'ing up another router. Then tried it again and now we're good to go. Guess it just needed a bit longer. Thanks dude

 

[Toni]

So I've recently purchased an R9000, and noticed that the 5GHz Wifi access point disappears sometimes. Assumed that there's something wrong with the stock firmware, I installed Voxel's firmware, and the behaviour is the same. For troubleshooting purposes I disabled all access points except the 5GHz one, and behaviour is still the same.

I suspect it has something to do with the 160MHz mode. Can anyone else confirm?

If you’re using DFS channels, probably you router is detecting a RADAR signal on the channels it’s running and it shutdown this channels. Probably this is the reason. Before start transmission on this channels the router should wait listening ten minutes on them.


Sent from my iPad using Tapatalk

 

[arabesc]

So strange occurrence when upgrading from 1.0.4.39...When the router (R9000) came back up, WAN, LAN 1 and LAN 2 no longer work. Anyone seen that before? Been a long time user of Voxel's firmware and never had an issue before. Did my ports just give up the ghost coincidentally?

I have a few issues also:

• I have port aggregation enabled on the ports 1-2, and it seems to work, but port 3 stopped to work after update;
• dnscrypt-proxy-2 doesn't start automatically after the first manual reboot after update, don't know what is the cause (it's enabled in nvram and as service);
• there's weird output from the opkg, e.g.:
  
  Spoiler: $ opkg info strace

  ERROR: truncating field 2 <0x46307> to 34 byteERROR: truncating field 2 <0x46307> to 34 byteERROR: truncating field 2 <0x46307> to 34 byteERROR: truncating field 2 <0x46307> to 34
  ...
  byteERROR: truncating field 2 <0x46307> to 23 byteERROR: truncating field 2 <0x46307> to 23 byteERROR: truncating field 2 <0x46307> to 23 bytePackage: strace
  Version: 5.4-1
  Depends: libc, libssp, librt, libpthread
  Status: unknown ok not-installed
  Section: utils
  Architecture: cortex-a15-3x
  Maintainer: Felix Fietkau <nbd@nbd.name>
  Size: 253376
  Filename: strace_5.4-1_cortex-a15-3x.ipk
  Source: ame: strace
  Description: A useful diagnostic, instructional, and debugging tool. Allows you to track what
  system calls a program makes while it is running.

 

[xTe22-pT]

I have a few issues also:

• dnscrypt-proxy-2 doesn't start automatically after the first manual reboot after update, don't know what is the cause (it's enabled in nvram and as service);

Hi there Voxel,

Looks like I am having same issue as reported by "arabesc", as after updaing firmware to your last version, my DNSCrypt is not working anymore, despite of being saying this at Kamoj add-on : "DNSCrypt v2 is not running, but is enabled"

I next ran "cat /var/log/dnscrypt-proxy-2.log" by using Telnet and got this :

[NOTICE] dnscrypt-proxy 2.0.42
[NOTICE] Network not available yet -- waiting...
[NOTICE] dnscrypt-proxy 2.0.42
[NOTICE] Network not available yet -- waiting...
[NOTICE] Network connectivity detected
[NOTICE] Network connectivity detected
[CRITICAL] Unable to retrieve source [public-resolvers]: [Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:05Z is before 2020-05-09T00:33:07Z]

Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:05Z is before 2020-05-09T00:33:07Z

Unable to retrieve source [public-resolvers]: [Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:06Z is before 2020-05-09T00:33:07Z]

Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:06Z is before 2020-05-09T00:33:07Z



Already tried to stop and restart it multiple times, but can not figure what is happening here. I am afraid it might be an issue somewhere.

Any ideias ?


Keep up the great job !

Cheers

 

[R. Gerrits]

Hi there Voxel,

Looks like I am having same issue as reported by "arabesc", as after updaing firmware to your last version, my DNSCrypt is not working anymore, despite of being saying this at Kamoj add-on : "DNSCrypt v2 is not running, but is enabled"

I'm guessing you are not yet running the latest beta v5.2b2-5 yet?

As that has a fix for this issue:

Changes in kamoj-addon beta version 5.2b2-5
------------------------------------------------------
.....
.....
- dnscrypt-proxy-2: Added: Set time to avoid CRITICAL/FATAL errors at boot. Example:
   [2020-04-22 16:29:11] [CRITICAL] Unable to retrieve source [public-resolvers]: [Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-22T16:29:11Z is before 2020-05-02T00:33:21Z]
   [2020-04-22 16:29:11] [FATAL] Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-22T16:29:11Z is before 2020-05-02T00:33:21Z

 

[arabesc]

I'm guessing you are not yet running the latest beta v5.2b2-5 yet?

Do you mean the Kamoj add-on is the source of the issue?
I tested the add-on some time ago but now opkg list-installed says the add-on isn't installed, although I don't remember deleting it.

Looks like I am having same issue as reported by "arabesc", as after updaing firmware to your last version, my DNSCrypt is not working anymore, despite of being saying this at Kamoj add-on : "DNSCrypt v2 is not running, but is enabled"

I can successfully launch dnscrypt-proxy-2 manually after boot:
$ /etc/init.d/dnscrypt-proxy-2 start
Does it work for you?

 

[Supersaiyan_IV]

If you’re using DFS channels, probably you router is detecting a RADAR signal on the channels it’s running and it shutdown this channels. Probably this is the reason. Before start transmission on this channels the router should wait listening ten minutes on them.


Sent from my iPad using Tapatalk

Suddenly I feel a bit stupid, yeah it's likely that DFS is messing with 160MHz. Changed 'Region' from 'Europe' to 'China', which doesn't even have any DFS channels, and it seems like there's no issues so far. Thank you

 

[xTe22-pT]

I'm guessing you are not yet running the latest beta v5.2b2-5 yet?

As that has a fix for this issue:

Changes in kamoj-addon beta version 5.2b2-5
------------------------------------------------------
.....
.....
- dnscrypt-proxy-2: Added: Set time to avoid CRITICAL/FATAL errors at boot. Example:
   [2020-04-22 16:29:11] [CRITICAL] Unable to retrieve source [public-resolvers]: [Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-22T16:29:11Z is before 2020-05-02T00:33:21Z]
   [2020-04-22 16:29:11] [FATAL] Get "https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md": x509: certificate has expired or is not yet valid: current time 2020-04-22T16:29:11Z is before 2020-05-02T00:33:21Z

Looks like the issue is not coming from Kamoj add-on, as I have just fully removed it and try to enable again DNSCrypt, but still not working.

Ran again "cat /var/log/dnscrypt-proxy-2.log" and this time I got a slightly different error message :



[NOTICE] dnscrypt-proxy 2.0.42
[NOTICE] Network connectivity detected
[NOTICE] System DNS configuration not usable yet, exceptionally resolving [raw.githubusercontent.com] using fallback resolvers over tcp
[NOTICE] Fallback resolvers didn't respond - Trying with the system resolver as a last resort

[ERROR] Unable to resolve [raw.githubusercontent.com] - Make sure that the system resolver works, or that `fallback_resolver` has been set to a resolver that can be reached

[CRITICAL] Unable to retrieve source [relays]: [Get "https://download.dnscrypt.info/resolvers-list/v2/relays.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:23Z is before 2020-05-09T00:33:07Z]

FATAL] Get "https://download.dnscrypt.info/resolvers-list/v2/relays.md": x509: certificate has expired or is not yet valid: current time 2020-04-23T11:58:23Z is before 2020-05-09T00:33:07Z

 

[xTe22-pT]

Do you mean the Kamoj add-on is the source of the issue?
I tested the add-on some time ago but now opkg list-installed says the add-on isn't installed, although I don't remember deleting it.


I can successfully launch dnscrypt-proxy-2 manually after boot:
$ /etc/init.d/dnscrypt-proxy-2 start
Does it work for you?

No luck on this side buddy, still facing same issue as stated above....

 

[kamoj]

The Kamoj add-on v5.2b2-5 has a fix/solve for the problem.
" dnscrypt-proxy-2: Added: Set time to avoid CRITICAL/FATAL errors at boot"
https://www.snbforums.com/threads/kamoj-add-on-5-1-beta-testing-poll.62315/page-8#post-580905
https://www.snbforums.com/threads/c...0-r8900-v-1-0-4-40hf.63602/page-3#post-582616

 

[xTe22-pT]

The Kamoj add-on v5.2b2-5 has a fix/solve for the problem.
https://www.snbforums.com/threads/kamoj-add-on-5-1-beta-testing-poll.62315/page-8#post-580905
https://www.snbforums.com/threads/c...0-r8900-v-1-0-4-40hf.63602/page-3#post-582616

Thanks for your message kamoj.

Unfortunately as I stated above, I am facing the DNSCrypt issue even after completely removing your add-on, so it can not be coming anymore from there right ?
On previous firmware version, it was working well.

 

[R. Gerrits]

Looks like the issue is not coming from Kamoj add-on, as I have just fully removed it and try to enable again DNSCrypt, but still not working.

Correct Kamoj is not causing it, but it does have a solution.

Real cause is that dnscrypt relies on certificates for the encryption. but certificates are only valid during a specific time.
As the router has no hardware clock, it's initial time (before it has connected to an NTP-server) is somewhere in 1970 (i think 1 January).
Either somewhere in Voxels firmware or by one of Kamoj's earlier addon versions I think this is already changed so that the router during boot initally sets the date to the firmware release date (in your case 2020-04-23).
But in both cases on that time, the dnscrypt certificate is not yet valid.

And I think latest Kamoj addon stores the current time at shutdown, and restores it during boot. So then the time would only be off by a minute or so.

(one strange thing in this theory -> with DNScrypt down, also dns-lookups for the ntp-server would fail. So it should never be able to recover from the error, unless dnsmasq at some point decides to ignore dnscrypt and starts resolving directly.)

 

[xTe22-pT]

Correct Kamoj is not causing it, but it does have a solution.

Real cause is that dnscrypt relies on certificates for the encryption. but certificates are only valid during a specific time.
As the router has no hardware clock, it's initial time (before it has connected to an NTP-server) is somewhere in 1970 (i think 1 January).
Either somewhere in Voxels firmware or by one of Kamoj's earlier addon versions I think this is already changed so that the router during boot initally sets the date to the firmware release date (in your case 2020-04-23).
But in both cases on that time, the dnscrypt certificate is not yet valid.

And I think latest Kamoj addon stores the current time at shutdown, and restores it during boot. So then the time would only be off by a minute or so.

(one strange thing in this theory -> with DNScrypt down, also dns-lookups for the ntp-server would fail. So it should never be able to recover from the error, unless dnsmasq at some point decides to ignore dnscrypt and starts resolving directly.)

Thanks R.Gerrits, I really understand your point here, but the weird thing over here for me is, why after updaing firmware to latest version DSNCrypt decided to stop working even more due to be exacly same version (2.0.42) as previous firmware version got.

I did state a manual NTP server to figure out if the issue was also coming from there but unfortunately for me no. So at this point, am out of solutions.

 

[kamoj]

Thank you for your always crisp and good thinking!

The Kamoj add-on solves the problem by getting current time from one of many internet companies,
until the ntp is synced. This option has been in the add-on for OpenVPN and Wireguard that have the same issue,
but I had to add it to DNSCrypt since it is started earlier in the boot sequence than mentioned services.

The better long term solution is to do the "preliminary" timesync always in the @Voxel firmware, maybe as you/me suggest:
- Set time to firmware compile time
- Set time to last known valid time
- Set time to "internet" time
- Set time to NTP-time
I'm sure Voxel will do that when he get back to his development environment.

Correct Kamoj is not causing it, but it does have a solution.

Real cause is that dnscrypt relies on certificates for the encryption. but certificates are only valid during a specific time.
As the router has no hardware clock, it's initial time (before it has connected to an NTP-server) is somewhere in 1970 (i think 1 January).
Either somewhere in Voxels firmware or by one of Kamoj's earlier addon versions I think this is already changed so that the router during boot initally sets the date to the firmware release date (in your case 2020-04-23).
But in both cases on that time, the dnscrypt certificate is not yet valid.

And I think latest Kamoj addon stores the current time at shutdown, and restores it during boot. So then the time would only be off by a minute or so.

(one strange thing in this theory -> with DNScrypt down, also dns-lookups for the ntp-server would fail. So it should never be able to recover from the error, unless dnsmasq at some point decides to ignore dnscrypt and starts resolving directly.)

 

[R. Gerrits]

Thanks R.Gerrits, I really understand your point here, but the weird thing over here for me is, why after updaing firmware to latest version DSNCrypt decided to stop working even more due to be exacly same version (2.0.42) as previous firmware version got.

looked a little bit closer:

DNSCrypt is fetching the list of anonymized resolvers from https://download.dnscrypt.info/resolvers-list/v2/relays.md
This site is using SSL certificates from LetsEncrypt. These certificates are only valid for 90 days, and usually renewed after 60 days.

current certificate of that site has these dates:
Not Valid Before: Saturday, 9 May 2020 at 02:33:07 Central European Summer Time
Not Valid After: Friday, 7 August 2020 at 02:33:07 Central European Summer Time

So your issue started on 9 May, when the SSL certificate was renewed (because 23 April is before 9 May). It might have coincided with your upgrade to the newer version of Voxel, but I'd say that is then simply a coincidence.

Before 9 May, that site would probably have had a certificate that was valid between 10 March and 8 June. (if they indeed renew after 60 days)
The previous version of Voxel firmware (1.0.4.39.1HF) was released end of March -> so also in that firmware there was no issue as end of March is after 10 March.

 

[xTe22-pT]

Thank you for your always crisp and good thinking!

The Kamoj add-on solves the problem by getting current time from one of many internet companies,
until the ntp is synced. This option has been in the add-on for OpenVPN and Wireguard that have the same issue,
but I had to add it to DNSCrypt since it is started earlier in the boot sequence than mentioned services.

The better long term solution is to do the "preliminary" timesync always in the @Voxel firmware, maybe as you/me suggest:
- Set time to firmware compile time
- Set time to last known valid time
- Set time to "internet" time
- Set time to NTP-time
I'm sure Voxel will do that when he get back to his development environment.

No worries kamoj, happy to report all the issues I found here. Fortunately this is the only one I have had as always used Voxel firmware since he began to building to R9000 routers (my actual one) and also your add-on, which defnitely unleashs very useful information to users like me

As I mentioned before, I was using your add-on untill figuring out it might be the source of my problems about DNSCrypt, but it is not.
But just to make sure I was running your latest version, should I one of both links stated at your thread, right ? One of those below :

curl -k -R -O https://voxel-firmware.com/Downloads/kamoj-addon_191214-083737-1_r9000.ipk
or:
wget --no-check-certificate https://voxel-firmware.com/Downloads/kamoj-addon_191214-083737-1_r9000.ipk


Just asking this as I am planning re-install it again since the problem was not coming from your add-on.

 

[xTe22-pT]

looked a little bit closer:

DNSCrypt is fetching the list of anonymized resolvers from https://download.dnscrypt.info/resolvers-list/v2/relays.md
This site is using SSL certificates from LetsEncrypt. These certificates are only valid for 90 days, and usually renewed after 60 days.

current certificate of that site has these dates:
Not Valid Before: Saturday, 9 May 2020 at 02:33:07 Central European Summer Time
Not Valid After: Friday, 7 August 2020 at 02:33:07 Central European Summer Time

So your issue started on 9 May, when the SSL certificate was renewed (because 23 April is before 9 May). It might have coincided with your upgrade to the newer version of Voxel, but I'd say that is then simply a coincidence.

Before 9 May, that site would probably have had a certificate that was valid between 10 March and 8 June. (if they indeed renew after 60 days)
The previous version of Voxel firmware (1.0.4.39.1HF) was released end of March -> so also in that firmware there was no issue as end of March is after 10 March.

Yeah I think you are right R.Gerrits, actually did not notice that. But after double checking, yeah, error message states something invalid around the time and date.

My question is, is there any way to bypass this issue to allow DNSCrypt retrives those certifications even if they are invalid or expired ? I mean, forcing it to get certifications despite of being invalid/expired or not

 

[kamoj]

The "official" kamoj add-on 5.0 beta you plan to re-install does not solve the certificate problem.
I would suggest you join the team of beta 5.2 testers. PM me if you want to. Then this problem is solved by router getting valid time before NTP has synced ok.

Yeah I think you are right R.Gerrits, actually did not notice that. But after double checking, yeah, error message states something invalid around the time and date.

My question is, is there any way to bypass this issue to allow DNSCrypt retrives those certifications even if they are invalid or expired ? I mean, forcing it to get certifications despite of being invalid/expired or not