We don't use the default TLS config, and have this defined explicitly here:
https://github.com/ministryofjustice/network-access-control-server/blob/main/radius/sites-enabled/radsec#L22
While debugging this, I set the tls_min_version to TLSv1.0, but this didn't
make a difference sadly.

Looked at the logs from the AP (Aruba 305), and the only error message is:

Sep 14 12:22:26  stm[5602]: <124026> <WARN> |AP
24:f2:7f:c7:7d:ee@192.168.0.38 stm|  tcp connected to
nac-radsec-production (51.149.xx.xx:2083), socket 0x226a7ec, socket id
20
Sep 14 12:22:26  stm[5602]: <199802> <ERRS> |AP
24:f2:7f:c7:7d:ee@192.168.0.38 stm|  rc_rad_tls.c,
RadsecTLSNegotiationHandler:599: Failed to open TLS socket error
error:00000001:lib(0):func(0):reason(1)
Sep 14 12:22:26  stm[5602]: <199802> <ERRS> |AP
24:f2:7f:c7:7d:ee@192.168.0.38 stm|  rc_rad_tls.c,
RadsecTLSNegotiationHandler:601: calling cleanup for 51.149.xx.xx
Sep 14 12:22:26  stm[5602]: <199802> <ERRS> |AP
24:f2:7f:c7:7d:ee@192.168.0.38 stm|  rc_rad_tls.c,
radsec_start_connection_retry_timer:144:
radsec_start_connection_retry_timer: Connection to server
nac-radsec-production failed or disconnected

Also did a packet capture on the server for a radsec request, but
couldn't find anything that points me in the direction of a fix.

Thanks,

Emile





On Tue, Sep 14, 2021 at 1:23 PM Josef Vybíhal <josef.vybihal@gmail.com>
wrote:

> Just a guess. Does the other side support TLSv1.2?
>
>
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/sites-available/tls#L306
>
> P.
>
> On Tue, Sep 14, 2021 at 2:12 PM Emile Swarts <emile.swarts123@gmail.com>
> wrote:
>
> > I recently upgraded Alpine from v3.12 to v3.14.
> >
> > Noticed that Radsec stopped working, and the only error message I get in
> > the server logs is "(0) FAILED in TLS handshake receive". Switching back
> to
> > v3.12 fixes the issue and the AP is able to establish the Radsec tunnel
> and
> > do the authentication.
> >
> > I'm currently looking through all the dependencies that upgraded as part
> of
> > the OS upgrade but it's difficult to pinpoint which one broke Radsec.
> Noted
> > that openssl has stayed on the same version.
> >
> > FreeRadius versions went from:
> > freeradius-lib-3.0.21-r3
> > freeradius-3.0.21-r3
> > freeradius-eap-3.0.21-r3
> >
> > To:
> > freeradius-lib-3.0.23-r0
> > freeradius-3.0.23-r0
> > freeradius-eap-3.0.23-r0
> >
> > The rest of the package upgrades can be found here:
> > https://gist.github.com/emileswarts/fd7d46556eacac096d318170aea7a19d
> >
> > Does anyone have any pointers on how to narrow down this bug?
> >
> > Thanks,
> > Emile
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html

Thanks for that. Had a look at the debug logs: ... new connection request on TCP socket Listening on auth from client (188.220.xx.xx, 57095) -> (*, 2083, virtual-server=radsec) Waking up in 0.6 seconds. (0) (TLS) Initiating new session (0) (TLS) Setting verify mode to require certificate from client (0) (TLS) Handshake state - before SSL initialization (0) (TLS) Handshake state - Server before SSL initialization (0) (TLS) Handshake state - Server before SSL initialization (0) (TLS) recv TLS 1.3 Handshake, ClientHello (0) (TLS) Handshake state - Server SSLv3/TLS read client hello (0) (TLS) send TLS 1.2 Handshake, ServerHello (0) (TLS) Handshake state - Server SSLv3/TLS write server hello (0) (TLS) send TLS 1.2 Handshake, Certificate (0) (TLS) Handshake state - Server SSLv3/TLS write certificate (0) (TLS) send TLS 1.2 Handshake, ServerKeyExchange (0) (TLS) Handshake state - Server SSLv3/TLS write key exchange (0) (TLS) send TLS 1.2 Handshake, CertificateRequest (0) (TLS) Handshake state - Server SSLv3/TLS write certificate request (0) (TLS) send TLS 1.2 Handshake, ServerHelloDone (0) (TLS) Handshake state - Server SSLv3/TLS write server done (0) (TLS) Server : Need to read more data: SSLv3/TLS write server done (0) (TLS) In Handshake Phase Waking up in 0.6 seconds. (0) (TLS) Server : Need to read more data: SSLv3/TLS write server done (0) (TLS) In Handshake Phase (0) (TLS) Application data. (0) FAILED in TLS handshake receive Closing TLS socket from client port 57095 Client has closed connection ... shutting down socket auth from client (188.220.xx.xx, 57095) -> (*, 2083, virtual-server=radsec) I can't see any mention of TLS1.0. Only tls_min_version has been set to 1.2 in the TLS config. The cipher_list has also been set to DEFAULT. I've been unable to find much about the default security policies of Openssl / Alpine. Is this something I can update myself, that could potentially solve the problem? Thanks, Emile On Tue, Sep 14, 2021 at 1:42 PM Alan DeKok <aland@deployingradius.com> wrote:

