Recent posts

#1
26.7 Series / Re: Is the Release IP Button M...
Last post by franco - Today at 06:07:24 PM
Quote from: darkarn on Today at 05:07:44 PMThanks, this seems clearer. Strange part is that I seem to be able to get a new public IP easily in pfSense but not here.

Behind the same modem? Classic case of preferring the old MAC address perhaps?


Cheers,
Franco
#2
26.7 Series / Re: Is the Release IP Button M...
Last post by Monviech (Cedrik) - Today at 05:39:20 PM
The release comes from the DHCP client.

E.g. the OpenBSD one seems to support it: (-r)
https://man.openbsd.org/OpenBSD-7.2/dhclient.8

But the FreeBSD one doesn't as shown in the other MAN page.

I don't know out of my head how to see the lease time on the client right now, probably in some file that dhclient owns or via some command, check the man page.
#3
26.7 Series / Re: Is the Release IP Button M...
Last post by darkarn - Today at 05:28:00 PM
Thanks, is there a way to see the lease time and also from which client does the DHCP RELEASE packet has to come from?
#4
26.7 Series / Re: Is the Release IP Button M...
Last post by Monviech (Cedrik) - Today at 05:16:04 PM
No, to get the chance to receive a new IP, either the lease time of the lease has to expire, or a DHCP RELEASE packet must be sent by the client.

I explicitely say "chance" since the DHCP server can still OFFER the old IP again.
#5
26.7 Series / Re: Is the Release IP Button M...
Last post by darkarn - Today at 05:07:44 PM
Thanks, this seems clearer. Strange part is that I seem to be able to get a new public IP easily in pfSense but not here.

Just really unsure if I am misunderstanding something though

If I really need to change public IP, will disabling the WAN interface (mentioned in linked thread) + waiting for a few mins + renabling it still work?

Also, what's the exact use of the Refresh button?
#6
26.7 Series / Re: Is the Release IP Button M...
Last post by Monviech (Cedrik) - Today at 05:01:53 PM
fyi the dhclient cannot send a DHCP RELEASE packet.

https://man.freebsd.org/cgi/man.cgi?dhclient
#7
26.7 Series / Re: Is the Release IP Button M...
Last post by meyergru - Today at 05:00:09 PM
It depends solely on your ISP if your actual IP changes upon reconnect - there is no way to force this from the client side. You should be able to see that the connection is coming down an up again in the logs, though.
#8
26.7 Series / Re: Is the Release IP Button M...
Last post by darkarn - Today at 04:58:44 PM
Quote from: meyergru on Today at 04:25:29 PMIn your first linked thread, Patrick even showed the screen shot and explained wher to find it.

Ah no wonder, I was browsing the forum without logging in and couldn't see that screenshot

Just to be very clear, as of 26.7, is the reload button also the release button (i.e. I should be seeing only one such button) + that button is supposed to help change/public IP?

Am asking cos I been clicking on that a few times and nothing seems to have changed
#9
Heads up that Mono's update server is down for everyone, not just me.

opnsense.mono.si accepts TCP on 443 but answers every ClientHello with a fatal
TLS alert 80 (internal_error) before ServerHello — no certificate is ever
presented. Port 80 is fine and returns 308 -> https with "Server: Caddy", so the
web server is up and only TLS termination is broken.

# openssl s_client -connect opnsense.mono.si:443 -servername opnsense.mono.si </dev/null
...tlsv1 alert internal error...SSL alert number 80
---
no peer certificate available
---
SSL handshake has read 7 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)

Effect on a Gateway DK running 26.1.10 (aarch64): the changelog fetch fails with
"Authentication error" and both the OPNsense and MonoGateway repo catalogues fail
with "An error occurred while fetching package: No error" (that string just means
no HTTP status was ever received - it died in TLS), so no updates at all.

Not client-specific: reproduced from FreeBSD 14/OpenSSL, macOS/LibreSSL, Chromium
and Python/OpenSSL, and an SSL Labs scan reports "No certificates found" with zero
supported protocols. IPv6 (2a01:4f8:1c1a:6d1c::1) is unreachable too.

First confirmed 2026-09-07 02:53 UTC in we-are-mono/docs issue #20, still failing
now. There's no user-side workaround - http:// just 308s back into the broken
listener, and no other mirror carries the mono flavour.

Maurice, since you maintain the Mono update server: could you take a look at the
Caddy cert / ACME state for that host?