On 21/10/2018 22.22, James Knott wrote:

On 10/21/2018 04:19 PM, Carlos E. R. wrote:

...

Hi,

I get these messages in the firewall log:

<0.4> 2018-10-21 22:16:14 Legolas kernel - - - [ 5112.933551] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 <0.4> 2018-10-21 22:16:29 Legolas kernel - - - [ 5128.151646] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 <0.4> 2018-10-21 22:16:44 Legolas kernel - - - [ 5143.203427] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

I understand it is a broadcast from the router, probably trying to find information about the local network. How do I tell the firewalld to accept them? I have no idea.

Packets leaving the firewall are generally not filtered.  However, broadcasts are also not normally passed by routers.

It is not leaving, it is entering the openSUSE 15.0 machine, and being refused by firewalld. Not the router firewall, but the firewalld daemon on Leap 15 laptop. Incoming. The router generates the package. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 21/10/2018 23.01, Bruce Ferrell wrote:

On 10/21/18 1:19 PM, Carlos E. R. wrote:

...

Hi,

I get these messages in the firewall log:

<0.4> 2018-10-21 22:16:14 Legolas kernel - - - [ 5112.933551] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 <0.4> 2018-10-21 22:16:29 Legolas kernel - - - [ 5128.151646] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 <0.4> 2018-10-21 22:16:44 Legolas kernel - - - [ 5143.203427] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

I understand it is a broadcast from the router, probably trying to find information about the local network. How do I tell the firewalld to accept them? I have no idea.

Any IP address that has 224 as it's first octet is called multicast, not broadcast.

Although it may seem to be the same thing, it's important to understand the difference.

At one time, long ago there was an experimental internet backbone called "The Mbone"... See this wikipedia entry:

https://en.wikipedia.org/wiki/Mbone

multicast traffic IS generally dropped by routers and should be kept INSIDE YOUR firewall, not passed out through it nor allowed in.

If you have a router emitting multicast traffic, it so so that it or some process on it can coordinate with other instances of it's own "kind" on the LAN the particular interface is connected to.

If you use tcpdump/wireshark on a network with OS X/Macs/Avahi/Windows Bonjour operating, you'll see a lot of these packets.  Multicast packets are how the OS X network advertising protocol(s) work.  I've also worked in places where multicast packets were used to coordinate bandwdth sharing between local instances of high bandwidth applications (I'm using/want to use X bandwidth), listening instances would themselves adjust and advertise to that.

Ok, so how do I tell the openSUSE firewalld to allow those packages in? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On Sun, 21 Oct 2018 23:38:01 +0200 "Carlos E. R." wrote:

...

Ok, so how do I tell the openSUSE firewalld to allow those packages in?

Other machines running Leap 42.3 and SuSEfirewal2 in the same network do not complain, and I use:

FW_IGNORE_FW_BROADCAST_EXT="no"

I'm not clear. Is the firewall on a machine that serves some other purpose (server or desktop etc) or is it a pass-through firewall between your router and your LAN? Why do you want to let them in if you don't know what they are for? I would suggest finding out what they are before allowing them to propagate. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 22 Oct 2018 01:54:06 +0200 (CEST) "Carlos E. R." wrote:

El 2018-10-21 a las 22:46 +0100, Dave Howorth escribió:

...

I'm not clear. Is the firewall on a machine that serves some other purpose (server or desktop etc) or is it a pass-through firewall between your router and your LAN?

It is the firewall in the same machine that reports the log, running Leap 15.0. This laptop.

...

Why do you want to let them in if you don't know what they are for? I would suggest finding out what they are before allowing them to propagate.

It is my router who is sending the packages. I have no reason to block them.

But equally, you have no reason to allow them :) I would suggest that good practice is to block all inbound traffic unless you know exactly what it is. That is the default presumption should be to block.

Router sends multicast. One laptop's firewall blocks it from getting inside the laptop. I don't want it to block it.

But again, if you don't know what it is, why not block it? Is anything broken? But as Andrei says a search throws up lots of info. I used 'igmp firewalld' as search terms. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/21/18 2:38 PM, Carlos E. R. wrote:

On 21/10/2018 23.23, Carlos E. R. wrote:

...

On 21/10/2018 23.01, Bruce Ferrell wrote:

...

On 10/21/18 1:19 PM, Carlos E. R. wrote: ...

...

...

multicast traffic IS generally dropped by routers and should be kept INSIDE YOUR firewall, not passed out through it nor allowed in.

If you have a router emitting multicast traffic, it so so that it or some process on it can coordinate with other instances of it's own "kind" on the LAN the particular interface is connected to.