On Sep 14, 2021, at 8:12 AM, Emile Swarts <emile.swarts123@gmail.com> wrote:

...

I recently upgraded Alpine from v3.12 to v3.14.

Upgrades generally change OpenSSL, and/or the default security policies.

...

I'm currently looking through all the dependencies that upgraded as part of the OS upgrade but it's difficult to pinpoint which one broke Radsec. Noted that openssl has stayed on the same version.

Debian also changed their default security policies

...

FreeRadius versions went from: freeradius-lib-3.0.21-r3 freeradius-3.0.21-r3 freeradius-eap-3.0.21-r3

To: freeradius-lib-3.0.23-r0 freeradius-3.0.23-r0 freeradius-eap-3.0.23-r0

That's good. 3.0.23 has MUCH better debugging messages for TLS.

...

The rest of the package upgrades can be found here: https://gist.github.com/emileswarts/fd7d46556eacac096d318170aea7a19d

Does anyone have any pointers on how to narrow down this bug?

I'll give it 99% that it's the security policies.

https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-avail...

Run the server in debug mode, and see which TLS version it's using.

Note that you *can't* set "tls_min_version=1" and have it work. Blame OpenSSL. You *also* have to set the cipher_list.

Why? OpenSSL magic. You can't use TLS 1.0 or 1.1, because they're insecure. If you ask, OpenSSL says "no".

Then you ask "pretty please?", and OpenSSL says "oh, fine then."

It's a little frustrating.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Ok thanks, Had a look at that C code, but understanding why it's not doing the right thing is a bit beyond me I'm afraid. I have a packet capture from the server as well: "188.220.232.134","10.180.101.189","TCP","76","56345 > 2083 [SYN] Seq=0 Win=25200 Len=0 MSS=1260 SACK_PERM=1 TSval=45917131 TSecr=0 WS=64" "10.180.101.189","188.220.232.134","TCP","76","2083 > 56345 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=8961 SACK_PERM=1 TSval=3850271683 TSecr=45917131 WS=128" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=1 Ack=1 Win=25216 Len=0 TSval=45917135 TSecr=3850271683" "188.220.232.134","10.180.101.189","TLSv1.2","217","Client Hello" "10.180.101.189","188.220.232.134","TCP","68","2083 > 56345 [ACK] Seq=1 Ack=150 Win=28032 Len=0 TSval=3850271693 TSecr=45917135" "10.180.101.189","188.220.232.134","TLSv1.2","1316","Server Hello" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=1249 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=2497 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","1316","2083 > 56345 [ACK] Seq=3745 Ack=150 Win=28032 Len=1248 TSval=3850271695 TSecr=45917135 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TLSv1.2","656","Certificate, Server Key Exchange, Certificate Request, Server Hello Done" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=1249 Win=27712 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=2497 Win=30208 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=3745 Win=32704 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=4993 Win=35200 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=150 Ack=5581 Win=37696 Len=0 TSval=45917141 TSecr=3850271695" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=150 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","68","2083 > 56345 [FIN, ACK] Seq=5581 Ack=1398 Win=30464 Len=0 TSval=3850271729 TSecr=45917153" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=1398 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TCP","1316","56345 > 2083 [ACK] Seq=2646 Ack=5581 Win=37696 Len=1248 TSval=45917153 TSecr=3850271695 [TCP segment of a reassembled PDU]" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TLSv1.2","509","Certificate" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5581 Win=0 Len=0" "188.220.232.134","10.180.101.189","TCP","68","56345 > 2083 [ACK] Seq=4335 Ack=5582 Win=37696 Len=0 TSval=45917158 TSecr=3850271729" "10.180.101.189","188.220.232.134","TCP","56","2083 > 56345 [RST] Seq=5582 Win=0 Len=0" Can see the server sending RST packets at the end. Thanks, Emile On Tue, Sep 14, 2021 at 5:41 PM Alan DeKok <aland@deployingradius.com> wrote:

