From owner-freebsd-hackers Fri Aug 28 08:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA29803 for freebsd-hackers-outgoing; Fri, 28 Aug 1998 08:16:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (cagw2.att.com [192.128.52.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA29783 for ; Fri, 28 Aug 1998 08:16:45 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: from caig2.fw.att.com by cagw2.att.com (AT&T/IPNS/UPAS-1.0) for freebsd.org!freebsd-hackers sender dcn.att.com!sbabkin (dcn.att.com!sbabkin); Fri Aug 28 11:11 EDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by caig2.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id LAA17975 for ; Fri, 28 Aug 1998 11:15:34 -0400 (EDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Fri, 28 Aug 1998 11:15:30 -0400 Message-ID: To: stefan@promo.de, hm@kts.org Cc: freebsd-hackers@FreeBSD.ORG Subject: RE: TCP checksum errors resulting from IP addr change Date: Fri, 28 Aug 1998 11:15:27 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Stefan Bethke [SMTP:stefan@promo.de] > > On Fre, 28. Aug 1998 9:22 Uhr +0200 Hellmuth Michaelis > wrote: > > > 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. > Sorry for a stupid question, but may it be related somehow to the header compression mode ? I'm not sure about the PPP compression but for SLIP these symptoms would clearly indicate that one side is working with compression while another one is working without compression. The SLIP compression works on a per-connection basis, so datagram packets and the TCP SYN packets are always not compressed - so ping works and you can establish the connection, but following TCP packets have their headers compressed by removing the redundant information that can be restored from previous TCP packets, so they would appear broken if the other side works in other mode. It may be that PPP is using something like this (and it also has 2 different compression modes). -Sergey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message