If you use tcpdump/wireshark on a network with OS X/Macs/Avahi/Windows Bonjour operating, you'll see a lot of these packets.  Multicast packets are how the OS X network advertising protocol(s) work.  I've also worked in places where multicast packets were used to coordinate bandwdth sharing between local instances of high bandwidth applications (I'm using/want to use X bandwidth), listening instances would themselves adjust and advertise to that. Ok, so how do I tell the openSUSE firewalld to allow those packages in? Other machines running Leap 42.3 and SuSEfirewal2 in the same network do not complain, and I use:

FW_IGNORE_FW_BROADCAST_EXT="no"

I'm running leap 15 so there is a module in yast for it. If you still have the iptables cli available you could do something like: iptables -A INPUT -s 224.0.0.0/8 -i <external interface name> -j ACCEPT I tend to create separate "chains" for special purpose rule sets and add the chain to the beginning of the firewall rule set... It makes keeping track easier. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [10-21-18 20:15]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2018-10-22 a las 00:03 +0200, David Haller escribió:

...

Hello,

On Sun, 21 Oct 2018, Carlos E. R. wrote: [..]

...

<0.4> 2018-10-21 22:16:44 Legolas kernel - - - [ 5143.203427] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

I understand it is a broadcast from the router, probably trying to find information about the local network. How do I tell the firewalld to accept them? I have no idea.

https://firewalld.org/documentation/service/examples.html

Last example, "mdns".

That example is incoming to port 5353 (mdns), I underrstand. But my problem is not coming on ANY port. See log entry carefully:

<0.4> 2018-10-21 23:15:13 Legolas kernel - - - [ 8651.485628] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

There is no port listed there. Proto=2, that's IGMP.

Anyway, mdns is already opened in the firewall. Firewall Configuration GUI, Runtime, Zone 'public', service 'mdns'.

- -- Cheers Carlos E. R.

(from openSUSE 15.0 (Legolas))

-----BEGIN PGP SIGNATURE-----

iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCW80WRBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVMcQAn2F884HowwN1kjc2LO2X 3xASGd1EAKCQNaSYwKQ1ReXpFfzKdNq5OTf9mQ== =4P75 -----END PGP SIGNATURE-----

from: https://www.centos.org/forums/viewtopic.php?t=60395 (following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT but you could have done that yourself. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

22.10.2018 8:46, Carlos E. R. пишет:

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Thanks, I'll try later.

...

but you could have done that yourself.

No, I could not. I did not, and still do not, know what to search for.

This link is among the first hits searching for "firewalld blocking multicast".

Carlos E. R. wrote:

On 22/10/2018 08.35, Andrei Borzenkov wrote:

...

22.10.2018 8:46, Carlos E. R. пишет:

...

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Thanks, I'll try later.

...

but you could have done that yourself.

No, I could not. I did not, and still do not, know what to search for.

This link is among the first hits searching for "firewalld blocking multicast".

You have to know that it is "multicast".

The address says '224.x.x.x' - 224/4 is all multicast. -- Per Jessen, Zürich (6.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 22/10/2018 09.30, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 22/10/2018 08.35, Andrei Borzenkov wrote:

...

22.10.2018 8:46, Carlos E. R. пишет:

...

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Thanks, I'll try later.

...

but you could have done that yourself.

No, I could not. I did not, and still do not, know what to search for.

This link is among the first hits searching for "firewalld blocking multicast".

You have to know that it is "multicast".

The address says '224.x.x.x' - 224/4 is all multicast.

Well, yes, but that's something I know only while I'm reading about it, like now. It is not knowledge I have.

Ah okay - I guess it's just normal for me to see them - plenty of such multicasts happening.

Still, the word "multicast" is not listed in the GUI administration tool to configure the firewalld, so the original question is still valid: how do I enable that traffic using the GUI firewalld administrative tool?

I can't help with that, but do you actually need to enable it? -- Per Jessen, Zürich (7.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

22.10.2018 11:04, Carlos E. R. пишет:

On 22/10/2018 09.30, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 22/10/2018 08.35, Andrei Borzenkov wrote:

...

22.10.2018 8:46, Carlos E. R. пишет:

...

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Thanks, I'll try later.

...

but you could have done that yourself.

No, I could not. I did not, and still do not, know what to search for.

This link is among the first hits searching for "firewalld blocking multicast".

You have to know that it is "multicast".

The address says '224.x.x.x' - 224/4 is all multicast.

Well, yes, but that's something I know only while I'm reading about it, like now. It is not knowledge I have. I confess my ignorance on it. It is not something I thought about when I saw the log entries as something I could google about, so I thought of asking others ;-)

Still, the word "multicast" is not listed in the GUI administration tool to configure the firewalld, so the original question is still valid: how do I enable that traffic using the GUI firewalld administrative tool?

You can edit direct rules also via GUI.

None of the google entries I have seen mention it. And the tool "help" menu is empty, only an "about" entry.

On 22/10/2018 13.44, Rodney Baker wrote:

On Monday, 22 October 2018 18:34:13 ACDT Carlos E. R. wrote:

You need to allow IP traffic TO the multicast address. You need to know how how multicast traffic works in relation to unicast and broadcast traffic.

Unicast traffic is one-to-one; broadcast traffic is one-to-all; multicast traffic is one-to-many.

Multicast group addresses are defined as the 224.0.0.0/4 subnet (that is, 224.0.0.0 to 239.255.255.255). Any traffic TO an address in that range is defined as multicast traffic. Multicast traffic always comes FROM a unicast address, TO the multicast group. Devices that want to receive traffic sent to that group register with their local router using an igmp join message (so you may also need to allow IGMP traffic to/through the firewall). The multicast traffic to the group address is then forwarded on all ports that have a receiver registered for that group. If there are no registered receivers for a group, the multicast traffic won't be forwarded.

Note that multicast group addresses in teh 224.0.0.0/24 range are reserved or "well known" multicast addresses used by routing protocols etc. For example, OSPF uses 224.0.0.5 and 224.0.0.6, EIGRP uses 224.0.0.10, PIM uses 224.0.0.39 and 224.0.0.40.

It is 224.0.0.1 Ok, I understand, more or less, but then how do I do that on the firewalld GUI? The suggestion is to do: firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT which I will apply blindly this evening, without really understanding what they do or if they will do the trick or need other commands. Nor do I know how to undo. Maybe instead of --permanent I could use --runtime. I see no mention on those rules of the 224.0.0.1 address. SuSEfirewall2 was easy to understand. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

On Monday, 22 October 2018 22:24:32 ACDT Carlos E. R. wrote:

On 22/10/2018 13.44, Rodney Baker wrote:

...

On Monday, 22 October 2018 18:34:13 ACDT Carlos E. R. wrote:

You need to allow IP traffic TO the multicast address. You need to know how how multicast traffic works in relation to unicast and broadcast traffic.

Unicast traffic is one-to-one; broadcast traffic is one-to-all; multicast traffic is one-to-many.

Multicast group addresses are defined as the 224.0.0.0/4 subnet (that is, 224.0.0.0 to 239.255.255.255). Any traffic TO an address in that range is defined as multicast traffic. Multicast traffic always comes FROM a unicast address, TO the multicast group. Devices that want to receive traffic sent to that group register with their local router using an igmp join message (so you may also need to allow IGMP traffic to/through the firewall). The multicast traffic to the group address is then forwarded on all ports that have a receiver registered for that group. If there are no registered receivers for a group, the multicast traffic won't be forwarded.

Note that multicast group addresses in teh 224.0.0.0/24 range are reserved or "well known" multicast addresses used by routing protocols etc. For example, OSPF uses 224.0.0.5 and 224.0.0.6, EIGRP uses 224.0.0.10, PIM uses 224.0.0.39 and 224.0.0.40.

It is 224.0.0.1

Ok, I understand, more or less, but then how do I do that on the firewalld GUI?

The suggestion is to do:

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

which I will apply blindly this evening, without really understanding what they do or if they will do the trick or need other commands. Nor do I know how to undo. Maybe instead of --permanent I could use --runtime.

I see no mention on those rules of the 224.0.0.1 address.

SuSEfirewall2 was easy to understand.

224.0.0.1 is the "All hosts" multicast address - it is used by a router to address all hosts on the same network segment. This is used for host discovery. From https://www.tldp.org/HOWTO/Multicast-HOWTO-2.html; "There are some special multicast groups, say "well known multicast groups", you should not use in your particular applications due the special purpose they are destined to: - 224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces. - 224.0.0.2 is the all-routers group. All multicast routers must join that group on all it's multicast capable interfaces." The full Ipv4 multicast address space registry is here; https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xht... Unless you are specifically wanting to receive multicast traffic (for example, to participate in dynamic routing protocols e.g. RIP, eigrp, ospf, bgp or is- is), or for receiving multicast video/audio traffic, you should not worry too much about it. If you want it to work, you'll need to permit traffic to 224.0.0.0/24 on all your firewall interfaces where multicast-capable hosts exist. The IPv6 equivalent addresses (link-local scope) are FF02::1 (for all hosts) and FF02::2 (for all routers). Node-local (or interface-local) equivalents are FF01::1 and FF01::2. The full list of well-known multicast addresses for IPv6 are here: https:// www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast- addresses.xhtml -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/10/2018 14.49, Rodney Baker wrote:

On Monday, 22 October 2018 23:10:54 ACDT Rodney Baker wrote:

...

[...]

224.0.0.1 is the "All hosts" multicast address - it is used by a router to address all hosts on the same network segment. This is used for host discovery. From https://www.tldp.org/HOWTO/Multicast-HOWTO-2.html;

"There are some special multicast groups, say "well known multicast groups", you should not use in your particular applications due the special purpose they are destined to:

- 224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces. - 224.0.0.2 is the all-routers group. All multicast routers must join that group on all it's multicast capable interfaces."

The full Ipv4 multicast address space registry is here; https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xht ml

Unless you are specifically wanting to receive multicast traffic (for example, to participate in dynamic routing protocols e.g. RIP, eigrp, ospf, bgp or is- is), or for receiving multicast video/audio traffic, you should not worry too much about it.

If you want it to work, you'll need to permit traffic to 224.0.0.0/24 on all your firewall interfaces where multicast-capable hosts exist.

The IPv6 equivalent addresses (link-local scope) are FF02::1 (for all hosts) and FF02::2 (for all routers). Node-local (or interface-local) equivalents are FF01::1 and FF01::2.

The full list of well-known multicast addresses for IPv6 are here: https:// www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast- addresses.xhtml

Just as a test, I tried to ping 224.0.0.1 on my local lan and got only one response - my L3 network switch which has igmp snooping enabled by default. No other devices responded.

I then enabled ip multicast-routing on my router and turned on PIM sparse-mode on the interface for my desktop vlan. Now, when I ping 224.0.0.1, both the router and the switch respond, but if I ping 224.0.0.2, only the router responds (as expected). They're the only 2 multicast-capable devices on the network.

[I turned multicast routing off again after the test as I have no need for it at home, although we do use it extensively at work.]

Thanks for the explanation :-) That rings a bell, because that router carries TV signal. And I have an application to watch TV that currently runs in a 42.3 machine. And the person that wrote it said that the TV module uses multicast. Indeed, the help forum for that application tells people that use an intermediate AP or router or switch that they need igmp snooping on. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

