jaybrown / dnscrypt-menu Goto Github PK

I can't manage to completely block sentry.io domain even with .sentry. as show below. Any suggestion?
Thank you in advance.

Hi .. This was working fine at home .. Just arrived at my daughters and I see the dnscrypt icon in the menu but it has a yellow triangle to the right. If I click, I see a section (below DNSCrypt Menu) that has:
sed: 1: "s/^lo0
2259: //": unterminated substitute pattern

Thanks

Just updated to 2.0.22 and everything so far so good. Thank you.
I just noticed that some cksum is flagged as incorrect in terminal log as show in the sample below. I guess is normal but why this can happen ?
Thank you in advance.

gCs-MacBook-Pro:~ gc$ sudo tcpdump -i en5 -vvv 'port 443'
Password:
tcpdump: listening on en5, link-type EN10MB (Ethernet), capture size 262144 bytes
02:24:59.078265 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 699, bad cksum 0 (->6310)!)
192.168.1.5.50414 > 95.101.180.26.https: Flags [P.], cksum 0xd7da (incorrect -> 0x3a06), seq 1885994789:1885995436, ack 579696828, win 20588, options [nop,nop,TS val 569486357 ecr 3914559841], length 647
02:24:59.101860 IP (tos 0x0, ttl 56, id 31019, offset 0, flags [DF], proto TCP (6), length 1492)
95.101.180.26.https > 192.168.1.5.50414: Flags [.], cksum 0xd5be (correct), seq 1:1441, ack 647, win 1392, options [nop,nop,TS val 3914561767 ecr 569486357], length 1440

etc...

Same problem as jedisct1/bitbar-dnscrypt-proxy-switcher/issues/5.

networksetup behavior now depends on the type of user running it:

networksetup Command
Starting with macOS 10.15.5, the networksetup command behaves differently when run as a standard user versus an admin user. Standard users can do the following:
• 1. Read various network settings
• 2. Turn Wi-Fi power on or off (networksetup -setairportpower en0 on)
• 3. Change the Wi-Fi access point (networksetup -setairportnetwork en0
ExampleWiFiAP)
Other network settings can no longer be modified by standard users via networksetup.
For admin users, networksetup will continue to behave as it has in previous releases of macOS, provided System Preferences > Security & Privacy > Advanced… > “Require an administrator password to access system-wide preferences” is unchecked (which is the default state). If it is checked, admins will be bound by the same constraints as standard users when
using networksetup.

https://mrmacintosh.com/whats-new-in-the-macos-catalina-10-15-5-update-19f96/

To get mine working, I prepended sudo onto the networksetup -setdnsservers call and set up sudoers to allow my non-admin user to run networksetup, as described here. But that's not optimal (due to needing to edit sudoers) and isn't a general fix.

J .. I know there are different ways to install, but if folks take your recommendation to install via brew, perhaps you can add a "sudo brew services restart"?

Thanks .. menu is working great.

Dear Jay,

The plugin was giving me a syntax error. I found that a curly bracket is missing in line 1957 of version 1.0.17 as follows:

Line 1957 is:
syslog=$(echo "$syslogline" | awk -F" = " 'print $2}')
Should be:
syslog=$(echo "$syslogline" | awk -F" = " '{print $2}')

Otherwise it works great. Excellent work!

Am I correct, that click on "DNSCrypt" should switch resolving to local proxy? That doesn't work for me. Nothing happens when I click on it.

If I chose 127.0.0.1 manually in my network settings it correctly shows "DNSCrypt", but, again, I can not switch to "Default DNS".

I am not sure if it is a bug or just my misunderstanding of how it is supposed to work

I have a quick question about why what I see the menu plugin reporting is not what I expect in regards to "Public DNS Information".

I've set my configuration in the dnscrypt-proxy.toml file to use adguard-dns:

server_names = ['adguard-dns']

Looking at the resolvers markdown I see the "DNS stamp" for adguard-dns is:

sdns://AQMAAAAAAAAAFDE3Ni4xMDMuMTMwLjEzMDo1NDQzINErR_JS3PLCu_iZEIbq95zkSV2LFsigxDIuUso_OQhzIjIuZG5zY3J5cHQuZGVmYXVsdC5uczEuYWRndWFyZC5jb20

Using the stamp conversion tool, I get an IP of:

176.103.130.130

However, the menu plugin reports:

I expected the two IPs to match, and therefore I don't understand where this IP of 74.125.92.100 that seems to belong to Google came from.