Yamaha receiver problem with Knot DNS


#1

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

0000   d8 58 d7 00 61 35 00 a0 de a4 88 5b 08 00 45 00  .X..a5.....[..E.
0010   00 44 00 21 00 00 80 11 28 cd c0 a8 c8 68 c0 a8  .D.!....(....h..
0020   c8 01 04 d1 00 35 00 30 62 89 34 12 01 00 00 01  .....5.0b.4.....
0030   00 00 00 00 00 00 0b 72 61 64 69 6f 79 61 6d 61  .......radioyama
0040   68 61 06 76 74 75 6e 65 72 03 63 6f 6d 00 00 01  ha.vtuner.com...
0050   00 01                                            ..

RESPONSE
31 29.821861 192.168.200.1 192.168.200.104 DNS 132 Standard query response 0x3412 A radioyamaha.vtuner.com CNAME primary13.vtuner.com A 198.23.79.227

0000   00 a0 de a4 88 5b d8 58 d7 00 61 35 08 00 45 00  .....[.X..a5..E.
0010   00 76 ae 82 40 00 40 11 7a 39 c0 a8 c8 01 c0 a8  .v..@.@.z9......
0020   c8 68 00 35 04 d1 00 62 12 2f 34 12 81 80 00 01  .h.5...b./4.....
0030   00 02 00 00 00 00 0b 72 61 64 69 6f 79 61 6d 61  .......radioyama
0040   68 61 06 76 74 75 6e 65 72 03 63 6f 6d 00 00 01  ha.vtuner.com...
0050   00 01 c0 0c 00 05 00 01 00 00 00 80 00 0c 09 70  ...............p
0060   72 69 6d 61 72 79 31 33 c0 18 09 70 72 69 6d 61  rimary13...prima
0070   72 79 31 33 c0 18 00 01 00 01 00 00 00 84 00 04  ry13............
0080   c6 17 4f e3      

In next step receiver repeat several DNS request.

DNS traffic with 8.8.8.8

QUERY
33 7.095759 192.168.200.104 8.8.8.8 DNS 82 Standard query 0x3412 A radioyamaha.vtuner.com

0000   d8 58 d7 00 61 35 00 a0 de a4 88 5b 08 00 45 00  .X..a5.....[..E.
0010   00 44 00 28 00 00 80 11 a1 60 c0 a8 c8 68 08 08  .D.(.....`...h..
0020   08 08 04 d0 00 35 00 30 db 24 34 12 01 00 00 01  .....5.0.$4.....
0030   00 00 00 00 00 00 0b 72 61 64 69 6f 79 61 6d 61  .......radioyama
0040   68 61 06 76 74 75 6e 65 72 03 63 6f 6d 00 00 01  ha.vtuner.com...
0050   00 01                                            ..

RESPONSE
34 7.097451 8.8.8.8 192.168.200.104 DNS 122 Standard query response 0x3412 A radioyamaha.vtuner.com CNAME primary13.vtuner.com A 198.23.79.227

0000   00 a0 de a4 88 5b d8 58 d7 00 61 35 08 00 45 00  .....[.X..a5..E.
0010   00 6c a5 a2 00 00 39 11 42 be 08 08 08 08 c0 a8  .l....9.B.......
0020   c8 68 00 35 04 d0 00 58 72 c7 34 12 81 80 00 01  .h.5...Xr.4.....
0030   00 02 00 00 00 00 0b 72 61 64 69 6f 79 61 6d 61  .......radioyama
0040   68 61 06 76 74 75 6e 65 72 03 63 6f 6d 00 00 01  ha.vtuner.com...
0050   00 01 c0 0c 00 05 00 01 00 00 02 1b 00 0c 09 70  ...............p
0060   72 69 6d 61 72 79 31 33 c0 18 c0 34 00 01 00 01  rimary13...4....
0070   00 00 02 1b 00 04 c6 17 4f e3

In next step receiver establish TCP communication with 198.23.79.227.


I see one main differences. Knot DNS sets DF flag (0x02), 8.8.8.8 is without flags (0x00).

It’s a right way? It’s important (DF) or the problem is elsewhere?


Settings for spotify connect
#2

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 ?

See https://en.wikipedia.org/wiki/IPv4

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.


#3

As the first one - sorry for my english :slight_smile: 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).


#4

I am of the same knowledge :slight_smile: 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:

https://transfer.sh/Y6yLo/yamaha161118a.pcapng

Hope that helps?


#5

Thanks for the tips.

„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.


#6

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.


#7

You won’t believe it, until you see it… the level of dumbness in the dumb devices are exceeding any limits.

The MR here: https://gitlab.labs.nic.cz/knot/resolver/merge_requests/78 should fix the DF issue. I have no idea why it should cause the IP (or UDP or DNS) packets to be seen as invalid, but …

Packages for testing are available here: https://howl.labs.nic.cz/omnia/

Please proceed with caution, install libuv first and then knot-resolver package.


#8

Thanks for patch. I tried it, but it isn’t solution. Receiver repeatedly send DNS query. https://transfer.sh/DCog9/dump.pcap


#9

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!!!

Any ideas?


#10

Yes, write to Garmin support (product support generally). I wrote to Yamaha support, but… I know, that I have only small chance for solution.


#11

Yes already have done as I can’t be sure if this is just a Garmin or just an Omina issue… Or both!


#12

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.


#13

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.


#14

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.


#15

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).

https://transfer.sh/5uLtE/garmin-dnsmasq-br-lan-161122.pcapng

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…

https://transfer.sh/Xvp28/garmin-kresd-br-lan-161122.pcapng

Here’s also the resolve and dhcp config files, just in case there is something wrong there…

https://transfer.sh/12fAbx/dhcp
https://transfer.sh/RWz2O/resolver

Are there any other files you require to assist?


#16

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.


#17

@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


#18

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

or just
checksum = off
dnsmasq & kresd


#19

I just tried ethtool --show-offload br-lan so see what it is set at before I do anything and ethtool isn’t installed by default it looks…

which packages do you recommend for the testing?

ethtool - 4.5-1 - ethtool is a small utility for examining and tuning your ethernet-based network interface

??


#20

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 :frowning: )

https://transfer.sh/C18gP/garmin-dnsmasq-br-lan-161122-2.pcapng
https://transfer.sh/VYRtg/garmin-kresd-br-lan-161122-2.pcapng

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]