On 22/10/2018 14.49, Rodney Baker wrote:

Just as a test, I tried to ping 224.0.0.1 on my local lan and got only one response - my L3 network switch which has igmp snooping enabled by default. No other devices responded.

I tried on three machines, and on all of them the ping had 100% failure. The firewall log of this machine did not reflect any hits. I guess they don't even get out. Legolas:~ # ping 224.0.0.1 PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data. ^C --- 224.0.0.1 ping statistics --- 24 packets transmitted, 0 received, 100% packet loss, time 23544ms Legolas:~ # On this machine I see more log entries, incoming from two sources and to two destinations: <0.4> 2018-10-22 21:33:13 Legolas kernel - - - [44907.911153] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 That's the one in the OP. After I turned on the printer, I also get these: <0.4> 2018-10-22 21:34:58 Legolas kernel - - - [45012.967174] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:fb:00:1e:0b:08:4c:cb:08:00 SRC=192.168.1.3 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=227 PROTO=2 The failure of these might be related to CUPS not finding the printer, has to be told of the IP. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

22.10.2018 22:52, Carlos E. R. пишет:

On 22/10/2018 14.49, Rodney Baker wrote:

...

Just as a test, I tried to ping 224.0.0.1 on my local lan and got only one response - my L3 network switch which has igmp snooping enabled by default. No other devices responded.

