lathiat
Wireshark reporting reflected mDNS responses as being malformed
I'm trying to separate some IOT devices onto a VLAN. I've setup avahi-daemon to reflect MDNS traffic between my main LAN and the new VLAN. I have a terrible issue with resolving mDNS domain names with this setup, and using wireshark to inspect mdns traffic reveals the following:
Original packet:
0000 01 00 5e 00 00 fb 48 e1 e9 32 ca c7 08 00 45 00 ..^...H..2....E.
0010 00 f9 e5 10 00 00 ff 11 e6 fe c0 a8 4d 40 e0 00 ............M@..
0020 00 fb 14 e9 14 e9 00 e5 2e 4b 00 00 84 00 00 00 .........K......
0030 00 01 00 00 00 05 04 5f 68 61 70 04 5f 74 63 70 ......._hap._tcp
0040 05 6c 6f 63 61 6c 00 00 0c 00 01 00 00 11 94 00 .local..........
0050 0e 0b 4d 53 47 31 30 30 2d 63 61 63 37 c0 0c c0 ..MSG100-cac7...
0060 27 00 10 80 01 00 00 11 94 00 4b 04 63 23 3d 32 '.........K.c#=2
0070 04 66 66 3d 32 14 69 64 3d 46 33 3a 42 45 3a 36 .ff=2.id=F3:BE:6
0080 37 3a 41 42 3a 31 30 3a 45 39 09 6d 64 3d 4d 53 7:AB:10:E9.md=MS
0090 47 31 30 30 06 70 76 3d 31 2e 31 04 73 23 3d 31 G100.pv=1.1.s#=1
00a0 04 73 66 3d 30 04 63 69 3d 34 0b 73 68 3d 52 64 .sf=0.ci=4.sh=Rd
00b0 6f 62 75 51 3d 3d c0 27 00 21 80 01 00 00 00 78 obuQ==.'.!.....x
00c0 00 0f 00 00 00 00 13 92 06 6d 74 37 36 38 37 c0 .........mt7687.
00d0 16 c0 9e 00 01 80 01 00 00 00 78 00 04 c0 a8 4d ..........x....M
00e0 40 c0 27 00 2f 80 01 00 00 11 94 00 09 c0 27 00 @.'./.........'.
00f0 05 00 00 80 00 40 c0 9e 00 2f 80 01 00 00 00 78 .....@.../.....x
0100 00 05 c0 9e 00 01 40 ......@
Reflected packet
0000 01 00 5e 00 00 fb 20 6d 31 21 0f d5 08 00 45 00 ..^... m1!....E.
0010 00 f9 00 d1 40 00 ff 11 7c 7d c0 a8 5c 01 e0 00 ....@...|}..\...
0020 00 fb 14 e9 14 e9 00 e5 21 62 00 00 84 00 00 00 ........!b......
0030 00 06 00 00 00 00 04 5f 68 61 70 04 5f 74 63 70 ......._hap._tcp
0040 05 6c 6f 63 61 6c 00 00 0c 00 01 00 00 11 94 00 .local..........
0050 0e 0b 4d 53 47 31 30 30 2d 63 61 63 37 c0 0c 06 ..MSG100-cac7...
0060 6d 74 37 36 38 37 c0 16 00 2f 80 01 00 00 00 78 mt7687.../.....x
0070 00 05 c0 9e 00 01 40 c0 27 00 2f 80 01 00 00 11 ......@.'./.....
0080 94 00 09 c0 27 00 05 00 00 80 00 40 c0 35 00 01 ....'[email protected]..
0090 80 01 00 00 00 78 00 04 c0 a8 4d 40 c0 27 00 21 .....x....M@.'.!
00a0 80 01 00 00 00 78 00 08 00 00 00 00 13 92 c0 35 .....x.........5
00b0 c0 27 00 10 80 01 00 00 11 94 00 4b 04 63 23 3d .'.........K.c#=
00c0 32 04 66 66 3d 32 14 69 64 3d 46 33 3a 42 45 3a 2.ff=2.id=F3:BE:
00d0 36 37 3a 41 42 3a 31 30 3a 45 39 09 6d 64 3d 4d 67:AB:10:E9.md=M
00e0 53 47 31 30 30 06 70 76 3d 31 2e 31 04 73 23 3d SG100.pv=1.1.s#=
00f0 31 04 73 66 3d 30 04 63 69 3d 34 0b 73 68 3d 52 1.sf=0.ci=4.sh=R
0100 64 6f 62 75 51 3d 3d dobuQ==
I have observed what I think is the same problem. The issue is that the NSEC record (0x00 0x2f) in the original packet gets reordered (from the end of the original packet) in the reflected packet, to the middle of it, and this means that it is no longer valid. I patched avahi-core/server.c to skip the reflection of NSEC records and Wireshark no longer reports the packets as being malformed. If I read the Avahi source correctly, Avahi does not generate NSEC records, but mDNSResponder, on the other hand, does.
Would this result in spurious hostnames, going up into the thousands? Like my iphone hostname goes up to iphone-1729.local before I reset it. I have the same malformed packets in my wireshark. These types of hostname conflicts didn't happen nearly as often before I installed avahi.
@diothar I don't think I've seen that during my tests but you are welcome to try out my patch for this issue, it is attached. It is possible that what you are seeing is a cross-interaction of some sort between the way Avahi works & mDNSResponder works and it may need further debugging. 110-do-not-reflect-nsec-records.patch.txt
It's absolutely some interaction between Avahi and mDNSResponder. Everything Apple-related is getting hit harder. I'll try the patch regardless because my last 10 minute pcap had 3400 malformed mdns packets.
There seem to be two issues here. When avahi reflects packets it moves NSEC RRs from the additional record section to the the answer section and it probably shouldn't do it. But that's not what Wireshark doesn't like because it can parse NSEC RRs included in the answer section just fine as long as they are valid. They aren't valid because avahi doesn't understand NSEC RRs so it copies them verbatim and it all breaks if they are compressed.
