On Mon, 11 Feb 2008 04:35:18 -0500, Lionel van den Berg wrote:

> I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It works

I haven't used it. Looks like it should be supported. Before running pppd,
try running "modprobe -v ppp_mppe".

In /etc/ppp/options add
nodeflate
nobsdcomp
to rule out problems with packet compression, and add
debug
so you can see (in /var/log/syslog), exactly where it is failing.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:

> On Mon, 11 Feb 2008 04:35:18 -0500, Lionel van den Berg
> wrote:
>
>> I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It
>> works
>
> I haven't used it. Looks like it should be supported. Before running pppd,
> try running "modprobe -v ppp_mppe".

Should I have got some response after doing this? It didn't give me
anything.

>
> In /etc/ppp/options add
> nodeflate
> nobsdcomp
> to rule out problems with packet compression, and add
> debug
> so you can see (in /var/log/syslog), exactly where it is failing.

This is what I got from the relevant part of the log:

Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
Feb 12 19:42:06 localhost pppd[7264]: unrecognized
option 'replacedefaultroute'
Feb 12 19:42:06 localhost pppd[7271]: pppd 2.4.4 started by root, uid 0
Feb 12 19:42:06 localhost pppd[7271]: using channel 3
Feb 12 19:42:06 localhost pppd[7271]: Using interface ppp0
Feb 12 19:42:06 localhost pppd[7271]: Connect: ppp0 <--> /dev/pts/4
Feb 12 19:42:07 localhost pppd[7271]: sent [LCP ConfReq id=0x1
]
Feb 12 19:42:34 localhost last message repeated 9 times
Feb 12 19:42:37 localhost pppd[7271]: LCP: timeout sending Config-Requests
Feb 12 19:42:37 localhost pppd[7271]: Connection terminated.
Feb 12 19:42:37 localhost pppd[7271]: Modem hangup
Feb 12 19:42:37 localhost pppd[7271]: Waiting for 1 child processes...
Feb 12 19:42:37 localhost pppd[7271]: script pptp --loglevel 1
brisbane.ansaldo-sts.com.au --nolaunchpppd, pid 7272
Feb 12 19:42:42 localhost pppd[7271]: sending SIGTERM to process 7272
Feb 12 19:42:42 localhost pppd[7271]: Exit.


--
Regards

Lionel.

On Tue, 12 Feb 2008 04:47:59 -0500, Lionel van den Berg wrote:

>> David W. Hodgins wrote:
>> try running "modprobe -v ppp_mppe".
> Should I have got some response after doing this? It didn't give me
> anything.

If it inserted the module, it would have printed a message. If it failed
to find the module, it would have printed a message. No output indicates
the module was already loaded, so it didn't do anything, which is ok.

> This is what I got from the relevant part of the log:
> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
> Feb 12 19:42:06 localhost pppd[7264]: unrecognized
> option 'replacedefaultroute'

From man pppd, the above options should be
mppe require
defaultrout
but mppe is for encryption. I'd remove that option, until you get the
connection working without it. Make sure /etc/ppp/chap-secrets has
the correct loginid and password.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Tue, 12 Feb 2008 12:34:55 -0500, David W. Hodgins wrote:

> From man pppd, the above options should be
> mppe require
> defaultrout

Great time for a typo . The above line should be
defaultroute

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:

> On Tue, 12 Feb 2008 04:47:59 -0500, Lionel van den Berg
> wrote:
>
>>> David W. Hodgins wrote:
>>> try running "modprobe -v ppp_mppe".
>> Should I have got some response after doing this? It didn't give me
>> anything.
>
> If it inserted the module, it would have printed a message. If it failed
> to find the module, it would have printed a message. No output indicates
> the module was already loaded, so it didn't do anything, which is ok.
>
>> This is what I got from the relevant part of the log:
>> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
>> Feb 12 19:42:06 localhost pppd[7264]: unrecognized
>> option 'replacedefaultroute'
>
> From man pppd, the above options should be
> mppe require
> defaultrout
> but mppe is for encryption. I'd remove that option, until you get the
> connection working without it.

OK, well I've tried *some* combinations, but I'm a little confused because
there are config files everywhere:

