Linux ignoring multicast route over loopback
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I'm trying to test some multicast code on a single machine. I'm trying to get the packets sent over the loopback device (lo) instead of the default eth1. Googling keeps turning up the incantation
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
ifconfig lo multicast
but even after doing this the packets are still going out over eth1. Sample code (Python)
#!/usr/bin/env python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'hello world', ('225.100.101.0', 8888))
Output from tcpdump -i any 'udp port 8888':
10:28:28.957679 IP 192.168.1.104.51159 > 225.100.101.0.8888: UDP, length 11
where 192.168.1.104 is the host address for eth1. I know I can use the IP_MULTICAST_IF socket option to force it (and this does work), but I'd prefer to be able to set routing policy once on the machine rather than in every application that does multicast.
I'm running Ubuntu 14.04 with kernel 3.13.0-68-generic.
linux ubuntu routing multicast
asked Nov 18 '15 at 8:40
Bruce Merry
1263
bumped to the homepage by Community♦ 17 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |Â
up vote
3
down vote
favorite
I'm trying to test some multicast code on a single machine. I'm trying to get the packets sent over the loopback device (lo) instead of the default eth1. Googling keeps turning up the incantation
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
ifconfig lo multicast
but even after doing this the packets are still going out over eth1. Sample code (Python)
#!/usr/bin/env python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'hello world', ('225.100.101.0', 8888))
Output from tcpdump -i any 'udp port 8888':
10:28:28.957679 IP 192.168.1.104.51159 > 225.100.101.0.8888: UDP, length 11
where 192.168.1.104 is the host address for eth1. I know I can use the IP_MULTICAST_IF socket option to force it (and this does work), but I'd prefer to be able to set routing policy once on the machine rather than in every application that does multicast.
I'm running Ubuntu 14.04 with kernel 3.13.0-68-generic.
linux ubuntu routing multicast
asked Nov 18 '15 at 8:40
Bruce Merry
1263
bumped to the homepage by Community♦ 17 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
You can test what route will be taken withip route get 225.100.101.0. It should saymulticast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache withip route flush cache.
– meuh
Nov 18 '15 at 10:40
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I'm trying to test some multicast code on a single machine. I'm trying to get the packets sent over the loopback device (lo) instead of the default eth1. Googling keeps turning up the incantation
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
ifconfig lo multicast
but even after doing this the packets are still going out over eth1. Sample code (Python)
#!/usr/bin/env python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'hello world', ('225.100.101.0', 8888))
Output from tcpdump -i any 'udp port 8888':
10:28:28.957679 IP 192.168.1.104.51159 > 225.100.101.0.8888: UDP, length 11
where 192.168.1.104 is the host address for eth1. I know I can use the IP_MULTICAST_IF socket option to force it (and this does work), but I'd prefer to be able to set routing policy once on the machine rather than in every application that does multicast.
I'm running Ubuntu 14.04 with kernel 3.13.0-68-generic.
linux ubuntu routing multicast
asked Nov 18 '15 at 8:40
Bruce Merry
1263
I'm trying to test some multicast code on a single machine. I'm trying to get the packets sent over the loopback device (lo) instead of the default eth1. Googling keeps turning up the incantation
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
ifconfig lo multicast
but even after doing this the packets are still going out over eth1. Sample code (Python)
#!/usr/bin/env python
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'hello world', ('225.100.101.0', 8888))
Output from tcpdump -i any 'udp port 8888':
10:28:28.957679 IP 192.168.1.104.51159 > 225.100.101.0.8888: UDP, length 11
where 192.168.1.104 is the host address for eth1. I know I can use the IP_MULTICAST_IF socket option to force it (and this does work), but I'd prefer to be able to set routing policy once on the machine rather than in every application that does multicast.
I'm running Ubuntu 14.04 with kernel 3.13.0-68-generic.
linux ubuntu routing multicast
linux ubuntu routing multicast
asked Nov 18 '15 at 8:40
Bruce Merry
1263
asked Nov 18 '15 at 8:40
Bruce Merry
1263
asked Nov 18 '15 at 8:40
Bruce Merry
1263
asked Nov 18 '15 at 8:40
Bruce Merry
1263
asked Nov 18 '15 at 8:40
Bruce Merry
1263
1263
bumped to the homepage by Community♦ 17 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 17 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
You can test what route will be taken withip route get 225.100.101.0. It should saymulticast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache withip route flush cache.
– meuh
Nov 18 '15 at 10:40
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16
add a comment |Â
You can test what route will be taken withip route get 225.100.101.0. It should saymulticast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache withip route flush cache.
– meuh
Nov 18 '15 at 10:40
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16
You can test what route will be taken with
ip route get 225.100.101.0. It should say multicast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache with ip route flush cache.– meuh
Nov 18 '15 at 10:40
You can test what route will be taken with
ip route get 225.100.101.0. It should say multicast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache with ip route flush cache.– meuh
Nov 18 '15 at 10:40
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
It turns out that looking at IP addresses in tcpdump was misleading: it always seems to use 192.168.1.104 as the source address, even when sending the packet over loopback. When specifying an interface to tcpdump I could tell which interface was actually used. The route was indeed working some of the time. This question describes a case where it doesn't work.
edited May 23 '17 at 12:40
Community♦
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
It turns out that looking at IP addresses in tcpdump was misleading: it always seems to use 192.168.1.104 as the source address, even when sending the packet over loopback. When specifying an interface to tcpdump I could tell which interface was actually used. The route was indeed working some of the time. This question describes a case where it doesn't work.
edited May 23 '17 at 12:40
Community♦
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
add a comment |Â
up vote
0
down vote
It turns out that looking at IP addresses in tcpdump was misleading: it always seems to use 192.168.1.104 as the source address, even when sending the packet over loopback. When specifying an interface to tcpdump I could tell which interface was actually used. The route was indeed working some of the time. This question describes a case where it doesn't work.
edited May 23 '17 at 12:40
Community♦
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
add a comment |Â
up vote
0
down vote
up vote
0
down vote
It turns out that looking at IP addresses in tcpdump was misleading: it always seems to use 192.168.1.104 as the source address, even when sending the packet over loopback. When specifying an interface to tcpdump I could tell which interface was actually used. The route was indeed working some of the time. This question describes a case where it doesn't work.
edited May 23 '17 at 12:40
Community♦
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
It turns out that looking at IP addresses in tcpdump was misleading: it always seems to use 192.168.1.104 as the source address, even when sending the packet over loopback. When specifying an interface to tcpdump I could tell which interface was actually used. The route was indeed working some of the time. This question describes a case where it doesn't work.
edited May 23 '17 at 12:40
Community♦
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
edited May 23 '17 at 12:40
Community♦
1
edited May 23 '17 at 12:40
Community♦
1
edited May 23 '17 at 12:40
Community♦
1
1
answered Nov 19 '15 at 7:23
Bruce Merry
1263
answered Nov 19 '15 at 7:23
Bruce Merry
1263
answered Nov 19 '15 at 7:23
Bruce Merry
1263
1263
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
add a comment |Â
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
Interesting and duly noted. Often people forget the loopback is the route to talk with the server itself.
– Rui F Ribeiro
Nov 19 '15 at 8:08
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f243799%2flinux-ignoring-multicast-route-over-loopback%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
You can test what route will be taken with
ip route get 225.100.101.0. It should saymulticast 225.100.101.0 dev lo .... Perhaps you need to clear the routing cache withip route flush cache.– meuh
Nov 18 '15 at 10:40
is not the route cache supposed to have a defined time to live...i.e. would there be a need to clear the routing cache?
– Rui F Ribeiro
Nov 18 '15 at 10:44
I did try flushing the cache: it didn't appear to make any difference.
– Bruce Merry
Nov 19 '15 at 7:16