Create a tunnel to a remote host via a gateway
ssh -L <local-port-to-listen>:<destination-host>:<destination-port> <gateway_user>@<gateway>
This opens a local port listening for traffic on <local-port-to-listen> and forwards that traffic via the gateway (user@gateway) to the remote destination <destination-host>:<destination-port>
-f executes ssh in the background
-N means no remote command (ie: just create a tunnel)
ssh -N -f -L 8080:destination:8080 user@gateway
Pointing your browser to localhost:8080 will connect to the ssh tunnel which forwards the data to destination:8080, going via the gateway
This blog serves as a dumping ground for my own interests. On it you will find anything which I want to keep track of; links, articles, tips and tricks. Mostly it focuses on C++, Javascript and HTML, linux and performance.
Saturday, 22 November 2014
Tuesday, 18 November 2014
Multicast troubleshooting
Troubleshooting multicast:
Check that the interface is configured with multicast:
$ ifconfig eth9.240
eth9.240 Link encap:Ethernet HWaddr 00:60:DD:44:67:9E
inet addr:10.185.131.41 Bcast:10.185.131.63 Mask:255.255.255.224
inet6 addr: fe80::260:ddff:fe44:679e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Check that the multicast addresses you are subscribing to have a route to that particular interface:
$ ip route
224.0.0.0/4 dev eth9.240 scope link
Run your application and check if the subscriptions are going to the correct interface:
$ netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
[...]
eth9.240 1 239.1.127.215
eth9.240 1 239.1.1.215
Run tcpdump and check that you are indeed receiving traffic. Do this while your application is running; otherwise the igmp subscription will not be on.
$ tcpdump -i eth9.240
10:15:13.385228 IP 10.0.8.121.45666 > 239.1.1.1.51001: UDP, length 16
If you got to the tcpdump part, the networking should be OK.
If your application is still not receiving packets, it is probably because of the rp_filter in Linux.
Check that the interface is configured with multicast:
$ ifconfig eth9.240
eth9.240 Link encap:Ethernet HWaddr 00:60:DD:44:67:9E
inet addr:10.185.131.41 Bcast:10.185.131.63 Mask:255.255.255.224
inet6 addr: fe80::260:ddff:fe44:679e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Check that the multicast addresses you are subscribing to have a route to that particular interface:
$ ip route
224.0.0.0/4 dev eth9.240 scope link
Run your application and check if the subscriptions are going to the correct interface:
$ netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
[...]
eth9.240 1 239.1.127.215
eth9.240 1 239.1.1.215
Run tcpdump and check that you are indeed receiving traffic. Do this while your application is running; otherwise the igmp subscription will not be on.
$ tcpdump -i eth9.240
10:15:13.385228 IP 10.0.8.121.45666 > 239.1.1.1.51001: UDP, length 16
If you got to the tcpdump part, the networking should be OK.
If your application is still not receiving packets, it is probably because of the rp_filter in Linux.
The rp_filter filters out any packets that do not have a route on a particular interface. In the example above, if 10.0.8.121 is not routable via eth9.240 so the solution is to:
Check the filter
$ cat /proc/sys/net/ipv4/conf/ethX/rp_filter
add this line to /etc/sysctl.conf
net.ipv4.conf.eth9/240.rp_filter = 0
$ sudo sysctl -p
Check if it’s OK
$ sysctl -a | grep “eth9/240.rp_filter”
Check the filter
$ cat /proc/sys/net/ipv4/conf/ethX/rp_filter
add this line to /etc/sysctl.conf
net.ipv4.conf.eth9/240.rp_filter = 0
$ sudo sysctl -p
Check if it’s OK
$ sysctl -a | grep “eth9/240.rp_filter”
Subscribe to:
Posts (Atom)