Forward ethernet packets in other network and back - linux

i have a networking problem i was hoping to get some answers here. So i have multiple raspberry pi that all have wifi connectivity and ethernet. All the PIs are connected to a network via wifi, and on ethernet to each other. what i need is this: if a raspberry has a problem with the wifi(no signal or smth) i want to send that package over the ethernet and another raspberry should pick up that package on ethernet and forward that on it's owm wifi interface further. Could anybody give me some hints on how this should be approached? Any help would be much appreciate.

you'll have to enable routing in each pi, using sysctl, then enable dynamic routing on each pi, be it ospf or rip does not matter in your case, but you'll have to stick with your choice with the other pis, otherwise you will need to do more complex configuration.
i strongly suggest that you try to set it up yourself by reading the man, you'll get a feeling of satisfaction when you do it, i'm sure.
edit 1 : each pi will be a router, having 2 interfaces,2 ethernet connected pis should belong to the same subnet of course.
edit 2: when a wifi link is down, a raspberry will use the ethernet, the next pi must use nat to translate the packets so they can reach the public network.
example : wlan0 is external, eth1 is internal
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o wlan0 -j ACCEPT
edit 3: Setting up ospf
first, install quagga on each router(pi)
edit /etc/quagga/daemons and replace no by yes in the lines zebra and ospf then do this
cd /etc/quagga
cp /usr/share/doc/quagga/examples/zebra.conf.sample .
mv zebra.conf.sample zebra.conf
do the same for ospfd.conf and vtysh.conf
let the fun begin : here is an example on how to do it
vtysh
conf t
router ospf
network 10.0.1.0/24 area 1
network 192.168.1.0/24 area 1
end

Related

Filtre layer 2 multicast packet

I tried to filter layer 2 multicast packet (no IP header) generated by GOOSE protocol.
The commands below are used (ebtable and iptables) but did not work. Can anyone please give some advice?
I used ebtables because i readed that iptables can't open packet who dont have ip header (layer 3 minimum). The packet were sent from machine A to machine B (client/server software).
a. ebtables -A INPUT -j DROP
ebtables -A OUTPUT -j DROP
b. iptables -A INPUT -m pkttype --pky-type multicast -j DROP
iptables -A OUTPUT -m pkttype --pky-type multicast -j DROP
I tried all the commands above, but i can't stop my multicast packet (DROP was just used for test purpose)
Thank you in advanced...
For the one's who are in the same probleme in the future, i manage to resolve the probleme, first, you should now that iptables can't filter protocole who don't use ip header, so in my case, my protocole is layer 2 (like arp), the best tool for that is ebtables.
The DROP test that i already realise didn't work because i used ebatbles in a normale inerface, and this is a probleme for ebtables, he don't accept it, you should configure an bridge interface before using ebtables.
This the command i typed to creat bridge:
brctl addbr br0
brctl stp br0 off
brctl addif br0 eno16777736
ifconfig br0 10.0.0.131 netmask 255.255.255.0
ifconfig eno16777736 0 0.0.0.0
ip route add default via 10.0.0.1
ebtables -t broute -A BROUTING -j DROP
Hop this will help some one in the future

After iptables -P INPUT DROP in Ubuntu, how can I apply my additional rule?

In Ubuntu 16.04LTS, I typed the folllowing lines:
iptables -F
iptables -X
iptables -A INPUT -m mac --mac-source 1C:**:2C:**:72:**:78 -j ACCEPT
here is the result of iptables -L -nvx.
I can't access my web server (port 80) with the machine that MAC address is
1C:**:2C:**:72:**:78.
However, with rule iptables -P INPUT ACCESS on the web server, it works well.
Could anyone give me any solution or advice for this?
Thanks.
I believe that it will not work with you except that your PC is on the same LAN with the WEB server.
Because if you where on different LAN then your packets will reach the server with the mac address with the latest network interface before the web server (which is the network switch interface mac address).
So you can filter the packets based on MAC address only if you where on the same LAN.
You need to supply the MAC address in the form xx:xx:xx:xx:xx:xx, not with :: in between. I.e.:
iptables -A INPUT -m mac --mac-source xx:xx:xx:xx:xx:xx -j ACCEPT
From man iptables:
--mac-source [!] address
Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX. Note that this only makes sense for packets coming from an Ethernet device and entering the PREROUTING, FORWARD or INPUT chains.

