Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: Adam on August 12, 2013, 12:09:31 PM
-
Hi all, I’m trying to setup a basic networking lab with Tiny Core Linux in VirtualBox.
(http://firewallengineer.files.wordpress.com/2013/08/routing.png)
I’ve setup all necessary routing configurations, unfortunately, Core_1 still unable to communicate with Core_3.
IP Setting
tc@Core1:~$ alias i
i=’ifconfig | grep dd’
tc@Core1:~$
tc@Core1:~$ i
eth0 Link encap:Ethernet HWaddr 08:00:27:6C:E7:79
inet addr:192.168.10.11 Bcast:192.168.10.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 08:00:27:26:33:AF
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
inet addr:127.0.0.1 Mask:255.0.0.0
tc@Core1:~$
tc@Core2:~$ i
eth0 Link encap:Ethernet HWaddr 08:00:27:CE:5F:07
inet addr:192.168.10.12 Bcast:192.168.10.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 08:00:27:10:0C:49
inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0
eth2 Link encap:Ethernet HWaddr 08:00:27:36:07:3E
inet addr:172.16.0.2 Bcast:172.16.255.255 Mask:255.255.0.0
inet addr:127.0.0.1 Mask:255.0.0.0
tc@Core2:~$
tc@Core3:~$ i
eth0 Link encap:Ethernet HWaddr 08:00:27:46:BF:41
inet addr:192.168.10.13 Bcast:192.168.10.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 08:00:27:37:61:DF
inet addr:172.16.0.1 Bcast:172.16.255.255 Mask:255.255.0.0
inet addr:127.0.0.1 Mask:255.0.0.0
tc@Core3:~$
Original Route
tc@Core1:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core1:~$
tc@Core2:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
172.16.0.0 * 255.255.0.0 U 0 0 0 eth2
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core2:~$
tc@Core3:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
172.16.0.0 * 255.255.0.0 U 0 0 0 eth1
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core3:~$
Test Route
tc@Core1:~$ traceroute 172.16.0.1
traceroute to 172.16.0.1 (172.16.0.1), 30 hops max, 38 byte packets
1traceroute: sendto: Network is unreachable
tc@Core1:~$
tc@Core1:~$ ip route get 172.16.0.1
RTNETLINK answers: Network is unreachable
tc@Core1:~$
tc@Core2:~$ ip route get 172.16.0.1
172.16.0.1 dev eth2 src 172.16.0.2
cache
tc@Core2:~$
tc@Core3:~$ ip route get 172.16.0.1
local 172.16.0.1 dev lo src 172.16.0.1
cache <local>
tc@Core3:~$
Adding Static Route
tc@Core1:~$ sudo route add -net 172.16.0.0 netmask 255.255.255.0 gw 10.0.0.2
tc@Core1:~$
Verify Route Again
tc@Core1:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
172.16.0.0 10.0.0.2 255.255.255.0 UG 0 0 0 eth1
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core1:~$
tc@Core1:~$ ip route get 172.16.0.1
172.16.0.1 via 10.0.0.2 dev eth1 src 10.0.0.1
cache
tc@Core1:~$
Traceroute Test
tc@Core1:~$ traceroute 172.16.0.1
traceroute to 172.16.0.1 (172.16.0.1), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
tcpdump in Core2
tc@Core2:~$ sudo tcpdump -i 2 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
16:00:03.193443 IP 10.0.0.1.52221 > 172.16.0.1.33435: UDP, length 10
16:00:08.201546 IP 10.0.0.1.52221 > 172.16.0.1.33436: UDP, length 10
16:00:13.208567 IP 10.0.0.1.52221 > 172.16.0.1.33437: UDP, length 10
http://firewallengineer.wordpress.com/2013/08/12/tiny-core-linux-routing/
-
That's working as expected?
Your box1 only knows of three networks, and has no default route. So a query for any network that's not one of those three won't leave the box.
If you don't want to have the static route, add a default route so it can fall back to that.
-
That's working as expected?
Your box1 only knows of three networks, and has no default route. So a query for any network that's not one of those three won't leave the box.
If you don't want to have the static route, add a default route so it can fall back to that.
No, it’s not working as expected.
As suggested, I’ve removed previous route and added default route.
DELETE ROUTE TO 172.16.0.0/24
tc@Core1:~$ sudo route del -net 172.16.0.0/24
tc@Core1:~$
ADDING DEFAULT ROUTE POINTING TO THE NEXT GATEWAY
tc@Core1:~$ sudo route add default gw 10.0.0.2
tc@Core1:~$
VERIFY ROUTE
tc@Core1:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.0.2 0.0.0.0 UG 0 0 0 eth1
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core1:~$
tc@Core1:~$ ip route get 172.16.0.1
172.16.0.1 via 10.0.0.2 dev eth1 src 10.0.0.1
cache ipid 0xa95d
tc@Core1:~$
Unfortunately, the result still same.
Weird thing is traceroute traffic don’t reach to the next hop even though it’s directly connected.
tc@Core1:~$ traceroute 172.16.0.1
traceroute to 172.16.0.1 (172.16.0.1), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
And from the tcpdump output, seems like the source, Core1 (10.0.0.1) is trying to send traceroute traffic (UDP), but not getting response from the destination, Core3 (172.16.0.1)
tc@Core2:~$ sudo tcpdump -i 2 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
11:08:30.277250 arp who-has 10.0.0.2 tell 10.0.0.1
11:08:30.277273 arp reply 10.0.0.2 is-at 08:00:27:10:0c:49
11:08:30.277620 IP 10.0.0.1.37930 > 172.16.0.1.33435: UDP, length 10
11:08:35.463414 IP 10.0.0.1.37930 > 172.16.0.1.33436: UDP, length 10
11:08:40.652115 IP 10.0.0.1.37930 > 172.16.0.1.33437: UDP, length 10
11:08:45.840060 IP 10.0.0.1.37930 > 172.16.0.1.33438: UDP, length 10
11:08:51.028691 IP 10.0.0.1.37930 > 172.16.0.1.33439: UDP, length 10
11:08:56.216410 IP 10.0.0.1.37930 > 172.16.0.1.33440: UDP, length 10
11:09:01.406705 IP 10.0.0.1.37930 > 172.16.0.1.33441: UDP, length 10
11:09:06.592886 IP 10.0.0.1.37930 > 172.16.0.1.33442: UDP, length 10
11:09:11.778991 IP 10.0.0.1.37930 > 172.16.0.1.33443: UDP, length 10
-
Yep, looks like box1 now knows how to get to box3, but box3 does not know how to get to box1. Try adding a default route to box3 as well.
-
Yep, looks like box1 now knows how to get to box3, but box3 does not know how to get to box1. Try adding a default route to box3 as well.
I’ve already configured Core1 & Core3 with default gateway, but no luck.
traceroute & tcpdump output still showing the same thing
tc@Core3:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.2 0.0.0.0 UG 0 0 0 eth1
10.0.0.0 172.16.0.2 255.255.255.0 UG 0 0 0 eth1
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
172.16.0.0 * 255.255.0.0 U 0 0 0 eth1
192.168.10.0 * 255.255.255.0 U 0 0 0 eth0
tc@Core3:~$
TRACEROUTE TEST
tc@Core1:~$ traceroute 172.16.0.1
traceroute to 172.16.0.1 (172.16.0.1), 30 hops max, 38 byte packets
1 * * *
2 * * *
3^C
tc@Core1:~$
TCPDUMP ON ALL DEVICES, ALL INTERFACES
tc@Core1:~$ tcpdump -D
1.eth0
2.eth1
3.lo
tc@Core1:~$
tc@Core2:~$ tcpdump -D
1.eth0
2.eth1
3.eth2
4.lo
tc@Core2:~$
tc@Core3:~$ tcpdump -D
1.eth0
2.eth1
3.lo
tc@Core3:~$
tc@Core1:~$ sudo tcpdump -i 2 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
12:24:41.681744 IP 10.0.0.1.42332 > 172.16.0.1.33435: UDP, length 10
12:24:46.687038 IP 10.0.0.1.42332 > 172.16.0.1.33436: UDP, length 10
12:24:46.690790 arp who-has 10.0.0.2 tell 10.0.0.1
12:24:46.691203 arp reply 10.0.0.2 is-at 08:00:27:10:0c:49
12:24:51.692250 IP 10.0.0.1.42332 > 172.16.0.1.33437: UDP, length 10
12:24:56.698376 IP 10.0.0.1.42332 > 172.16.0.1.33438: UDP, length 10
12:25:01.704608 IP 10.0.0.1.42332 > 172.16.0.1.33439: UDP, length 10
12:25:06.709748 IP 10.0.0.1.42332 > 172.16.0.1.33440: UDP, length 10
12:25:11.714829 IP 10.0.0.1.42332 > 172.16.0.1.33441: UDP, length 10
12:25:11.716603 arp who-has 10.0.0.2 tell 10.0.0.1
12:25:11.717025 arp reply 10.0.0.2 is-at 08:00:27:10:0c:49
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
tc@Core1:~$
tc@Core2:~$ sudo tcpdump -i 2 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
12:32:17.105116 IP 10.0.0.1.42332 > 172.16.0.1.33435: UDP, length 10
12:32:22.293545 IP 10.0.0.1.42332 > 172.16.0.1.33436: UDP, length 10
12:32:22.297261 arp who-has 10.0.0.2 tell 10.0.0.1
12:32:22.297269 arp reply 10.0.0.2 is-at 08:00:27:10:0c:49
12:32:27.481478 IP 10.0.0.1.42332 > 172.16.0.1.33437: UDP, length 10
12:32:32.669707 IP 10.0.0.1.42332 > 172.16.0.1.33438: UDP, length 10
12:32:37.858409 IP 10.0.0.1.42332 > 172.16.0.1.33439: UDP, length 10
12:32:43.046765 IP 10.0.0.1.42332 > 172.16.0.1.33440: UDP, length 10
12:32:48.235227 IP 10.0.0.1.42332 > 172.16.0.1.33441: UDP, length 10
12:32:48.237083 arp who-has 10.0.0.2 tell 10.0.0.1
12:32:48.237099 arp reply 10.0.0.2 is-at 08:00:27:10:0c:49
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
tc@Core2:~$
tc@Core2:~$ sudo tcpdump -i 3 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
tc@Core2:~$
tc@Core3:~$ sudo tcpdump -i 2 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
tc@Core3:~$
-
Linux does not by default forward packets. Have you enabled that on the middle box, acting as a router? Your tcpdump shows the packets dying at that box.
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
-
Linux does not by default forward packets. Have you enabled that on the middle box, acting as a router? Your tcpdump shows the packets dying at that box.
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
Thanks. I did not realize ip forwarding disable on the middle host.
Once I enabled it, I worked like a charm.
tc@Core1:~$ traceroute 172.16.0.1
traceroute to 172.16.0.1 (172.16.0.1), 30 hops max, 38 byte packets
1 10.0.0.2 (10.0.0.2) 0.322 ms 0.295 ms 0.204 ms
2 172.16.0.1 (172.16.0.1) 0.375 ms 0.602 ms 0.585 ms
tc@Core1:~$ traceroute 172.16.0.1
I found another problem when looking at tcpdump log. The time of these three boxes are not synchronized? Is there any solution for this?
http://forum.tinycorelinux.net/index.php/topic,15773.0.html