Captivo Portal changelog — 2026 · Page 5 of 12

Improvements

• The e-mail carrying WiFi details said "These details are valid for 120 minutes", but that number was the session length after connecting. A guest who used the password late found it no longer worked, well inside the time they had been given. The e-mail now states both durations separately: how soon the password must be used, and how long the guest stays online after connecting.
• On the message templates page, {duration} and {expiry} were listed on one line under a single description and read as two names for the same thing. They are now listed separately and named: one is the session length after connecting, the other is how long an unused password lasts.
• The "Credential validity duration" description in RADIUS settings did not describe what the setting actually does; it has been rewritten.

Fixes

• Portal login with a directory (AD/LDAP) account failed: even with the correct username and password the login was refused and the guest landed on the firewall's error page. The browser was blocking the verification request from the portal page, so it never reached Captivo; the typed details went straight to the firewall and were rejected there, without the directory server ever being asked. Verification now travels the same channel as SMS and e-mail. For this fix to take effect, the portal template must be downloaded again and uploaded to the firewall.

Fixes

• Devices that connect automatically by MAC address were missing from the "Recent Logins" list on the dashboard. No guest record is created for them, so the list never knew they had connected; they now appear with the name you gave them on the device list and the time they last connected.
• The dashboard's "Authentication Methods" chart left MAC devices out, and its percentages were calculated without them. They now have their own slice.

Fixes

• Filling in only the "Post-login redirect" address in portal settings raised a warning asking you to add that address to your access point's allowed list, and the warning spoke about terms and privacy pages you had never filled in. Guests follow the redirect after their connection is complete, with full internet access, so it needs no allowed-list entry. The warning now covers only the terms and privacy addresses, which guests do open before logging in.

New

• Devices that connect automatically by MAC address now show up as "MAC" in the panel. Active Sessions used to show just "—" in the method column: nobody types anything for these devices, so there was no name to show. The name you gave the device on the list ("Floor 3 Printer", "Lobby TV") now appears beside the session, and the method filter can show MAC devices on their own.
• The authentication method breakdown in Report Centre gained a "MAC (Device)" row. These devices were not counted at all, so printers, TVs and cameras were invisible in reports.
• 5651 identity resolution now answers with the device's name from the device list. A device removed from the list later can still be named for its past sessions.

Improvements

• The mobile app shows the same information for MAC-connected devices, and the device's MAC address in the username field is now masked there, as it is elsewhere.

Improvements

• The pfSense integration guide now covers setting up automatic MAC-address access, with a screenshot. This route lets you manage the device list from the Captivo panel and see those devices in Active Sessions and reports. The guide also names the three mistakes people actually make: leaving RADIUS MAC Secret empty (the firewall then never sends the request at all), not ticking Login page Fallback (a guest not on the list never sees the portal), and not uploading the error page.

Fixes

• With automatic MAC-address access enabled, guests whose device is not on the list landed on an error page that offered only a username and password box — no SMS, e-mail, sponsor or hotel tab. A guest who did not have a password yet could not register there and was stuck. The error page is now identical to the portal page and carries every sign-in method.
• The notice on that page always read "Username or password incorrect". A guest who arrives there because MAC access did not match has typed nothing at all. The wording now fits both cases.

Improvements

• The Log Server source list now shows the share of unrecognised lines for each device. The figure rises when a device sends logs in an unexpected format or a record type that is not supported yet; this was previously invisible.

Improvements

• Guest profiles can now be assigned to "Directory (AD/LDAP)" as well. Assign a profile to Directory and its session length, speed limit, idle timeout and simultaneous-device limit apply to users signing in with their domain account.

Fixes