How to set up autoip with local-link (RNDIS) on linux and embedded linux

I'm trying to figure out how to automatically setup an zeroconfig network address on a RNDIS Usb Gadget.
currently when i plug in the device, on the device i have to
$ modprobe g_ether
$ ifconfig usb0 up
$ avahi-autoipd usb0 &
and on the host i have to
$ avahi-autoipd usb0 &
they'll both get a 169.x.x.x number and I can ping, sometimes it doesn't work though. The device does not have a NetworkManager, we use busy box to start, I'm sort of looking at this as a possible solution Static Host RNDIS IP by linux based USB Gadget device, but I'd prefer to use local ip's.
A long time ago i some vague instructions on how to set a script to run in /etc/network/interfaces when a interface becomes available, but i'm having a hard time finding that again.
Thanks!
I figured it out, in /etc/network/interfaces
allow-hotplug usb0
iface usb* inet manual
up /usr/sbin/avahi-autoipd --force-bind -D $IFACE
down /usr/sbin/avahi-autoipd --kill $IFACE

Isolated test network on a Linux server running a web server (lightttpd) and (curl) clients

I'm writing a testing tool that requires known traffic to be captured from a NIC (using libpcap), then fed into the application we are trying to test.
What I'm attempting to set-up is a web server (in this case, lighttpd) and a client (curl) running on the same machine, on an isolated test network. A script will drive the entire setup, and the goal is to be able to specify a number of clients as well as a set of files for each client to download from the web server.
My initial approach was to simply use the loopback (lo) interface... run the web server on 127.0.0.1, have the clients fetch their files from http://127.0.0.1, and run my libpcap-based tool on the lo interface. This works ok, apart from the fact that the loopback interface doesn't emulate a real Ethernet interface. The main problem with that is that packets are all inconsistent sizes... 32kbytes and bigger, and somewhat random... it's also not possible to lower the MTU on lo (well, you can, but it has no effect!).
I also tried running it on my real interface (eth0), but since it's an internal web client talking to an internal web server, traffic never leaves the interface, so libpcap never sees it.
So then I turned to tun/tap. I used socat to bind two tun interfaces together with a tcp connection, so in effect, i had:
10.0.1.1/24 <-> tun0 <-socat-> tcp connection <-socat-> tun1 <-> 10.0.2.1/24
This seems like a really neat solution... tun/tap devices emulate real Ethernet devices, so i can run my web server on tun0 (10.0.1.1) and my capture tool on tun0, and bind my clients to tun1 (10.0.2.1)... I can even use tc to apply shaping rules to this traffic and create a virtual WAN inside my linux box... but it just doesn't work...
Here are the socat commands I used:
$ socat -d TCP-LISTEN:11443,reuseaddr TUN:10.0.1.1/24,up &
$ socat TCP:127.0.0.1:11443 TUN:10.0.2.1/24,up &
Which produces 2 tun interfaces (tun0 and tun1), with their respective IP addresses.
If I run ping -I tun1 10.0.1.1, there is no response, but when i tcpdump -n -i tun0, i see the ICMP echo requests making it to the other side, just no sign of the response coming back.
# tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
16:49:16.772718 IP 10.0.2.1 > 10.0.1.1: ICMP echo request, id 4062, seq 5, length 64
<--- insert sound of crickets here (chirp, chirp)
So am I missing something obvious or is this the wrong approach? Is there something else i can try (e.g. 2 physical interfaces, eth0 and eth1???).
The easiest way is just to use 2 machines, but I want all of this self-contained, so it can all be scripted and automated on a single machine, without and other dependencies...
UPDATE:
There is no need for the 2 socats to be connected with a tcp connection, it's possible (and preferable for me) to do this:
socat TUN:10.0.1.1/24,up TUN:10.0.2.1/24,up &
The same problem still exists though...
OK, so I found a solution using Linux network namespaces (netns). There is a helpful article about how to use it here: http://code.google.com/p/coreemu/wiki/Namespaces
This is what I did for my setup....
First, download and install CORE: http://cs.itd.nrl.navy.mil/work/core/index.php
Next, run this script:
#!/bin/sh
core-cleanup.sh > /dev/null 2>&1
ip link set vbridge down > /dev/null 2>&1
brctl delbr vbridge > /dev/null 2>&1
# create a server node namespace container - node 0
vnoded -c /tmp/n0.ctl -l /tmp/n0.log -p /tmp/n0.pid > /dev/null
# create a virtual Ethernet (veth) pair, installing one end into node 0
ip link add name veth0 type veth peer name n0.0
ip link set n0.0 netns `cat /tmp/n0.pid`
vcmd -c /tmp/n0.ctl -- ip link set n0.0 name eth0
vcmd -c /tmp/n0.ctl -- ifconfig eth0 10.0.0.1/24 up
# start web server on node 0
vcmd -I -c /tmp/n0.ctl -- lighttpd -f /etc/lighttpd/lighttpd.conf
# create client node namespace container - node 1
vnoded -c /tmp/n1.ctl -l /tmp/n1.log -p /tmp/n1.pid > /dev/null
# create a virtual Ethernet (veth) pair, installing one end into node 1
ip link add name veth1 type veth peer name n1.0
ip link set n1.0 netns `cat /tmp/n1.pid`
vcmd -c /tmp/n1.ctl -- ip link set n1.0 name eth0
vcmd -c /tmp/n1.ctl -- ifconfig eth0 10.0.0.2/24 up
# bridge together nodes using the other end of each veth pair
brctl addbr vbridge
brctl setfd vbridge 0
brctl addif vbridge veth0
brctl addif vbridge veth1
ip link set veth0 up
ip link set veth1 up
ip link set vbridge up
This basically sets up 2 virtual/isolated/name-spaced networks on your Linux host, in this case, node 0 and node 1. A web server is started on node 0.
All you need to do now is run curl on node 1:
vcmd -c /tmp/n1.ctl -- curl --output /dev/null http://10.0.0.1
And monitor the traffic with tcpdump:
tcpdump -s 1514 -i veth0 -n
This seems to work quite well... still experimenting, but looks like it will solve my problem.

