[384.12_Alpha - builds] Testing all variants.

[XIII]

There’s always the hash you could verify...isn’t there an mdasha1 hash on alphas?

Sometimes there is, at other times not.

I always check the checksum behore flashing, but since the hash and the firmware are in the same file (from the same source) this is only good for checking corruption during download, not for tempering by someone.

 

[heysoundude]

Can’t the hash/checksum from @RMerlin ‘s website be used to verify against wherever you download it from, or am I confused in my understanding of how these things work? Maybe I trust these things too much...


Sent from my iPhone using Tapatalk

 

[RMerlin]

It would be nice if the scroll menu for ping under network monitoring applies the ip address of the service instead of the website link, so google list 8.8.8.8 etc. ,

The IP address will change depending on your location, hence the use of a hostname. You don't want to test the ping time to a US server if you are located in Germany.

And www.google.com does not resolve to 8.8.8.8...

 

[Swistheater]

i understand the IP will change based on your location.

The IP address will change depending on your location, hence the use of a hostname. You don't want to test the ping time to a US server if you are located in Germany.

And www.google.com does not resolve to 8.8.8.8...

and i was not implying www.google.com will resolve 8.8.8.8, just suggesting using 8.8.8.8 may be better to use for ping, than www.google.com .

 

[Swistheater]

I am still trying to wrap my head around the idea of

With it selected Yes the only thing that gets placed in resolv.conf is ----
Nameserver 127.0.0.1
(what are the benefits of this option-- and what may be some of the concerns)
v.s.
With it selected No you will see place in resolv.conf ----
Nameserver Wan DNS1(or isp dns1)
Nameserver Wan DNS2(or isp dns2)
Nameserver 127.0.1.1(why is this involved?)
(what are the benefits of this option-- and what may be some of the concerns)

 

[Swistheater]

Rmerlin Another thing I am now noticing, in system logs, with the new wsdd parameter order that has been changed:

May 20 07:52:08 wsdd2[3800]: starting.
May 20 07:52:08 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:08 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:08 statd[3801]: Version 1.3.3 starting
May 20 07:52:08 statd[3801]: Failed to open directory sm: No such file or directory
May 20 07:52:08 statd[3801]: Running as root.  chown /var/lib/nfs to choose different user
May 20 07:52:08 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use
May 20 07:52:08 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use
May 20 07:52:08 kernel: svc: failed to register lockdv1 RPC service (errno 97).
May 20 07:52:54 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:54 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:54 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use
May 20 07:52:54 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use
May 20 07:52:58 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:58 wsdd2[3800]: wsdd-http-v6: open_ep: bind: Address already in use
May 20 07:52:58 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use
May 20 07:52:58 wsdd2[3800]: llmnr-tcp-v6: open_ep: bind: Address already in use

 

[scjr]

I am still trying to wrap my head around the idea of
View attachment 17725
With it selected Yes the only thing that gets placed in resolv.conf is ----
Nameserver 127.0.0.1
(what are the benefits of this option-- and what may be some of the concerns)
v.s.
With it selected No you will see place in resolv.conf ----
Nameserver Wan DNS1(or isp dns1)
Nameserver Wan DNS2(or isp dns2)
Nameserver 127.0.1.1(why is this involved?)
(what are the benefits of this option-- and what may be some of the concerns)

Way over my head, but this is set to default “Yes” in 384.11_2 and now in 384.12 the default will be “No”?

I did notice in the commit notes this:

‘it's safer (and more reliable) to have the router always use the ISP resolvers by default’

And still way over my head, but I like ‘safer and more reliable’ for sure.

 

[jerry6]

is 384.12 aLPHA working well on the AC3200 for people , i run no scripts , just plain vanilla router ,. bit I've never had trouble before , so guess I'll dive in . thanks
and a big thanks for keeping the AC3200 in the builds , still think it's a great router , never crashes , goes for 6 months without slowdowns or reboots and transfers 100's of GB week on over 20 devices .
AYE m she is working well onm my ac 3200 so far ,, will see how long it lasts .
Still not sure of all the new DNS settings , but will read and try to learn
thanks all in the forum for all the help

 

[isr25]

I know this sounds crazy and all, but I had the dcd tainted errors on my AC86U since 348_2 through this latest build. However, I just setup my first openvpn server on the router - and all the errors went away. Not a single line of the dcd tainted error messages every 20mins since for the past 24 hours. Will keep monitoring and let you guys know

 

[Delusion]

