starred/uspot
1
0
Fork 0
mirror of https://github.com/f00b4r0/uspot.git synced 2026-04-25 22:25:51 +03:00
Code Issues 6 Projects Releases Packages Wiki Activity

[GH-ISSUE #42] Accounting-On request may not be delivered at first boot #26

New issue
Open
opened 2026-03-04 14:52:28 +03:00 by kerem · 6 comments
kerem commented 2026-03-04 14:52:28 +03:00
Owner
Copy link

Originally created by @nemesifier on GitHub (Sep 2, 2025).
Original GitHub issue: https://github.com/f00b4r0/uspot/issues/42

Originally assigned to: @f00b4r0 on GitHub.

Describe the bug
While dealing with fixing stale RADIUS accounting sessions due to unexpected cold reboots (eg: power loss), I noticed freeradius provides a solution which listens on Accounting-On RADIUS packets to close any open previous session for the same NAS, so I started playing with it.

Unfortunately I noticed that uspot tries to perform the accounting-on request early in the boot process while DNS is not yet ready and hence the accounting-on request is not delivered to the server.

I am going to use a hacky workaround in rc.local for this, but I thought it may be a good idea to open an issue on github and look for a more robust generic solution in the long run.

To Reproduce
Steps to reproduce the behavior:

  1. Boot
  2. Run RADIUS server in debug mode to wait for Accounting-On
  3. Accounting-On is not received.

Expected behavior
Accounting-On should be received by the RADIUS server.

Logs

Tue Sep  2 00:17:06 2025 kern.warn kernel: [   15.865482] uspot.uc[4176]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
Tue Sep  2 00:17:11 2025 daemon.err uspot-radius[4580]: radcli: init_session: init_session: cannot resolve [wifi.openwisp.io](http://wifi.openwisp.io/)
Tue Sep  2 00:17:11 2025 daemon.crit uspot-radius[4580]: radcli: rc_apply_config: error initializing tls
Tue Sep  2 00:17:11 2025 daemon.err uspot-radius: Failed to apply radcli config!
Tue Sep  2 00:17:11 2025 daemon.debug uspot: captive acct-on call

Additional context
I am not sure if this happens in all setups or only in my setup.

Originally created by @nemesifier on GitHub (Sep 2, 2025). Original GitHub issue: https://github.com/f00b4r0/uspot/issues/42 Originally assigned to: @f00b4r0 on GitHub. **Describe the bug** While dealing with fixing stale RADIUS accounting sessions due to unexpected cold reboots (eg: power loss), I noticed freeradius provides a solution which listens on Accounting-On RADIUS packets to close any open previous session for the same NAS, so I started playing with it. Unfortunately I noticed that uspot tries to perform the accounting-on request early in the boot process while DNS is not yet ready and hence the accounting-on request is not delivered to the server. I am going to use a hacky workaround in rc.local for this, but I thought it may be a good idea to open an issue on github and look for a more robust generic solution in the long run. **To Reproduce** Steps to reproduce the behavior: 1. Boot 2. Run RADIUS server in debug mode to wait for Accounting-On 3. Accounting-On is not received. **Expected behavior** Accounting-On should be received by the RADIUS server. **Logs** ``` Tue Sep 2 00:17:06 2025 kern.warn kernel: [ 15.865482] uspot.uc[4176]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set Tue Sep 2 00:17:11 2025 daemon.err uspot-radius[4580]: radcli: init_session: init_session: cannot resolve [wifi.openwisp.io](http://wifi.openwisp.io/) Tue Sep 2 00:17:11 2025 daemon.crit uspot-radius[4580]: radcli: rc_apply_config: error initializing tls Tue Sep 2 00:17:11 2025 daemon.err uspot-radius: Failed to apply radcli config! Tue Sep 2 00:17:11 2025 daemon.debug uspot: captive acct-on call ``` **Additional context** I am not sure if this happens in all setups or only in my setup.
kerem commented 2026-03-04 14:52:29 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Sep 2, 2025):

ACK. The init script should wait for wan to be up before uspot is started. Will fix.

<!-- gh-comment-id:3246282643 --> @f00b4r0 commented on GitHub (Sep 2, 2025): ACK. The init script should wait for wan to be up before uspot is started. Will fix.
kerem commented 2026-03-04 14:52:29 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Sep 15, 2025):

OK so I took another look at this and I don't understand what's going on.

uspot already starts at order 80, which is among the very last things to start. dnsmasq starts at 19 and network at 20, so I'm not sure how uspot could be started before DNS is ready. I never saw such a problem on the hundreds of instances currently deployed either, hence my confusion.

Can you shed more light on your setup?

<!-- gh-comment-id:3293444398 --> @f00b4r0 commented on GitHub (Sep 15, 2025): OK so I took another look at this and I don't understand what's going on. uspot already starts at order 80, which is among the very last things to start. dnsmasq starts at 19 and network at 20, so I'm not sure how uspot could be started *before* DNS is ready. I never saw such a problem on the hundreds of instances currently deployed either, hence my confusion. Can you shed more light on your setup?
kerem commented 2026-03-04 14:52:29 +03:00
Author
Owner
Copy link

@nemesifier commented on GitHub (Sep 15, 2025):

The config is the same of the one I shared for #45. Let me know if I can provide more info.

<!-- gh-comment-id:3293663875 --> @nemesifier commented on GitHub (Sep 15, 2025): The config is the same of the one I shared for #45. Let me know if I can provide more info.
kerem commented 2026-03-04 14:52:30 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Sep 15, 2025):

I see you have 2 WAN interfaces, is it possible that you have a particular setup that delays the availability of name resolution?
Can you provide full log context around the init lines (so I can see the sequence of other system events)?

<!-- gh-comment-id:3294189131 --> @f00b4r0 commented on GitHub (Sep 15, 2025): I see you have 2 WAN interfaces, is it possible that you have a particular setup that delays the availability of name resolution? Can you provide full log context around the init lines (so I can see the sequence of other system events)?
kerem commented 2026-03-04 14:52:30 +03:00
Author
Owner
Copy link

@nemesifier commented on GitHub (Sep 18, 2025):

You mean to send you the whole logread output since boot?

<!-- gh-comment-id:3307755335 --> @nemesifier commented on GitHub (Sep 18, 2025): You mean to send you the whole `logread` output since boot?
kerem commented 2026-03-04 14:52:30 +03:00
Author
Owner
Copy link

@f00b4r0 commented on GitHub (Sep 18, 2025):

Yes, then I can see the sequencing of startup events. Thanks

<!-- gh-comment-id:3308309033 --> @f00b4r0 commented on GitHub (Sep 18, 2025): Yes, then I can see the sequencing of startup events. Thanks
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
next
TIP
No results found.
Labels
Clear labels   
bug

   
enhancement

   
invalid

   
invalid

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
bug
enhancement
invalid
invalid
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uspot#26
No description provided.