Date: Thu, 07 Feb 2002 11:33:59 -0700 From: Ian <freebsd@damnhippie.dyndns.org> To: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Re[6]: natd UDP errors with PPP demand dial Message-ID: <B88816A7.9D9E%freebsd@damnhippie.dyndns.org> In-Reply-To: <70574510802.20020207102129@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm starting to feel like I *almost* understand what's happening here. I'm actually in the middle of making some changes to natd, but not to this part of it. (I'm just fixing some bugs in the code that translates IRC DCC control message packets.) From the output you posted, things start out looking normal. Your IP on this PPP session appears to be 207.69.102.20: > > 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@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B88816A7.9D9E%freebsd>