I know this sounds crazy and all, but I had the dcd tainted errors on my AC86U since 348_2 through this latest build. However, I just setup my first openvpn server on the router - and all the errors went away. Not a single line of the dcd tainted error messages every 20mins since for the past 24 hours. Will keep monitoring and let you guys know

Me too. No dcd crashes with Diversion+pixelserv-tls.

 

[Dabombber]

I am still trying to wrap my head around the idea of
View attachment 17725
With it selected Yes the only thing that gets placed in resolv.conf is ----
Nameserver 127.0.0.1
(what are the benefits of this option-- and what may be some of the concerns)
v.s.
With it selected No you will see place in resolv.conf ----
Nameserver Wan DNS1(or isp dns1)
Nameserver Wan DNS2(or isp dns2)
Nameserver 127.0.1.1(why is this involved?)
(what are the benefits of this option-- and what may be some of the concerns)

By default, DNS queries generated by the router itself are handled/cached by dnsmasq. Disabling this will send these queries directly to your WAN DNS servers (like stock firmware does). This means scripts running on the router will not be able to resolve local hostnames, but might work better with some setups. This does not affect your clients, ONLY queries done by the router itself.

 

[Gar]

I am still trying to wrap my head around the idea of
View attachment 17725
With it selected Yes the only thing that gets placed in resolv.conf is ----
Nameserver 127.0.0.1
(what are the benefits of this option-- and what may be some of the concerns)
v.s.
With it selected No you will see place in resolv.conf ----
Nameserver Wan DNS1(or isp dns1)
Nameserver Wan DNS2(or isp dns2)
Nameserver 127.0.1.1(why is this involved?)
(what are the benefits of this option-- and what may be some of the concerns)

How does this effect DoT, if at all?

 

[Swistheater]

Quoting a generic message answer that speaks in generalities does not answer a question, I am looking for specifics and examples to make an informed decision

 

[Dabombber]

That pretty much explains it though. If the router itself (not clients) wants to know the ip of a domain, the option will decide if it goes through dnsmasq or not. That'd usually be what you want since it'll have caching and resolve lan domains, but if you have a weird setup you might want to bypass dnsmasq.

 

[Swistheater]

That pretty much explains it though. If the router itself (not clients) wants to know the ip of a domain, the option will decide if it goes through dnsmasq or not. That'd usually be what you want since it'll have caching and resolve lan domains, but if you have a weird setup you might want to bypass dnsmasq.

Okay so now that explains it a little better. So it would be preferred to have the router as cache for the dnsmasq then.

 

[Centrifuge]

No dcd crashes

Or has the log level been changed, or are we thinking the firmware applied a fix to the Trend Micro engine, that would be awesome.

 

[Delusion]

Or has the log level been changed, or are we thinking the firmware applied a fix to the Trend Micro engine, that would be awesome.

When I noticed dcd wasn't crashing anymore, I thought maybe Diversion new update was removing the crash from the log. BUT when dcd was crashing, also the firewall was having a restart and Skynet block count was resetting as well- This doesn't happen anymore..

 

[scjr]

Okay so now that explains it a little better. So it would be preferred to have the router as cache for the dnsmasq then.

I’ve haven’t changed this setting since running Merlin and always had it on “Yes”. I run DoT now. Guess I will stay were I’m at. Being a novice to networking and since I’m running DoT, the comment in the commit would have swayed me to set it to “No”.

With the increased complexity involving DNS Privacy, ntpd and WAN monitoring, it's safer (and more reliable) to have the router always use the ISP resolvers by default.

Lot’s of great people here with networking experience. I read and appreciate all of your great posts. Thank you all.

 

[Swistheater]

I’ve haven’t changed this setting since running Merlin and always had it on “Yes”. I run DoT now. Guess I will stay were I’m at. Being a novice to networking and since I’m running DoT, the comment in the commit would have swayed me to set it to “No”.



Lot’s of great people here with networking experience. I read and appreciate all of your great posts. Thank you all.

Yes I was trying to understand the safer and more reliable part that was used for wording.

 

[dave14305]

Yes I was trying to understand the safer and more reliable part that was used for wording.

If the router uses WAN DNS directly, no more dependency on Dnsmasq and potential conflicts with NTP (e.g. all those custom configs to resolve pool.ntp.org with 1.1.1.1). No more worries about Stubby or DNSSEC working if NTP isn’t synced yet. The router will do DNS monitoring directly to the internet instead of through dnsmasq, although that 127.0.1.1 in resolv.conf is counter to this idea.

The downside is the inability for the router to resolve local client names if that’s important to you or your scripts.