I fixed that yesterday.

I opened a ticket for the jquery one: https://redmine.pfsense.org/issues/5867

I am using it as an OPT1 (additional LAN) interface with a single wireless AP plugged into it through a POE injector, no switch.  The IPv4 of the interface is static with DHCP on the subnet.  IPv6 tracks the WAN interface and gets an additional /64 from the delegated /60.  Not bridged in any way.

@Asterix:

OK got IPv6 lookup after static assignment.

Found a couple of issues with static DHCPv6 assignment process.

1. Since I didn't have an easy way to find the DUID for the host I need IPV6 on, I picked up the one assigned thru DHCPv6. I picked the host from the DHCPv6 leases status and click on + add static mapping on the right. It picked up the DUID from it and I assigned my desired info. The moment I hit save, it creates the static mapping but then disables the DHCPv6 Server/RA on that interface. I have to click enable and re-assign the range. And yes, the static mapping was outside of the DHCPv6 range beforehand.

2. The DHCPv6 static mapping list in the Server/RA page is not sorted based on the IPv6 assignment but sorted on the last added static host. So whichever is the last added host, it's on top of the list.

Can anyone confirm this DHCPv6 behaviour?

This suggests that there is some value in being able to configure a gateway monitor IP of 'nth hop to a given IP address', with the actual IPv4/IPv6 address to monitor on the interface being determined after interface creation and again after every link down to link up transition. This approach is necessarily imperfect, as routing can change dynamically, but it would be more foolproof than periodic manual redetermination of the monitor address.

I can't monitor my ISP's IPv6 gateway address because it doesn't respond to ICMPv6 echo requests. In scenarios like this, I look for a recursive DNS server that is topologically close to the gateway and monitor that instead. DNS servers are unlikely to change address because the address will be 'baked in' to so many configurations.

Ironically, this approach means that I land up monitoring the IPv6 address of another ISP's DNS server. My connection terminates on my ISP's London gateways, but my ISP's DNS servers are all in Rochdale, around 200 miles from London.

@phil.davis:

The bit that had me confused was:

Submitted as a 10.1-release bugfix, will they merge it to 10.3 when it comes out? (and 10.2)?

It surprised me that this would be something to go in the 10.1 branch - I would have expected it to go in 11-CURRENT and then back-port to the 10-STABLE branch so it could appear in whatever 10.* it manged to get into - as David_W has explained.

I was confused as to where to actually submit it, I patched it on 10.1 code - now it's been made clear I should submit it against SVN / Head if I actually want it to be accepted.

@a_wein:

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

I submitted my own bug report also under puma as it is the chip family, again .. easily fixed .. I can even put the tablet code in if need be.

@David_W:

@a_wein:

Actually - there is already a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202629

That's a good start. It would help if someone checked out FreeBSD head, applied the patch, built and tested the resulting code, then submitted the patch (svn diff preferred) to the bug, noting the details of the board that it fixes. The more work that is done for a committer, the more likely the fix is to be committed.

I will do this tonight or tomorrow depending on the free time I get.

Thanks for pointing a few things out, I've had little to do with coding experience and even less with actually submitting something to an open source project (then again the patch isn't much, it's only a couple of id's).

Initially I only posted here to help the community and those who wanted to patch their temps because these things run hot and I know when my room where the apu sits gets up to 40c + in the day it's nice to know what temp it's running at. Thanks.

known open issue.
https://redmine.pfsense.org/issues/5453

That wouldn't be specific to 2.3 then, you might have better luck posting that on the Proxy board.

This issue is known to many of us. There is not currently a known solution.

Nice. Caught 2 bugs this week which were rectified.

I should be knighted… lol  ;)

All hail Sir Asterix !!!    ;D ;D

Think this may have been inadvertently resolved.

I believe the horizontal scroll bar on the empty table may have been due to no table rows (tr).  Seen the same behavior while doing some work on firewall status logs and wizard.

Went back to the firewall rules to check but there is now a message being displayed when there rules list is empty so the table is no longer really empty (row-less).

You're welcome.

Phil,
The start and end columns could be used for the description so long as it's 2 actual columns (no colspan attribute).  The second column being empty is all it takes.

The caveats I see with that approach are:

The column title "Start" becomes a little confusing when there are descriptions in there instead of times. Sorting.  Depending on the contents of the start column the descriptions could be interspersed or at top/bottom.

Another possibility may be to put the description on a second line.  Like one of the options in firewall rules for displaying rule descriptions.

Yet another option may be to have a separate collapsible panels for static lease and other types.

Just updated and saw 4.2 being uninstalled and new 4.3 package added to pfSense.

Did you receive it ok?

@yon:

where find the  RFC 2136 to the Dynamic DNS?  I have not find it in services_dyndns_edit.php

services_rfc2136.php
services_rfc2136_edit.php

On the UI for Dynamic DNS there is a tab for RFC2136.

Thanks for your fast work.

Idle situation (no login on GUI), putty to pfSense

CLI: sysctl -a | grep "freq:"
dev.cpu.0.freq: 1600

After GUI login (even after a while):
dev.cpu.0.freq: 3101

So it seems the GUI causes the CPU to max frequency

Hmm, well unless you had them in at a point before you upgrade to a snap with this code it's not as useful to know, since it's not clear if the issue was already there.