I am trying to run PTPDV2 (precision timing protocol) server which binds on interface for setting up multicasting.
I have a following virtual interface
eth1:0 Link encap:Ethernet HWaddr 00:00:50:A0:42:BD
inet addr:10.2.0.17 Bcast:10.2.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xa000
Now, I don't have any issues binding to a normal interface, but for any virtual interface I get a failure.
(ptpd debug1) 09:28:12.995509 (init) netInit
(ptpd debug1) 09:28:12.996254 (init) Local IP address used : 10.2.0.17
(ptpd error) 09:28:12.997099 (init) failed to call SO_BINDTODEVICE on the interface (strerror: No such device)
I need some pointers to overcome this issue. Any help here is appreciated.
I found a workaround to this problem. But it may not be the perfect solution. I am still open for suggestions.
I observed that socket bind is successful, so the socket does get the IP address of eth1:0 . But SO_BINDTODEVICE was failing since this was a virtual interface.
So i decided to call SO_BINDTODEVICE on the real interface that is eth1, since both eth1:0 and eth1 share same MAC.
Which this, i am no longer blocked as the responses are typically unicast for me. But this may not work perfectly if some one wants multicast support on receiving too.
Open for suggestion
Related
I want to make my Raspberry PI model 3 as a router that is as follows -
Computer will be connected to RPI via Ethernet (eth0) interface
Phone will be connected to RPI over Wifi (wlan0) interface.
I was able to setup a interfaces with the help of the following links -
https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/
But I am not able to do the multicast routing from wlan0 to eth0 (or) vice versa Can you please help me with it. I need to route bonjour packets over the interfaces.
Note:
both the interfaces wlan and eth are supporting MULTICAST ( verified with ifconfig command ) I was able to get UP BROADCAST RUNNING MULTICAST for both the interfaces.
I have tried using the following commands for multicasting -
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
route add -net 224.0.0.0 netmask 240.0.0.0 dev wlan0
You can use avahi-daemon to reflect mDNS queries between interfaces. Some basic configuration like this in avahi-daemon.conf should be enough:
[server]
use-ipv4=yes
use-ipv6=yes
enable-dbus=no
allow-interfaces=eth0,wlan0
[publish]
disable-publishing=yes
[reflector]
enable-reflector=yes
This is quite an old discussion but I tried the given answer and it broke LAN DNS, so don't do it. Instead, edit file:
nano /etc/avahi/avahi-daemon.conf
change this one line to ‘yes’:
enable-reflector=yes
restart the service:
service avahi-daemon restart
check to see if the ports are detected automatically:
systemctl status avahi-daemon.service
Takes a minute for new services to be discovered and appear. Works on Buster. The app Discovery (formerly Bonjour Browser) is helpful to verify mDNS ZEROCONF multicast packets are getting across. Also there's an iOS app.
To receive a multicast on my not default NIC (dvb) I do the following:
open a socket (AF_INET, SOCK_DGRAM)
join the multicast address with IP_ADD_MEMBERSHIP on the dvb interface
bind the multicast address (note that a common error is to bind "0.0.0.0" and then receive on that socket even multicast you are not interested in) and the port
at this point the only way to receive the needed multicast packets is to add in the routing table a rule to reach the network where the sender is (another network) trough the dvb, as if the dvb needs to reply to the multicast sender; let say a sort of source sender multicast mode. Anyone knows what is going on? The problem is annoying to me because in principle I don't know the ip of sender.
You appear to be being stung by rp_filter reverse-path filtering. This drops packets if they arrive on an interface that doesn't have a route for the source address.
You can disable it on a per-interface basis with the sysctl /proc/sys/net/ipv4/conf/<if>/rp_filter.
bind the multicast address
That is definitely wrong. You must bind to an actual IP address of a real adapter, or 0.0.0.0.
note that a common error is to bind
"0.0.0.0"
That's not an error. THat is correct procedure unless you only want to listen to one IP address.
and then receive on that
socket even multicast you are not
interested in
I don't know what this means.
in principle I don't know the ip of sender
The IP address of the sender of any UDP datagram is available via the sockets API.
Greetings,
For various reasons, my connection to the internet looks like this:
[DSL Modem in Bridge Mode] <-ethernet-> (eth0)[Linux system](eth1) <-ethernet-> [Wireless Router]
(Where the Linux system is running PPPoE, BIND, DHCP, etc.)
In order to diagnose a recent problem, I needed to connect to the web interface on the DSL modem. In order to do this I have to connect from a specific address range and as I am running PPPoE on eth0, I haven't assigned an address to it nor even turn it on. (The modem's web interface is at a fixed IP address regardless of what mode the modem is in and only answers to traffic from a fixed address range)
So anyway, to connect to the modem, and not finding anything helpful on the internet, I just tried assigning an IP address to eth0 after already starting PPPoE (like this: ifconfig eth0 192.168.1.5 netmask 255.255.255.0 up). I didn't really think that it would actually work. But it did. I.e. PPPoE and a static address assigned to eth0 at the same time and both worked correctly. Thus my question.. Should it? Is it safe to do this long-term or am I just lucky that it works long enough for me to get that which I need to done?
Thanks!
It's fine. PPPoE and IP are carried in Ethernet frames of different types.
I have a problem:
When I try to connect to a network, initially with ifconfig eth2 I get (correctly):
eth2 inet addr:192.168.1.56 ....
inet6 addr: fe80:221:ff:fe96:4598/64
but after a few seconds the 102.168.1.56 disappears and after some other seconds disappears the inet6 address too. In this case the network is wireless and no DHCP.
At uni, the connection is a DHCP one. It works for the first few seconds but after it doesn't.
Any possible solution?
Whats this 102.168.1.56?
cat /var/log/syslog will give more info about what happening in the system. Usually it contains large amount of information.
I'm working with a cluster of about 40 nodes running Debian 4. Each node runs a daemon which sits and listens on a multicast IP.
I wrote some client software to send out a multicast over the LAN with a client computer on the same switch as the cluster, so that each node in the cluster would receive the packet and respond.
It works great, except when I run the client software on a computer that has both LAN and WAN interfaces. If there is a WAN interface, the multicast doesn't work. So obviously, I figure the multicast is incorrectly going over the WAN interface (eth0), rather than the LAN (eth1.) So, I use the SO_BINDTODEVICE socket option to force the multicast socket to use eth1, and all is well.
But I thought that the kernel's routing table should determine that the LAN (eth1) is obviously a lower cost destination for the multicast. Is there some reason I have to explicitly force the socket to use eth1? And, is there some way (perhaps an ioctl call) that I can have the application automatically determine if a particular interface is a LAN or WAN?
If you don't explicitly bind to an
interface, I believe Linux uses the
interface for the default unicast
route for multicast sending.
Linux needs a multicast route, if none exists you will get a EHOSTUNREACH or ENETUNREACH error. The LCM project documents this possible problem. The routing will be overridden if you use the socket option IP_MULTICAST_IF or IPV6_MULTICAST_IF. You are supposed be able to specify the interface via scope-id field in IPv6 addresses but not all platforms properly support it. As dameiss points out, Stevens' Unix Network Programming book covers these details, you can browse most of the chapter on multicast via Google Books for free.
If you don't explicitly bind to an interface, I believe Linux uses the interface for the default unicast route for multicast sending. So my guess is that your default route is via the WAN interface.
Richard Stevens' "Unix Network Programming, Vol. 1", chapter 17 (at least in the 3rd edition), has some good information and examples of how to enumerate the network interfaces.