[root@localhost ppp]# pwd
/etc/ppp
[root@localhost ppp]# ls
chap-secrets ip-down.ipv6to4* ipv6-down* options.pptpd
connect-errors@ ip-up* ipv6-up* pap-secrets
ip-down* ip-up.d/ options peers/
ip-down.d/ ip-up.ipv6to4* options.pptp resolv.conf@
[root@localhost ppp]#

And one for each profile:

[root@localhost ppp]# ls /etc/ppp/peers/
kvpnc.Ansaldo kvpnc.Ansaldo1 kvpnc.Ansaldo2 wvdial wvdial-pipe

> Make sure /etc/ppp/chap-secrets has
> the correct loginid and password.

These are correct. The entries are of the form:

# --- generated by kvpnc. Do not edit it.
# +++ generated by kvpnc. Do not edit it.
# profile: Ansaldo1
username profilename password *

--
Regards

Lionel.

On Thu, 14 Feb 2008 03:38:43 -0500, Lionel van den Berg wrote:

> OK, well I've tried *some* combinations, but I'm a little confused because
> there are config files everywhere:

Take it one step at a time. pppd will die, if it finds an invalid option.

What do you get from syslog, for pppd with the options fixed?

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Tue, 12 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
, David W. Hodgins wrote:

>Lionel van den Berg wrote:

>> This is what I got from the relevant part of the log:
>> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'

lsmod is the module in there?

The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
such minor things as distribution and release).

>> Feb 12 19:42:06 localhost pppd[7264]: unrecognized
>> option 'replacedefaultroute'

That was a SuSE specific security hole included because they didn't
understand IP routing. It was added in an attempt to hide a problem, rather
than actually doing anything useful like fixing the root cause of the problem.
The option was made known to the ANU ppp maintainers, who laughed at the
incredible stupidity and ignored it.

>From man pppd, the above options should be
>mppe require

"require-mppe" has been a valid option since ppp-2.4.2 and is one of
several of that family

require-mppe
Require the use of MPPE (Microsoft Point to Point Encryp-
tion). This option disables all other compression types.
This option enables both 40-bit and 128-bit encryption.
In order for MPPE to successfully come up, you must have
authenticated with either MS-CHAP or MS-CHAPv2. This
option is presently only supported under Linux, and only
if your kernel has been configured to include MPPE sup-
port.

require-mppe-40
Require the use of MPPE, with 40-bit encryption.

require-mppe-128
Require the use of MPPE, with 128-bit encryption.


>defaultrout

You caught your error. Actually, the so-called "replacedefaultroute"
needs a few other "regular" options regarding authentication and MANUAL
routing changes.

* Fri Feb 25 2000 - bk@suse.de
- wrote patch which replaces the old defaut route on successfully
completed IPCP negotiation unless the included noreplacedefaultroute
option is given. Documented in the man page and /etc/ppp/options.
On connection shutdown, the old default route is restored automatically.
Nice feature for many people with laptops which have a default
route set trough their ethernet and want go online with their
modem if not connected to the ethernet. Should reduce support
load in this area dramatically.

Security? Who cares about that???

>but mppe is for encryption. I'd remove that option, until you get the
>connection working without it. Make sure /etc/ppp/chap-secrets has
>the correct loginid and password.

See the "require-mppe" snippet above. The peer may simply hang up the
phone on you leet h4x0rs trying to crack into their notwork.

Old guy

Moe Trin wrote:

> On Tue, 12 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in
> article , David W. Hodgins wrote:
>
>>Lionel van den Berg wrote:
>
>>> This is what I got from the relevant part of the log:
>>> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
>
> lsmod is the module in there?

[root@localhost lionel]# lsmod | grep mppe
ppp_mppe 6820 0
ppp_generic 23348 4 ppp_deflate,ppp_mppe,ppp_synctty,ppp_async
[root@localhost lionel]# lsmod | grep pppd
[root@localhost lionel]#


> The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
> such minor things as distribution and release).

[root@localhost lionel]# uname -r
2.6.22.18-desktop-1mdv
[root@localhost lionel]#


>>From man pppd, the above options should be
>>mppe require
>
> "require-mppe" has been a valid option since ppp-2.4.2 and is one of
> several of that family
>
> require-mppe
> Require the use of MPPE (Microsoft Point to Point Encryp-
> tion). This option disables all other compression types.
> This option enables both 40-bit and 128-bit encryption.
> In order for MPPE to successfully come up, you must have
> authenticated with either MS-CHAP or MS-CHAPv2. This
> option is presently only supported under Linux, and only
> if your kernel has been configured to include MPPE sup-
> port.
>
> require-mppe-40
> Require the use of MPPE, with 40-bit encryption.
>
> require-mppe-128
> Require the use of MPPE, with 128-bit encryption.