On Sep 14, 2021, at 12:03 PM, Emile Swarts <emile.swarts123@gmail.com> wrote:

...

Thanks for that.

Had a look at the debug logs:

... (0) (TLS) Application data. (0) FAILED in TLS handshake receive

Hmm... that message means that FreeRADIUS is ready for application data (i.e. stuff inside of the radsec tunnel), but OpenSSL thinks that the TLS handshake isn't finished.

See src/main/tls_listen.c, the label "check_for_setup". It does:

* if SSL init is not done try to do more handshake if handshake data to send, then send that

* else there's no handshake data to send, then the SSL init MUST be done but OpenSSL says it's not... so who knows what's up :(

It's not clear what's going on here. Maybe some wireshark debugging of the TLS packets might help. But I haven't had any luck getting wireshark to decode TLS recently.

...

I've been unable to find much about the default security policies of Openssl / Alpine. Is this something I can update myself, that could potentially solve the problem?

See the link I posted... setting the cipher_list will over-ride the default security policies.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

No radsecproxy in this production setup, tested with 2 APs (Aruba 305 and Mist) establishing a connection directly to the server. When debugging this, we did run tests with eapol_test going through radsecproxy to the upgraded server running locally, and strangely this succeeded. I have switched the OS to the latest version of Ubuntu and this seems to work. The code is in version control and could craft a reproducible test case. On Thu, 16 Sep 2021 at 00:17, Alan DeKok <aland@deployingradius.com> wrote:

On Sep 15, 2021, at 7:32 AM, Emile Swarts <emile.swarts123@gmail.com> wrote:

...

Had a look at that C code, but understanding why it's not doing the right thing is a bit beyond me I'm afraid.

Looking at the C code won't help. The issue is inside of OpenSSL, and how we're using their (rather opaque) API.

...

I have a packet capture from the server as well:

