On Sun, 29 Sep 2002 12:37:42 -0700
"Matthew Schalit" <[EMAIL PROTECTED]> wrote:
>
> Hi Chad,
> Hope things are working out.
>
> I like your diagram, and then again I don't.
> But maybe it's just me, I don't know, but I can't
> understand it as much as I need to. I admire your
> attempt, though, because it was properly spaced,
> readable, and darn good for what it was.
Thanks very much for your patience. This diagram is trying to detail
something that doesn't happen usually in nature, which is the existence of
a mobile node on the "wrong" subnet, with two computers in cooperation
(home agent and foreign agent) attempting to get packets to it.
I'll try again:
172.24.8.1/24 172.24.20.1/22
________ ^________^ __________
| switch |-------| router |-------| switch |
|________| |________| |__________|
| | |
______|_____ _____________|_ _|___________
| | | | | |
| home agent | | foreign agent | | mobile node |
|____________| |_______________| |_____________|
172.24.8.99/24 172.24.20.104/22 172.24.8.24/24
All links are CAT5 ethernet. Home agent, foreign agent and mobile node
are each separate, regular PC hosts with one NIC (eth0) and one IP address
each.
The titles "home agent" and "foreign agent" are simply relative to the
mobile node. The home agent "catches" packets destined for the mobile
node (via proxy arp), tunnels them through the router to the foreign
agent, who has agreed to detunnel them and deliver them (via the mobile
node's known _hardware_ address) to the mobile node. The mobile node
really "belongs" on the same network as the home agent. The foreign agent
is not a bridge - it knows the ethernet address of the mobile node and has
a host route to it that indicates that it is on the same link (see below).
The IP-in-IP tunnel is between the home agent and the foreign agent. I
have verified that the packets routing between them are properly formed
and have correct checksums in all the right places.
I have verified that the foreign agent is receiving the tunneled packet on
eth0 by logging all packets seen on PREROUTING and INPUT using the
following rules:
iptables -A PREROUTING -t mangle -j LOG
iptables -A INPUT -t mangle -j LOG
I also see the de-tunneled packet arriving on tunl0 via the PREROUTING
chain. I have also added the following rule to track packets on the
FORWARD chain, which is where I think the de-tunneled packet should go
next.
iptables -F FORWARD -t mangle -j LOG
I see nothing. I am sorry I do not have the logs at home. I can send
them on Monday. The following are reconstructions of the setup on the
foreign agent to the best of my memory.
"ip addr sh" on foreign agent:
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:60:b0:45:f6:d8 brd ff:ff:ff:ff:ff:ff
inet 172.24.20.104/22 brd 172.24.23.255 scope global eth0
19: tunl0@NONE: <NOARP> mtu 1480 qdisc noop
link/ipip 0.0.0.0 brd 0.0.0.0
inet 172.24.8.104/32 scope global tunl0
"ip route sh" on foreign agent:
172.24.8.24 dev eth0 scope link
172.24.20.0/22 dev eth0 proto kernel scope link src 172.24.20.104
default via 172.24.20.1 dev eth0
"ip neigh sh" on foreign agent
172.24.8.24 dev eth0 lladdr 00:00:0d:2f:0f:0b nud permanent
172.24.20.1 dev eth0 lladdr 00:d0:b7:1c:5a:90 nud reachable
"ip -s tunnel sh" on foreign agent
tunl0: ip/ip remote any local any ttl inherit nopmtudisc
RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
5 580 0 0 0 0
TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
0 0 0 0 0 0
The packet and byte count increment properly when packets are received.
The byte count increases by the size of the _inner_ packet.
Again, I appreciate your time and patience. I hope these drawings and
material are a little clearer; it is by nature a bit of a weird setup.
I feel that I have sort of covered all of the bases on this one and still
have a disconnect. My next step is to get inside the kernel itself and
try and figure out where the packets are getting dropped and why - sort of
an inside-out approach, I guess.
Thanks.
--
------------------------------------------------------------------------
Chad Carr [EMAIL PROTECTED]
------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
