[SOLVED] Tiny Core Linux Routing Issue

[Adam]

Hi all, I’m trying to setup a basic networking lab with Tiny Core Linux in VirtualBox.



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

Code: [Select]

    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/

[curaga]

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.

[Adam]

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

Code: [Select]

tc@Core1:~$ sudo route del -net 172.16.0.0/24
tc@Core1:~$
ADDING DEFAULT ROUTE POINTING TO THE NEXT GATEWAY

Code: [Select]

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.

Code: [Select]

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)

Code: [Select]

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


[curaga]

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.

[Adam]

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:~$

[curaga]

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/

[Adam]

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