Whenever I do a dmesg, I noticed it is filled with SFW2-INext-DROP-DEFLT messages as shown below. What are they and can they be turned off? I have seen these even on LEAP 42.1.
You could allow UDP 5353 traffic; this would presumably do nothing
“bad” since nothing on your box probably listens to it, but it does mean
you’re opening a socket unnecessarily. Still, it’s the easiest way to get
rid of the messages, and since that’s what you have described as the
“problem” I am providing the wrong way to get rid of that problem.
You could define a rule that drops things silently, rather than having
the final drop-all-and-log rule get hit.
You could find whatever is using mDNS and disable it. I’d probably
start with this, though it’s probably the most work. Having systems using
mDNS unnecessarily is just wasting bandwidth, and probably causing similar
messages on all kinds of systems all over your network.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
First, I agree that you should investigate the source of the traffic.
It might be mDNS, but since we’re talking about “dumb” IP Tables, it really might be any UDP traffic over port 5353.
Determining the source IP address would at least identify the machine emanating the traffic if not the app or why.
If the log entry doesn’t specify the source, then you might want to run Wireshark to get more info on these packets.
If you’re really skilled at using Wireshark you might also take a look at the payload and headers to get more clues.
Parsing the name of traffic "SFW2-INext-DROP-DEFLT",
On 12/21/2016 11:46 AM, tsu2 wrote:
>
> Since I can’t Google up exactly what “INext” is supposed to stand for,
> I’m making a very wild guess it might be something close to
>
> “I Network extension”
>
> Wildly Guessing,
Not bad; I’m going to educated-ly (I like the SUSE firewall and play with
it a fair bit) guess that it means “IN” (traffic coming into the system)
and “ext” (via something assigned to the external zone, or something not
assigned to any zone at all which by default gets lumped into the external
zone).
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
BTW - Silly me, talking about Wireshark to determine the source.
The IPv6 source address is there in the log.
I assume that the following <might> return the Hostname
ping6 -N fe80:0000:0000:0000:0266:77ff:fe88:9900
That looks like a link-local address to me, so I don’t think that you’ll get a match if you also look in any DHCP6 records.
But, as I originally suggested, you can use Wireshark if you can’t locate this IPv6 address any other way.
My new speculation is that there is some device/machine sending out queries to find another machine.
This is how IPv6 works, it doesn’t use broadcasts like IPv4, ARP and other similar are no longer in the IPv6 world… In IPv6 everything is a directed connection, although there are some functions like this that approximate what broadcasts used to do.
Yes… Even in the world of TCP/IP you have this doublespeak, “We don’t support that any more, but this is what we now do (without saying it’s really close to the same)”
If what I’m speculating is the case, then
It uses bandwidth, but very minimal.
Unlike broadcasts like ARP, not every machine has to process the request and decide whether to respond. Although it should not require a FW rule, a directed connection attempt to something else should just be dropped by the NIC or very, very lowest layers of the OS.
This kind of request on the network should be normal, but only “as needed” and not continuously. If you see exactly the same log entries and not variations of the same, then it should be addressed as any other name resolution issue… Either provide a better way to resolve the request (The target machine is not configured with an IPv6 address? No IPv6 entries in DNS?) or when the offending machine is found, disable its IPv6 if it’s not necessary.
I am not sure I do understand what you said above. My computer is just installed with OpenSuSE LEAP 42.2 as a Linux desktop computer with a capability to print to a network printer.
First, you should know what IP addressing is (pls look it up if you don’t know).
There is IPv4 addressing and IPv6 addressing, completely different ways for machines to identify themselves on a network.
From what you posted, some machine on your network is trying to find another machine.
The machine sending out the queries is the “source”(SRC) in what you posted.
It’s looking for a machine with the destination (DST) address.
It may be that in your network you only need and use IPv4 addresses, which is why something might not have an IPv6 address, but nonetheless some machine or device is still trying to look for another machine with that IPv6 address.
So, more than likely you need to find the machine with that SRC address and turn off IPv6 or…
If you’re really using IPv6 addressing in your LAN, then you need to fix why the DST address can’t be found.
Anything in your network could be the culprit… It could be your openSUSE itself, it could be your router/gateway, it coould be an IP camera or a network connected TV or <anything> that is connected to your network.
You can start by looking at your openSUSE itself… run the following in a console (terminal app) like Konsole. It will display <all> the addresses on every network interface on your machine. None of them should match either the SRC or DST addresses. You need to do something like this on every other machine in your network (I’d probably not suspect a Windows box, since it’s more likely than other machines to have IPv6 on and working properly).
The weird thing is the destination address is the same:** ff02:0000:0000:0000:0000:0000:0000:00fb
**The source address (fe80:0000:0000:0000:6670:02ff:fe2f:74d8) is the ipv6 address of my machine.
The source add destination ports are 5353.
I have no idea what program/service might be trying to reach ff02:0000:0000:0000:0000:0000:0000:00fb, any idea how to find this out?
The problem seems to be the avahi-daemon that implements the “zerconf” network protocol (I don’t know why is used for, it’ seems to be related to finding other devices and printers)
Here’s a bug that have been reported: https://bugzilla.opensuse.org/show_bug.cgi?id=959707
Well CUPS does make use of it for network printer discovery (via avahi-daemon), but as others have mentioned if it is of concern it’s best to locate the source of the traffic and analyse it further.