Hmm... that's not really a packet capture. It's a CSV file with IP addresses as double quoted strings. :(

In order to track this down, it will be necessary to look into the TLS protocol internals. Looking at a high level of "IP 1 sent packet to IP 2" doesn't give enough information to find out what's going wrong.

Which version of radsecproxy are you using?

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Sep 17, 2021, at 5:46 AM, 老咪 via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

I download the newest code in github, master branch.After I fixed some small bugs, run the freeRadius  server 4.0 by radiusd -X It show like this:

We don't recommend that people run the "master" branch. It's still alpha, and hasn't had an official release. It may or may not work, depending on the day.

... ... Scheduler created in single-threaded mode #### Opening listener interfaces #### Ready to process requests Network - Failed adding new socket to network event loop: Failed inserting filters for FD 15: EFAULT: Bad address Network - Failed adding new socket to network event loop: Failed inserting filters for FD 16: EFAULT: Bad address Network - Failed adding new socket to network event loop: Failed inserting filters for FD 17: EFAULT: Bad address Network - Failed adding new socket to network event loop: Failed inserting filters for FD 18: EFAULT: Bad address

That's an error from libkeueue. You're probably running a very old version, because that's what most distributions ship. We've put a lot of fixes into libkqueue, and the latest version from GitHub should work a lot better. Alan DeKok.

Dear Alan, Thanks for your kindly remind. However, we need use EAP AKA authentication, but 3.X version don't support it, so I choose the master branch, I download the code in 2021/9/16. About the error from libkqueue, actually when I executed the configure command, it shows I need to install libkqueue first, but when I try to install libkqueue, it shows I&nbsp; need to install rpmlib(SetVersion) first, but I can't find the rpmlib(SetVersion) package in the internet. So I install the libkqueue 2.0.1 devel without rpmlib(SetVersion) by rpm -i --force --nodeps, I think this is the true cause. How can I find the&nbsp;rpmlib(SetVersion) package or code? could you help me, thank you very much. The installation info like this: [root@localhost ~]# rpm -qa|grep libkqueue libkqueue-2.0.1-alt5.x86_64 libkqueue-devel-2.0.1-alt5.x86_64 [root@localhost ~]# rpm -qa|grep rpmlib kobo-rpmlib-0.6.0-2.el7.noarch ------------------&nbsp;原始邮件&nbsp;------------------ 发件人:                                                                                                                        "Alan DeKok"                                                                                    <aland@deployingradius.com&gt;; 发送时间:&nbsp;2021年9月17日(星期五) 晚上7:47 收件人:&nbsp;"FreeRadius users mailing list"<freeradius-users@lists.freeradius.org&gt;; 抄送:&nbsp;"老咪"<93327349@qq.com&gt;; 主题:&nbsp;Re: The problem when I run freeRadius server 4.0 in master: Failed adding new socket to network event loop: Failed inserting filters for FD 15: EFAULT: Bad address On Sep 17, 2021, at 5:46 AM, 老咪 via Freeradius-Users <freeradius-users@lists.freeradius.org&gt; wrote: &gt; I download the newest code in github, master branch.After I fixed some small bugs, run the freeRadius&amp;nbsp; server 4.0 by radiusd -X &gt; It show like this: &nbsp; We don't recommend that people run the "master" branch.&nbsp;&nbsp; It's still alpha, and hasn't had an official release.&nbsp; It may or may not work, depending on the day. &gt; ... ... &gt; Scheduler created in single-threaded mode &gt; #### Opening listener interfaces #### &gt; Ready to process requests &gt; Network - Failed adding new socket to network event loop: Failed inserting filters for FD 15: EFAULT: Bad address &gt; Network - Failed adding new socket to network event loop: Failed inserting filters for FD 16: EFAULT: Bad address &gt; Network - Failed adding new socket to network event loop: Failed inserting filters for FD 17: EFAULT: Bad address &gt; Network - Failed adding new socket to network event loop: Failed inserting filters for FD 18: EFAULT: Bad address &nbsp; That's an error from libkeueue.&nbsp; You're probably running a very old version, because that's what most distributions ship.&nbsp; We've put a lot of fixes into libkqueue, and the latest version from GitHub should work a lot better. &nbsp; Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Sep 17, 2021, at 10:23 PM, 老咪 <93327349@qq.com> wrote:

However, we need use EAP AKA authentication, but 3.X version don't support it, so I choose the master branch, I download the code in 2021/9/16. About the error from libkqueue, actually when I executed the configure command, it shows I need to install libkqueue first, but when I try to install libkqueue, it shows I  need to install rpmlib(SetVersion) first, but I can't find the rpmlib(SetVersion) package in the internet. So I install the libkqueue 2.0.1 devel without rpmlib(SetVersion) by rpm -i --force --nodeps, I think this is the true cause.

How can I find the rpmlib(SetVersion) package or code? could you help me, thank you very much. The installation info like this:

I don't use RedHat or CentOS, so I can't help you find RPMs for those systems. CentOS 7 is very old, and is no longer getting updates. Why not use a more recent distribution? We do builds on recent distributions all of the time (Ubuntu 20, etc). They work just fine. But in the end, if the "master" branch doesn't work, then there isn't much we can do. It's unreleased, it's unsupported, and it's alpha. And we're very much not going to spend time debugging issues for a distribution which was first released in 2014. The master branch requires newer compilers, newer libraries, etc. Alan DeKok.

On Sep 18, 2021, at 10:13 AM, Noel Butler <noel.butler@ausics.net> wrote:

On 18/09/2021 22:40, Alan DeKok wrote:

...

CentOS 7 is very old, and is no longer getting updates.

centos 7 is getting updates, its 6.2 that recently stopped getting them, 7 will be supported for a few more years

OK. In any case... v4 is "use at your own risk" Alan DeKok.

Hi Alan, Thanks for your help, we solved the problem by update the libkquequ version to 2.4.0. Now I run the v4.0 like this, thank you very much. However, I can't find the way to use EAP MD5 or EAP AKA&nbsp; authentication, I modify the the conf files of the server, but it doesn't work. Could you please help to tell me how to configure it, thanks a lot. ------------------&nbsp;原始邮件&nbsp;------------------ 发件人:                                                                                                                        "FreeRadius users mailing list"                                                                                    <aland@deployingradius.com&gt;; 发送时间:&nbsp;2021年9月18日(星期六) 晚上10:26 收件人:&nbsp;"FreeRadius users mailing list"<freeradius-users@lists.freeradius.org&gt;; 主题:&nbsp;Re: reply: The problem when I run freeRadius server 4.0 in master: Failed adding new socket to network event loop: Failed inserting filters for FD 15: EFAULT: Bad address On Sep 18, 2021, at 10:13 AM, Noel Butler <noel.butler@ausics.net&gt; wrote: &gt; &gt; On 18/09/2021 22:40, Alan DeKok wrote: &gt; &gt;&gt; CentOS 7 is very old, and is no longer getting updates. &gt; &gt; centos 7 is getting updates, its 6.2 that recently stopped getting them, 7 will be supported for a few more years &nbsp; OK.&nbsp; In any case... v4 is "use at your own risk" &nbsp; Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Hi Alan,     thanks for your reply, I try to find the FAQ in the website https://wiki.freeradius.org/guide/FAQ, but I only find one part about stuff: Of course a Makefile is suited perfectly for this kind of stuff.      In fact, I read all the FAQ, but only a question about PAP and CHAP authentication, not EAP AKA authentication.      Could you please help to check it, thank you very much. ------------------ 原始邮件 ------------------ 发件人: "Alan DeKok" <aland@deployingradius.com>; 发送时间: 2021年9月22日(星期三) 晚上8:49 收件人: "FreeRadius users mailing list"<freeradius-users@lists.freeradius.org>; 抄送: "老咪"<93327349@qq.com>; 主题: Re: reply: The problem when I run freeRadius server 4.0 in master: Failed adding new socket to network event loop: Failed inserting filters for FD 15: EFAULT: Bad address On Sep 21, 2021, at 11:59 PM, 老咪 via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote: > Thanks for your help, we solved the problem by update the libkquequ version to 2.4.0. Now I run the v4.0 like this, thank you very much.   That's good. > However, I can't find the way to use EAP MD5 or EAP AKA&amp;nbsp; authentication, I modify the the conf files of the server, but it doesn't work. > Could you please help to tell me how to configure it, thanks a lot.   See the FAQ / Wiki for "I did stuff, and it doesn't work".   Alan DeKok.

On Sep 23, 2021, at 4:25 AM, 老咪 <93327349@qq.com> wrote:

Hi Alan, thanks for your reply, I try to find the FAQ in the website https://wiki.freeradius.org/guide/FAQ, but I only find one part about stuff: Of course a Makefile is suited perfectly for this kind of stuff. In fact, I read all the FAQ, but only a question about PAP and CHAP authentication, not EAP AKA authentication. Could you please help to check it, thank you very much.

Check what? What you're asking is this: "I made a bunch of changes and it didn't work. But I'm not gong to tell you what I changed. I'm not going to tell you what happened when I did the tests. But I want you to magically understand what the problem is, and tell me what to fix" It's impossible for us to help you with such a question. When you joined the list, you got a link to http://wiki.freeradius.org/list-help Please read it. Alan DeKok.

On Sep 24, 2021, at 6:03 AM, 老咪 <93327349@qq.com> wrote:

Hi Alan, Thanks for your reply. When will the 4.0 version to be released? Is it possible to release this year? Thank you

Probably not. We hope to have an alpha next year. Alan DeKok.

Hi Alan,     I add a module based freeRadius server 2.2.7, it's about the EAP_AKA authentication, now it workes well, thank you and your team very much.      I found that the default configure file of the module is radius.conf, I try to use sql.conf or other new configure file, but it didn't work.     I try to find the cause in the code, I found that all modules did use its own configure file, maily in /usr/local/etc/raddb/modules/, named by the module,  and /usr/local/etc/raddb/radiusd.conf is the default file,  It can be modified,  but until now I haven't found the accurate place.     Could you please tell me how to specify the configure file for a module, thank a lot.

On Nov 11, 2021, at 12:56 AM, 老咪 via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Hi Alan,     I add a module based freeRadius server 2.2.7, it's about the EAP_AKA authentication, now it workes well, thank you and your team very much. 

Version 2 is end of life. There are no more bug fixes, security fixes, or anything done to it.

    I found that the default configure file of the module is radius.conf, I try to use sql.conf or other new configure file, but it didn't work.     I try to find the cause in the code, I found that all modules did use its own configure file, maily in /usr/local/etc/raddb/modules/, named by the module,  and /usr/local/etc/raddb/radiusd.conf is the default file,  It can be modified,  but until now I haven't found the accurate place.     Could you please tell me how to specify the configure file for a module, thank a lot.

In the "modules" section. As with all versions of the server. Alan DeKok.