Thanks Rafael,
On 02/08/2017 11:26 AM, Rafael Zalamena wrote:
On Thu, Feb 02, 2017 at 04:04:36PM +0000, Kaya Saman wrote:
Hi,
Hello,
it seems like the recent changes to the kernel have stopped IGMP proxy from
functioning?
The last time this worked was after an update I had performed in the
beginning of 2017, I can't recall the exact date or snapshot that I used.
I've looked at your configuration and setup and I found that you have
the multicast reject route:
224/4 127.0.0.1 URS 66747 530612 32768 8 lo0
Please try running it again without it by stopping igmpproxy and removing
the entry above.
e.g. "route -qn delete 224.0.0.0/4"
To make this change permanent you should add "multicast=YES" to your
/etc/rc.conf.local. For more information, please read man 8 netstart
section "MULTICAST ROUTING".
I have this in my rc.conf.local:
multicast_router=YES
however, I will also add your suggestion too. There is a strange thing
though with rc.conf.local in that some services do not auto start?? I
have added a few packages from the OBSD @Ports collection but even with
the correct naming and syntax for flags etc... they just don't do
anything unless I manually start them after boot or start through shell
script in crontab??? A very strange thing indeed!
Back on topic, I stopped igmpproxy, removed the multicast reject route
as you suggested then restart igmpproxy. The multicast address that I am
interested is the upnp auto discovery one: 239.255.255.250
# tcpdump -eni vlan20 host 239.255.255.250
tcpdump: listening on vlan20, link-type EN10MB
13:28:20.030662 f0:de:f1:c1:79:93 01:00:5e:7f:ff:fa 0800 60: * >
239.255.255.250: igmp nreport 239.255.255.250 (DF) [tos 0xc0] [ttl 1]
13:28:20.129481 f0:de:f1:c1:79:93 01:00:5e:7f:ff:fa 0800 143: *.48351 >
239.255.255.250.1900: udp 101 (DF)
13:28:20.229349 f0:de:f1:c1:79:93 01:00:5e:7f:ff:fa 0800 143: *.48351 >
239.255.255.250.1900: udp 101 (DF)
13:28:32.049283 f0:de:f1:c1:79:93 01:00:5e:7f:ff:fa 0800 60: * >
239.255.255.250: igmp nreport 239.255.255.250 (DF) [tos 0xc0] [ttl 1]
^C
# tcpdump -eni vlan40 host 239.255.255.250
tcpdump: listening on vlan40, link-type EN10MB
13:28:54.195941 0c:c4:7a:30:0f:f0 01:00:5e:7f:ff:fa 0800 215: *.10767 >
239.255.255.250.1900: udp 173 (DF)
13:28:54.195943 0c:c4:7a:30:0f:f0 01:00:5e:7f:ff:fa 0800 215: *.10767 >
239.255.255.250.1900: udp 173 (DF)
13:28:59.636767 00:01:2e:53:89:de 01:00:5e:7f:ff:fa 0800 215: *.8374 >
239.255.255.250.1900: udp 173 (DF)
13:28:59.636771 00:01:2e:53:89:de 01:00:5e:7f:ff:fa 0800 215: *.8374 >
239.255.255.250.1900: udp 173 (DF)
13:29:07.771561 0c:c4:7a:30:0f:f0 01:00:5e:7f:ff:fa 0800 215: *.6322 >
239.255.255.250.1900: udp 173 (DF)
13:29:07.771563 0c:c4:7a:30:0f:f0 01:00:5e:7f:ff:fa 0800 215: *.6322 >
239.255.255.250.1900: udp 173 (DF)
13:29:07.930321 0c:c4:7a:30:0f:f0 01:00:5e:7f:ff:fa 0800 136: *.43984 >
239.255.255.250.1900: udp 94 (DF) [ttl 1]
^C
which shows that the hosts are sending requests to the address, but
unfortunately there is no propergation through the network. If this was
working properly I would be seeing both hosts within the tcpdump output:
more so if I use this: tcpdump -eni vlan40 host 239.255.255.250 or host
<ip on vlan20>
What I am seeing is the standard tcp connections between the hosts to
various service ports which is fine, but the multicast proxying is not
functioning.
With the same configuration I have, it was working fine till recently.
Something in the update stopped it meaning either I need to adjust
something on my end or there is a deeper issue....
<-----snip------->
