4

I got these messages in system log. They happened when some of my partners upgrade there machine to Windows 10.

I found some related topics on the internet and they said I can safely ignore the errors. But network admin warning me about my machine is sending the malicious traffic.

I consider what these logs mean? and how to make my machine stop sending malicious traffic?

I am using Ubuntu 14.04.

Nov 30 09:17:08 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.105.
Nov 30 09:17:08 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.105.
Nov 30 09:17:08 vinhphat avahi-daemon[890]: Invalid response packet from host fe80::8ca7:d096:794a:6295.
Nov 30 09:17:08 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.101.
Nov 30 09:18:01 vinhphat avahi-daemon[890]: message repeated 3 times: [ Invalid response packet from host 192.168.100.101.]
Nov 30 09:18:01 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.105.
Nov 30 09:18:54 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.101.
Nov 30 09:19:36 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.105.
Nov 30 09:19:36 vinhphat avahi-daemon[890]: Invalid response packet from host 192.168.100.101.

Thks,

PhatHV
  • 1,203

1 Answers1

3

It could very well be a protocol issue with the other hosts. What type of hosts are .101 and .105? Are both Windows 10 machines?

There's a know bug on Avahi in this regard, seem to happen with both OSX and Windows 10 hosts: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1342400

An explanation of the interaction that causes the log can be found at: https://github.com/lathiat/avahi/issues/10/#issuecomment-131972196:

The patch in that bug deals with OSX mDNS response packets that include Additional RRs, but do not include Answer RRs. Windows 10 does something different. It sends responses to all mDNS queries, whether or not it has any records for those requests. That is, it responds with a mDNS packet containing 0 Answer RRs and 0 Additional RRs. This appears to me to be in violation of RFC 6762 (Multicast DNS) Section 6, which states "A Multicast DNS responder MUST only respond when it has a positive, non-null response to send, or it authoritatively knows that a particular record does not exist." I don't know how to file a bug with Microsoft, but IMHO this should probably be addressed on their side.

Anders Olsson
  • 563
  • 1
    I already read the topic. Their solution is ignore the logs but I want to stop traffic spam and understand what the logs mean. – PhatHV Dec 03 '15 at 10:45
  • 1
    In the comments on the bug on Launchpad, there is a link to a .deb where this is fixed. Seems to only have been tested on 15.10, though, so might not work on your 14.04.

    Another option would be to try the patch (also linked in the comments) on your version of the package. This is of course also not guaranteed to work, depending on how much the code has changed between your version and the one that is base for this patch. This AU answer gives clear instructions on how to rebuild an Ubuntu package: http://askubuntu.com/a/81889/456122, you would just need to insert the patch before building.

     – Anders Olsson Dec 04 '15 at 06:40
  • My suggestion would be to ignore the logs, though. They're not terribly frequent, and are know to not be an indicator of problems. To bring them further out of sight you could also redirect logs from that particular service to it's own file, by configuring Rsyslog. – Anders Olsson Dec 04 '15 at 06:47
  • I dont't know what logs about "Invalid response" mean. Do I send the requests to that hosts or they send request to my machine? – PhatHV Dec 04 '15 at 07:50
  • It's in the nature of Avahi that requests and responses are being passed around all the time, it's what it's supposed to do. Adding details on the cause of the logs in the answer. – Anders Olsson Dec 04 '15 at 08:16
  • Thanks you. I may try to disable multicast on avahi to stop reproduce problems. – PhatHV Dec 04 '15 at 09:28