I have Yamaha receiver HTR-4066 and I’m uses internet radio streams. With Knot DNS it doesn’t work. If I set (on receiver) DNS server to 8.8.8.8, it’s work right.
DNS traffic with Knot DNS (without forwarding)
QUERY
30 29.821619 192.168.200.104 192.168.200.1 DNS 82 Standard query 0x3412 A radioyamaha.vtuner.com
Looking at my DNS answers using wire shark, they have the IP DF flag set to 0x02 also, in wireshark, there is a hint that this means “do not fragment”, which I take to translate to this is a whole package of information, do not split it if it is routed through somewhere ?
Flags
A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):
bit 0: Reserved; must be zero.[note 1]
bit 1: Don’t Fragment (DF)
bit 2: More Fragments (MF)
If the DF flag is set, and fragmentation is required to route the packet, then the packet is dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. It can also be used for Path MTU Discovery, either automatically by the host IP software, or manually using diagnostic tools such as ping or traceroute. For unfragmented packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the MF flag set. The last fragment has a non-zero Fragment Offset field, differentiating it from an unfragmented packet.
As the first one - sorry for my english Isn’t very good.
Yes, “my” DF mean “do not fragment”. I have only basic knowledge about low level networking. I understand DF mark and between Turris Omnia router and Yamaha receiver is only cable. No additional devices like switch etc.
My idea is that firmware in Yamaha receiver is “simple” and doesn’t understand the DF flag (throw away packet with DF).
I am of the same knowledge My interest in your problem was because I am trying to solve another “simple appliance” which isn’t behaving since the Turris arrived…
I too have a Yamaha RX-V1073 and I have just tried the net radio out on it. It works OK, I was able to load the station list and then stream BBC Radio 2.
I would note, I am not using Knot but dnsmasq as the DNS, I followed the instructions in this thread:
I also changed /etc/config/resolver as follows to change the port to not conflict with dnsmasq and run Unbound:
option port ‘53’ to option port ‘153’
option prefered_resolver ‘kresd’ to option prefered_resolver ‘unbound’
Here’s the pcap of all the data from turning on, then eventually streaming the radio station:
„Slow DNS resolution - just me?“ I have same setting (port for Dnsmasq set to 0), but it’s right, because Turris Omnia uses Knot DNS reslover (kresd) on port 53. I tried stop kresd and launched Dnsmasq on port 53. Yamaha receiver worked right.
I don’t use standart setting, because if I turn on DNS forwarding (to DNS of my ISP), DNS not work. My ISP have problem with DNSSEC (I thing). Therefore I override DNS from DHCP to 217.31.204.130, 193.29.206.206, 2001:1488:800:400::130, 2001:678:1::206. It’s servers of CZ.NIC and the DNS forwarding works.
I recorded 4 situations (different configurations):
All communication was with filter on MAC address of Yamaha receiver on all interfaces.
If I will have new information, I will write the solution (or main problem) to this thread. My receiver works with Google DNS - It’s sufficient for me, because the time is expensive. I will try to ask more people about this topic.
Hello,
I experienced the same behaviour last week with my DENON AVR-X2200W. So this issue is not related only to Yamaha Receiver.
The Internet Radio was not working as expected. There are two different modes - Streaming Stations and PodCasts. The PodCasts worked nicely - but streaming Radio Stations did not work at all.
I tried many things and at eventually I gave the DENON a static IP Address and an DNS server outside of my network.
Then everything worked again seamlessly - so I found the same work around.
So I edited my resolver config file to put the preferred back to kresd and ensured the port is 53
Updated libuv file first, then knot-resolver.
I’ve set dnsmasq port to ‘0’ in the config.
dnsmasq also required option 6 set to my router IP (192.168.1.1) to work with kresd
disabled unbound
enabled kresd
rebooted
“netstat -nlp | grep :53” shows kresd is listening on port 53 on the router.
I still have DHCP (from dnsmasq) and I have DNS but my dumb device (Garmin scales) is not getting all the data.
For some reason it will resolve clock.garmin.com and then do some NTP with that, then it will attempt to resolve glod.garmin.com, the DNS server will respond with the details, but the Garmin device then asks again!
If I revert back to dnsmasq-full providing DNS the Garmin device will proceed from the first answer back for gold.garmin.com to start an encrypted conversation (still doesn’t finish the conversation, but thats not the point here…)
So I am not sure that this version of libuv / kresd fixes these ‘dumb’ devices unfortunately… there is still something wrong!!!
Encountered same issue with my Denon AVR-X1200W, unfortunately had no time yet for extensive debugging and packet capturing, to see why it does not like Omnia provided DNS resolution.
At least we have eliminated the possibility of DF being the cause. Thanks for the feedback.
I suspect this might be related to the DNS compression. I’ll try to prepare libknot version that will disable DNS compression altogether as an experiment and let you know.
There’s another version that has a DNS compression completely disabled (1.1.1-3+nocompr.2). You need to install all packages in https://howl.labs.nic.cz/omnia/ for it to work.
If it still doesn’t work a pcaps with working and non-working DNS traffic would be much much appreciated.
So I installed the packages
libuv_1.10.1-1_mvebu.ipk
knot-libdnssec_2.3.2-1_mvebu.ipk
knot-libzscanner_2.3.2-1_mvebu.ipk
knot-libknot_2.3.2-1_mvebu.ipk
knot-resolver_1.1.1-3+nocompr.2_mvebu.ipk
Using “opkg install libuv_1.10.1-1_mvebu.ipk” and “opkg install knot-*”
root@turris:~/omnia# opkg install libuv_1.10.1-1_mvebu.ipk
Installing libuv (1.10.1-1) to root…
Configuring libuv.
Warning: Locally installed packages will be removed with the next automatic update!
root@turris:~/omnia# opkg install knot-*
Upgrading knot-libdnssec on root from 2.3.0-2 to 2.3.2-1…
Configuring knot-libdnssec.
Warning: Locally installed packages will be removed with the next automatic update!
Upgrading knot-libknot on root from 2.3.0-2 to 2.3.2-1…
Removing obsolete file /usr/lib/libknot.so.3.
Removing obsolete file /usr/lib/libknot.so.3.0.0.
Configuring knot-libknot.
Warning: Locally installed packages will be removed with the next automatic update!
Upgrading knot-libzscanner on root from 2.3.0-2 to 2.3.2-1…
Configuring knot-libzscanner.
Warning: Locally installed packages will be removed with the next automatic update!
Upgrading knot-resolver on root from 1.1.1-3 to 1.1.1-3+nocompr.2…
Configuring knot-resolver.
[ -z ]
/etc/init.d/dnsmasq restart
sleep 2
/etc/init.d/resolver restart
Called /etc/init.d/kresd stop
Called /etc/init.d/kresd start
grep: ./etc/services_wanted: No such file or directory
grep: ./usr/lib/opkg/info/base-files.list: No such file or directory
Warning: Locally installed packages will be removed with the next automatic update!
Then fired up wireshark with a tcpdump of br-lan and pppoe-wan
First capture was with dnsmasq at 53 and kresd at 153. DNS responses are picked up fine by the Garmin device, it still fails at the encrypted discussion with gold.garmin.com. So dnsmasq works with the device (as expected).
Second set was with resolver edited to put kresd at port 53 and then dnsmasq with port 0 (DNS disabled). Same behaviour as before, DNS resolves for clock.garmin.com and Garmin NTP’s successfully, then Garmin devices asks DNS for gold.garmin.com, Kresd answers, Garmin ignores and asks again…
Thanks. I have compared the packets sent back and I don’t see any differences that should make the Garmin to drop the packets in the DNS part. dnsmasq even uses partial compression (It compresses the .net part in the gold. CNAME RDATA part), so that shouldn’t be a problem.
I’ll give it some more thought and get back to you. Thanks for the pcaps.
And of course, if anyone has an idea what’s going on, I would be very happy to hear your hypotheses.
@jiberjaber could you try disable checksum offloading on the interfaces and retry again?
Something like:
# for if in br-lan eth0 eth1 eth2; do ethtool --offload $if rx off tx off gso off; done
It should look like this afterwards:
# ethtool --show-offload br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: off
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: off
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
udp-fragmentation-offload: off [requested on]
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [requested on]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
Reenable with:
# for if in br-lan eth0 eth1 eth2; do ethtool --offload $if rx on tx on gso on; done
I noticed on inspection of the two pcap files that the response for the gold.garmin.com in the kresd version (line 17) is a longer data length (24) than the dnsmasq one (line 14) (21):
Kresd:
Frame 17: 217 bytes on wire (1736 bits), 217 bytes captured (1736 bits) on interface 0
Ethernet II, Src: CzNicZSP_00:38:5e (d8:58:d7:00:38:5e), Dst: GarminIn_42:d6:d4 (14:8f:21:42:d6:d4)
Internet Protocol Version 4, Src: turris.lan (192.168.1.1), Dst: GarminIndexScales.lan (192.168.1.24)
User Datagram Protocol, Src Port: domain (53), Dst Port: 62672 (62672)
Domain Name System (response)
[Request In: 16]
[Time: 0.006959000 seconds]
Transaction ID: 0xc26f
Flags: 0x8180 Standard query response, No error
Questions: 1
Answer RRs: 3
Authority RRs: 0
Additional RRs: 0
Queries
Answers gold.garmin.com: type CNAME, class IN, cname gold.garmin.com.edgekey.net
Name: gold.garmin.com
Type: CNAME (Canonical NAME for an alias) (5)
Class: IN (0x0001)
Time to live: 157
Data length: 29
CNAME: gold.garmin.com.edgekey.net gold.garmin.com.edgekey.net: type CNAME, class IN, cname e8867.b.akamaiedge.net
Name: gold.garmin.com.edgekey.net
Type: CNAME (Canonical NAME for an alias) (5)
Class: IN (0x0001)
Time to live: 68 Data length: 24
CNAME: e8867.b.akamaiedge.net e8867.b.akamaiedge.net: type A, class IN, addr 104.66.84.213
Name: e8867.b.akamaiedge.net
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 19
Data length: 4
Address: e8867.b.akamaiedge.net (104.66.84.213)
Dnsmasq:
Frame 14: 165 bytes on wire (1320 bits), 165 bytes captured (1320 bits) on interface 0
Ethernet II, Src: CzNicZSP_00:38:5e (d8:58:d7:00:38:5e), Dst: GarminIn_42:d6:d4 (14:8f:21:42:d6:d4)
Internet Protocol Version 4, Src: turris.lan (192.168.1.1), Dst: GarminIndexScales.lan (192.168.1.24)
User Datagram Protocol, Src Port: domain (53), Dst Port: 57688 (57688)
Domain Name System (response)
[Request In: 13]
[Time: 0.007111000 seconds]
Transaction ID: 0xda92
Flags: 0x8180 Standard query response, No error
Questions: 1
Answer RRs: 3
Authority RRs: 0
Additional RRs: 0
Queries
Answers gold.garmin.com: type CNAME, class IN, cname gold.garmin.com.edgekey.net
Name: gold.garmin.com
Type: CNAME (Canonical NAME for an alias) (5)
Class: IN (0x0001)
Time to live: 181
Data length: 29
CNAME: gold.garmin.com.edgekey.net gold.garmin.com.edgekey.net: type CNAME, class IN, cname e8867.b.akamaiedge.net
Name: gold.garmin.com.edgekey.net
Type: CNAME (Canonical NAME for an alias) (5)
Class: IN (0x0001)
Time to live: 37 Data length: 21
CNAME: e8867.b.akamaiedge.net e8867.b.akamaiedge.net: type A, class IN, addr 104.66.84.213
Name: e8867.b.akamaiedge.net
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 8
Data length: 4
Address: e8867.b.akamaiedge.net (104.66.84.213)
Will do, do you want me to try:
checksum = on
dnsmasq & kresd
checksum = off
dnsmasq & kresd
Done, but same result I’m afraid…
Kresd - repeated DNS request and ignore
Dnsmasq - DNS fine.
I just noticed that the wlan isn’t in the list of interfaces, the Garmin is wireless…
(just added wlan0 and wlan1 to the command, re-ran the test, same result )
root@turris:~# opkg install ethtool
Installing ethtool (4.5-1) to root…
Downloading https://api.turris.cz/openwrt-repo/omnia/packages//packages/ethtool_4.5-1_mvebu.ipk.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29309 100 29309 0 0 82264 0 --:–:-- --:–:-- --:–:-- 84221
Configuring ethtool.
root@turris:~# ethtool --show-offload br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [requested on]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
root@turris:~# vim /etc/config/resolver
root@turris:~# vim /etc/config/dhcp
root@turris:~# for if in br-lan eth0 eth1 eth2; do ethtool --offload $if rx off tx off gso off; done
Cannot change rx-checksumming
Actual changes:
tx-checksumming: off
tx-checksum-ip-generic: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: off
Cannot change rx-checksumming
Actual changes:
tx-checksumming: off
tx-checksum-ipv4: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
generic-segmentation-offload: off
Cannot change rx-checksumming
Actual changes:
tx-checksumming: off
tx-checksum-ipv4: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
generic-segmentation-offload: off
Cannot change rx-checksumming
Actual changes:
tx-checksumming: off
tx-checksum-ipv4: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
generic-segmentation-offload: off
root@turris:~# ethtool --show-offload br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: off
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: off
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
udp-fragmentation-offload: off [requested on]
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [requested on]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
Isn’t very good.
My interest in your problem was because I am trying to solve another “simple appliance” which isn’t behaving since the Turris arrived…
)