Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: Jim Huneycutt on April 26, 2003, 03:36:15 AM
-
The reference for recent 5.6 update 4 refers to this fix: "#6546 PPTP: recurring session delays and disconnects".
Does anyone know if this fixes the PPTP problems reported in the forum and listed as a bug here:
http://www.e-smith.org/bugs/index.php3?op=showBug&bugID=93
Thanks,
jim
-
Jim,
It appears that Update 4 has removed the template fragment which puts in the ip_nat_pptp and ip_conntrack_pptp lines into masq (effectively the same as the published workaround). However, there are updated pptp and ipmasq modules in the update as well. I'll test it out and see.
Kelvin
-
I have installed Update 4 and my vpn pptp (from local 5.6 to remote 5.5) seems to be working OK (have been connected for well over an hour now), but it did work OK after implementing the bug fix anyway (did not work before that though).
Regards
Ray Mitchell
-
I suspect there is still something amiss with PPTP.
I applied update 4 to a fresh V5.6 install and found that outgoing PPTP connections from the first PC which I used worked reliably.
After DISCONNECTING that VPN link (as only one can be active at a time to the same remote PPTP server) I tried to establish another link from a different machine on the LAN to the same remote SME V5.5 server.
It failed with Windows reporting an Error 619.
In total I tried connecting from 3 machines (2 x XP, 1 x Win2000) and in every case the PC that I used to establish the first VPN connection, after rebooting the SME V5.6u4, could reliably and repeatedly connect.
I used the same and different Username/Passwords from each machine, all with the same results. I was always connecting to the same remote server.
As a double check I applied Update 4 to my normal SME 5.6 machine and experienced the same results. In my case at least there still appears to be an issue, has anyone else seen the above?
-
I was wondering if the removal of these modules (ip_nat_pptp and ip_conntrack_pptp) also means that trying to do PPTP connections *through* a 5.6U4 server would stop working - I think the bug report listed that as a side effect of this work around, unfortunately that information has been removed from the report.
Can anyway with U4 installed comment on the ability to make PPTP connections from internal clients through 5.6 to machines across the net?
G
-
Dear Guck Puppy
That's what I said in my earlier post, but to elaborate I can connect (at different times) from a Win2K w/s and a Win95 w/s through a local 5.6U4 server to a remote 5.5U6 server and connect to workstations on the remote network also. I have had a number of connections established this evening ranging from 15 minutes to 1 hour to over 2.5 hours without any problem.
When I first installed the 5.6 server I could not get reliable connections at all. Then I applied the bug fix that was posted on the bugs page, and that fixed the problem with getting out of my 5.6 server. I applied the U4 update yesterday and vpn pptp outgoing still works OK.
I never loaded any of the modules at Charlie's website as I understaood that these were for debugging only and were not meant to be fixes at all.
So for me anyway, outgoing through 5.6 is working fine now.
Regards
Ray Mitchell
-
Martin,
I think that problem is not from 5.6 itself. I have sites running SME 5.1.2 as the PPTP server where clients (and me) connect to. They have reported before that when they connect from home or another location, the first machine connects OK. If that machine logs off, then another machine at the *same* location tries to log in, they get the 619 error. Moreover, they are not running SME at home, just a normal broadband router box. This second machine will not be able to log in until the router box gets reset (in your case, your SME server getting rebooted). I'm suspecting either it's a protocol issue, cache issue or the way PPTP is implemented in SME (whichever version).
Jim, GP & Ray, so far so good. With Update 4 installed I've been able to establish connections to every remote site I tried successfully and maintain that connection. In the past, even with the workaround applied, I can connect to some but not others until the server gets rebooted, after which soem of the site I could connect to before, I can't while the ones I couldn't before I can (try saying that 20 times in a row quickly :-) ). I'll continue testing and will post back if any new developments arise.
Kelvin
-
Kelvin,
Good point, so to prove my problem at least is caused by the SME 5.6 U4 at home I remove the SME and re-enabled my Linksys router to provide DHCP and PPPoE.
Running through the same tests I was able to successfully connect from 2 different machines to the remote SME V5.5.
So in my case it looks like SME 5.6 U4 is causing some sort of problem. I always allowed a minimum of 30 seconds between connections as I have seen issues in the past when you reconnect quickly.
Regards
Martin
-
Hi Martin,
Hmmm... interesting. I wonder if the SMC router is the culprit with these other clients.
Will try with other router..
Kelvin
-
Martin Trigg wrote:
> So in my case it looks like SME 5.6 U4 is causing some sort
> of problem. I always allowed a minimum of 30 seconds between
> connections as I have seen issues in the past when you
> reconnect quickly.
Please try again, but with a minimum of 2 minutes between connections. Without connection tracking modules the masquerading code won't know to tear down the GRE connection when the PPTP control connection is terminated. This means that GRE will still be forwarded to the first workstation for two minutes after the PPTP connection is terminated. This will prevent a connection from being made from the second one.
Run iptstate if you want to vizualize the expiry of the connection tracking.
2 minutes is the default timeout for connections - I expect that you can find a way to adjust that, if you really need multiple (serial, not simultaneous) outbound connections to the same remote server.
regards
Charlie
-
I too have applied 5.6U4 now, and have been able to PPTP TO the server with no problems.
Connecting *through* did give me issues - I had unsuccessful connection attempts, the 619 error.
I'm only connecting through the 5.6 server from a single workstation - and I see using iptstate that the 1723 connections made from the workstation out to the remote PPTP server and I see the 2 minute TTL.
The GRE connection looks to have a TTL of 10 minutes though:
Source IP Destination IP Proto State TTL
{remote-pptp-ip} {sme5.6u4-external-ip} gre 0:09:04
so after the failed attempt to connect, I waited 10 mins, tried again, and the connection was successful - now GRE is being forwarded to my workstation! Whee!
G
-
I also saw a similar situation to GP, first attempt to connect failed. After waiting 10 minutes I was able to successfully connect. Seemed to be a one off problem.
Charlie, thanks for your continued support of the unsupported developers release :-)
Martin
-
I have the same problem, after installing U4 I can only do an outgoing VPN connection once, if I try to connect a second time the connection fails with error
619 (on Windows XP). In U3 everything worked well.
-
I've found a solution for failing repeating outgoing pptp connections (Windows error 619), i have compared the content of the following packages "e-smith-ipmasq-1.8.1-01.noarch.rpm" "e-smith-ipmasq-1.8.2-01.noarch.rpm" and found the "10masq_pptp" file missing. After copying the file to the correct folder (/etc/e-smith/templates/etc/rc.d/init.d/masq) and applying the signal-events post-upgrade and reboot everyting is working well again.
-
Yeah... but I think the reason that was left out was to implement the workaround of having unreliable PPTP connections in the first place... I believe (need to check search the forum) that Charlie Brady mentioned it was these masq and conntrack modules that were causing the problems in the first place, that's why they took them out.
I'd be very interested to know if you suffer from the problems that were reported about PPTP before U4.
G
-
I've had unreliable incoming PPTP connections in previous versions (5.6) but losing the ability to connect to an external VPN concentrator is worse. In 5.5 I've had no problems at all with incoming and outgoing PPTP connections so maybe I'll try the modules of 5.5 instead of 5.6 (if possible).
-
I've replaced the kernel modules ip_conntrack_pptp.o and ip_nat_pptp.o with the 5.5 modules and everything seems to be more stable now. I no longer get the "GRE: Discarding for incorrect call" message and the incomming connection no longer drops eventualy.
-
That sounds good - how did you get those modules? Do you have to extract them from the rpms? I decided to give 5.6 another try, based on the PPTP issues maybe being resolved, but after applying the updates I still couldn't even make one connection to my 5.5 box at home.
Thanks,
Bobby
-
Are you kidding me. PPTP still isn't fixed? What was the big rush in releasing 5.6 then? It's been months, now.
>Bobby wrote:
>
> That sounds good - how did you get those modules? Do you have
> to extract them from the rpms? I decided to give 5.6 another
> try, based on the PPTP issues maybe being resolved, but after
> applying the updates I still couldn't even make one
> connection to my 5.5 box at home.
> Thanks,
> Bobby
-
My results with 5.6 so far are:
a) Able to connect from a W2K worstation behind 5.6u4 to another 5.6u4 OK
b) Able to connect from a W98 PC begind 5.6u4 to another 5.6u4 OK
c) At least 40 seconds to connect and unable to maintain a connection (disconnects while accessing network shares) from a W98 PC behind a 3COM DSL Gateway to a 5.6u4. Worked fine with 5.1.2. However, I reset the 3COM unit this AM and the connection seems to be OK so far, still slow to connect though.
-
I did extract them from the RPMS of the 5.5 edition and copied them to the 5.6 server. After a reboot everything is ok again. I've made a VPN connection (incomming) and had it running for almost 2 days without errors, after that I disconnected the connection myself.
-
Ghislain
Any chance of documenting what RPMs you used? Did they just install because they were not in 5.6u4?
Many Thanks
-
Gordon,
Update4 has also broken my PPTP between a 5.6 at home and a 5.6 at work. Prior to the upgrade, it was working with Charlie's fix. My problem is getting the 619 error on XP after trying to reconnect hours later. A reboot of the outgoing server seems to fix it. I am interested in the 5.5 module fix. Please post how you did this.
Thanks,
ryan
-
Ghislain
How is your 5.6U4 VPN connections working. Can you share your fix method?
Many Thanks
Gordon
-
More for the topic......
I set up another 5.6 box a few days ago. After default install, I added smtp mail front with rbl support, and IMP/horde 3.2.1. I then installed U4. This box has probems with PPTP on the first attempt to another 5.6 box. It worked ok to older SME 5.1.2 just fine.
I experimented by adding the preU4 pptp custom template (10masq_pptp which is blank 0k) patch, expand template, reboot.
(don't forget to 'service pptpd stop') before you expand a template.
After reboot, remove the custom template, expand template, reboot......no more error 619 and in the very short term, PPTP seems OK between 5.6 and 5.6 using XP pro.
Hope this helps, or if it does not help please post it.
RS
-
Gordon,
I've made a RPM-package that will install the files in the correct folders. You can get the package here: ftp://vd-steen.com/e-smith-56-pptp-fix-0.1-1.noarch.rpm
After installing the RPM you have to initiate the following events:
/sbin/e-smith/signal-event post-upgrade
/sbin/e-smith/signal-event reboot
This is what the package will do:
1) copy the file "10masq_pptp" to the folder:
"/etc/e-smith/templates/etc/rc.d/init.d/masq"
2) copy the files "ip_conntrack_pptp.o" and "ip_nat_pptp.o"
(from the SME55 release) to the folder:
"/lib/modules/2.4.18-5/kernel/net/ipv4/netfilter"
Ghislain
-
Ghislain,
Sorry, but I could not get the ftp link to work - got a "not found" response. Using ftp://vd-steen.com/e-smith-56-pptp-fix-0.1-1.noarch.rpm
Has the file been removed?
Thanks,
jim
-
Sorry, the correct link is: http://www.vd-steen.com/files/e-smith-56-pptp-fix-0.1-1.noarch.rpm
(The ftp link is for lan only!)
Ghislain
-
Full error post:
___________________
Enabling IP masquerading: /lib/modules/2.4.18-5/kernel/net/ipv4/netfilter/ip_nat
_pptp.o: unresolved symbol ip_nat_helper_register_R657ae5df
/lib/modules/2.4.18-5/kernel/net/ipv4/netfilter/ip_nat_pptp.o: unresolved symbol
irq_stat_R861c5a5e
/lib/modules/2.4.18-5/kernel/net/ipv4/netfilter/ip_nat_pptp.o: unresolved symbol
ip_nat_helper_unregister_R1c381b0f
/lib/modules/2.4.18-5/kernel/net/ipv4/netfilter/ip_nat_pptp.o:
Hint: You are trying to load a module without a GPL compatible license
and it has unresolved symbols. The module may be trying to access
GPLONLY symbols but the problem is more likely to be a coding or
user error. Contact the module supplier for assistance, only they
can help you.
_____________________
:-(
-
OK, the command /sbin/modprobe ip_nat_pptp gives the same error shown above, with your .o or with the .o from 5.6.
I've checked, there are'nt any other ip_nat_pptp.o files floating around.
I have two 5.6 boxes however. In general, as far as I can imagine applies here, they are setup the same. The failing one has pptp enabled, but the working one doesn't.
The working one will happily load ip_nat_pptp as a module, the 5.6 version. The one I ran your rpm on won't laod either version!
Can anyone please tell me where to start looking? MD5-identical modules behave differently on two installs of the same version/distribution. I just don't get it.
Help! AAARRGH!
-
Well I'm at the stage now where I have three 5.6U e-smith boxen.
two will /sbin/modprobe ip_nat_pptp just fine.
The one I actually want to use gives all kinds of rubbish and can't load either nat_pptp or contrack_pptp, specifically unresolved symbols and a GPL license problem. I don't understand this at all!
Any offers of help would make me jump up and down with glee.