Module-Failure-Message creation in rlm_mschap
The rlm_mschap change to create the Module-Failure-Message attribute creates it on the request chain. I notice that the original commit on 2010-09-10 (35ee205d4e2dcb4fe5e3<http://github.com/alandekok/freeradius-server/commit/35ee205d4e2dcb4fe5e34143a06bd9cafd279eeb>) had it in the reply. Then, a subsequent commit intentionally changed it to the request (401dcce982f9a9972bc7<http://github.com/alandekok/freeradius-server/commit/401dcce982f9a9972bc7bb87d5ee7e0bf3888f3a>). Would you be opposed to putting it back on the reply chain? I ask because of the pending change to save the reply attributes upon failure to survive the final eap round trip. If it's not in the reply chain, then it gets lost. If you're opposed to this, should the request chain be saved as well (or perhaps just save Module-Failure-Message if it exists)?
Garber, Neal wrote:
The rlm_mschap change to create the Module-Failure-Message attribute creates it on the request chain. I notice that the original commit on 2010-09-10 (35ee205d4e2dcb4fe5e3 <http://github.com/alandekok/freeradius-server/commit/35ee205d4e2dcb4fe5e34143a06bd9cafd279eeb>) had it in the reply. Then, a subsequent commit intentionally changed it to the request (401dcce982f9a9972bc7 <http://github.com/alandekok/freeradius-server/commit/401dcce982f9a9972bc7bb87d5ee7e0bf3888f3a>).
Every other module adds it to the request list.
Would you be opposed to putting it back on the reply chain? I ask because of the pending change to save the reply attributes upon failure to survive the final eap round trip. If it’s not in the reply chain, then it gets lost. If you’re opposed to this, should the request chain be saved as well (or perhaps just save Module-Failure-Message if it exists)?
Or, copy it from the request to the reply... Alan DeKok.
If you're opposed to this, should the request chain be saved as well (or perhaps just save Module-Failure-Message if it exists)?
Or, copy it from the request to the reply...
Ok. So, in rlm_eap_peap & rlm_eap_ttls, I will *copy* Request:Module-Failure-Message to Reply if it exists. Then, after restoring the saved Reply list, I will *move* Reply:Module-Failure-Message back to Request (if it exists in the Reply list). Sound reasonable?
Or, copy it from the request to the reply...
Ok. So, in rlm_eap_peap & rlm_eap_ttls, I will *copy* Request:Module-Failure-Message to Reply if it exists. Then, after restoring the saved Reply list, I will *move* Reply:Module-Failure-Message back to Request (if it exists in the Reply list).
Sound reasonable?
Hi Alan - I know you've been busy (and out of town), so I understand if you haven't had time to think about this. But, just in case you forgot, I thought I would "ping" you about it. Are you ok with saving the Module-Failure-Message Request attr. with the saved Reply attributes and then moving it back to the Request list at time of restore? Would you prefer to have it stored separately from the Reply attributes? I'd like to code the patch in a way that aligns with your preference to increase the chances of acceptance. If you need more time to think about the best approach, that's ok too (and sorry to bug you if so).
Garber, Neal wrote:
Hi Alan - I know you've been busy (and out of town),
You have no idea.
so I understand if you haven't had time to think about this. But, just in case you forgot, I thought I would "ping" you about it. Are you ok with saving the Module-Failure-Message Request attr. with the saved Reply attributes and then moving it back to the Request list at time of restore? Would you prefer to have it stored separately from the Reply attributes? I'd like to code the patch in a way that aligns with your preference to increase the chances of acceptance.
Sure... copy it from the tunnel to the reply, and then move it back. It's a hack, but a useful one. Alan DeKok.
participants (2)
-
Alan DeKok -
Garber, Neal