headers
Kenneth Kassing | 7 Nov 17:44
Favicon

Multilink PPP Problem

I am trying to use pppd 2.4.4 to do MLPPP over several hdlc interfaces. 
For my test case, I have two identical units connected back to back. The 
link establishes correctly and will pass data.  If the master link is 
reset for any reason, the master will fail to reestablish a connection.

For a test case, I manually disable the link from the remote side, and 
then re-enable it.  I tail the syslog for the link I did not reset to 
wach the output from pppd.  I see that pppd is rejecting the configure 
requests for multilink.  Here is the error message I see:

sent [IPCP ConfReq id=0x1 <addr 192.168.254.1>]
rcvd [proto=0x3d] 80 00 00 07 80 21 02 01 00 0a
Unsupported protocol 'Multi-Link' (0x3d) received
sent [LCP ProtRej id=0x6 00 3d 80 00 00 07 80 21 02 01 00 0a]
rcvd [proto=0x3d] 40 00 00 08 03 06 c0 a8 fe 01
Unsupported protocol 'Multi-Link' (0x3d) received
sent [LCP ProtRej id=0x8 00 3d 40 00 00 08 03 06 c0 a8 fe 01]
rcvd [proto=0x3d] 40 00 00 0a 03 06 c0 a8 fe 00

I have looked into the code, and found that pppd is looking to match 
protocols in "struct protent *protocols[]" table (in main.c).  Multilink 
does not have an entry in this table, and therefore will never link 
correctly.  (The line which prints the 'Unsupported protocol' message is 
shortly after the code which loops this table, in the function 'get_input'.)

Any suggestions here?

Thanks

Ken Kassing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Palenschat | 20 Nov 23:16

Logging problem with 2.4.4

Hello, I am running ppp 2.4.4 on CentOS 4.4 (RHEL Clone) and have my ppp
configured to use the radius plugin. I have copied the
dictionary.microsoft file from the source tree into my config directory
and included it in my main dictionary file.
This works well, but there are some errors being logged and the primary
problem is that pppd is not logging which user is connecting. This is
only a problem because I track user activity by that. 
Here are some sample logs:

Nov 19 18:53:04 dialin mgetty[4328]: data dev=ttyR0, pid=4328,
caller='none', conn='38400', name='', cmd='/usr/local/sbin/pppd',
user='/AutoPPP/'
Nov 19 18:53:04 dialin pppd[4328]: Plugin radius.so loaded.
Nov 19 18:53:04 dialin pppd[4328]: RADIUS plugin initialized.
Nov 19 18:53:04 dialin pppd[4328]: Plugin radattr.so loaded.
Nov 19 18:53:04 dialin pppd[4328]: RADATTR plugin initialized.
Nov 19 18:53:04 dialin pppd[4328]: pppd 2.4.4 started by a_ppp, uid 0
Nov 19 18:53:04 dialin pppd[4328]: Using interface ppp0
Nov 19 18:53:04 dialin pppd[4328]: Connect: ppp0 <--> /dev/ttyR0
Nov 19 18:53:09 dialin pppd[4328]: rc_avpair_gen: received unknown
attribute 25 of length 30:
0x434F0496000001370001C0A8010901C70A4B25DE5060000000000000001A
Nov 19 18:53:10 dialin pppd[4328]: found interface eth0 for proxy arp
Nov 19 18:53:10 dialin pppd[4328]: local  IP address 192.168.1.15
Nov 19 18:53:10 dialin pppd[4328]: remote IP address 192.168.1.219
Nov 19 19:05:24 dialin pppd[4328]: Hangup (SIGHUP)
Nov 19 19:05:24 dialin pppd[4328]: Modem hangup
Nov 19 19:05:24 dialin pppd[4328]: rc_avpair_new: unknown attribute 48
Nov 19 19:05:24 dialin pppd[4328]: rc_avpair_new: unknown attribute 47
Nov 19 19:05:24 dialin pppd[4328]: Connect time 12.3 minutes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Brady | 22 Nov 01:24

chap_passwd_hook() not used in server mode - why?


get_secret() in auth.c has this code:

...
     } else if (!am_server && chap_passwd_hook) {
         if ( (*chap_passwd_hook)(client, secbuf) < 0) {
             error("Unable to obtain CHAP password for %s on %s from plugin",
                   client, server);
             return 0;
         }
     } else {
...

I'm curious as to the reason for not enabling the hook to be used when 
pppd is running in server mode. When authenticating PPTP connections using 
MSCHAPv2, it would be useful to read NT hashes from smbpasswd or from 
ldap. The current hook structure doesn't facilitate that, however, and as 
a result, a number of plugin authors have duplicated large parts of 
chap_ms.c in their plugin's chap_verify function.

The only plugin I've found which implements a chap_passwd_hook function is 
passwordfd, and I doubt that that would ever be used in server mode.

Would anyone object to this patch?

--- ppp-2.4.4.orig/pppd/auth.c  2006-06-18 07:26:00.000000000 -0400
+++ ppp-2.4.4/pppd/auth.c       2006-11-21 19:12:25.000000000 -0500
@@ -1938,7 +1938,7 @@

      if (!am_server && passwd[0] != 0) {
(Continue reading)

Permalink | Reply | 0 comments |

Gmane