"PPP did not converge"

This message is given by the TSX Radius server and is seen in the RADIUS event log. In order to fully understand why you see this message you need to fully understand why logging onto a TSX system through RADIUS is a multistaged process. To explain this it helps to detail the steps that led to the evolution of this multistaged process.

In the first incarnation of the RADIUS server, once an authentication request was granted, the RADIUS server immediately told the who server that they new user was on the system. This was done for the purpose of detecting duplicate logons.

We very soon discovered that if people's modems got screwed up during the logon process, during the PPP negotiations between their computer and the terminal server, that we could see the authentication request coming in from the aborted phone call. User would redial the system immediately and start PPP negotiations over again. You see, part of these PPP negotiations are the PAP authorization packets, but there is more involved; the two ends have to agree on assignment of IP addresses, use of magic numbers, which control characters can be transmitted over the circuit, and so forth. Seems the terminal server shoots off that authentication request when it gets the PAP packets (reasonable enough) but that the whole process might break down after the TSX server has already responded to the request.

The process of PPP negotiations is pretty interesting. One side just sends out a suggested configuration, and the other side does too -- possibly at the same time. Each side has to look at the options the other guy is requesting, compare them to what he likes and send out a (possibly revised) configuration request. The two sides keep nattering at each other this way until the packets going back and forth become identical. When his suggestion is the same as her suggestion, the server and the client... um... converge.

We noticed that once the PPP negotiations finally did converge, the terminal server would send a packet to the accounting server (which was also TSX) saying that the guy had finally logged on.

Hence, the decision was made in the RADIUS server, since we wanted to do duplicate detection of logons, that we would hold the user in an embryonic state after we granted the accounting request, and that this embryo of a logged in user would only fully develop into a breathing, kicking, logged in customer when we got the logon packet at the accounting port. Only then would we tell the WHO server that the guy was logged on and begin doing duplicate logon detection and charging the guy for his time on the system.

What happens if one of these embryonic logins never completes, because we never see the LOGON accounting packet, is that the RADIUS server guesses that the PPP negotiations never converged. That's why we use the message "PPP did not converge". Perhaps a better message would have been "I never saw an account logon message for such and such user".

It's possible to run the RADIUS server in "non-convergent mode". Currently the way you engage this is to patch TPR.EXP and set the byte named RADWAIT to 0:

CD BBSBIN:
PATCH TPR.EXP
Patch> eb radwait 0
Patch> exit