I tried on three machines, and on all of them the ping had 100% failure. The firewall log of this machine did not reflect any hits. I guess they don't even get out.

Legolas:~ # ping 224.0.0.1 PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data. ^C --- 224.0.0.1 ping statistics --- 24 packets transmitted, 0 received, 100% packet loss, time 23544ms

Legolas:~ #

On this machine I see more log entries, incoming from two sources and to two destinations:

<0.4> 2018-10-22 21:33:13 Legolas kernel - - - [44907.911153] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

That's the one in the OP. After I turned on the printer, I also get these:

<0.4> 2018-10-22 21:34:58 Legolas kernel - - - [45012.967174] FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:fb:00:1e:0b:08:4c:cb:08:00 SRC=192.168.1.3 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=227 PROTO=2

Destination MAC and IP are for mDNS (Avahi), but mDNS is using UDP and here PROTO=2 == IGMP. It does not match. It would be interesting to see full packet trace.

The failure of these might be related to CUPS not finding the printer, has to be told of the IP.

On 23/10/2018 10.58, Carlos E. R. wrote:

On 23/10/2018 06.56, Andrei Borzenkov wrote:

...

...

Destination MAC and IP are for mDNS (Avahi), but mDNS is using UDP and here PROTO=2 == IGMP. It does not match. It would be interesting to see full packet trace.

