Hi,
I have a python script running on the router. This one should listen to MULTICAST from WLAN and send MULTICAST data to WLAN - both on 224.150.2.1:10000
So far I added in /etc/config/network
config route
option type 'multicast'
option interface 'lan'
option target '224.0.0.0'
option netmask '240.0.0.0'
after that devices on WLAN receive data from other devices on WLAN but not from the python program on the router.
What am I missing?
Can you explain why do you think you need that route config in etc config network?
I use multicast only for ospf in my network and did not needed anything to have the router receiving multicast on its local interfaces.
Your application runs just on the local network aka layer-2? So no need for multicast routing? If yes you should not need anything as far I can tell. Multicast on a layer-2 should just work(tm).
Without this config item, the devices can not see each other on WLAN, too.
I found it here:
I have no such route and have never heard of such a behavior. Sorry.
Just checked:
OSPFv2 via multicast on WLAN between my Laptop and the Router.
18:34:55.298560 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, LS-Update, length 108
18:34:56.276606 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, Hello, length 48
18:34:56.775442 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, LS-Ack, length 244
18:34:56.936591 wlan0 M IP 192.168.65.1 > 224.0.0.5: OSPFv2, LS-Ack, length 84
18:35:01.774919 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, LS-Ack, length 44
18:35:04.309498 wlan0 M IP 192.168.65.1 > 224.0.0.5: OSPFv2, Hello, length 48
18:35:06.277036 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, Hello, length 48
18:35:14.344898 wlan0 M IP 192.168.65.1 > 224.0.0.5: OSPFv2, Hello, length 48
18:35:16.277530 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, Hello, length 48
18:35:24.175528 wlan0 M IP 192.168.65.1 > 224.0.0.5: OSPFv2, Hello, length 48
18:35:26.277151 wlan0 Out IP 192.168.65.106 > 224.0.0.5: OSPFv2, Hello, length 48
And neither on the Laptop nor on the Router I have set nor do I see a route for 224.0.0.0/4.
But you have the default MUTLICAST flag on your interface(s)? As an example
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 90:9a:4a:1a:xx:xx brd ff:ff:ff:ff:ff:ff
root@cpe:~#
root@cpe:~# ip link show dev wlan0-1
38: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-vlan65 state UP mode DEFAULT group default qlen 1000
link/ether 90:9a:4a:1a:xx:xx brd ff:ff:ff:ff:ff:ff
interesting...
I run this script on the router:
#!/usr/bin/python
# -*- coding: utf-8 -*-
import socket
UDP_PORT = 10000
UDP_IP = '224.0.0.150'
_dobber = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP
_dobber.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
_dobber.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 20) # Change TTL (=20) to suit
_dobber.sendto(unichr(3) + 'ping', (UDP_IP, UDP_PORT))
_dobber.close()
and can not see the packet on WLAN
Make sure you bind the socket to the correct interface:
_dobber.bind((<local_address>, <local port>))
I have tried both: 224.150.2.1 and 224.0.0.150 (an address from the 224.0.0.x segment) with no success.
Or do you mean I need to do a bind before sending? That is not necessary
You do not send from 240.0.0.0/4 address space. You send with your interface address to a multicast address.
If your router's LAN address is 192.168.65.1, that is the address you want to bind to.
I though it would be easier, if I try only to send in the first place. So bind is not needed, as I do not want to listen - or am I wrong?
you mean something like this for binding my local ip for sending:
_dobber.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton('10.150.92.1'))
but no success
What is the address of the router on the LAN? The issue is that the router itself has multiple addresses (WAN, LAN, possibly VLANs), so you need to make sure you bind the UDP broadcast transmission to the desired interface.
the router address is:
10.150.92.1
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
inet6 fe80::9683:c4ff:fe19:9247/64 scope link
valid_lft forever preferred_lft forever
3: teql0: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100
link/void
4: ra0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 00:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.8.105/24 brd 192.168.8.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::21e:10ff:fe1f:0/64 scope link
valid_lft forever preferred_lft forever
6: rz-all-tap: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 10.150.92.1/16 scope global rz-all-tap
valid_lft forever preferred_lft forever
inet6 fe80::132d:6a6b:8b01:d443/64 scope link stable-privacy
valid_lft forever preferred_lft forever
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 94:83:c4:19:92:48 brd ff:ff:ff:ff:ff:ff
inet 10.150.92.1/24 brd 10.150.92.255 scope global br-lan
valid_lft forever preferred_lft forever
8: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 94:83:c4:19:92:48 brd ff:ff:ff:ff:ff:ff
9: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
10: ra1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 96:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
11: wds0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
12: wds1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
13: wds2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
14: wds3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 94:83:c4:19:92:47 brd ff:ff:ff:ff:ff:ff
15: apcli0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 96:83:c4:09:92:47 brd ff:ff:ff:ff:ff:ff
You have this address assigned two times, on two interfaces. One time with /24 and one time with /16. Does this work? Seams odd to me. I would expect one or another issue with that setup....
I only know that having the same IP with /32 on multiple interfaces works in unnumbered scenarios. Or do you use a funky proxy setup? I do really hope we are making some progress here...
Edit: are the wds interfaces your wifi? All are down...
ra1 is wifi
so far my ip setup works fine. I can get into the WAN, into the tunnel, on wifi and vice versa.
But you are right - removing the tunnel makes all work again...
setting the br-lan IP net mask to the same as the tunnel mask leads to a not working tunnel.
trying to add the rz-all-tap to the bridge leads to:
can't add rz-all-tap to bridge br-lan: Invalid argument
One Suggestion: try to specify the device in your python socket script.
The other: I think your overlapping address space will clash if you would have a host in the addr space of the /24. How would the router know how to resolve IP to ARP? It might work if the host contacts the router first so the neighbor table got populated. But still this looks like an odd design.
Do you have at least proxy ARP enabled on these two interfaces?
Hmm,
I think the best solution would be, getting my tinc vpn device into the br-lan bridge.
But that so far does not work ether.
I will open a new thread for that...