Menu
▾
▴
pptpclient-devel — PPTP Client Development and Support
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: <tom...@rc...> - 2015-10-30 06:30:26
|
Hey! New message, please read <http://lapeste.org/early.php?8tn> tom...@rc... |
|
From: Margie C. <43...@ce...> - 2015-10-21 17:50:33
|
Hello! New message, please read <http://thecontentsplash.com/noble.php?yd56> Margie Connors |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:48:37
|
Hello! New message, please read <http://xn--vckzb1a5fx51t.com/saw.php?ur> Ada Riggs |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:48:34
|
Hello! New message, please read <http://tungtk.com/quarter.php?k9qru> Ada Riggs |
|
From: Christopher J. W. <43...@ce...> - 2015-10-21 17:45:25
|
Hello! New message, please read <http://sibzem.ru/woman.php?oayu6> Christopher J. Werner |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:35:54
|
Hello! New message, please read <http://campingmeetingpoint.com/especially.php?csq> Ada Riggs This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:35:48
|
Hello! New message, please read <http://yorbaridge.com/near.php?r3> Ada Riggs This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:35:48
|
Hello! New message, please read <http://puretistl.com/together.php?8x> Ada Riggs This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx |
|
From: Ada R. <43...@ce...> - 2015-10-21 17:35:43
|
Hello! New message, please read <http://travelsnips.co.uk/fresh.php?wla> Ada Riggs This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx |
|
From: Lillian N. T. A. F. L. <43...@ce...> - 2015-10-21 17:31:36
|
Hello! New message, please read <http://nicnelsonbooks.com/fact.php?o1z> Lillian N. Temme Andres F. Lipscomb |
|
From: Lillian N. T. A. F. L. <43...@ce...> - 2015-10-21 17:31:30
|
Hello! New message, please read <http://bestcoffeemachinesguide.com/become.php?0a> Lillian N. Temme Andres F. Lipscomb |
|
From: Lillian N. T. A. F. L. <43...@ce...> - 2015-10-21 17:31:22
|
Hello! New message, please read <http://fractalpros.com/thus.php?wj10r> Lillian N. Temme Andres F. Lipscomb |
|
From: Lillian N. T. A. F. L. <43...@ce...> - 2015-10-21 17:31:22
|
Hello! New message, please read <http://europemoteurs.com/the.php?10> Lillian N. Temme Andres F. Lipscomb |
|
From: Lillian N. T. A. F. L. <43...@ce...> - 2015-10-21 17:31:20
|
Hello! New message, please read <http://credencecare.com/what.php?l0> Lillian N. Temme Andres F. Lipscomb |
|
From: David N. <pp...@da...> - 2015-09-25 14:40:55
|
On 25/09/15 17:28, James Cameron wrote: > Have you thought of doing this in Network Manager? Then I guess it > could be available to other tunnel protocols. Is there a reason why > it has to be done in pptp? I didn't think of that. PPTP would still need to be modified because it installs a single route to the remote server replacing any existing route. That code could be removed and performed by the invoking process, which might be Network Manager, or could be a simple wrapper. I don't want to propose removing existing PPTP function (updates to routing table), merely an incremental change. I agree that other protocols could benefit from this, but Network Manager looks rather harder to change, particularly as I'd also have to change those other protocols (e.g. changes required to pptp.) It seems productive to demonstrate utility by changing PPTP, and leaving a generalised solution until we have actual (rather than theoretical) need. |
|
From: James C. <qu...@la...> - 2015-09-25 07:59:02
|
I've looked at your patch. Have you thought of doing this in Network Manager? Then I guess it could be available to other tunnel protocols. Is there a reason why it has to be done in pptp? -- James Cameron http://quozl.linux.org.au/ |
|
From: David N. <pp...@da...> - 2015-09-24 06:36:10
|
Two weeks and no comment: is it so good or is it so bad?
-------- Forwarded Message --------
Subject: Add and remove policy routes
Date: Fri, 11 Sep 2015 01:29:26 +0930
From: David Newall <pp...@da...>
To: ppt...@li...
Hi all,
I've got a patch which I hope might be useful. It isn't perfect but
it's good enough to discuss.
It installs and removes policy routing rules to route to the end-point
so that the PPtP packets will still be delivered if the default route is
changed. I've found it useful when installing multiple tunnels between
the same two end-points, but via redundant paths, and setting my default
route for the local endpoint to the remote. (It's kind of cool setting
up a three-way tunnel and then removing the cable for one of the paths;
and seeing packets still flow.)
I overload the --localbind option, allowing an interface name to be
specified. When this is done, I find an unused policy routing table and
install a route and rule matching packets between that interfaces
address and the remote pptp server. I use it like this:
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if0 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if1 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if2 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
I use the ip(8) command, which was already used, so, although that seems
like it might only be useful on Linux platforms, I guess I haven't
introduced any new prerequisite.
The patch is an attachment (q.v. MIME) so that TABS don't get mangled by
the otherwise obedient MUA. If it gets stripped off, you can pick it up
at http://davidnewall.com/pptp-localbind-policy-routing.diff
Regards,
David
|
|
From: James C. <qu...@la...> - 2015-09-24 00:52:40
|
G'day James, I don't know of a way to set routes on a per process or program basis apart from isolating that program into a virtual host or container. You'd face the same issue with any tunnel method, like OpenVPN, so don't restrict your research to PPTP. Yes, you can add static routes to specific hosts by IP address, but for major services there may be too many IP addresses to make it practical. (When any of them change, the problem would return.) You use the "ip route" command to do this, after using the "host" command to figure out what IP addresses or ranges to cover. Also, it is not practical for major services to identify a connection as coming from a VPN unless they are tracking major VPN service providers, so if you use a provider that isn't tracked, or your own remote virtual host, they won't be able to tell. -- James Cameron http://quozl.linux.org.au/ |
|
From: Wei S. <wsh...@ou...> - 2015-09-24 00:40:48
|
That sounds like a route problem. You can specify which route to use for a particular destination. For example, in Linux, if you only want traffic to 6.6.6.0/24 to go via VPN, then all you need to do is route add -net 6.6.6.0/24 ppp0 Or if you have your default gateway pointed to VPN (check with route output), you need to change that first (may be to your home router by default). Then add route to traffic you want to go through VPN. Hope that would help you. Best.Wei Shen.From: jam...@gm... Date: Wed, 23 Sep 2015 17:07:05 -0700 To: ppt...@li... Subject: [pptp-devel] PPTP Client for only one program Raspberry pi B+, raspbian jessie I want to add transmission onto my raspberry pi and installed PPTP Client on it to run that traffic through VPN. This makes it so mopidy can't connect to spotify, because spotify does not allow users to communicate through a VPN. Is there a way to configure things so either only traffic from transmission runs through PPTP Client or that traffic from mopidy does not run through it? Either way would solve my issue. ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ pptpclient-devel mailing list ppt...@li... https://lists.sourceforge.net/lists/listinfo/pptpclient-devel |
|
From: James S. <jam...@gm...> - 2015-09-24 00:07:13
|
Raspberry pi B+, raspbian jessie I want to add transmission onto my raspberry pi and installed PPTP Client on it to run that traffic through VPN. This makes it so mopidy can't connect to spotify, because spotify does not allow users to communicate through a VPN. Is there a way to configure things so either only traffic from transmission runs through PPTP Client or that traffic from mopidy does not run through it? Either way would solve my issue. |
|
From: David N. <pp...@da...> - 2015-09-10 16:40:05
|
Hi all,
I've got a patch which I hope might be useful. It isn't perfect but
it's good enough to discuss.
It installs and removes policy routing rules to route to the end-point
so that the PPtP packets will still be delivered if the default route is
changed. I've found it useful when installing multiple tunnels between
the same two end-points, but via redundant paths, and setting my default
route for the local endpoint to the remote. (It's kind of cool setting
up a three-way tunnel and then removing the cable for one of the paths;
and seeing packets still flow.)
I overload the --localbind option, allowing an interface name to be
specified. When this is done, I find an unused policy routing table and
install a route and rule matching packets between that interfaces
address and the remote pptp server. I use it like this:
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if0 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if1 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
# /usr/sbin/pppd pty "pptp pptp.example.com --localbind if2 --nolaunchpppd" \
name myhost remotename PPTP defaultroute replacedefaultroute \
nodetach file /etc/ppp/options.pptp &
I use the ip(8) command, which was already used, so, although that seems
like it might only be useful on Linux platforms, I guess I haven't
introduced any new prerequisite.
The patch is an attachment (q.v. MIME) so that TABS don't get mangled by
the otherwise obedient MUA. If it gets stripped off, you can pick it up
at http://davidnewall.com/pptp-localbind-policy-routing.diff
Regards,
David
|
|
From: James C. <qu...@la...> - 2015-04-30 03:53:27
|
On Thu, Apr 30, 2015 at 02:09:05AM +0000, Tobias wrote: > If a invalid server is provided, PPTP client complain? Yes, it uses syslog, but not terminal. This is because pptp is meant to be run from pppd as a plugin. If it wrote output to terminal, then pppd may misdirect it. > I am specifing some invalid server and it just don't do nothing. Not true, and you can prove this with strace. > root@DD-WRT:~# pptp invalid.com file /tmp/pptpd_client/options.vpn > This is a DD-WRT error or PPTP Client? Your error. Look at syslog. Or use pppd instead of pptp. -- James Cameron http://quozl.linux.org.au/ |
|
From: Tobias <tob...@ms...> - 2015-04-30 02:21:39
|
Hi, just to confirm. If a invalid server is provided, PPTP client complain? I am specifing some invalid server and it just don't do nothing. root@DD-WRT:~# pptp invalid.com file /tmp/pptpd_client/options.vpn This is a DD-WRT error or PPTP Client? Thanks. |
|
From: James C. <qu...@la...> - 2015-04-16 10:08:28
|
On Thu, Apr 16, 2015 at 11:06:06AM +0200, Lorenzo Maurizi - C.S.I.A. UniMC wrote: > > > > > > At the moment neither the client machine nor the receiving windows > > > machine have a firewall enabled. > > > > So iptables-save (if present) yields nothing. > Exactly Thanks. > > > > > > Just to confirm though; in your packet capture on the server, after IPCP > > ConfAck you see GRE packets from the server to the client, but they are > not > > in the packet capture on the client. > > > Let me paste here the 60 summary lines of packets captured by > wireshark: Is this capture server or client side? I guess server, since you are talking about Wireshark. > PPP IPCP 58 Configuration Request > 42 2015-04-16 09:15:37.137462000 192.168.0.112 172.16.0.46 > PPP IPCP 62 Configuration Ack > 43 2015-04-16 09:15:37.140776000 172.16.0.46 192.168.0.112 > PPP Comp 133 Compressed data > 44 2015-04-16 09:15:45.034637000 192.168.0.112 172.16.0.46 > PPP Comp 135 Compressed data > > Packet 42 is the PPTP confack? Yes, it is a PPP ConfAck at the IPCP protocol level. At this point the interface can be considered active. > As you can see there are no GRE packets after that, only one ppp > compressed packet (number 43) from server to client and then nothing > else. Does this packet 43 appear in the client trace? I thought not. > The other packets from 44 to 53 should be the pings and the telnet. > > Did you say in a previous message that the server is unable to > understand what is in the compressed packets? No, I was suggesting possibility since disproven; that the client was unable to understand what the server said. But since then the packet trace has shown a blockage of some sort. I'm still thinking the blockage is outside both systems. On the other hand, if that is the server packet trace above, it is puzzling that the server is not responding to the GRE packets received. > Thanks a lot, and I owe you a beer and a pizza! Heh. -- James Cameron http://quozl.linux.org.au/ |
|
From: Lorenzo M. - C.S.I.A. U. <lor...@un...> - 2015-04-16 09:06:21
|
> >
> > At the moment neither the client machine nor the receiving windows
> > machine have a firewall enabled.
>
> So iptables-save (if present) yields nothing.
Exactly
>
>
> Just to confirm though; in your packet capture on the server, after IPCP
> ConfAck you see GRE packets from the server to the client, but they are
not
> in the packet capture on the client.
Let me paste here the 60 summary lines of packets captured by wireshark:
8<-------------------------------------
No. Time Source Destination
Protocol Length Info
1 2015-04-16 09:15:30.169620000 192.168.0.112 172.16.0.46
TCP 74 54320→1723 [SYN] Seq=0 Win=14600 Len=0 MSS=1380
TSval=143125160 TSecr=0 WS=128
2 2015-04-16 09:15:30.169759000 172.16.0.46 192.168.0.112
TCP 74 1723→54320 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460
WS=256 TSval=2033944 TSecr=143125160
3 2015-04-16 09:15:30.473334000 192.168.0.112 172.16.0.46
TCP 66 54320→1723 [ACK] Seq=1 Ack=1 Win=14720 Len=0
TSval=143125236 TSecr=2033944
4 2015-04-16 09:15:30.473741000 192.168.0.112 172.16.0.46
PPTP 222 Start-Control-Connection-Request
5 2015-04-16 09:15:30.473996000 172.16.0.46 192.168.0.112
PPTP 222 Start-Control-Connection-Reply
6 2015-04-16 09:15:30.745045000 192.168.0.112 172.16.0.46
TCP 66 54320→1723 [ACK] Seq=157 Ack=157 Win=15744 Len=0
TSval=143125304 TSecr=2033975
7 2015-04-16 09:15:31.474462000 192.168.0.112 172.16.0.46
PPTP 234 Outgoing-Call-Request
8 2015-04-16 09:15:31.475317000 172.16.0.46 192.168.0.112
PPTP 98 Outgoing-Call-Reply
9 2015-04-16 09:15:31.802745000 192.168.0.112 172.16.0.46
TCP 66 54320→1723 [ACK] Seq=325 Ack=189 Win=15744 Len=0
TSval=143125568 TSecr=2034075
10 2015-04-16 09:15:31.803035000 192.168.0.112 172.16.0.46
PPP LCP 70 Configuration Request
11 2015-04-16 09:15:31.803985000 172.16.0.46 192.168.0.112
PPP LCP 107 Configuration Request
12 2015-04-16 09:15:31.804089000 172.16.0.46 192.168.0.112
PPP LCP 70 Configuration Ack
13 2015-04-16 09:15:33.803613000 172.16.0.46 192.168.0.112
PPP LCP 103 Configuration Request
14 2015-04-16 09:15:34.128430000 192.168.0.112 172.16.0.46
PPP LCP 65 Configuration Reject
15 2015-04-16 09:15:34.128822000 172.16.0.46 192.168.0.112
PPP LCP 100 Configuration Request
16 2015-04-16 09:15:34.165745000 192.168.0.112 172.16.0.46
PPP LCP 70 Configuration Request
17 2015-04-16 09:15:34.166158000 172.16.0.46 192.168.0.112
PPP LCP 74 Configuration Ack
18 2015-04-16 09:15:34.454705000 192.168.0.112 172.16.0.46
PPP LCP 100 Configuration Ack
19 2015-04-16 09:15:34.455016000 172.16.0.46 192.168.0.112
PPTP 90 Set-Link-Info
20 2015-04-16 09:15:34.455597000 172.16.0.46 192.168.0.112
PPP CHAP 80 Challenge (NAME='MEETING',
VALUE=0xb8832dc1993278dcded156d33dbfec5c)
21 2015-04-16 09:15:34.491590000 192.168.0.112 172.16.0.46
PPP LCP 60 Echo Request
22 2015-04-16 09:15:34.491931000 172.16.0.46 192.168.0.112
PPP LCP 60 Echo Reply
23 2015-04-16 09:15:34.775821000 192.168.0.112 172.16.0.46
TCP 66 54320→1723 [ACK] Seq=325 Ack=213 Win=15744 Len=0
TSval=143126312 TSecr=2034373
24 2015-04-16 09:15:34.777174000 192.168.0.112 172.16.0.46
PPP CHAP 114 Response (NAME='VPN_User',
VALUE=0xdf57269a4805ddd929a953deb4364a130000000000000000...)
25 2015-04-16 09:15:34.779836000 172.16.0.46 192.168.0.112
PPP CHAP 98 Success
(MESSAGE='S=C86575BD50EFDE46FDF7AC201DE9434039C95583')
26 2015-04-16 09:15:34.784006000 172.16.0.46 192.168.0.112
PPP CCP 58 Configuration Request
27 2015-04-16 09:15:34.784049000 172.16.0.46 192.168.0.112
PPP IPCP 58 Configuration Request
28 2015-04-16 09:15:35.153902000 192.168.0.112 172.16.0.46
PPP CCP 62 Configuration Request
29 2015-04-16 09:15:35.154582000 172.16.0.46 192.168.0.112
PPP CCP 62 Configuration Nak
30 2015-04-16 09:15:35.159294000 192.168.0.112 172.16.0.46
PPP CCP 62 Configuration Nak
31 2015-04-16 09:15:35.159297000 192.168.0.112 172.16.0.46
PPP IPCP 60 Termination Ack
32 2015-04-16 09:15:35.159705000 172.16.0.46 192.168.0.112
PPP CCP 62 Configuration Request
33 2015-04-16 09:15:35.502553000 192.168.0.112 172.16.0.46
PPP CCP 62 Configuration Request
34 2015-04-16 09:15:35.503203000 172.16.0.46 192.168.0.112
PPP CCP 62 Configuration Ack
35 2015-04-16 09:15:35.505576000 192.168.0.112 172.16.0.46
PPP CCP 62 Configuration Ack
36 2015-04-16 09:15:35.603524000 172.16.0.46 192.168.0.112
GRE 46 Encapsulated PPP
37 2015-04-16 09:15:35.825474000 192.168.0.112 172.16.0.46
PPP IPCP 68 Configuration Request
38 2015-04-16 09:15:35.825864000 172.16.0.46 192.168.0.112
PPP IPCP 62 Configuration Reject
39 2015-04-16 09:15:36.128897000 192.168.0.112 172.16.0.46
PPP IPCP 62 Configuration Request
40 2015-04-16 09:15:36.129447000 172.16.0.46 192.168.0.112
PPP IPCP 62 Configuration Ack
41 2015-04-16 09:15:36.799812000 172.16.0.46 192.168.0.112
PPP IPCP 58 Configuration Request
42 2015-04-16 09:15:37.137462000 192.168.0.112 172.16.0.46
PPP IPCP 62 Configuration Ack
43 2015-04-16 09:15:37.140776000 172.16.0.46 192.168.0.112
PPP Comp 133 Compressed data
44 2015-04-16 09:15:45.034637000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
45 2015-04-16 09:15:46.049241000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
46 2015-04-16 09:15:47.048778000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
47 2015-04-16 09:15:48.048569000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
48 2015-04-16 09:15:49.048019000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
49 2015-04-16 09:15:50.047515000 192.168.0.112 172.16.0.46
PPP Comp 135 Compressed data
50 2015-04-16 09:15:57.124190000 192.168.0.112 172.16.0.46
PPP Comp 111 Compressed data
51 2015-04-16 09:15:58.120571000 192.168.0.112 172.16.0.46
PPP Comp 111 Compressed data
52 2015-04-16 09:16:00.123756000 192.168.0.112 172.16.0.46
PPP Comp 111 Compressed data
53 2015-04-16 09:16:04.130220000 192.168.0.112 172.16.0.46
PPP Comp 111 Compressed data
54 2015-04-16 09:16:04.513867000 192.168.0.112 172.16.0.46
PPP LCP 60 Echo Request
55 2015-04-16 09:16:10.048285000 192.168.0.112 172.16.0.46
PPTP 82 Call-Clear-Request
56 2015-04-16 09:16:10.048291000 192.168.0.112 172.16.0.46
TCP 66 54320→1723 [FIN, ACK] Seq=341 Ack=213 Win=15744 Len=0
TSval=143135134 TSecr=2034373
57 2015-04-16 09:16:10.729637000 172.16.0.46 192.168.0.112
PPTP 214 Call-Disconnect-Notify
58 2015-04-16 09:16:10.903264000 192.168.0.112 172.16.0.46
PPTP 82 [TCP Spurious Retransmission] Call-Clear-Request
59 2015-04-16 09:16:10.903373000 172.16.0.46 192.168.0.112
TCP 66 [TCP Dup ACK 57#1] 1723→54320 [ACK] Seq=361 Ack=342
Win=131072 Len=0 TSval=2038018 TSecr=143135134
60 2015-04-16 09:16:11.075660000 192.168.0.112 172.16.0.46
TCP 60 54320→1723 [RST] Seq=342 Win=0 Len=0
8<-----------------------------
Packet 42 is the PPTP confack?
As you can see there are no GRE packets after that, only one ppp compressed
packet (number 43) from server to client and then nothing else.
The other packets from 44 to 53 should be the pings and the telnet.
Did you say in a previous message that the server is unable to understand
what is in the compressed packets?
Thanks a lot, and I owe you a beer and a pizza!
Best Regards
Lorenzo
|
18 messages has been excluded from this view by a project administrator.