So what is your suggestion about what I should be using?


>>but mppe is for encryption. I'd remove that option, until you get the
>>connection working without it. Make sure /etc/ppp/chap-secrets has
>>the correct loginid and password.
>
> See the "require-mppe" snippet above. The peer may simply hang up the
> phone on you leet h4x0rs trying to crack into their notwork.


--
Regards

Lionel.

On Fri, 15 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
<47b549d3@dnews.tpgi.com.au>, Lionel van den Berg wrote:

>Moe Trin wrote:

>> lsmod is the module in there?
>
>[root@localhost lionel]# lsmod | grep mppe
>ppp_mppe 6820 0
>ppp_generic 23348 4 ppp_deflate,ppp_mppe,ppp_synctty,ppp_async

It's there, and unused. OK

>> The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
>> such minor things as distribution and release).
>
>[root@localhost lionel]# uname -r
>2.6.22.18-desktop-1mdv
>[root@localhost lionel]#

OK - I'm not using that kernel, but the fact that lsmod shows the module
there indicates that the hooks are there and usable.

>> "require-mppe" has been a valid option since ppp-2.4.2 and is one of
>> several of that family

>So what is your suggestion about what I should be using?

If we look back at a previous post, you showed:

]Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
]Feb 12 19:42:06 localhost pppd[7264]: unrecognized
]option 'replacedefaultroute'
]Feb 12 19:42:06 localhost pppd[7271]: pppd 2.4.4 started by root, uid 0

Minor confusion. Process 7263 (on what is presumably ppp-2.4.4) didn't
recognize the require-mppe option. I don't know why. Process 7264 and the
invalid 'replacedefaultroute' option is fine - that's a setup error. The
pppd not wanting to _replace_ an existing default, and requiring the peer
to authenticate TO YOU if one exists are security issues - sneaking
around a company firewall would be a good description, and that's a very
big no-no at most places who can spell the word security.

]Feb 12 19:42:07 localhost pppd[7271]: sent [LCP ConfReq id=0x1
] ]

You sent a "generic" hello - those are pretty stock options.

]Feb 12 19:42:34 localhost last message repeated 9 times
]Feb 12 19:42:37 localhost pppd[7271]: LCP: timeout sending Config-Requests

But the other side didn't so much as mumble at you. No response what so
ever. So what my next step would be is to go to the server at the other
end of the telephone, and look at it's logs. What did it get all huffy
about. Did the ppp process even hear you? You indicate that the server
is a company box (company admin problems) running windoze (the logs of a
windoze box are intentionally designed to look complicated, with lots of
techno-babble - the whole idea is to scare you away from those nasty
technical thingies), but if the peer won't even talk to you, you have to
go to the peer to find out why. Sorry I can't advise further, but
microsoft has never been know to go out of their way to follow standards,
even their own. That makes it difficult to troubleshoot from "outside".

The only thing I can say from here is that the modems appear to have
connected, and there is some "non-text" service (really meaning not a
classic terminal server) listening, but not hearing the right things.

Most of us don't have to deal with the microsoft abortion and the
intentional non-standard additions that are needed. Example - with
just about every accessible ppp dialin server, the mode today is to
dial the phone, when the modems report CONNECT, start slinging LCP
frames at each other (that "sent [LCP ConfReq" stuff above). 15 years
ago, it was more common to be presented with a UNIX style "Login:"
prompt and you logged into a remote shell process. That died when
microsoft invented the telephone, because win95 users couldn't see
where to click their mouse button on this text crap. Later, with NT,
microsoft developed a new idea, that when the modems connected, they
would send a bit of text identifying what they were: "CLIENT" or
"CLIENT/SERVER" or some such B/S. As far as I've been able to tell, it
served no purpose, but if you were trying to connect to a server whose
admin hadn't disabled the microsoft "features", that server was not going
to talk to you until you said that magic word. No one else used this
function, and I think even microsoft has ignored that it existed, but you
never can tell.

Old guy