Ok, I'll do that this night.

I just did, got a capture, uploaded to susepaste: cer@Legolas:~> susepaste -n "Carlos E.R." -t "ethereal capture, multicast" -e 10080 /tmp/multicast.pcapng Pasted as: http://susepaste.org/60313875 http://paste.opensuse.org/60313875 Link is also in your clipboard. cer@Legolas:~> But the download of that is zero bytes. Some sugestion to upload it? Or can I just email it to you, or anybody that wants it? It is just 18KB, I could attach to the mail list, not that big. This machine is responding to the multicast. IGMPV2 Membership report group 224.0.0.251- I think that the printer is also responding. And another more interesting response: 16 39.835966537 192.168.1.133 224.0.0.251 MDNS 204 Standard query 0x0000 PTR _nfs._tcp.local, "QM" question PTR _ftp._tcp.local, "QM" question PTR _webdav._tcp.local, "QM" question PTR _webdavs._tcp.local, "QM" question PTR _sftp-ssh._tcp.local, "QM" question PTR _smb._tcp.local, "QM" question PTR _afpovertcp._tcp.local, "QM" question PTR LEGOLAS._smb._tcp.local PTR Legolas._sftp-ssh._tcp.local Also on IPv6, from another machine, I think: 13 36.383238110 fe80::f034:b90c:d529:7757 ff02::fb MDNS 270 Standard query 0x0000 PTR _nfs._tcp.local, "QM" question PTR _ftp._tcp.local, "QM" question PTR _webdav._tcp.local, "QM" question PTR _webdavs._tcp.local, "QM" question PTR _sftp-ssh._tcp.local, "QM" question PTR _smb._tcp.local, "QM" question PTR _afpovertcp._tcp.local, "QM" question PTR LEGOLAS._smb._tcp.local PTR ISENGARD._smb._tcp.local PTR Legolas._sftp-ssh._tcp.local PTR Isengard._sftp-ssh._tcp.local -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

* Carlos E. R. [10-22-18 01:48]:

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Thanks, I'll try later.

...

but you could have done that yourself.

No, I could not. I did not, and still do not, know what to search for.

firewalld allow multicast, iirc -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [10-22-18 10:07]:

On 22/10/2018 14.47, Patrick Shanahan wrote:

...

* Carlos E. R. <> [10-22-18 01:48]:

...

firewalld allow multicast, iirc

The log message implies it doesn't:

FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

DST=224.0.0.1 google says that is multicast. you concede much too easily -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/10/2018 16.19, Patrick Shanahan wrote:

* Patrick Shanahan [10-22-18 10:16]:

...

* Carlos E. R. [10-22-18 10:07]:

...

On 22/10/2018 14.47, Patrick Shanahan wrote:

...

* Carlos E. R. <> [10-22-18 01:48]:

...

firewalld allow multicast, iirc

The log message implies it doesn't:

FINAL_REJECT: IN=wlan1 OUT= MAC=01:00:5e:00:00:01:f8:8e:85:64:78:f2:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

DST=224.0.0.1

google says that is multicast. you concede much too easily

"firewalld allow multicast" is the google search term which you didn't know to use, not a firewalld instruction or statement of fact.

Ah! A google search string. :-o -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

On 22/10/2018 21.55, Carlos E. R. wrote:

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

* Carlos E. R. <> [10-21-18 20:15]:

...

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Legolas:~ # firewall-cmd --runtime --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT usage: see firewall-cmd man page Can't use stand-alone options with other options. Legolas:~ #

I have no idea what that means. The words "stand" or "alone" do not appear on the man page.

Dropping "--runtime" and not including "--permanent" seems to work. The log is now silent :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

On Mon, 22 Oct 2018 21:55:29 +0200 "Carlos E. R." wrote:

On 22/10/2018 04.28, Patrick Shanahan wrote:

...

* Carlos E. R. <> [10-21-18 20:15]:

...

...

from: https://www.centos.org/forums/viewtopic.php?t=60395

(following are one liners) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

Legolas:~ # firewall-cmd --runtime --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT usage: see firewall-cmd man page Can't use stand-alone options with other options. Legolas:~ #

I have no idea what that means. The words "stand" or "alone" do not appear on the man page.

Did you actually try the command suggested, rather than your hacked-about version? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org