cmnorton

[Log in to get rid of this advertisement]

I believe I have configured kvpnc (Kubuntu) properly. It works inside our firewall connecting to the wan vpn address. Outside the firewall, it appears that after the initial connection, a delay needs inserting. That is my pptp client is bailing after a zero length read.

What parameters control delay after initial connection and which config files are involved?

Here are the log results:

root@mrshighpants:/var/log# tail syslog
pptp[10092]: anon log[ctrlp_dispptp_ctrl.c:857]: Received Outgoing Call Reply.
pptp[10092]: anon log[ctrlp_dispptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 101).
pptp[10092]: anon log[pptp_read_someptp_ctrl.c:543]: read returned zero, peer has closed
pptp[10092]: anon log[callmgr_mainptp_callmgr.c:255]: Closing connection (shutdown)
pptp[10092]: anon log[ctrlp_repptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
pptp[10092]: anon log[pptp_read_someptp_ctrl.c:543]: read returned zero, peer has closed
pptp[10092]: anon log[call_callbackptp_callmgr.c:78]: Closing connection (call state)
pppd[10087]: Modem hangup
pppd[10087]: Connection terminated.
pppd[10087]: Exit.

Any pointers would be appreciated.

blackhole54

Hi,

I don't know how much help I can give you with your problem (but who knows -- maybe a thought will occur to me.) But I am seeing a bunch of "smilies" in your log listing. This wouldn't happen if you wrapped your listing in "code tags." If you need more info, check out the link in my signature.

Also, I don't see any time stamps in your log listing. Not always, but sometimes the timing of messages gives clues as to what is going on.

cmnorton

Attached is a recent log wrapped in code tags:

blackhole54

Thanks for the update. I've not come up with any ideas, but poking around has revealed to me that kvpnc is just a front end. In your case, I believe it is pptpclient that is doing the real work. So at the risk of telling you something you already know, I would suggest that Internet searches might be more productive with the term pptp or pptpclient than with the term kvpnc.

I did find a fairly extensive diagnostic page here. A quick search using keywords didn't reveal anything hopeful, but I didn't look at it in detail. You might want to take a look at it and see if it is any help. In particular, I noted it had instructions on using tcpdump (a packet sniffer) for troubleshooting. You might find that to be useful. It also has a fault tree which might help.

Also, I'm not trying to be a nag, but in your last post you quoted the log output instead of using code tags. The effect is quite different. If you are clicking on the icon to use the tags, the icon for code tags is the hash mark (#) right next to the icon for quoting. The "quick reply" box does not have this icon.

blackhole54

After receiving some information about pptp in another thread and doing some Internet searching and looking at the Wikipedia articles on pptp and GRE, I see that pptp actually uses two streams: GRE for the tunneling and TCP for control. As such it can be tricky to pass through firewalls and NAT devices. So when you are outside your corporate firewall, you might have failure either at the corporate firewall and/or at your own router/NAT device.

You might want to take a look at this link that LQ member mostlyharmless kindly provided. It tells (as I read it) what needs to be done at the corporate firewall to let a pptp connection through. In particular, the firewall must allow GRE packets through and route them correctly in addition to allowing the TCP/1723 packets through.

Likewise, your DSL router (or whatever you are using at home) must allow the GRE packets through and route them correctly. (If you have a firewall on your client machine, it must also track these packets correctly. But since you didn't have problems when behind the corporate firewall, I assume this is not an issue.) I also noted that one of the comment posters on the technet link above states that "Many consumer grade routers have issues passing GRE Protocol 47 traffic." So perhaps your home router isn't even capable of this. And if you look on that that other LQ thread I linked to you, will see the mostlyharmless remembers a requirement to open one or more ports on the router the client is behind.

I hope this gives you some useful information for troubleshooting further.