Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]



> 
> Out [TCP]  [TCP] 192.168.0.10:3978 -> 207.69.200.225:110 aliased to
>            [TCP] 207.69.102.20:3978 -> 207.69.200.225:110
> In  [TCP]  [TCP] 207.69.200.225:110 -> 207.69.102.20:3978 aliased to
>            [TCP] 207.69.200.225:110 -> 192.168.0.10:3978
> Out [TCP]  [TCP] 192.168.0.10:3978 -> 207.69.200.225:110 aliased to
>            [TCP] 207.69.102.20:3978 -> 207.69.200.225:110
> In  [TCP]  [TCP] 207.69.200.225:110 -> 207.69.102.20:3978 aliased to
>            [TCP] 207.69.200.225:110 -> 192.168.0.10:3978
> 
> Above  is where I think the end of one ppp session is.  My workstation
> is finishing talking with the mail server.
> I think the next ppp session is dialed here somewhere.
> 
> Routing message 0x2 received.
> Routing message 0xd received.

As I understand it, you have no PPP IP at this point, that's what the 0x2
and 0xd routing messages were telling natd: a route and an address were
removed from the interface.  But natd ignores this condition (other than
logging that it got the notification on the routing socket).  Now it gets
some outgoing packets from the workstation, and translates them using the
old IP address:

> Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
>            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110
> Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
>            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110
> Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
>            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110

Where did these packets go?  I can't answer that.  However I can speculate
that perhaps they didn't go very far at all, just into the IP stack on the
local machine.  Then we get some more routing info:

> Routing message 0x2 received.
> Routing message 0xd received.
> Routing message 0xc received.
> Interface address/MTU has probably changed.
> Routing message 0x1 received.
> Routing message 0xc received.
> Interface address/MTU has probably changed.
> Routing message 0x1 received.
> Routing message 0x1 received.
> Routing message 0x3 received.
> 
> I see that the IP changed above and natd recognized that Here is where
> natd  enters  the cone of confusion.  It starts relaying messages from
> the mail server to its previous IP.

It's the 0xc messages that cause natd to notice it has a new address on the
dynamic interface.  This causes it to discard existing stale alias entries
in its internal tables and obtain the new IP from the interface (actually it
just sets a flag to get the new address the next time a packet comes
through).  I think the new IP at this point is 207.69.100.116.

Now we get the really confusing part:
 
> In  [TCP]  [TCP] 207.69.200.225:110 -> 207.69.102.20:3979 aliased to
>            [TCP] 207.69.200.225:110 -> 207.69.102.20:3979
> Out [TCP]  [TCP] 207.69.200.225:110 -> 207.69.102.20:3979 aliased to
>>>>>>>>>    [TCP] 207.69.100.116:110 -> 207.69.102.20:3979

I think the "In" packet here may be the last "Out" packet from above.  It
floated around in the IP stack and since IP forwarding is on it decided the
packet needs to be routed out the default gateway to get where it's going
(because 207.69.102.20 isn't us anymore).  Or maybe something else is going
on here, but it's hard to explain how a packet for 207.69.102.20 ended up on
the input side since that isn't our IP anymore.

Then, the "Out" packet here is the attempt to route that same packet back
out the default gateway.  This time, on the way out, the packet is aliased
so that the source address is the new IP for the PPP interface.

I think the bulk of the problem happens when outbound packets appear during
the brief time when the PPP interface has no IP yet (at least from natd's
point of view, because it received the DELADDR routing message but hasn't
gotten the NEWADDR message yet).  I think when natd gets the DELADDR it
should clean up its aliasing tables at that point, and forget any old IP
addresses for that interface.  But then what does it do about packets that
come through while it's in that state?  I'm not sure what the right answer
is, maybe one of the people who maintains this part of natd would have a
better answer.

-- Ian



To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-hackers" in the body of the message