Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Aug 1998 16:47:30 +0200
From:      Stefan Bethke <stefan@promo.de>
To:        hm@kts.org
Cc:        FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: TCP checksum errors resulting from IP addr change
Message-ID:  <1193403.3113311650@d254.promo.de>
In-Reply-To: <m0zCIrr-00001vC@bert.kts.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fre, 28. Aug 1998 9:22 Uhr +0200 Hellmuth Michaelis <hm@kts.org> wrote:

> Hi,
> 
> I've posted this to -net without a reaction. Any reaction is welcome since
> i totally ran out of ideas:
> 
> 
> I'm trying to debug a strange effect occuring on a sync PPP ISDN interface
> which is used to connect to a Cisco 1003 (on 192.76.124.10).
> 
> To get an address dynamically from the remote side, the local PPP inter-
> face (on 2.2.5-RELEASE) is set up with:
> 
>     ifconfig isppp0 link1 0.0.0.0 192.76.124.10 netmask 0xffffffff debug
> 
> Now i telnet to 192.76.124.10 and the link gets established but the telnet
> session doesn't.
> 
> I looked at the traces and noticed the very first IP packet going out with
> source address 0.0.0.0 to the Cisco - i removed that in the driver but
> still the telnet session is not established. (btw. only the first session
> is not  established, if i terminate the first telnet and restart it on
> the open link, it works immediately; but i want the first to work ...).
> 
> I enabled TCP debugging on the Cisco, and for all the packets from this
> first telnet session it says "TCP checksum error".
> 
> So i think, IP address 0.0.0.0 is used for checksum calculation of the TCP
> packets for this forst session, but the "real" IP address of the interface
> changes to 192.something after the first packet and the TCP checksum is 
> somehow not recalculated causing checksum errors on the remote side (Is
> this correct ?).

The problem here is that as soon as telnet does it's connect(), the socket
is completly bound for both local and remote address and port. The (bogus)
local address will be kept until telnet closes the socket, disconnect it,
or bind()s a new address.

The TCP checksum errors result from ip_output() (or so, I have to check the
source and/or Stevens for that) putting the first IP if_addr as the source
address into the packet. TCP still will use the address bound to (0.0.0.0)
and will calculate it's checksum based on that.

> Is there a way to inform the TCP layer to recalculate checksums or to get
> the new IP address from the interface ?

No, IMO.

> Do i have to recalculate the checksums for this session in the driver ?

This might help in terms of a telnet session, but I'm pretty sure
getsockname() will return 0.0.0.0, which in itself will cause some nasty
problems (consider FTP).

> Has anyone another hint or an idea how to solve this ?

Basically, I feel, you have three options:
- Until the real address is assigned, drop all packets with an error
(ENETDOWN or such). This at least will be straightforward to implement,
although not very pleasent to use.
- Make the socket layer listen to routing messages, and update all sockets
on an interface address change. This is probably complicated enought, and
won't even help with a) programs doing getsockname() too early, and b) with
subseqent address changes due to the line going down, then up again, thus
being assigned a different address by the PPP server.
- Implement a "mini" NAT inside of the interface, just as userland ppp does.

The easiest solution however is to get a decent ISP :-)

Cheers,
Stefan

--
Stefan Bethke
Promo Datentechnik      |  Tel. +49-40-851744-18
+ Systemberatung GmbH   |  Fax. +49-40-851744-44
Eduardstrasse 46-48     |  e-mail: stefan@Promo.DE
D-20257 Hamburg         |  http://www.Promo.DE/

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?1193403.3113311650>