Date: Thu, 8 Aug 2002 17:09:37 +0200 From: "Sven Euteneuer" <maillists@euteneuer.com> To: <freebsd-net@FreeBSD.ORG> Subject: PPTP connections breaking down Message-ID: <MGEDLGINJKPJJFNKBNIIOEECCEAA.maillists@euteneuer.com>
next in thread | raw e-mail | index | archive | help
Hi guys, it looks like I have an issue with the way PPP/PPTP is implemented in FreeBSD 4.6. I'm using an old Cyrix166 box to serve as a tunnel gateway for WLAN devices to our standard 100BaseTx Ethernet LAN. The box has run a very similar configuration under Linux 2.4.4 (the SuSE variety) before without any issues, but after converting it to FreeBSD, PPTP tunnels into the LAN (e.g. to get a file from an SMB server) break down after a small amount of data has been transferred (~4-6MB). The logs suggest that client and gateway completely lose sync (see below for a short excerpt of the logs). The tunnel stays open after both sides have lost sync until LQM detects the problem and closes the connection, but no packet makes it thru from either side. I've tried the PoPToP daemon v1.1.2 from the ports collection (which I've used under Linux as well), as well as the mpd daemon v3.8 & netgraph to serve as PPTP entry points, but both exhibit the exact same behavior. The PPTP clients are usually running Windows 2000 and Belkin 802.11b cards and connect to the PPTP server using the standard Windows RAS PPTP client. Connection and authentication work like a charm and both sides negotiate MSCHAPv2 for authentication and MPPE128 stateless for compression&encryption. Thru trial and error I was able to track down the problem to somewhere between the WLAN card & the PPP daemon. However, since the WLAN cards have worked with the Linux incarnation of the gateway I'm tempted to believe that the issue *might* (I've no reason to believe that this is actually true) be with the PPP userland implementation. Any insight from someone more knowledgeable than me? Thanks, Sven --- /var/log/messages: Aug 6 18:11:32 router1 ppp[235]: tun1: Warning: deflink: Reducing configured MRU from 1500 to 1492 Aug 6 18:11:32 router1 pptpd[234]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! <file download starts> Aug 6 18:12:00 router1 ppp[235]: tun1: Error: MPPE: Input: Invalid packet (flags = 0x3000) Aug 6 18:12:07 router1 pptpd[234]: GRE: Bad packet flags 30 ver 81 proto 8800 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4467, already have 12340 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4468, already have 12340 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4469, already have 12340 ... Aug 6 18:13:04 router1 pptpd[234]: EOF reading from pppd /var/log/ppp.log: <tunnel established> Aug 6 18:11:36 router1 ppp[235]: tun1: LCP: Reducing MTU from 1492 to 1490 (CCP requirement) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 0 = ioctl(7, 2148037723, 0xbfbfefb8) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 1 = socket(17, 3, 0) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 108 = write(1, data, 108) Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN SOA inspiron8000.xxxxxx.xxx. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN A router1..xxxxxx.xxx. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query <0x97 <0xc0 .xxxxxx.xxx... Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN SOA 0.168.192.in-addr.arpa. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query <0x65 <0x26 0.168.192.in-addr.arpa... Aug 6 18:11:37 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(1) state = Opened Aug 6 18:11:42 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(1) state = Opened Aug 6 18:11:43 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(2) state = Opened Aug 6 18:11:43 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(2) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(3) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(3) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: DNS: INbound query IN A amd2000xp.xxxx.xxx. <this is where the SMB transfer starts> Aug 6 18:11:53 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(4) state = Opened Aug 6 18:11:53 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(4) state = Opened Aug 6 18:11:58 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(5) state = Opened Aug 6 18:11:58 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(5) state = Opened Aug 6 18:12:00 router1 ppp[235]: tun1: Error: MPPE: Input: Invalid packet (flags = 0x3000) Aug 6 18:12:03 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(6) state = Opened Aug 6 18:12:03 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(6) state = Opened Aug 6 18:12:07 router1 ppp[235]: tun1: Phase: Unknown protocol 0x0068 (unrecognised protocol) ... <this is where the sync is lost> Aug 6 18:12:34 router1 ppp[235]: tun1: Phase: deflink: HDLC errors -> FCS: 0, ADDR: 0, COMD: 0, PROTO: 1 Aug 6 18:12:34 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(12) state = Opened Aug 6 18:12:34 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(12) state = Opened Aug 6 18:12:38 router1 ppp[235]: tun1: Phase: Unknown protocol 0x3434 (unrecognised protocol) ... Aug 6 18:13:04 router1 ppp[235]: tun1: Phase: deflink: ** Too many ECHO LQR packets lost ** Aug 6 18:13:04 router1 ppp[235]: tun1: LQM: deflink: Too many ECHO LQR packets lost Aug 6 18:13:04 router1 ppp[235]: tun1: CCP: deflink: LayerDown. <tunnel down> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MGEDLGINJKPJJFNKBNIIOEECCEAA.maillists>