I have a busy Linux-based PPTP concentrator (backed by pppd) using Radius authentication and am seeing some situations where a user connects and gets no /var/run/radattr file. I've determined the situation is occuring as a result of User A connecting and being assigned interface ppp0; disconnecting, and while disconnecting user B connects and is assigned interface ppp0 (it apparently is made available before User A's disconnection process or plugins complete running). User B's radattr script is written before user A's disconnect process is completed. User A's process removes the radattr file (which is actually for user B!). Here is an example from my logs of this type of situation occurring: Jun 28 23:08:50 chico-pptp1 pppd[22494]: Plugin radius.so loaded. Jun 28 23:08:50 chico-pptp1 pppd[22494]: RADIUS plugin initialized. Jun 28 23:08:50 chico-pptp1 pppd[22494]: Plugin radattr.so loaded. Jun 28 23:08:50 chico-pptp1 pppd[22494]: RADATTR plugin initialized. Jun 28 23:08:50 chico-pptp1 pppd[22494]: pppd 2.4.3 started by root, uid 0 Jun 28 23:08:50 chico-pptp1 pppd[22494]: Using interface ppp29 Jun 28 23:08:50 chico-pptp1 pppd[22494]: Connect: ppp29 <--> /dev/pts/113 Jun 28 23:08:53 chico-pptp1 pppd[22494]: Peer jewell@xxxxxxxxx CHAP authentication succeeded Jun 28 23:08:53 chico-pptp1 pppd[22494]: MPPE 128-bit stateless compression enabled Jun 28 23:08:55 chico-pptp1 pppd[22494]: found interface eth0 for proxy arp Jun 28 23:08:55 chico-pptp1 pppd[22494]: local IP address 208.53.80.9 Jun 28 23:08:55 chico-pptp1 pppd[22494]: remote IP address 208.53.80.189 Jun 28 23:09:49 chico-pptp1 pppd[22494]: LCP terminated by peer (^D~^SM-a^@<M-Mt^@^@^@^@) Jun 28 23:09:50 chico-pptp1 pppd[22494]: Connect time 1.0 minutes. Jun 28 23:09:50 chico-pptp1 pppd[22494]: Sent 504 bytes, received 1294 bytes. Jun 28 23:09:50 chico-pptp1 pppd[22494]: Modem hangup Jun 28 23:09:50 chico-pptp1 pppd[22494]: Connection terminated. Jun 28 23:09:51 chico-pptp1 pppd[23135]: Plugin radius.so loaded. Jun 28 23:09:51 chico-pptp1 pppd[23135]: RADIUS plugin initialized. Jun 28 23:09:51 chico-pptp1 pppd[23135]: Plugin radattr.so loaded. Jun 28 23:09:51 chico-pptp1 pppd[23135]: RADATTR plugin initialized. Jun 28 23:09:51 chico-pptp1 pppd[23135]: pppd 2.4.3 started by root, uid 0 Jun 28 23:09:51 chico-pptp1 pppd[23135]: Using interface ppp29 Jun 28 23:09:51 chico-pptp1 pppd[23135]: Connect: ppp29 <--> /dev/pts/268 Jun 28 23:09:51 chico-pptp1 pppd[23135]: Peer frems21@xxxxxxxxx CHAP authentication succeeded Jun 28 23:09:51 chico-pptp1 pppd[23135]: MPPE 128-bit stateless compression enabled Jun 28 23:09:51 chico-pptp1 pppd[23135]: found interface eth0 for proxy arp Jun 28 23:09:51 chico-pptp1 pppd[23135]: local IP address 208.53.80.9 Jun 28 23:09:51 chico-pptp1 pppd[23135]: remote IP address 208.53.81.169 Jun 28 23:09:51 chico-pptp1 pppd[22494]: Exit. As you can see, process 22494 doesn't exit until after 23135 completes its plugin processing (you'll have to take my word for it since timestamp accuracy is in seconds). I hacky fix idea I had in mind was to have cleanup() in radattr.c check the file modification time on the file in question to ensure it hasn't been written to by another process. If so, don't remove it. Maybe the proper fix would be to do some file locking or to reserve the interface from being assigned to another pppd until the previous connection has completed? Suggestions? Ray - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
