You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(39) |
Feb
(10) |
Mar
(16) |
Apr
(42) |
May
(95) |
Jun
(34) |
Jul
(9) |
Aug
(5) |
Sep
(15) |
Oct
(41) |
Nov
(32) |
Dec
(8) |
2002 |
Jan
(9) |
Feb
(95) |
Mar
(83) |
Apr
(63) |
May
(52) |
Jun
(62) |
Jul
(42) |
Aug
(104) |
Sep
(47) |
Oct
(82) |
Nov
(102) |
Dec
(99) |
2003 |
Jan
(120) |
Feb
(95) |
Mar
(121) |
Apr
(125) |
May
(127) |
Jun
(98) |
Jul
(101) |
Aug
(74) |
Sep
(86) |
Oct
(85) |
Nov
(91) |
Dec
(135) |
2004 |
Jan
(23) |
Feb
(68) |
Mar
(75) |
Apr
(147) |
May
(64) |
Jun
(193) |
Jul
(124) |
Aug
(103) |
Sep
(95) |
Oct
(129) |
Nov
(83) |
Dec
(88) |
2005 |
Jan
(69) |
Feb
(159) |
Mar
(173) |
Apr
(114) |
May
(138) |
Jun
(48) |
Jul
(119) |
Aug
(83) |
Sep
(58) |
Oct
(79) |
Nov
(26) |
Dec
(38) |
2006 |
Jan
(44) |
Feb
(35) |
Mar
(72) |
Apr
(83) |
May
(37) |
Jun
(14) |
Jul
(26) |
Aug
(31) |
Sep
(42) |
Oct
(25) |
Nov
(51) |
Dec
(15) |
2007 |
Jan
(21) |
Feb
(54) |
Mar
(71) |
Apr
(22) |
May
(16) |
Jun
(8) |
Jul
(1) |
Aug
(17) |
Sep
(5) |
Oct
(19) |
Nov
(31) |
Dec
(11) |
2008 |
Jan
(7) |
Feb
(26) |
Mar
(24) |
Apr
(22) |
May
(20) |
Jun
(8) |
Jul
(10) |
Aug
(22) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(7) |
2009 |
Jan
(20) |
Feb
(11) |
Mar
(15) |
Apr
(18) |
May
(27) |
Jun
(18) |
Jul
(3) |
Aug
(11) |
Sep
(4) |
Oct
(4) |
Nov
(41) |
Dec
(13) |
2010 |
Jan
(21) |
Feb
(10) |
Mar
(9) |
Apr
(22) |
May
|
Jun
(55) |
Jul
|
Aug
(4) |
Sep
(12) |
Oct
(5) |
Nov
(2) |
Dec
(4) |
2011 |
Jan
(13) |
Feb
(4) |
Mar
(12) |
Apr
(6) |
May
|
Jun
(1) |
Jul
(8) |
Aug
|
Sep
(13) |
Oct
(2) |
Nov
(16) |
Dec
(20) |
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
2013 |
Jan
(35) |
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
|
Dec
|
2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2015 |
Jan
(8) |
Feb
(5) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(19) |
Nov
(1) |
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(3) |
2017 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
(4) |
2018 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
(2) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: James C. <qu...@la...> - 2020-09-08 08:08:20
|
Thanks. Your patch did not apply using "git am", possibly because it was not against master branch, so it was merged by hand. I took the opportunity to remove some trailing spaces. On Sun, Aug 16, 2020 at 04:57:52PM +0200, Hrvoje Cavrak wrote: > Hi everyone, > > I'd like to try and submit a patch for a feature I needed and had to > implement myself, so my reasoning was to try and help someone else and > the project as well. > > TL;DR - I wasn't able to connect to some Cisco gear, the admin kept > mentioning he set terminate-from to something he provided and I need > to set my hostname. I had no idea what he was on about, but decided to > investigate. > > Cisco gear apparently can assign users to different VPDN groups using > terminate-from option. This references to the hostname field in the > PPTP control header that is hardcoded to "local" in Linux PPTP client. > This option merely provides user the means to specify the client > hostname that's going to be reported to the server. If nothing is > provided, it defaults to local and there is no change in behavior. > Other PPTP stacks can do this apparently (MikroTik routers for > example) so I thought it would be cool if Linux could as well :) > > I would like to thank everyone for the hard work in maintaining this > alive. Apparently legacy systems are pretty much all around us and > having software that works is a great thing. > > Cheers! > > Hrvoje -- James Cameron http://quozl.netrek.org/ |
From: Hrvoje C. <hrv...@gm...> - 2020-08-16 14:58:01
|
Hi everyone, I'd like to try and submit a patch for a feature I needed and had to implement myself, so my reasoning was to try and help someone else and the project as well. TL;DR - I wasn't able to connect to some Cisco gear, the admin kept mentioning he set terminate-from to something he provided and I need to set my hostname. I had no idea what he was on about, but decided to investigate. Cisco gear apparently can assign users to different VPDN groups using terminate-from option. This references to the hostname field in the PPTP control header that is hardcoded to "local" in Linux PPTP client. This option merely provides user the means to specify the client hostname that's going to be reported to the server. If nothing is provided, it defaults to local and there is no change in behavior. Other PPTP stacks can do this apparently (MikroTik routers for example) so I thought it would be cool if Linux could as well :) I would like to thank everyone for the hard work in maintaining this alive. Apparently legacy systems are pretty much all around us and having software that works is a great thing. Cheers! Hrvoje |
From: James C. <qu...@la...> - 2020-05-15 03:49:31
|
Thanks, taken. -- James Cameron http://quozl.netrek.org/ |
From: Jaroslav S. <jsk...@re...> - 2020-05-14 20:01:17
|
Hi, in Fedora we did man pages check and it seems the new option --missing-window is missing from the manual page. I also added the --version option and fixed one typo in the built-in help. Patch is attached thanks & regards Jaroslav |
From: James C. <qu...@la...> - 2020-04-27 03:36:32
|
Hello Kim, I agree you don't have the firewall software turned on. I suggest looking for iptables or other filtering rules. I'm not familiar with OpenSUSE, but on other systems I've used the command iptables-save to dump all currently active rules. Looking again at your pppd debug dump and tcpdump; - the PPTP control connection is established from the pptp program and there is good communication with the server over TCP, - the GRE packets in the tcpdump show the server is negotiating toward LCP agreement, as expected, but that the client is repeating the same sequence number LCP ConfReq; this means pppd has not heard any answers, - the pppd process is not receiving packets from the server, but is able to transmit packets and they are seen in both pppd debug dump and tcpdump; this implies that the pptp program is continuing to run and is relaying data from the pty to the GRE socket, - once the negotiation times out, the PPTP control connection properly collapses with a call clear request, and the call id fields do match the GRE packets; this implies the NAT router that must be nearby is modifying the PPTP control connection and the GRE packets consistently. You might look at "ip route" _during_ the connection attempt. You might use "strace" to instrument the pptp program to see if the packets from the server shown by tcpdump are being received on the GRE socket without error. You might check for log files of the pptp program. You might check for GRE or PPTP related kernel modules with lsmod; none of them are expected, they are most often used on routers that run Linux. I do have vague memory of one scenario where a NAT router modifies the packets in a way that works with Windows but doesn't work with Linux. I'm sure you have a NAT router of some sort, because the client IP address is 192.168.0.102, in an unroutable subnet. You might check for later firmware for your NAT router. Also, if you have any other tunnelling protocol you can use instead, please do so. PPTP is weak and fragile, and was not designed for the environment we have now. -- James Cameron http://quozl.netrek.org/ |
From: Kim F. <kaf...@ya...> - 2020-04-26 00:34:26
|
James Cameron <qu...@la...>To:ppt...@li...UnsubscribeMon, Apr 20 at 12:53 AMYour pppd debug log shows LCP ConfReq and no LCP ConfAck, yet the tcpdump shows LCP ConfAck. Looks like none of the received GRE packets are getting through. -- James Cameron http://quozl.netrek.org/ Everyone: I know this looks suspiciously like a firewall issue but the firewall is turned off. I checked ip route before trying to connect: kim@linux-nogg:~> ip route default via 192.168.0.1 dev eth0 proto dhcp metric 100 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.102 metric 100 and after: kim@linux-nogg:~> ip route default via 192.168.0.1 dev eth0 proto dhcp metric 100 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.102 metric 100 The change looks right to me and I think the script in the folder at /ect/ppp/Ip-up.d/ is working correctly. I don't think the router is filtering anything because the VPN tunnel works correctly in Windows. This is April 25th and it is my 66th birthday. I was hoping for a less difficult problem to solve as a present but don't think I am getting my wish. I would appreciate even wild speculation as to what to look for that might cause this. Thanks. |
From: James C. <qu...@la...> - 2020-04-20 05:53:37
|
Your pppd debug log shows LCP ConfReq and no LCP ConfAck, yet the tcpdump shows LCP ConfAck. Looks like none of the received GRE packets are getting through. -- James Cameron http://quozl.netrek.org/ |
From: Kim F. <kaf...@ya...> - 2020-04-18 22:06:23
|
- Maris & James: Upgraded pptp. kim@linux-nogg:~> zypper se -si pptp Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+----------------------+--------+--------------------------------------- i+ | NetworkManager-pptp | package | 1.2.8-2.1 | x86_64 | openSUSE:Factory i+ | NetworkManager-pptp-gnome | package | 1.2.8-2.1 | x86_64 | openSUSE:Factory i+ | NetworkManager-pptp-lang | package | 1.2.8-2.1 | noarch | openSUSE:Factory i+ | plasma-nm5-pptp | package | 5.12.8-lp151.1.1 | x86_64 | Main Repository (OSS) i+ | plasma-nm5-pptp-debuginfo | package | 5.18.4.1-lp151.349.1 | x86_64 | home:wolfi323:branches:KDE:Frameworks5 i+ | pptp | package | 1.10.0-1.1 | x86_64 | openSUSE:Factory i+ | pptpd | package | 1.4.0-lp151.2.2 | x86_64 | Main Repository (OSS) upgraded iproute. kim@linux-nogg:~> zypper se -si iproute Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+---------------+---------+---------------+--------+------------------ i+ | iproute2 | package | 5.3-lp152.2.2 | x86_64 | (System Packages) i | iproute2-arpd | package | 5.6.0-2.1 | x86_64 | openSUSE:Factory I don't see any real difference in the dumps. kim@linux-nogg:~> sudo pppd call OESC-VPN debug dump logfd 2 nodetach [sudo] password for root: pppd options in effect: debug # (from command line) nodetach # (from command line) idle 600 # (from /etc/ppp/options) logfd 2 # (from command line) dump # (from command line) active-filter xxx # [don't know how to print value] # (from /etc/ppp/filters) noauth # (from /etc/ppp/options.pptp) refuse-pap # (from /etc/ppp/peers/OESC-VPN) refuse-chap # (from /etc/ppp/peers/OESC-VPN) refuse-mschap # (from /etc/ppp/peers/OESC-VPN) refuse-eap # (from /etc/ppp/peers/OESC-VPN) name kimf # (from /etc/ppp/peers/OESC-VPN) remotename OESC-VPN # (from /etc/ppp/peers/OESC-VPN) # (from /etc/ppp/options.pptp) pty pptp 204.87.122.177 --nolaunchpppd # (from /etc/ppp/peers/OESC-VPN) crtscts # (from /etc/ppp/options) # (from /etc/ppp/options) asyncmap 0 # (from /etc/ppp/options) mru 1000 # (from /etc/ppp/options.pptp) mtu 1000 # (from /etc/ppp/options.pptp) lcp-echo-failure 10 # (from /etc/ppp/options.pptp) lcp-echo-interval 10 # (from /etc/ppp/options.pptp) lcp-restart 2 # (from /etc/ppp/options) lcp-max-configure 60 # (from /etc/ppp/options) ipparam OESC-VPN # (from /etc/ppp/peers/OESC-VPN) noipdefault # (from /etc/ppp/options) nobsdcomp # (from /etc/ppp/options.pptp) nodeflate # (from /etc/ppp/options.pptp) require-mppe # (from /etc/ppp/options.pptp) nomppe-stateful # (from /etc/ppp/peers/OESC-VPN) noipx # (from /etc/ppp/options) using channel 5 Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x3290acf4> <pcomp> <accomp>] ^CTerminating on signal 2 Modem hangup Connection terminated. Script pptp 204.87.122.177 --nolaunchpppd finished (pid 6049), status = 0x0 20:35:25.789525 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [S], seq 2814903810, win 29200, options [mss 1460,sackOK,TS val 923047128 ecr 0,n op,wscale 7], length 0 20:35:25.789692 IP 192.168.0.102.48987 > resolver2.opendns.com.domain: 30616+ PTR? 177.122.87.204.in-addr.arpa. (45) 20:35:25.812904 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [S.], seq 1455657974, ack 2814903811, win 32120, options [mss 1350], length 0 20:35:25.812974 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [.], ack 1, win 29200, length 0 20:35:25.813406 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [P.], seq 1:157, ack 1, win 29200, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER( 1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian) 20:35:25.825903 IP resolver2.opendns.com.domain > 192.168.0.102.48987: 30616 NXDomain 0/1/0 (108) 20:35:25.835769 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [.], ack 157, win 31964, length 0 20:35:25.836776 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [P.], seq 1:157, ack 157, win 32120, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VE R(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft) 20:35:25.836789 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [.], ack 157, win 30016, length 0 20:35:26.813819 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [P.], seq 157:325, ack 157, win 30016, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID (58740) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(3) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR( ) 20:35:26.833375 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [.], ack 325, win 31952, length 0 20:35:26.834389 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [P.], seq 157:189, ack 325, win 32120, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID( 53397) PEER_CALL_ID(58740) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(13277755) RECV_WIN(16384) PROC_DELAY(0) PHY_CHAN_ID(0) 20:35:26.834417 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [.], ack 189, win 30016, length 0 20:35:26.834664 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 1, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:26.856260 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 0, ack 1, length 73: LCP, Conf-Request (0x01), id 0, length 55 20:35:26.856305 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 1, length 40: LCP, Conf-Ack (0x02), id 1, length 26 20:35:27.478857 IP 192.168.0.102.ntp > linode.ibendit.com.ntp: NTPv4, Client, length 48 20:35:27.494442 IP linode.ibendit.com.ntp > 192.168.0.102.ntp: NTPv4, Server, length 48 20:35:27.921657 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 2, length 69: LCP, Conf-Request (0x01), id 1, length 55 20:35:28.735456 IP 192.168.0.102.51968 > 151.101.49.7.https: Flags [.], ack 1708411365, win 524, options [nop,nop,TS val 1424763506 ecr 373795959], l ength 0 20:35:28.735886 IP 192.168.0.102.52790 > resolver2.opendns.com.domain: 56721+ PTR? 7.49.101.151.in-addr.arpa. (43) 20:35:28.748913 IP 151.101.49.7.https > 192.168.0.102.51968: Flags [.], ack 1, win 63, options [nop,nop,TS val 373807223 ecr 1424176040], length 0 20:35:28.754048 IP resolver2.opendns.com.domain > 192.168.0.102.52790: 56721 NXDomain 0/1/0 (103) 20:35:28.780317 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 2, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:28.799956 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 3, ack 2, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:30.782505 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 3, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:30.803783 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 4, ack 3, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:30.921872 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 5, length 69: LCP, Conf-Request (0x01), id 2, length 55 20:35:32.784722 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 4, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:32.803628 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 6, ack 4, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:33.079789 IP 192.168.0.102.48594 > e1.ycpi.vip.daa.yahoo.com.https: Flags [P.], seq 1:216, ack 1, win 2820, options [nop,nop,TS val 3746948112 ecr 725006688], length 215 20:35:33.079886 IP 192.168.0.102.48594 > e1.ycpi.vip.daa.yahoo.com.https: Flags [P.], seq 216:650, ack 1, win 2820, options [nop,nop,TS val 374694811 2 ecr 725006688], length 434 20:35:33.095735 IP e1.ycpi.vip.daa.yahoo.com.https > 192.168.0.102.48594: Flags [.], ack 650, win 716, options [nop,nop,TS val 725022555 ecr 37469481 12], length 0 20:35:33.096713 IP e1.ycpi.vip.daa.yahoo.com.https > 192.168.0.102.48594: Flags [P.], seq 1:32, ack 650, win 716, options [nop,nop,TS val 725022556 e cr 3746948112], length 31 20:35:33.096726 IP 192.168.0.102.48594 > e1.ycpi.vip.daa.yahoo.com.https: Flags [.], ack 32, win 2820, options [nop,nop,TS val 3746948129 ecr 7250225 56], length 0 20:35:33.096819 IP e1.ycpi.vip.daa.yahoo.com.https > 192.168.0.102.48594: Flags [P.], seq 32:62, ack 650, win 716, options [nop,nop,TS val 725022556 ecr 3746948112], length 30 20:35:33.096825 IP 192.168.0.102.48594 > e1.ycpi.vip.daa.yahoo.com.https: Flags [.], ack 62, win 2820, options [nop,nop,TS val 3746948129 ecr 7250225 56], length 0 20:35:33.183575 IP 192.168.0.101.netbios-ns > 192.168.0.255.netbios-ns: UDP, length 50 20:35:33.183707 IP6 710-C952YR2.local.50392 > ff02::1:3.llmnr: UDP, length 22 20:35:33.183730 IP 192.168.0.101.50392 > 224.0.0.252.llmnr: UDP, length 22 20:35:33.183739 IP6 710-C952YR2.local.52824 > ff02::1:3.llmnr: UDP, length 22 20:35:33.183838 IP 192.168.0.101.52824 > 224.0.0.252.llmnr: UDP, length 22 20:35:33.183939 IP 192.168.0.102.39115 > resolver2.opendns.com.domain: 29929+ PTR? 255.0.168.192.in-addr.arpa. (44) 20:35:33.198915 IP resolver2.opendns.com.domain > 192.168.0.102.39115: 29929 NXDomain* 0/1/0 (103) 20:35:33.224452 IP 192.168.0.102.41481 > resolver2.opendns.com.domain: 54048+ PTR? 3.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip 6.arpa. (90) 20:35:33.370569 IP 192.168.0.102.52125 > resolver2.opendns.com.domain: 36423+ PTR? 252.0.0.224.in-addr.arpa. (42) 20:35:33.600232 IP6 710-C952YR2.local.50392 > ff02::1:3.llmnr: UDP, length 22 20:35:33.600282 IP6 710-C952YR2.local.52824 > ff02::1:3.llmnr: UDP, length 22 20:35:33.600293 IP 192.168.0.101.52824 > 224.0.0.252.llmnr: UDP, length 22 20:35:33.600399 IP 192.168.0.101.50392 > 224.0.0.252.llmnr: UDP, length 22 20:35:33.943296 IP 192.168.0.101.netbios-ns > 192.168.0.255.netbios-ns: UDP, length 50 20:35:34.007895 IP 192.168.0.101.netbios-ns > 192.168.0.255.netbios-ns: UDP, length 50 20:35:34.710059 IP 192.168.0.101.netbios-ns > 192.168.0.255.netbios-ns: UDP, length 50 20:35:34.772868 IP 192.168.0.101.netbios-ns > 192.168.0.255.netbios-ns: UDP, length 50 20:35:34.786853 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 5, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:34.805443 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 7, ack 5, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:34.937520 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 8, length 69: LCP, Conf-Request (0x01), id 3, length 55 20:35:36.789079 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 6, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:36.807281 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 9, ack 6, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:38.791250 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 7, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:38.811153 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 10, ack 7, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:38.953202 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 11, length 69: LCP, Conf-Request (0x01), id 4, length 55 20:35:38.975465 IP 192.168.0.102.51402 > o2.ycpi.vip.ne1.yahoo.com.https: Flags [.], ack 397765338, win 387, options [nop,nop,TS val 2398546124 ecr 5 10965189], length 0 20:35:38.975484 IP 192.168.0.102.42128 > e2.ycpi.vip.daa.yahoo.com.https: Flags [.], ack 668828125, win 500, options [nop,nop,TS val 3851547131 ecr 1 480249259], length 0 20:35:38.975670 IP 192.168.0.102.35931 > resolver2.opendns.com.domain: 8699+ PTR? 137.228.6.74.in-addr.arpa. (43) 20:35:38.989177 IP e2.ycpi.vip.daa.yahoo.com.https > 192.168.0.102.42128: Flags [.], ack 1, win 147, options [nop,nop,TS val 1480294314 ecr 385069010 1], length 0 20:35:38.993283 IP resolver2.opendns.com.domain > 192.168.0.102.35931: 8699 1/0/0 PTR o2.ycpi.vip.ne1.yahoo.com. (82) 20:35:39.012103 IP o2.ycpi.vip.ne1.yahoo.com.https > 192.168.0.102.51402: Flags [.], ack 1, win 197, options [nop,nop,TS val 511010243 ecr 2397688552 ], length 0 20:35:40.793430 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 8, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:40.811874 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 12, ack 8, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:41.307194 IP 151.101.49.7.https > 192.168.0.102.51968: Flags [P.], seq 1:32, ack 1, win 63, options [nop,nop,TS val 373810362 ecr 1424176040], length 31 20:35:41.307262 IP 192.168.0.102.51968 > 151.101.49.7.https: Flags [.], ack 32, win 524, options [nop,nop,TS val 1424776078 ecr 373810362], length 0 20:35:41.307364 IP 151.101.49.7.https > 192.168.0.102.51968: Flags [F.], seq 32, ack 1, win 63, options [nop,nop,TS val 373810362 ecr 1424176040], le ngth 0 20:35:41.351455 IP 192.168.0.102.51968 > 151.101.49.7.https: Flags [.], ack 33, win 524, options [nop,nop,TS val 1424776122 ecr 373810362], length 0 20:35:42.795613 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 9, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:42.818782 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 13, ack 9, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:42.953830 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 14, length 69: LCP, Conf-Request (0x01), id 5, length 55 20:35:44.644993 IP 192.168.0.139.50390 > 192.168.0.102.weblogin: UDP, length 28 20:35:44.645362 IP 192.168.0.102.35719 > resolver2.opendns.com.domain: 5468+ PTR? 139.0.168.192.in-addr.arpa. (44) 20:35:44.661680 IP resolver2.opendns.com.domain > 192.168.0.102.35719: 5468 NXDomain* 0/1/0 (103) 20:35:44.797788 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 10, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:44.817563 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 15, ack 10, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:46.799925 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 11, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:46.822333 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 16, ack 11, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:46.954691 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 17, length 69: LCP, Conf-Request (0x01), id 6, length 55 20:35:47.062628 ARP, Request who-has 192.168.0.1 (Broadcast) tell 192.168.0.86, length 46 20:35:47.063058 IP 192.168.0.102.37710 > resolver2.opendns.com.domain: 56068+ PTR? 86.0.168.192.in-addr.arpa. (43) 20:35:47.080727 IP resolver2.opendns.com.domain > 192.168.0.102.37710: 56068 NXDomain* 0/1/0 (102) 20:35:48.802109 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 12, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:48.822255 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 18, ack 12, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:49.214905 ARP, Request who-has 192.168.0.102 (b8:97:5a:90:4a:0b (oui Unknown)) tell 192.168.0.139, length 46 20:35:49.214944 ARP, Reply 192.168.0.102 is-at b8:97:5a:90:4a:0b (oui Unknown), length 28 20:35:49.934329 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 256 20:35:49.934362 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 328 20:35:49.934461 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 324 20:35:49.934566 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 304 20:35:49.934673 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 336 20:35:49.934866 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 318 20:35:49.934958 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 320 20:35:49.935050 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 320 20:35:50.804294 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 13, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:50.824042 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 19, ack 13, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:50.954163 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 20, length 69: LCP, Conf-Request (0x01), id 7, length 55 20:35:52.806474 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 14, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:52.825873 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 21, ack 14, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:53.837971 ARP, Request who-has 192.168.0.102 tell 192.168.0.1, length 46 20:35:53.837990 ARP, Reply 192.168.0.102 is-at b8:97:5a:90:4a:0b (oui Unknown), length 28 20:35:54.808661 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 15, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:54.827638 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 22, ack 15, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:54.970821 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 23, length 69: LCP, Conf-Request (0x01), id 8, length 55 20:35:56.810846 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 16, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:56.836573 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 24, ack 16, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:58.813032 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 17, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:35:58.833285 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 25, ack 17, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:35:59.017444 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 26, length 69: LCP, Conf-Request (0x01), id 9, length 55 20:36:00.396429 ARP, Request who-has 192.168.0.126 (Broadcast) tell 192.168.0.86, length 46 20:36:00.396825 IP 192.168.0.102.34454 > resolver2.opendns.com.domain: 38506+ PTR? 126.0.168.192.in-addr.arpa. (44) 20:36:00.411154 IP resolver2.opendns.com.domain > 192.168.0.102.34454: 38506 NXDomain* 0/1/0 (103) 20:36:00.815216 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 18, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:36:00.834121 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 27, ack 18, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:36:02.817387 IP 192.168.0.102 > 204.87.122.177: GREv1, call 53397, seq 19, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:36:02.835960 IP 204.87.122.177 > 192.168.0.102: GREv1, call 58740, seq 28, ack 19, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:36:03.034138 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [P.], seq 189:205, ack 325, win 32120, length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID( 53397) 20:36:03.034211 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [.], ack 205, win 30016, length 0 20:36:03.390610 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [P.], seq 325:341, ack 205, win 30016, length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID( 58740) 20:36:03.390680 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [F.], seq 341, ack 205, win 30016, length 0 20:36:03.409191 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [.], ack 341, win 32104, length 0 20:36:03.410175 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [.], ack 342, win 32120, length 0 20:36:03.410289 IP 204.87.122.177.pptp > 192.168.0.102.40400: Flags [P.], seq 205:353, ack 342, win 32120, length 148: pptp CTRL_MSGTYPE=CDN CALL_ID( 58740) RESULT_CODE(0) ERR_CODE(0) CAUSE_CODE(0) CALL_STATS() 20:36:03.410310 IP 192.168.0.102.40400 > 204.87.122.177.pptp: Flags [R], seq 2814904152, win 0, length 0 20:36:04.763053 IP 192.168.0.102.49248 > resolver2.opendns.com.domain: 44829+ PTR? 242.79.217.3.in-addr.arpa. (43) 20:36:04.777938 IP resolver2.opendns.com.domain > 192.168.0.102.49248: 44829 1/0/0 PTR ec2-3-217-79-242.compute-1.amazonaws.com. (97) 20:36:08.478852 IP 192.168.0.102.ntp > ntp2.wiktel.com.ntp: NTPv4, Client, length 48 20:36:08.524414 IP ntp2.wiktel.com.ntp > 192.168.0.102.ntp: NTPv4, Server, length 48 Show original message - |
From: James C. <qu...@la...> - 2020-04-16 10:39:53
|
I agree. I didn't get the original mail, but checked archives. According to https://software.opensuse.org/package/pptp openSUSE Leap 15.1 packaged pptp 1.8.0, and pptp 1.10.0 can be found in openSUSE Tumbleweed. According to https://software.opensuse.org/package/iproute2 openSUSE Leap 15.1 packaged iproute2 4.12, so is probably vulnerable to the bug that was fixed by 7d9a428. You can either downgrade iproute2, upgrade pptp, or patch pptp with 7d9a428. openSUSE is lagging a bit; * 7d9a428 was made in 2017-12-03, * pptp 1.10.0 was released in 2018-01-18, and; * openSUSE Leap 15.1 was released 2019-05-22, To get this fixed for future openSUSE please report the bug to openSUSE Project. On Thu, Apr 16, 2020 at 09:47:29AM +0300, Maris Nartiss wrote: > Hello Kim, > this awfully looks like the issue with >=iproute2-4.10.0 emitting > extra uid. It was fixed in 1.10.0 release (commit: > https://sourceforge.net/p/pptpclient/git/ci/7d9a428a0744b3053767dc2d239f305c86f1fcee/ > ) > Please check that you are using the latest version of pptpclient. > > Māris. > > ceturtd., 2020. g. 16. apr., plkst. 05:13 — lietotājs Kim Foltz via > pptpclient-devel (<ppt...@li...>) rakstīja: > > > > Error: either "to" is duplicate, or "uid" is a garbage. > > > _______________________________________________ > pptpclient-devel mailing list > ppt...@li... > https://lists.sourceforge.net/lists/listinfo/pptpclient-devel -- James Cameron http://quozl.netrek.org/ |
From: Maris N. <mar...@gm...> - 2020-04-16 06:47:07
|
Hello Kim, this awfully looks like the issue with >=iproute2-4.10.0 emitting extra uid. It was fixed in 1.10.0 release (commit: https://sourceforge.net/p/pptpclient/git/ci/7d9a428a0744b3053767dc2d239f305c86f1fcee/ ) Please check that you are using the latest version of pptpclient. Māris. ceturtd., 2020. g. 16. apr., plkst. 05:13 — lietotājs Kim Foltz via pptpclient-devel (<ppt...@li...>) rakstīja: > > Error: either "to" is duplicate, or "uid" is a garbage. |
From: Kim F. <kaf...@ya...> - 2020-04-16 02:02:23
|
I am running OpenSuse Leap 15.1. My firewall is turned off. I am trying to connect to my office VPN server. Connecting with Windows works but I am struggling with Suse. Telnet to the server works. Tcpdump shows multiple GRE Conf-Requests going out and multiple Conf-Acks coming back but my computer never proceeds to authentication. Any advice would be appreciated. kim@linux-nogg:~> sudo pppd call OESC-VPN debug dump logfd 2 nodetach [sudo] password for root: pppd options in effect: debug # (from command line) nodetach # (from command line) idle 600 # (from /etc/ppp/options) logfd 2 # (from command line) dump # (from command line) active-filter xxx # [don't know how to print value] # (from /etc/ppp/filters) noauth # (from /etc/ppp/options.pptp) refuse-pap # (from /etc/ppp/peers/OESC-VPN) refuse-chap # (from /etc/ppp/peers/OESC-VPN) refuse-mschap # (from /etc/ppp/peers/OESC-VPN) refuse-eap # (from /etc/ppp/peers/OESC-VPN) name (hidden) # (from /etc/ppp/peers/OESC-VPN) remotename OESC-VPN # (from /etc/ppp/peers/OESC-VPN) # (from /etc/ppp/options.pptp) pty pptp 204.87.122.177 --nolaunchpppd # (from /etc/ppp/peers/OESC-VPN) crtscts # (from /etc/ppp/options) # (from /etc/ppp/options) asyncmap 0 # (from /etc/ppp/options) mru 1000 # (from /etc/ppp/options.pptp) mtu 1000 # (from /etc/ppp/options.pptp) lcp-echo-failure 10 # (from /etc/ppp/options.pptp) lcp-echo-interval 10 # (from /etc/ppp/options.pptp) lcp-restart 2 # (from /etc/ppp/options) lcp-max-configure 60 # (from /etc/ppp/options) ipparam OESC-VPN # (from /etc/ppp/peers/OESC-VPN) noipdefault # (from /etc/ppp/options) nobsdcomp # (from /etc/ppp/options.pptp) nodeflate # (from /etc/ppp/options.pptp) require-mppe # (from /etc/ppp/options.pptp) nomppe-stateful # (from /etc/ppp/peers/OESC-VPN) noipx # (from /etc/ppp/options) using channel 27 Using interface ppp0 Connect: ppp0 <--> /dev/pts/5 Error: either "to" is duplicate, or "uid" is a garbage. sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x56b5083e> <pcomp> <accomp>] ^CTerminating on signal 2 Modem hangup Connection terminated. Script pptp 204.87.122.177 --nolaunchpppd finished (pid 5817), status = 0x0 20:44:14.161592 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [S], seq 2821635234, win 29200, options [mss 1460,sackOK,TS val 3290319591 ecr 0, nop,wscale 7], length 0 20:44:14.161760 IP 192.168.0.102.50289 > resolver2.opendns.com.domain: 57715+ PTR? 177.122.87.204.in-addr.arpa. (45) 20:44:14.182814 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [S.], seq 2387090724, ack 2821635235, win 32120, options [mss 1350], length 0 20:44:14.182846 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [.], ack 1, win 29200, length 0 20:44:14.183225 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [P.], seq 1:157, ack 1, win 29200, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER( 1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian) 20:44:14.206725 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [.], ack 157, win 31964, length 0 20:44:14.207721 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [P.], seq 1:157, ack 157, win 32120, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VE R(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft) 20:44:14.446828 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 3947379877:3947379923, ack 881343165, win 254, length 46 20:44:14.446883 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [.], ack 46, win 1452, length 0 20:44:14.447240 IP 192.168.0.102.34099 > resolver2.opendns.com.domain: 59029+ PTR? 246.147.20.146.in-addr.arpa. (45) 20:44:14.447640 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [P.], seq 1:36, ack 46, win 1452, length 35 20:44:14.521000 IP resolver2.opendns.com.domain > 192.168.0.102.34099: 59029 NXDomain 0/1/0 (108) 20:44:14.532770 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 46:99, ack 36, win 254, length 53 20:44:14.532969 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [P.], seq 36:75, ack 99, win 1452, length 39 20:44:14.585929 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 99:173, ack 75, win 254, length 74 20:44:14.586292 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [P.], seq 75:130, ack 173, win 1452, length 55 20:44:14.645456 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 173:342, ack 130, win 254, length 169 20:44:14.645720 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [P.], seq 130:191, ack 342, win 1452, length 61 20:44:14.706145 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 342:459, ack 191, win 254, length 117 20:44:14.711939 IP 192.168.0.78.58282 > 239.255.255.250.ssdp: UDP, length 125 20:44:14.713956 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [P.], seq 191:230, ack 459, win 1452, length 39 20:44:14.775217 IP 146.20.147.246.imaps > 192.168.0.102.52966: Flags [P.], seq 459:498, ack 230, win 254, length 39 20:44:14.815956 IP 192.168.0.102.52966 > 146.20.147.246.imaps: Flags [.], ack 498, win 1452, length 0 20:44:15.183401 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [P.], seq 157:325, ack 157, win 30016, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID (0) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(3) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR() 20:44:15.203765 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [.], ack 325, win 31952, length 0 20:44:15.204744 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [P.], seq 157:189, ack 325, win 32120, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID( 23848) PEER_CALL_ID(0) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(13277755) RECV_WIN(16384) PROC_DELAY(0) PHY_CHAN_ID(0) 20:44:15.204761 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [.], ack 189, win 30016, length 0 20:44:15.204910 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 1, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:15.230077 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 1, length 40: LCP, Conf-Ack (0x02), id 1, length 26 20:44:15.230195 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 0, ack 1, length 73: LCP, Conf-Request (0x01), id 0, length 55 20:44:16.412596 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 2, length 69: LCP, Conf-Request (0x01), id 1, length 55 20:44:17.141003 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 2, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:17.160272 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 3, ack 2, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:19.141179 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 3, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:19.161672 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 4, ack 3, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:19.428894 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 5, length 69: LCP, Conf-Request (0x01), id 2, length 55 20:44:21.143355 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 4, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:21.163788 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 6, ack 4, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:23.144183 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 5, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:23.163448 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 7, ack 5, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:23.388847 IP 192.168.0.102.36943 > resolver2.opendns.com.domain: 46745+ A? safebrowsing.brave.com. (40) 20:44:23.405711 IP resolver2.opendns.com.domain > 192.168.0.102.36943: 46745 2/0/0 CNAME p.ssl.fastly.net., A 151.101.49.7 (86) 20:44:23.459535 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 8, length 69: LCP, Conf-Request (0x01), id 3, length 55 20:44:25.144437 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 6, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:25.163163 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 9, ack 6, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:25.461225 ARP, Request who-has 192.168.0.139 (Broadcast) tell 192.168.0.86, length 46 20:44:25.461568 IP 192.168.0.102.41594 > resolver2.opendns.com.domain: 4716+ PTR? 139.0.168.192.in-addr.arpa. (44) 20:44:25.477524 IP resolver2.opendns.com.domain > 192.168.0.102.41594: 4716 NXDomain* 0/1/0 (103) 20:44:25.477850 IP 192.168.0.102.58615 > resolver2.opendns.com.domain: 26048+ PTR? 86.0.168.192.in-addr.arpa. (43) 20:44:25.499609 IP resolver2.opendns.com.domain > 192.168.0.102.58615: 26048 NXDomain* 0/1/0 (102) 20:44:26.975958 IP 192.168.0.102.60448 > 216.218.159.29.https: Flags [.], ack 1346815657, win 319, options [nop,nop,TS val 3108996143 ecr 2170591728] , length 0 20:44:26.976377 IP 192.168.0.102.50665 > resolver2.opendns.com.domain: 12881+ PTR? 29.159.218.216.in-addr.arpa. (45) 20:44:26.999166 IP resolver2.opendns.com.domain > 192.168.0.102.50665: 12881 NXDomain 1/1/0 CNAME 29.0-27.159.218.216.in-addr.arpa. (124) 20:44:27.037034 IP 216.218.159.29.https > 192.168.0.102.60448: Flags [.], ack 1, win 64, options [nop,nop,TS val 2170603216 ecr 3108950148], length 0 20:44:27.138731 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 256 20:44:27.138837 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 328 20:44:27.138927 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 324 20:44:27.138941 IP 192.168.0.102.40782 > resolver2.opendns.com.domain: 2918+ PTR? 1.0.168.192.in-addr.arpa. (42) 20:44:27.139105 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 304 20:44:27.139451 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 336 20:44:27.139540 IP 192.168.0.1.26302 > 239.255.255.250.ssdp: UDP, length 318 20:44:27.167001 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 10, ack 7, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:27.476246 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 11, length 69: LCP, Conf-Request (0x01), id 4, length 55 20:44:29.148786 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 8, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:29.169834 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 12, ack 8, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:30.092656 IP 192.168.0.78.58379 > 239.255.255.250.ssdp: UDP, length 122 20:44:31.043724 IP 216.218.159.29.https > 192.168.0.102.60448: Flags [P.], seq 1:40, ack 1, win 64, options [nop,nop,TS val 2170604217 ecr 3108950148 ], length 39 20:44:31.044207 IP 192.168.0.102.60448 > 216.218.159.29.https: Flags [F.], seq 1, ack 40, win 319, options [nop,nop,TS val 3109000211 ecr 2170604217] , length 0 20:44:31.044832 IP 216.218.159.29.https > 192.168.0.102.60448: Flags [F.], seq 40, ack 1, win 64, options [nop,nop,TS val 2170604217 ecr 3108950148], length 0 20:44:31.044848 IP 192.168.0.102.60448 > 216.218.159.29.https: Flags [.], ack 41, win 319, options [nop,nop,TS val 3109000212 ecr 2170604217], length 0 20:44:31.100110 IP 216.218.159.29.https > 192.168.0.102.60448: Flags [.], ack 2, win 64, options [nop,nop,TS val 2170604231 ecr 3109000211], length 0 20:44:31.150954 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 9, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:31.170715 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 13, ack 9, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:31.522943 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 14, length 69: LCP, Conf-Request (0x01), id 5, length 55 20:44:32.112025 IP 192.168.0.78.53166 > 239.255.255.250.ssdp: UDP, length 122 20:44:33.153135 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 10, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:33.173557 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 15, ack 10, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:33.382478 IP 192.168.0.78.53242 > 239.255.255.250.ssdp: UDP, length 125 20:44:34.112045 IP 192.168.0.78.51679 > 239.255.255.250.ssdp: UDP, length 122 20:44:35.155196 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 11, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:35.173307 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 16, ack 11, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:35.539511 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 17, length 69: LCP, Conf-Request (0x01), id 6, length 55 20:44:36.050498 ARP, Request who-has 192.168.0.102 tell 192.168.0.1, length 46 20:44:36.050542 ARP, Reply 192.168.0.102 is-at b8:97:5a:90:4a:0b (oui Unknown), length 28 20:44:37.132053 IP 192.168.0.78.41595 > 239.255.255.250.ssdp: UDP, length 125 20:44:37.156130 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 12, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:37.176114 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 18, ack 12, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:37.215957 IP 192.168.0.102.56426 > 151.101.49.7.https: Flags [.], ack 2546731282, win 336, options [nop,nop,TS val 1778917674 ecr 2453209210], length 0 20:44:37.216283 IP 192.168.0.102.33610 > resolver2.opendns.com.domain: 10345+ PTR? 7.49.101.151.in-addr.arpa. (43) 20:44:37.231196 IP 151.101.49.7.https > 192.168.0.102.56426: Flags [.], ack 1, win 63, options [nop,nop,TS val 2453220474 ecr 1778827071], length 0 20:44:37.231469 IP resolver2.opendns.com.domain > 192.168.0.102.33610: 10345 NXDomain 0/1/0 (103) 20:44:39.158354 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 13, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:39.178010 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 19, ack 13, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:39.571156 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 20, length 69: LCP, Conf-Request (0x01), id 7, length 55 20:44:40.814853 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [S], seq 2863409155, win 29200, options [mss 1460,sackOK,TS val 3109009982 ecr 0 ,nop,wscale 7], length 0 20:44:40.821991 IP 192.168.0.78.51839 > 239.255.255.250.ssdp: UDP, length 125 20:44:40.868875 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [S.], seq 1419408411, ack 2863409156, win 28960, options [mss 1460,sackOK,TS val 2170606674 ecr 3109009982,nop,wscale 9], length 0 20:44:40.868965 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 3109010037 ecr 2170606674], length 0 20:44:40.869348 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 1:518, ack 1, win 229, options [nop,nop,TS val 3109010037 ecr 21706066 74], length 517 20:44:40.930212 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [.], seq 1:1449, ack 518, win 59, options [nop,nop,TS val 2170606689 ecr 3109010 037], length 1448 20:44:40.930264 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [.], ack 1449, win 251, options [nop,nop,TS val 3109010098 ecr 2170606689], leng th 0 20:44:40.930357 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 1449:3105, ack 518, win 59, options [nop,nop,TS val 2170606689 ecr 310 9010037], length 1656 20:44:40.930367 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [.], ack 3105, win 277, options [nop,nop,TS val 3109010098 ecr 2170606689], leng th 0 20:44:40.930788 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 518:582, ack 3105, win 277, options [nop,nop,TS val 3109010098 ecr 217 0606689], length 64 20:44:40.930903 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 582:674, ack 3105, win 277, options [nop,nop,TS val 3109010099 ecr 217 0606689], length 92 20:44:40.931068 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 674:1259, ack 3105, win 277, options [nop,nop,TS val 3109010099 ecr 21 70606689], length 585 20:44:40.931157 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 1259:1493, ack 3105, win 277, options [nop,nop,TS val 3109010099 ecr 2 170606689], length 234 20:44:40.983810 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [.], ack 1259, win 61, options [nop,nop,TS val 2170606702 ecr 3109010098], lengt h 0 20:44:40.984013 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 3105:3184, ack 1493, win 64, options [nop,nop,TS val 2170606703 ecr 31 09010099], length 79 20:44:40.984034 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 3184:3263, ack 1493, win 64, options [nop,nop,TS val 2170606703 ecr 31 09010099], length 79 20:44:40.984127 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 3263:3335, ack 1493, win 64, options [nop,nop,TS val 2170606703 ecr 31 09010099], length 72 20:44:40.984146 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [.], ack 3263, win 277, options [nop,nop,TS val 3109010152 ecr 2170606703], leng th 0 20:44:40.984251 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [P.], seq 1493:1524, ack 3335, win 277, options [nop,nop,TS val 3109010152 ecr 2 170606703], length 31 20:44:40.991897 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 3335:3770, ack 1493, win 64, options [nop,nop,TS val 2170606704 ecr 31 09010099], length 435 20:44:40.991920 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [P.], seq 3770:3828, ack 1493, win 64, options [nop,nop,TS val 2170606704 ecr 31 09010099], length 58 20:44:40.992000 IP 192.168.0.102.60452 > 216.218.159.29.https: Flags [.], ack 3828, win 300, options [nop,nop,TS val 3109010160 ecr 2170606704], leng th 0 20:44:41.087862 IP 216.218.159.29.https > 192.168.0.102.60452: Flags [.], ack 1524, win 64, options [nop,nop,TS val 2170606729 ecr 3109010152], lengt h 0 20:44:41.160528 IP 192.168.0.102 > 204.87.122.177: GREv1, call 23848, seq 14, length 40: LCP, Conf-Request (0x01), id 1, length 26 20:44:41.178770 IP 204.87.122.177 > 192.168.0.102: GREv1, call 0, seq 21, ack 14, length 44: LCP, Conf-Ack (0x02), id 1, length 26 20:44:41.311951 IP 192.168.0.102.40698 > e2.ycpi.vip.daa.yahoo.com.https: Flags [.], ack 447314494, win 2519, options [nop,nop,TS val 3682034731 ecr 575196459], length 0 20:44:41.327945 IP e2.ycpi.vip.daa.yahoo.com.https > 192.168.0.102.40698: Flags [.], ack 1, win 716, options [nop,nop,TS val 575241516 ecr 3681898114 ], length 0 20:44:42.825270 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [P.], seq 325:341, ack 189, win 30016, length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID( 0) 20:44:42.825334 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [F.], seq 341, ack 189, win 30016, length 0 20:44:42.844668 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [.], ack 341, win 32104, length 0 20:44:42.844803 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [.], ack 342, win 32120, length 0 20:44:42.845593 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [P.], seq 189:337, ack 342, win 32120, length 148: pptp CTRL_MSGTYPE=CDN CALL_ID( 0) RESULT_CODE(0) ERR_CODE(0) CAUSE_CODE(0) CALL_STATS() 20:44:42.845620 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [R], seq 2821635576, win 0, length 0 20:44:42.845624 IP 204.87.122.177.pptp > 192.168.0.102.48222: Flags [F.], seq 337, ack 342, win 32120, length 0 20:44:42.845629 IP 192.168.0.102.48222 > 204.87.122.177.pptp: Flags [R], seq 2821635576, win 0, length 0 ^C 141 packets captured 147 packets received by filter 6 packets dropped by kernel |
From: James C. <qu...@la...> - 2018-11-03 00:05:32
|
No plan to do so. Go ahead. -- James Cameron http://quozl.netrek.org/ |
From: Wladimir M. <mw...@mw...> - 2018-11-02 14:55:47
|
Dear everyone, My PPTP server has 2 external interfaces, both with real/routable IP on them These IPs are recorded as A-records for a single DNS name, so a DNS query for A-records of this name returns them both as a list. However, from what I see in get_ip_address function, pptp uses only first of them. Are there any plans or adding support for something like RFC8305 to pptp client ? (like, quickly scan port 1723 on every returned A-record, then connect to the one with the fastest response on SYN). For modern networking software it is a very useful thing to support. Thanks in advance for your responses. |
From: dz <dz...@gm...> - 2018-09-23 11:52:41
|
Hello Christoph, Thanks for your help and detailed reply. I cloned git repository of pptp-linux and messed a bit with various versions. Providing the summary. - the baseline of the 'good behaviour' is still pptp-linux_1.8.0-1_amd64.deb; it throws occasional single 'discarding duplicate packet' messages but keeps the steady connection for days - I was not able to determine corresponding 'good' baseline while compiling packages myself; - 1.8.0 compiles with several warnings in a numer of .c files and the resulting package does not keep the steady connection - compiled 1.9.0 stalls the connection and altogether drops it with no 'discarding duplicate packet' messages in syslog - compiled 1.10.0 keeps the connection for longer (some several hours) but eventually stalls it with the same 'discarding duplicate packet' burst in the log - under the circumstances it would be hard to proceed with 'git bisect' as there is no 'good' baseline among packages compiled from source My suggestions: - compiling at my default Ubuntu 18.04.1 server system seems to provide packages somehow different from *.deb; maybe some compiling options should be changed; - my specific VPN server is an Asus home router based PPTP server; maybe it is not enough performant and hence creates such challenging conditions for the client; '--loglevel 1' shows numerous packet reordering messages; - I still think that stalling the connection under such conditions is related to some bug/memory leak issue in packages after pptp-linux_1.8.0-1_amd64.deb Would play more with my test system. I've not compared the memory usage yet. Regards, Dmitry |
From: Christoph B. <sou...@ma...> - 2018-09-22 17:14:38
|
James Cameron wrote... > 1. upgrade to 1.10.0 which was released in January, although none of > the patches between 1.9.0 and 1.10.0 seem to me to be related to your > problem, Debian maintainer here ... Any change here was fairly surprising since technically 1.9.0+ds-2 is 1.10.0 as it contains all the patches. That's why I haven't done another upload yet although it's on the agenda. > 2. check what the Debian or Ubuntu developers changed in the package, > and remove those changes, or; Checking that requires (slight) knowledge of Debian packaging, so a hint, there was a change in how modifications were organized. Up to and including 1.8.0-1 you'd examine the tree after unpacking (dpkg-source -x *.dsc) but don't be fooled by debian/patches/ in these versions though, it's not used. You'll find several changes, especially all this "missing window" handling already exists before it was added upstream in 1.9.0 >From 1.9.0+ds-1, just look into the files in debian/patches/, they can also be found at https://sources.debian.org/patches/pptp-linux/1.9.0+ds-2/ So, after a first glance I saw no reason why the Debian changes caused this regression. Of the many changes, two stick out a bit, though: For quite a while I have been staring at pqueue.c: @@ -421,8 +426,9 @@ int decaps_gre (int fd, callback_t callback, int cl) seq, seq_recv + 1); stats.rx_underwin++; /* sequence number too high, is it reasonably close? */ - } else if ( (missing_window == -1) || - (seq < seq_recv + missing_window || WRAPPED(seq, seq_recv + missing_window)) ) { + } else if ( (seq < seq_recv + missing_window || + WRAPPED(seq, seq_recv + missing_window)) || + (missing_window == -1) ) { stats.rx_buffered++; if ( log_level >= 1 ) log("%s packet %d (expecting %d, lost or reordered)", ... but doubt it has any effect - with missing_window == -1 the latter (and current) form might result in underruns but this shouldn't do harm, it's just visual. Another change is pqueue.c: @@ -137,6 +149,7 @@ int pqueue_add (u_int32_t seq, unsigned char *packet, int packlen) { if (point->seq == seq) { // queue already contains this packet warn("discarding duplicate packet %d", seq); + pq_freelist_add(point); return -1; } if (point->seq > seq) { This was brought by 503ceb0 ("pqueue: close a memory leak") and never backported in Debian (but probably should by yours truly). The obvious assumption was there is no proper cleanup when re-using a blob but it seems to be done right. 3. Find a third option :) > 4. use git bisect to find which patch introduced the problem between > 1.8.0 and 1.9.0. Dmitry, do you have knowledge in compiling from source and re-building Debian packages? Since your situation is hard to create, we cannot test from outside. Another thing, when using 1.8.0-1 you might see increasing memory usage of the pptp process, can you confirm? Christoph |
From: dz <dz...@gm...> - 2018-09-21 22:21:06
|
Thank you. Last option seems to be most certain to localize the reason. Staying at 1.8.0 until I learn how to use git bisect. Regards, Dmitry ------ Wiadomość oryginalna ------ Od: "James Cameron" <qu...@la...> Do: ppt...@li... Data: 21.09.2018 23:47:32 Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works fine in pptp-linux_1.8.0-1 >You could either; > >1. upgrade to 1.10.0 which was released in January, although none of >the patches between 1.9.0 and 1.10.0 seem to me to be related to your >problem, > >2. check what the Debian or Ubuntu developers changed in the package, >and remove those changes, or; > >4. use git bisect to find which patch introduced the problem between >1.8.0 and 1.9.0. > >On Fri, Sep 21, 2018 at 09:20:47PM +0000, dz wrote: >>Hello, >> >>Adding --missing-window 300 to pptp command does not solve the issue >>in >>v.1.9.0+ds-2. >>Still the connection stalls after a burst of 'discarding duplicate >>packet' >>warnings: >>--- >>Sep 21 22:36:34 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166186 >>Sep 21 22:36:34 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166188 >>Sep 21 22:36:34 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166189 >>... >>Sep 21 22:36:36 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166295 >>Sep 21 22:36:36 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166296 >>Sep 21 22:36:36 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166297 >>Sep 21 22:36:36 dz-test pptp[1620]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 166298 >>--- >>Should I try anything else? >> >>Regards, Dmitry >> >>------ Wiadomość oryginalna ------ >>Od: "James Cameron" <qu...@la...> >>Do: "dz" <dz...@gm...> >>DW: ppt...@li... >>Data: 21.09.2018 02:35:12 >>Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works >>fine >>in pptp-linux_1.8.0-1 >> >> >It's an option for pptp, not an option for pppd. >> > >> >On Thu, Sep 20, 2018 at 10:20:55PM +0000, dz wrote: >> >>Thanks for your prompt reply! >> >>However default Ubuntu 18.04 pptp-linux v.1.9.0+ds-2 does not seem >>to >> >>recognize the option: >> >>--- >> >>pon provider --missing-window 300 >> >>/usr/sbin/pppd: unrecognized option '--missing-window' >> >>pppd version 2.4.7 >> >>Usage: /usr/sbin/pppd [ options ], where options are: >> >> <device> Communicate over the named device >> >> <speed> Set the baud rate to <speed> >> >> <loc>:<rem> Set the local and/or remote interface IP >> >> addresses. Either one may be omitted. >> >> asyncmap <n> Set the desired async map to hex <n> >> >> auth Require authentication from peer >> >> connect <p> Invoke shell command <p> to set up the serial >>line >> >> crtscts Use hardware RTS/CTS flow control >> >> defaultroute Add default route through interface >> >> file <f> Take options from file <f> >> >> modem Use modem control lines >> >> mru <n> Set MRU value to <n> for negotiation >> >>See pppd(8) for more options. >> >>--- >> >>Should a version of the package understanding the option be >>installed >> >>from a >> >>specific location other than default Ubuntu 18.04 repository? >> >> >> >>------ Wiadomość oryginalna ------ >> >>Od: "James Cameron" <qu...@la...> >> >>Do: "dz" <dz...@gm...> >> >>DW: ppt...@li... >> >>Data: 21.09.2018 00:05:36 >> >>Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* >>Works >> >>fine >> >>in pptp-linux_1.8.0-1 >> >> >> >>>Your network environment is probably unusual, with duplicate or >> >>>dropped packets. >> >>> >> >>>Please try adding --missing-window 300 to the pptp command. >> >>> >> >>>That was the default in 1.8.0, and it was disabled in 1.9.0. >> >>> >> >>>On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: >> >>>>Dear developers, >> >>>> >> >>>>After upgrading Ubuntu and hence pptp-linux package to version >> >>>>1.9.0+ds-2 my >> >>>>connection to an Asus home router-based pptp server dies after >>some >> >>>>minutes >> >>>>of active usage throwing in syslog a burst of dozens of messages >> >>>>"pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding >>duplicate >> >>>>packet >> >>>>nnnnn". >> >>>>The connection is still on and ppp0 is shown among interfaces but >>no >> >>>>data >> >>>>goes through. Disconnecting and re-connecting resolves the issue >>just >> >>>>for >> >>>>few minutes of active use. >> >>>>Uninstalling 1.9.0+ds-2 version of pptp-linux and installing >>instead >> >>>>pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single >> >>messages >> >>>>"discarding duplicate packet yyyyy" appear in the log with no >>impact >> >>to >> >>>>the >> >>>>connection. It stays on and works stable for days. >> >>>>The problem is repeatable. I have installed a fresh formatted test >> >>>>system >> >>>>with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 >>and >> >>the >> >>>>problem was there at once. Downgrading to >> >>>>pptp-linux_1.9.0+ds-1_amd64.deb >> >>>>does not solve the issue. Downgrading to v.1.8.0-1 does solve it >>at >> >>>>once. >> >>>>Providing a relevant fragment of syslog for the reference: >> >>>>--- >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58793 >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58797 >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58839 >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58840 >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58841 >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58842 >> >>>>... >> >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58884 >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58885 >> >>>>... >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58906 >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58907 >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58908 >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58909 >> >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon >> >>warn[pqueue_add:pqueue.c:151]: >> >>>>discarding duplicate packet 58910 >> >>>>--- >> >>>>After the last line the connection became unusable. >> >>>>I could provide more information if needed. >> >>>>Please help to investigate the issue and possibly to resolve it in >>the >> >>>>next >> >>>>version of pptp-linux package. >> >>>> >> >>>>With best regards, Dmitry >> >>>> >> >>>> >> >>>> >> >>>>_______________________________________________ >> >>>>pptpclient-devel mailing list >> >>>>ppt...@li... >> >>>>https://lists.sourceforge.net/lists/listinfo/pptpclient-devel >> >>> >> >>>-- >> >>>James Cameron >> >>>http://quozl.netrek.org/ >> >> >> > >> >-- >> >James Cameron >> >http://quozl.netrek.org/ >> > >-- >James Cameron >http://quozl.netrek.org/ > > >_______________________________________________ >pptpclient-devel mailing list >ppt...@li... >https://lists.sourceforge.net/lists/listinfo/pptpclient-devel |
From: James C. <qu...@la...> - 2018-09-21 21:47:48
|
You could either; 1. upgrade to 1.10.0 which was released in January, although none of the patches between 1.9.0 and 1.10.0 seem to me to be related to your problem, 2. check what the Debian or Ubuntu developers changed in the package, and remove those changes, or; 4. use git bisect to find which patch introduced the problem between 1.8.0 and 1.9.0. On Fri, Sep 21, 2018 at 09:20:47PM +0000, dz wrote: > Hello, > > Adding --missing-window 300 to pptp command does not solve the issue in > v.1.9.0+ds-2. > Still the connection stalls after a burst of 'discarding duplicate packet' > warnings: > --- > Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166186 > Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166188 > Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166189 > ... > Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166295 > Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166296 > Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166297 > Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 166298 > --- > Should I try anything else? > > Regards, Dmitry > > ------ Wiadomość oryginalna ------ > Od: "James Cameron" <qu...@la...> > Do: "dz" <dz...@gm...> > DW: ppt...@li... > Data: 21.09.2018 02:35:12 > Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works fine > in pptp-linux_1.8.0-1 > > >It's an option for pptp, not an option for pppd. > > > >On Thu, Sep 20, 2018 at 10:20:55PM +0000, dz wrote: > >>Thanks for your prompt reply! > >>However default Ubuntu 18.04 pptp-linux v.1.9.0+ds-2 does not seem to > >>recognize the option: > >>--- > >>pon provider --missing-window 300 > >>/usr/sbin/pppd: unrecognized option '--missing-window' > >>pppd version 2.4.7 > >>Usage: /usr/sbin/pppd [ options ], where options are: > >> <device> Communicate over the named device > >> <speed> Set the baud rate to <speed> > >> <loc>:<rem> Set the local and/or remote interface IP > >> addresses. Either one may be omitted. > >> asyncmap <n> Set the desired async map to hex <n> > >> auth Require authentication from peer > >> connect <p> Invoke shell command <p> to set up the serial line > >> crtscts Use hardware RTS/CTS flow control > >> defaultroute Add default route through interface > >> file <f> Take options from file <f> > >> modem Use modem control lines > >> mru <n> Set MRU value to <n> for negotiation > >>See pppd(8) for more options. > >>--- > >>Should a version of the package understanding the option be installed > >>from a > >>specific location other than default Ubuntu 18.04 repository? > >> > >>------ Wiadomość oryginalna ------ > >>Od: "James Cameron" <qu...@la...> > >>Do: "dz" <dz...@gm...> > >>DW: ppt...@li... > >>Data: 21.09.2018 00:05:36 > >>Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works > >>fine > >>in pptp-linux_1.8.0-1 > >> > >>>Your network environment is probably unusual, with duplicate or > >>>dropped packets. > >>> > >>>Please try adding --missing-window 300 to the pptp command. > >>> > >>>That was the default in 1.8.0, and it was disabled in 1.9.0. > >>> > >>>On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: > >>>>Dear developers, > >>>> > >>>>After upgrading Ubuntu and hence pptp-linux package to version > >>>>1.9.0+ds-2 my > >>>>connection to an Asus home router-based pptp server dies after some > >>>>minutes > >>>>of active usage throwing in syslog a burst of dozens of messages > >>>>"pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate > >>>>packet > >>>>nnnnn". > >>>>The connection is still on and ppp0 is shown among interfaces but no > >>>>data > >>>>goes through. Disconnecting and re-connecting resolves the issue just > >>>>for > >>>>few minutes of active use. > >>>>Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead > >>>>pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single > >>messages > >>>>"discarding duplicate packet yyyyy" appear in the log with no impact > >>to > >>>>the > >>>>connection. It stays on and works stable for days. > >>>>The problem is repeatable. I have installed a fresh formatted test > >>>>system > >>>>with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and > >>the > >>>>problem was there at once. Downgrading to > >>>>pptp-linux_1.9.0+ds-1_amd64.deb > >>>>does not solve the issue. Downgrading to v.1.8.0-1 does solve it at > >>>>once. > >>>>Providing a relevant fragment of syslog for the reference: > >>>>--- > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58793 > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58797 > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58839 > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58840 > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58841 > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58842 > >>>>... > >>>>Sep 19 23:12:18 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58884 > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58885 > >>>>... > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58906 > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58907 > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58908 > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58909 > >>>>Sep 19 23:12:19 dz-test pptp[1320]: anon > >>warn[pqueue_add:pqueue.c:151]: > >>>>discarding duplicate packet 58910 > >>>>--- > >>>>After the last line the connection became unusable. > >>>>I could provide more information if needed. > >>>>Please help to investigate the issue and possibly to resolve it in the > >>>>next > >>>>version of pptp-linux package. > >>>> > >>>>With best regards, Dmitry > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>pptpclient-devel mailing list > >>>>ppt...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/pptpclient-devel > >>> > >>>-- > >>>James Cameron > >>>http://quozl.netrek.org/ > >> > > > >-- > >James Cameron > >http://quozl.netrek.org/ > -- James Cameron http://quozl.netrek.org/ |
From: dz <dz...@gm...> - 2018-09-21 21:21:01
|
Hello, Adding --missing-window 300 to pptp command does not solve the issue in v.1.9.0+ds-2. Still the connection stalls after a burst of 'discarding duplicate packet' warnings: --- Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166186 Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166188 Sep 21 22:36:34 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166189 ... Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166295 Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166296 Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166297 Sep 21 22:36:36 dz-test pptp[1620]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 166298 --- Should I try anything else? Regards, Dmitry ------ Wiadomość oryginalna ------ Od: "James Cameron" <qu...@la...> Do: "dz" <dz...@gm...> DW: ppt...@li... Data: 21.09.2018 02:35:12 Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works fine in pptp-linux_1.8.0-1 >It's an option for pptp, not an option for pppd. > >On Thu, Sep 20, 2018 at 10:20:55PM +0000, dz wrote: >>Thanks for your prompt reply! >>However default Ubuntu 18.04 pptp-linux v.1.9.0+ds-2 does not seem to >>recognize the option: >>--- >>pon provider --missing-window 300 >>/usr/sbin/pppd: unrecognized option '--missing-window' >>pppd version 2.4.7 >>Usage: /usr/sbin/pppd [ options ], where options are: >> <device> Communicate over the named device >> <speed> Set the baud rate to <speed> >> <loc>:<rem> Set the local and/or remote interface IP >> addresses. Either one may be omitted. >> asyncmap <n> Set the desired async map to hex <n> >> auth Require authentication from peer >> connect <p> Invoke shell command <p> to set up the serial line >> crtscts Use hardware RTS/CTS flow control >> defaultroute Add default route through interface >> file <f> Take options from file <f> >> modem Use modem control lines >> mru <n> Set MRU value to <n> for negotiation >>See pppd(8) for more options. >>--- >>Should a version of the package understanding the option be installed >>from a >>specific location other than default Ubuntu 18.04 repository? >> >>------ Wiadomość oryginalna ------ >>Od: "James Cameron" <qu...@la...> >>Do: "dz" <dz...@gm...> >>DW: ppt...@li... >>Data: 21.09.2018 00:05:36 >>Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works >>fine >>in pptp-linux_1.8.0-1 >> >> >Your network environment is probably unusual, with duplicate or >> >dropped packets. >> > >> >Please try adding --missing-window 300 to the pptp command. >> > >> >That was the default in 1.8.0, and it was disabled in 1.9.0. >> > >> >On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: >> >>Dear developers, >> >> >> >>After upgrading Ubuntu and hence pptp-linux package to version >> >>1.9.0+ds-2 my >> >>connection to an Asus home router-based pptp server dies after some >> >>minutes >> >>of active usage throwing in syslog a burst of dozens of messages >> >>"pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding >>duplicate >> >>packet >> >>nnnnn". >> >>The connection is still on and ppp0 is shown among interfaces but no >> >>data >> >>goes through. Disconnecting and re-connecting resolves the issue >>just >> >>for >> >>few minutes of active use. >> >>Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead >> >>pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single >>messages >> >>"discarding duplicate packet yyyyy" appear in the log with no impact >>to >> >>the >> >>connection. It stays on and works stable for days. >> >>The problem is repeatable. I have installed a fresh formatted test >> >>system >> >>with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and >>the >> >>problem was there at once. Downgrading to >> >>pptp-linux_1.9.0+ds-1_amd64.deb >> >>does not solve the issue. Downgrading to v.1.8.0-1 does solve it at >> >>once. >> >>Providing a relevant fragment of syslog for the reference: >> >>--- >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58793 >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58797 >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58839 >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58840 >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58841 >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58842 >> >>... >> >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58884 >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58885 >> >>... >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58906 >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58907 >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58908 >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58909 >> >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >> >>discarding duplicate packet 58910 >> >>--- >> >>After the last line the connection became unusable. >> >>I could provide more information if needed. >> >>Please help to investigate the issue and possibly to resolve it in >>the >> >>next >> >>version of pptp-linux package. >> >> >> >>With best regards, Dmitry >> >> >> >> >> >> >> >>_______________________________________________ >> >>pptpclient-devel mailing list >> >>ppt...@li... >> >>https://lists.sourceforge.net/lists/listinfo/pptpclient-devel >> > >> >-- >> >James Cameron >> >http://quozl.netrek.org/ >> > >-- >James Cameron >http://quozl.netrek.org/ |
From: James C. <qu...@la...> - 2018-09-21 00:35:28
|
It's an option for pptp, not an option for pppd. On Thu, Sep 20, 2018 at 10:20:55PM +0000, dz wrote: > Thanks for your prompt reply! > However default Ubuntu 18.04 pptp-linux v.1.9.0+ds-2 does not seem to > recognize the option: > --- > pon provider --missing-window 300 > /usr/sbin/pppd: unrecognized option '--missing-window' > pppd version 2.4.7 > Usage: /usr/sbin/pppd [ options ], where options are: > <device> Communicate over the named device > <speed> Set the baud rate to <speed> > <loc>:<rem> Set the local and/or remote interface IP > addresses. Either one may be omitted. > asyncmap <n> Set the desired async map to hex <n> > auth Require authentication from peer > connect <p> Invoke shell command <p> to set up the serial line > crtscts Use hardware RTS/CTS flow control > defaultroute Add default route through interface > file <f> Take options from file <f> > modem Use modem control lines > mru <n> Set MRU value to <n> for negotiation > See pppd(8) for more options. > --- > Should a version of the package understanding the option be installed from a > specific location other than default Ubuntu 18.04 repository? > > ------ Wiadomość oryginalna ------ > Od: "James Cameron" <qu...@la...> > Do: "dz" <dz...@gm...> > DW: ppt...@li... > Data: 21.09.2018 00:05:36 > Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works fine > in pptp-linux_1.8.0-1 > > >Your network environment is probably unusual, with duplicate or > >dropped packets. > > > >Please try adding --missing-window 300 to the pptp command. > > > >That was the default in 1.8.0, and it was disabled in 1.9.0. > > > >On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: > >>Dear developers, > >> > >>After upgrading Ubuntu and hence pptp-linux package to version > >>1.9.0+ds-2 my > >>connection to an Asus home router-based pptp server dies after some > >>minutes > >>of active usage throwing in syslog a burst of dozens of messages > >>"pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate > >>packet > >>nnnnn". > >>The connection is still on and ppp0 is shown among interfaces but no > >>data > >>goes through. Disconnecting and re-connecting resolves the issue just > >>for > >>few minutes of active use. > >>Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead > >>pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single messages > >>"discarding duplicate packet yyyyy" appear in the log with no impact to > >>the > >>connection. It stays on and works stable for days. > >>The problem is repeatable. I have installed a fresh formatted test > >>system > >>with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and the > >>problem was there at once. Downgrading to > >>pptp-linux_1.9.0+ds-1_amd64.deb > >>does not solve the issue. Downgrading to v.1.8.0-1 does solve it at > >>once. > >>Providing a relevant fragment of syslog for the reference: > >>--- > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58793 > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58797 > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58839 > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58840 > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58841 > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58842 > >>... > >>Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58884 > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58885 > >>... > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58906 > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58907 > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58908 > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58909 > >>Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > >>discarding duplicate packet 58910 > >>--- > >>After the last line the connection became unusable. > >>I could provide more information if needed. > >>Please help to investigate the issue and possibly to resolve it in the > >>next > >>version of pptp-linux package. > >> > >>With best regards, Dmitry > >> > >> > >> > >>_______________________________________________ > >>pptpclient-devel mailing list > >>ppt...@li... > >>https://lists.sourceforge.net/lists/listinfo/pptpclient-devel > > > >-- > >James Cameron > >http://quozl.netrek.org/ > -- James Cameron http://quozl.netrek.org/ |
From: dz <dz...@gm...> - 2018-09-20 22:21:07
|
Thanks for your prompt reply! However default Ubuntu 18.04 pptp-linux v.1.9.0+ds-2 does not seem to recognize the option: --- pon provider --missing-window 300 /usr/sbin/pppd: unrecognized option '--missing-window' pppd version 2.4.7 Usage: /usr/sbin/pppd [ options ], where options are: <device> Communicate over the named device <speed> Set the baud rate to <speed> <loc>:<rem> Set the local and/or remote interface IP addresses. Either one may be omitted. asyncmap <n> Set the desired async map to hex <n> auth Require authentication from peer connect <p> Invoke shell command <p> to set up the serial line crtscts Use hardware RTS/CTS flow control defaultroute Add default route through interface file <f> Take options from file <f> modem Use modem control lines mru <n> Set MRU value to <n> for negotiation See pppd(8) for more options. --- Should a version of the package understanding the option be installed from a specific location other than default Ubuntu 18.04 repository? ------ Wiadomość oryginalna ------ Od: "James Cameron" <qu...@la...> Do: "dz" <dz...@gm...> DW: ppt...@li... Data: 21.09.2018 00:05:36 Temat: Re: [pptp-devel] pptp connection dies in pptp-linux_1.9.* Works fine in pptp-linux_1.8.0-1 >Your network environment is probably unusual, with duplicate or >dropped packets. > >Please try adding --missing-window 300 to the pptp command. > >That was the default in 1.8.0, and it was disabled in 1.9.0. > >On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: >>Dear developers, >> >>After upgrading Ubuntu and hence pptp-linux package to version >>1.9.0+ds-2 my >>connection to an Asus home router-based pptp server dies after some >>minutes >>of active usage throwing in syslog a burst of dozens of messages >>"pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate >>packet >>nnnnn". >>The connection is still on and ppp0 is shown among interfaces but no >>data >>goes through. Disconnecting and re-connecting resolves the issue just >>for >>few minutes of active use. >>Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead >>pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single >>messages >>"discarding duplicate packet yyyyy" appear in the log with no impact >>to the >>connection. It stays on and works stable for days. >>The problem is repeatable. I have installed a fresh formatted test >>system >>with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and >>the >>problem was there at once. Downgrading to >>pptp-linux_1.9.0+ds-1_amd64.deb >>does not solve the issue. Downgrading to v.1.8.0-1 does solve it at >>once. >>Providing a relevant fragment of syslog for the reference: >>--- >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58793 >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58797 >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58839 >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58840 >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58841 >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58842 >>... >>Sep 19 23:12:18 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58884 >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58885 >>... >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58906 >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58907 >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58908 >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58909 >>Sep 19 23:12:19 dz-test pptp[1320]: anon >>warn[pqueue_add:pqueue.c:151]: >>discarding duplicate packet 58910 >>--- >>After the last line the connection became unusable. >>I could provide more information if needed. >>Please help to investigate the issue and possibly to resolve it in the >>next >>version of pptp-linux package. >> >>With best regards, Dmitry >> >> >> >>_______________________________________________ >>pptpclient-devel mailing list >>ppt...@li... >>https://lists.sourceforge.net/lists/listinfo/pptpclient-devel > >-- >James Cameron >http://quozl.netrek.org/ |
From: James C. <qu...@la...> - 2018-09-20 22:05:53
|
Your network environment is probably unusual, with duplicate or dropped packets. Please try adding --missing-window 300 to the pptp command. That was the default in 1.8.0, and it was disabled in 1.9.0. On Thu, Sep 20, 2018 at 07:10:50PM +0000, dz wrote: > Dear developers, > > After upgrading Ubuntu and hence pptp-linux package to version 1.9.0+ds-2 my > connection to an Asus home router-based pptp server dies after some minutes > of active usage throwing in syslog a burst of dozens of messages > "pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet > nnnnn". > The connection is still on and ppp0 is shown among interfaces but no data > goes through. Disconnecting and re-connecting resolves the issue just for > few minutes of active use. > Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead > pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single messages > "discarding duplicate packet yyyyy" appear in the log with no impact to the > connection. It stays on and works stable for days. > The problem is repeatable. I have installed a fresh formatted test system > with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and the > problem was there at once. Downgrading to pptp-linux_1.9.0+ds-1_amd64.deb > does not solve the issue. Downgrading to v.1.8.0-1 does solve it at once. > Providing a relevant fragment of syslog for the reference: > --- > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58793 > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58797 > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58839 > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58840 > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58841 > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58842 > ... > Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58884 > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58885 > ... > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58906 > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58907 > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58908 > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58909 > Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: > discarding duplicate packet 58910 > --- > After the last line the connection became unusable. > I could provide more information if needed. > Please help to investigate the issue and possibly to resolve it in the next > version of pptp-linux package. > > With best regards, Dmitry > > > > _______________________________________________ > pptpclient-devel mailing list > ppt...@li... > https://lists.sourceforge.net/lists/listinfo/pptpclient-devel -- James Cameron http://quozl.netrek.org/ |
From: dz <dz...@gm...> - 2018-09-20 19:11:01
|
Dear developers, After upgrading Ubuntu and hence pptp-linux package to version 1.9.0+ds-2 my connection to an Asus home router-based pptp server dies after some minutes of active usage throwing in syslog a burst of dozens of messages "pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet nnnnn". The connection is still on and ppp0 is shown among interfaces but no data goes through. Disconnecting and re-connecting resolves the issue just for few minutes of active use. Uninstalling 1.9.0+ds-2 version of pptp-linux and installing instead pptp-linux_1.8.0-1_amd64.deb fixes the issue. Occasional single messages "discarding duplicate packet yyyyy" appear in the log with no impact to the connection. It stays on and works stable for days. The problem is repeatable. I have installed a fresh formatted test system with ubuntu-18.04.1-server-amd64 OS and pptp-linux v.1.9.0+ds-2 and the problem was there at once. Downgrading to pptp-linux_1.9.0+ds-1_amd64.deb does not solve the issue. Downgrading to v.1.8.0-1 does solve it at once. Providing a relevant fragment of syslog for the reference: --- Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58793 Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58797 Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58839 Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58840 Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58841 Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58842 ... Sep 19 23:12:18 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58884 Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58885 ... Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58906 Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58907 Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58908 Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58909 Sep 19 23:12:19 dz-test pptp[1320]: anon warn[pqueue_add:pqueue.c:151]: discarding duplicate packet 58910 --- After the last line the connection became unusable. I could provide more information if needed. Please help to investigate the issue and possibly to resolve it in the next version of pptp-linux package. With best regards, Dmitry |
From: James C. <qu...@la...> - 2018-04-20 06:03:55
|
As PureVPN gave you those instructions, you should talk to them about it. On the face of it, they look correct, though out of date and overblown. They failed to explain quoting and substituting values while editing the file. The error you got looks like the file is incomplete or has a gap. For security reasons, don't share the file without removing your username and password. My instructions for doing the same thing are here; http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand I've checked, and these instructions are still correct; I was able to configure a tunnel with these words in the file; pty "pptp $SERVER --nolaunchpppd" name $USER remotename PPTP require-mppe-128 file /etc/ppp/options.pptp With my password in chap-secrets. On Mon, Apr 16, 2018 at 03:26:23PM +0000, Darren Browne via pptpclient-devel wrote: > I'm having a problem setting up PureVPN on a Raspberry Pi. I followed the PPTP > instructions at the link [1]https://support.purevpn.com/ > how-to-setup-purevpn-on-raspberry-pi. I created a file in /etc/ppp/peers named > server.config and entered the recommended settings. For $VPNHOSTNAME, PureVPN > doesn't provide IP addresses, so I used one of their DNS server addresses; > vlus-af1.pointtoserver.com. > > When I enter pon server.config, I get the following error: > /usr/sbin/ppdp: in file /etc/ppp/peers/server.config: ' > vlus-af1.pointtoserver.com' > > I've tried replacing the VPNHOSTNAME with other servers without any success. I > am a complete Linux NOOB, so there isn't much that I know how to do, and I > haven't seen this exact error in google searches. Others seem to have > difficulty with other options in their file (for other services, not PureVPN). > > I've checked in with PureVPN help. They gave me a few other servers to try then > suggested that I try openvpn, but I have tried openvpn before without success. > So, before I switch, I'd like to see if there is an easy fix for this error. > Would this error be because pptp tried to connect to the server and failed, is > the server name format wrong, should I be editing another file, or is this a > problem with iptables that I can somehow fix? > > References: > > [1] https://support.purevpn.com/how-to-setup-purevpn-on-raspberry-pi > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > pptpclient-devel mailing list > ppt...@li... > https://lists.sourceforge.net/lists/listinfo/pptpclient-devel -- James Cameron http://quozl.netrek.org/ |
From: Darren B. <da...@ya...> - 2018-04-16 15:30:46
|
I'm having a problem setting up PureVPN on a Raspberry Pi. I followed the PPTP instructions at the link https://support.purevpn.com/how-to-setup-purevpn-on-raspberry-pi. I created a file in /etc/ppp/peers named server.config and entered the recommended settings. For $VPNHOSTNAME, PureVPN doesn't provide IP addresses, so I used one of their DNS server addresses; vlus-af1.pointtoserver.com. When I enter pon server.config, I get the following error:/usr/sbin/ppdp: in file /etc/ppp/peers/server.config: 'vlus-af1.pointtoserver.com' I've tried replacing the VPNHOSTNAME with other servers without any success. I am a complete Linux NOOB, so there isn't much that I know how to do, and I haven't seen this exact error in google searches. Others seem to have difficulty with other options in their file (for other services, not PureVPN). I've checked in with PureVPN help. They gave me a few other servers to try then suggested that I try openvpn, but I have tried openvpn before without success. So, before I switch, I'd like to see if there is an easy fix for this error. Would this error be because pptp tried to connect to the server and failed, is the server name format wrong, should I be editing another file, or is this a problem with iptables that I can somehow fix? |
From: James C. <qu...@la...> - 2018-01-18 09:22:07
|
On Thu, Jan 18, 2018 at 09:00:03AM +0100, Christoph Biedl wrote: > James Cameron wrote... > > > PPTP Client 1.10.0 is released. > > Great to see. > > > https://sourceforge.net/projects/pptpclient/files/pptp/pptp-1.10.0/ > > https://quozl.linux.org.au/pptp/ > > > > 8d25341352fdae5ad5b36b9f18254908 pptp-1.10.0.tar.gz > > The .signature file is present on https://quozl.linux.org.au/pptp/ only, > not on sf. Is this just a mishap? Wasn't in my release process. Download statistics for the .signature file seem to suggest it isn't needed. Fixed, though. > (Debian's upgrade check is told to look for the signature file as well, > and failed. Hence the question.) Thanks. -- James Cameron http://quozl.netrek.org/ |