Date: Mon, 23 Nov 1998 16:46:23 +0100 (CET) From: Malte Lance <malte.lance@gmx.net> To: van.woerkom@netcologne.de Cc: marc@netcologne.de, G.Sittig@abo.FreiePresse.DE, freebsd-isdn@FreeBSD.ORG Subject: Re: isppp + dynamic IP Message-ID: <199811231546.QAA00687@neuron.webmore.prv> In-Reply-To: <199811221609.RAA00533@oranje.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Nov, Marc van Woerkom wrote: > >> When the connection goes up >> the ISDN interface has ANY address and sends out its first packet. >> While negotiating with the ISP the interface CHANGES its address to >> the newly assigned one and won't accept the answer for the first sent Wrong. The first outgoing packet on a dynamic-IP interface never gets back. Read on. >> packet (in addition the ISP won't even send this answer to THIS >> interface since the dynamic address meanwhile belongs somewhere else). >> Sending a second packet when the connection is up and configured >> you get your answer. > > %&$!, you are right. No ... not. You both better reread the discussion with subject: "TCP checksum errors resulting from IP addr change" on hackers, where Hellmuth raised a similiar topic. In short, until the interface has not been assigned the dynamic IP-adr, the outgoing packets get a source-IP of 0.0.0.0 This would be solvable if it were all about it, unfortunately there is more than this: some clients, take telnet for example, are bound for the whole session after calling connect(). That means the session is bound to 0.0.0.0 on the local side when the connect() returns prior to the link getting established. > > And the network interface often changes its IP address several times, > for I use an idle time of about 30s to minimi$e online time.. > > Sometimes I see the line going up again, without me doing a request. Left over requests. > > My guess is that this is some sort of control packet, by an older > request of mine, that has not been completed (e.g. a lame ftp transfer), > and that is now fooled because the IP at time of the request > is different from the present IP now due to a hang up in between. > > Solution? > For *incoming* packages, the network mechanism ought to keep a table > of all IP addresses that were in use by the interface, > routing packages with outdated addresses to the address in use now. Nooo !!! You don't really want such a thing !!! Besides the data-privacy issues, it would require you to change the routing of dialin-servers. > > I am not sure how to make the system work like this. > Well, natd looks promising - is anyone familiar with it here? > > >> i4l has a dynip patch which stores the first packet with the old >> address which triggers dialing and resends it when the connection >> is up (with the new address in the packet). Try this with telnet on linux. Does it work ? As i said, there is much more than this. Read the discussion i mentioned above. It also gives the reason, why this solution only works for some clients. > BTW - what is the easiest way to monitor an interface, at socket level? > 'tcpdump' (the way I use it) produces way too much information, > 'systat 1 -net' is a bit too transient. Make havy use of "expression" in tcpdump to filter the output-stream. Malte. > > > Regards, > Marc -- Malte Lance. --- composed with TkRat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811231546.QAA00687>