How to route in linux

I have 20 ips from my isp. I have them bound to a router box running centos. What commands, and in what order, do I set up so that the other boxes on my lan, based either on their mac addresses or 192 ips can I have them route out my box on specific ips. For example I want mac addy xxx:xxx:xxx0400 to go out 72.049.12.157 and xxx:xxx:xxx:0500 to go out 72.049.12.158.
Use iptables to setup NAT.
iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j SNAT --to-source 72.049.12.157
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 72.049.12.158
This should cause any ips on the 192.168.0.0 subnet to have an 'external' ip of 72.049.12.157 and those on the 192.168.1.0 subnet to have an 'external' ip of 72.049.12.158. For MAC address matching, use -m mac --mac-source MAC-ADDRESS in place of the -s 192.168.0.0/24 argument
Don't forget to activate ip forwarding:
cat /proc/sys/net/ipv4/ip_forward
If the above returns a 0 then it won't work, you'll have to enable it. Unfortunately this is distro-specific and I don't know CentOS.
For a quick hack, do this:
echo 1 > /proc/sys/net/ipv4/ip_forward
What's the router hardware and software version?
Are you trying to do this with a linux box? Stop now and go get a router. It will save you money long-term.
Answering this question with the little information you gave amounts to rewriting a routing Howto here. You could either
read about routing and IP in general (e.g. Linux System Administrator's Guide) or
give us more info on the exact IP addresses you got.
The above answer using NAT is definately not what you intend to use when you have public IP addresses. This solution is not going to scale well.

Resources