• Copy buttons did not work when the panel was reached over an unencrypted (http://) address. The button responded to clicks but nothing happened and no warning appeared. Browsers grant clipboard access only on secure addresses, so on installations reached by IP every copy button failed silently — including the RADIUS shared secret in the setup wizard, the two-factor key and the recovery codes. They now work on any address.
• Users signing in with Active Directory / LDAP had no profile applied: no speed limit, no idle timeout and no simultaneous-device limit. The session length on the directory settings page keeps working; you can now assign a profile as well. When a profile is assigned the session length comes from it too, and the field now says so.

Fixes

• The "Hotel Guest Profile" and "VIP Guest Profile" settings on the Hotel PMS page were saved but never applied. Guests signing in through the PMS had no rule enforced beyond session length: no speed limit, no idle timeout and no simultaneous-device limit. The profile you choose is now applied, and VIP guests receive the VIP profile when one is set.
• The "Hotel PMS" option added to "Default Assignment" on the guest profiles screen in the previous release has been removed. The same setting was configurable in two places with no clear winner. The PMS profile is now chosen only under Settings → Hotel PMS, which is also the only place where the VIP distinction can be expressed.

Improvements

• Guest profiles can now be assigned to "Hotel PMS" as well. Assign a profile to Hotel PMS and its speed limit, idle timeout and simultaneous-device limit apply to guests who sign in through the hotel system. Behaviour is unchanged if no profile is assigned.

Fixes

• Guests signing in through the hotel PMS had no profile applied at all: no speed limit, no idle timeout and no simultaneous-device limit, so PMS guests used unlimited bandwidth. The profile you choose is now applied.
• Devices authenticated by MAC address never appeared under Active Sessions. The firewall reports these sessions without a user name, so the session could not be matched to a tenant; it is now matched on the device's MAC address instead. As no session record was kept, the traffic of these devices was missing from reports too.
• Removing a device from the MAC whitelist did not drop its open session; the restriction only took effect the next time the device reconnected. An administrator would remove the device and believe access had been cut while the device stayed online. Removal now ends the open session immediately.

Fixes

• The Identity Resolution query (used for identifying the responsible party under Turkish law 5651) found no match when the IP had been recorded with a network mask, as most access devices do. The record was found and then discarded, so the result was always "no matching session record found". The correct session is now found whichever way you type the IP.
• "Device and Operating System Distribution" in Advanced Analytics counted only guest and local-user logins; hotel PMS and voucher logins never appeared. The device card on the home page counted only guest logins. All four are now included. Because device details were never stored for those logins before, the distribution covers only logins made after this release.
• In the "Recent Logins" card on the dashboard, the "Online / Offline" label sat in the middle of the row whenever that row had quick-action buttons, while rows without them kept it on the right. The label is now aligned consistently on every row.

Improvements

• The directory (AD/LDAP) connection test now says which stage fails: the server name cannot be resolved, the port is closed, the connection opens but the server does not answer, or the server rejects unencrypted connections because it enforces signing. Each case comes with what to do about it.
• The default directory connection timeout was raised from 5 to 10 seconds. Domain controllers reached across a network routinely take longer than 5 seconds to send their first reply.

Fixes

• A healthy directory server that simply answered slowly was reported as "Cannot reach the directory server". Even when the timeout fell short by only a couple of seconds, the problem looked like a network fault and the administrator was told neither the real cause nor what value to enter. The server's response time is now measured and the value to use is suggested.
• The advice given when a server name cannot be resolved was wrong for installations using LDAPS: it suggested entering an IP address instead of the host name, but the certificate is issued to the host name, so validation against an IP fails. The message has been corrected.

Fixes

• With "Skip TLS verification" ticked, plain ldap:// addresses could not be connected to. Despite its name, that checkbox switched the connection into encrypted mode; as the domain controller does not speak TLS on port 389, the connection was left unanswered and timed out. It was hard to diagnose because network tests (is the port open) all looked fine.
• TLS settings now apply only to ldaps:// addresses. Installations using plain ldap:// connect normally even with the box ticked.

Improvements

• Directory (AD/LDAP) connection errors now say why. Previously a network problem, a wrong service password, an incorrect base DN and a timeout all appeared as "Cannot reach the directory server", sending the administrator to check the network when the problem was usually elsewhere.
• The new messages point at the right place: network unreachable, server did not answer in time, service account credentials rejected, base DN or user filter invalid.
• Connection attempts are now written to the server log in detail (error code and class). The bind DN and password are never logged.

Improvements

• The setup and MFA reminder cards on the dashboard now offer "Don't show again". The choice is saved to your account, so the card stays hidden whichever device or browser you sign in from.
• Closing with the X now hides the card for a day. Anyone who wants it gone for good can use "Don't show again" - both behaviours are deliberate.

Fixes

• The MFA reminder card came back on every page refresh after being closed; the dismissal was not stored anywhere.
• Dismissing the setup card was only remembered in the browser. The card returned on another device, in a private window, after clearing browser data, or when the panel was reached once by IP and once by hostname.

Improvements

• Audit records now have a retention period: entries older than 365 days are removed by the daily cleanup. Previously SMS and email records were cleaned after 180 days while audit records accumulated indefinitely. An audit record also holds the actor's IP and browser, so keeping it forever was not right. The period can be adjusted if needed.

Improvements

• The RADIUS server's timezone is now UTC in the image itself. The image previously shipped with a local timezone and correctness depended on a single line in the installation file; without that line credentials could be treated as expiring three hours early. Existing installations were already correct - this is hardening.

Fixes

• The "Session Duration" setting in Guest Profiles was not applied to guests signing in by SMS or email. Even with 2 hours in the profile, a guest stayed connected only as long as the "credential validity" in RADIUS settings (15 minutes by default). The setting was saved and displayed, but never reached the network device. Fixed - the profile value is now what applies.
• The problem was silent: sessions ended normally with "session timeout", and it was only visible by comparing against the number in the profile. Every sign-in path was affected, both through the portal and the external API (SMS, email verification, email credential delivery); a test now keeps all five wired to the same rule.
• The "use the password in the SMS within N minutes" rule still holds: unused credentials are cleaned up when the window passes. Used ones stay valid for the session, so a guest who loses connection can reconnect - which previously was not possible either.
• Vouchers and local users are unchanged: there the expiry date is a real end date and shortening the session is the correct behaviour.

Fixes

• On the Identity Resolution page (used to determine who was responsible under 5651), searching by IP found nothing. Firewalls report the IP address together with its network mask, while the page looked for exactly what you typed. As nearly all of our records carry the mask, the search always came back empty - as though the address had never been used. Fixed; searching by MAC already worked.
• The "Guest" column and filter in Log Server search were empty for the same reason. The link between a traffic record and the session owner could never be made because of the same masked-address problem. On pfSense and OPNsense that is the only available link, so the username never appeared there at all.
• In the same matching, the fallback path based on the device MAC ignored time: a device's older traffic could be attributed to whoever used that device most recently. Only the session covering the moment of the event is matched now. Leaving it blank is better than naming the wrong person.
• MAC addresses can be stored with mixed upper and lower case; matching now takes that into account.
• Error messages on the Identity Resolution page now follow the panel language.

Improvements

• Device guides are now named "… Integration" instead of "… Setup" (pfSense, OPNsense, MikroTik, FortiGate, Cisco Meraki, Ruijie, UniFi). The old name suggested you were installing the device itself.
• The pfSense guide now covers the setting speed limits actually depend on: "Enable per-user bandwidth restriction" on the Configuration tab. With that box unticked the speed limit in a Captivo profile is not applied, and nothing tells you so.
• The pfSense guide's step order now follows the pfSense interface. Uploading the portal page was left to the end, although that field sits higher up the page and the reader had to return to a page they had already saved. The zone page is now filled in a single pass, top to bottom.
• A live-session warning was added to the OPNsense, FortiGate, Cisco Meraki and Ruijie guides: even with RADIUS accounting enabled, a device that sends no periodic updates makes a session drop off the Active Sessions list while the guest is still online. This was documented nowhere until now.
• The UniFi guide now states plainly that this integration produces no session data. The UniFi connection works through the controller API; Active Sessions stays empty and duration/usage figures are not produced. Guest records and the portal work normally.
• In the FortiGate, Meraki and Ruijie guides, registering the device in Captivo moved to the first step. It used to be last, so the steps in between configured a device that could not accept any login yet.

Improvements

• Under the dashboard's "Recent Logins" card, every kind of record actually present in the list is now offered as a link. If the card holds both guest and voucher logins, you get both "Guests" and "Vouchers"; previously it always went to the guest list, where the voucher rows are not found. With a single kind, nothing changed.

Fixes

• Firewall records were still not being parsed for businesses whose pfSense is set to send logs in the "syslog (RFC 5424)" format. In that format the program name arrives as a header field rather than inside the message, and the system was not reading it. All three of pfSense's log formats are now supported; which one you choose no longer changes the result.
• The same problem affected other device types: on a device sending RFC 5424, technical header remnants were left at the front of the record text, making it harder to recognise. This is fixed too.
• Past records left unparsed because of this are reprocessed automatically during the update and become searchable.

Improvements

• The "Recent Activity" list became able to grow in the previous release, but it then ran taller than the "Recent Logins" card beside it, moving the empty space to the left. The list now has a lower and an upper bound: it is not cramped when the neighbouring card is short, and it no longer stretches the card when there are many records.
• The heading now states how many events are shown ("last 30 events"), so the end of the list is not mistaken for missing data.

Improvements

• The "Recent Activity" list on the dashboard now grows with the height of its card. It used to be squeezed into a fixed box, leaving a large empty area below it; it now shows as many records as the space allows.

Fixes

• The link under the dashboard's "Recent Logins" card led to an empty page. The card shows four kinds of login together (guest, local user, voucher, hotel/room), but the link always went to the guest list. In a business using only the hotel PMS the card was full while the page said "No guests yet"; the same happened for businesses using only vouchers or only local users. The link now goes to the right page for the kind of records listed, and its label changes to match.

Improvements

• The pfSense Setup guide has been rewritten from scratch with screenshots. It walks through the current pfSense interface step by step: defining the RADIUS server, the portal zone, authentication, accounting, the walled garden and uploading the portal page. Every step has a screenshot taken from a working installation.
• The guide had been describing pfSense's older (2.4/2.5) interface; instructions such as "Authentication Method: select RADIUS Authentication" referred to steps that no longer exist, which made it impossible to follow.
• Documented why the Active Sessions list stays empty: unless "Send accounting updates" is set to Interim, the firewall reports only the start and end of a session and a guest who is still online drops off the list. The guide previously recommended Stop/start for this setting.
• The route to take on pfSense for devices that must skip the portal (printers, smart TVs, payment terminals) is now spelled out, along with why the Captivo MAC Whitelist does not apply in that scenario.
• The troubleshooting section was rewritten around real failure modes: empty session list, download/upload appearing swapped, logins always failing, SMS codes not arriving, speed limits not applied.
• The guide is bilingual: Turkish and English.

Improvements

• Added a "Data counters" section to the pfSense Setup guide. With its default setting pfSense reports download and upload the other way round, so on the Sessions page a guest appeared to have uploaded far more than they downloaded. One setting in the guide fixes it. MikroTik and other devices are unaffected.

Fixes

• Records from pfSense/OPNsense firewalls were never parsed in the Log Server. Lines were received, stored and signed, but no event was produced, so search, reports and SIEM forwarding stayed empty for that device. The cause was the process id the device adds to its log tag. Fixed.
• pfSense records received in the past are re-parsed automatically during the update - your older records become searchable.
• The "Parsed" column in the raw records list showed "Yes" even for lines that produced no event. It now tells the truth: "Yes" if the line became an event, "No" if it did not.