Messages

I cited "Reporting: Health" and "Reporting: Unbound DNS" as examples of good usability. I don't necessarily look for consistency.

I think it is appropriate to regard functions that operate temporarily such as "DNS Lookup" and "Trace Route" as diagnostic functions. And regarding the diagnostic function, I think it makes sense to display "Settings" first.

However, since "Automatic Discovery" is a function that operates continuously, wouldn't it be appropriate to regard it as a reporting function? And regarding the reporting function, I think it is appropriate to display the report results first from a usability perspective.

Hi everyone

In "Interfaces: Neighbors: Automatic Discovery," the Settings tab is located in the first tab position (the most left tab), while the Discovered Hosts tab is located in the last tab position (the most right one). With this order, the Discovered Hosts is not displayed first when a menu item is selected.

Is this the intended order?

In "Reporting: Health" and "Reporting: Unbound DNS", the main information tab is located in the first tab position, while Settings tab is located in the last tab position. With this order, the main information is displayed first when a menu item is selected.

I think this is the natural order.

In case you want to try it: opnsense-core -a sopex 5bfd77c

You cannot view this attachment.

Cache is back!

Thanks.

I am running UFS.

It appears that the "cache" metric no longer exists in the memory line of the top command. "Laundry" exists in place of "cache," and it shows a non-zero value.

If the "System memory" in "Reporting Health" follows the memory metrics used by the top command, I believe it would be better to eliminate "cache" and introduce "laundry."

Is it not possible to change the cache display, given the need to maintain compatibility with past data?

Hi everyone

System memory cache in "Reporting Health" is always zero.

You cannot view this attachment.

Should the graph show "laundry" instead of "cache"?
Is the graph always zero because it doesn't reflect the value of "laundry"?

I confirmed the change in 26.7-RC2.

Thanks.

Hi everyone

"Reporting Health" page feels cluttered.

Just like the "Reporting Unbound DNS" page, wouldn't the layout look cleaner if the following settings were separated from the graphs using tabs?

You cannot view this attachment.

I noticed that flat lines are not displayed in zoomed graph.

You cannot view this attachment.

It seems better to hide flat lines rather than displaying zero-value lines.

Hi everyone

Prior to 26.1.8_5, the value of Collected Reports was zero in the power-off time Health graphs. However, in 26.1.9, in the power-off time Health graphs, the value of Collected Reports is constant but not zero.

The following is an example of a Health graph for Quality, but the phenomenon is similar for other categories. Power-off time is from around 7:00 to around 18:00.

You cannot view this attachment.

But I'm not sure where the issue is since you haven't published your MTU settings (both interface and PPP device).

MTU settings for both interface and PPP device are blank.

MPD5 version for both OPNsense 23.7.2 and OPNsense 23.7.3 is 5.9_16. Also, MPD5 has not been reinstalled on OPNsense 23.7.3. However, results of automatic MTU setting are clearly different between OPNsense 23.7.2 and OPNsense 23.7.3.

Since the results of the automatic MTU setting are different even though there is no change in MPD5, I don't think it's an MPD5 issue.

I noticed that the behavior of MTU settings for PPP devices is significantly different between OPNsense 23.7.2 and OPNsense 23.7.3.

[OPNsense23.7.2]
MTU setting for PPP devices in OPNsense 23.7.2 respects the result of LCP negotiation.

• If I set a value larger than 1454, that is not reflected in the actual MTU.
• If I set a value smaller than 1454, that is reflected in the actual MTU.
• If I set it to 1492, the actual MTU remains at 1454.

[OPNsense23.7.3]
MTU setting for PPP devices in OPNsense 23.7.3 ignores the result of LCP negotiation.

• If I set a value larger than 1454, that is reflected in the actual MTU.
• If I set a value smaller than 1454, that is reflected in the actual MTU.
• If I set it to 1492, the actual MTU is 1492.

OPNsense may be implemented in such a way that if the MTU setting is blank, it assumes that 1492 is set. If this assumption is correct, the results of the automatic MTU setting in OPNsense 23.7.2 and OPNsense 23.7.3 will be consistent with the expected MTU.

I am concerned about the statement in the MTU setting help that says "MTU will default to 1492".

[1454]

I tested with an older OPNsense and confirmed that OPNsense 23.7.2 sets the MTU to 1454, and that OPNsense 23.7.3 sets the MTU to 1492.

Updating from OPNsense 23.7.2 to OPNsense 23.7.3 did not require a reboot, and the MTU was 1454 after the update. After that, the MTU was 1492 after PPPoE session reconnection the by reload or reboot.

This regression may be due to the "interfaces: further improve PPP MTU handling" in the OPNsense 23.7.3 release announcement.

Today introduces a change in MTU handling for parent interfaces mostly noticed by PPPoE use where the respective MTU values need to fit the parent plus the additional header of the VLAN or PPPoE.  Should the MTU already be misconfigured to a smaller value it will be used as configured so check your configuration and clear the MTU value if you want the system to decide about the effective parent MTU size.

I found the above description of the parent interfaces MTU handling changes related to PPPoE in the OPNsense 23.7.5 release announcement.

Is the reason why the MTU is set to 1492 because the manual MTU setting in the Generic configuration takes precedence over the automatic MTU setting by LCP negotiation? (When the MTU setting is blank, "Calculated PPP MTU: 1492" will be displayed.)

[1454]

My ISP uses a PPPoE line with separate PPPoE sessions for IPv4 and IPv6. Since the username for IPv4 and the username for IPv6 are different, IPv4 and IPv6 cannot be shared in a single PPPoE session.

Configuration for IPv4 is standard "IPv4 over PPPoE", and configuration for IPv6 is "DHCPv6-PD over PPPoE". Both IPv4 and IPv6 work fine.

MRU of PPPoE server is 1454. PPPoE server performs "LCP negotiation" with MRU=1454 option, and OPNsense accepts MRU=1454. However, OPNsense sets MTU to 1492 instead of 1454. Normally, if OPNsense accepts MRU=1454 of PPPoE server in LCP negotiation, OPNsense should set MTU to 1454 or less, but this is not actually the case.


I checked the MTU with the following combinations (a) to (f).

The former value is the MTU after Bootup, and the latter value is the MTU after reload. Reload means clicking the "Reload icon" in the Commands column of the Interfaces Overview.

[One PPPoE session]
After bootup, both IPv4 and IPv6 have MTU=1492. After reload, IPv4 has MTU=1492.

(a) WAN  - pppoe0 - IPv4: 1492 / 1492

(b) WAN  - pppoe0 - IPv6: 1492 / N/A

[Two PPPoE sessions]
After bootup, both IPv4 and IPv6 have MTU=1492. After reload, IPv4 has MTU=1492 and IPv6 has MTU=1454.
For IPv4 and IPv6 combinations, when I check the logs, the PPPoE process always occurs in the order IPv4 first and IPv6 second.

(c) WAN  - pppoe0 - IPv4: 1492 / 1492
    OPT1 - pppoe1 - IPv6: 1492 / 1454

(d) WAN  - pppoe1 - IPv6: 1492 / 1454
    OPT1 - pppoe0 - IPv4: 1492 / 1492

(e) WAN  - pppoe1 - IPv4: 1492 / 1492
    OPT1 - pppoe0 - IPv6: 1492 / 1454

(f) WAN  - pppoe0 - IPv6: 1492 / 1454
    OPT1 - pppoe1 - IPv4: 1492 / 1492


From the results of (a) to (f), it appears that after reload, the first PPPoE process will result in MTU=1492, and the second PPPoE process will result in MTU=1454.

I check MTU on OPNsense with:

• ifconfig output
• Interface Overview Details
• Routes Status

I set MTU to blank in Generic configuration of Interfaces for OPNsense.

Below is the LCP negotiation log:

[wan_link0]   MAGICNUM 0x5848d693
[wan_link0]   AUTHPROTO CHAP MD5
[wan_link0]   MRU 1454
[wan_link0] LCP: SendConfigAck #1
[wan_link0]   MAGICNUM 0x5848d693
[wan_link0]   AUTHPROTO CHAP MD5
[wan_link0]   MRU 1454
[wan_link0] LCP: rec'd Configure Request #1 (Req-Sent)

[opt1_link0]   MAGICNUM 0x43d4f057
[opt1_link0]   AUTHPROTO CHAP MD5
[opt1_link0]   MRU 1454
[opt1_link0] LCP: SendConfigAck #1
[opt1_link0]   MAGICNUM 0x43d4f057
[opt1_link0]   AUTHPROTO CHAP MD5
[opt1_link0]   MRU 1454
[opt1_link0] LCP: rec'd Configure Request #1 (Req-Sent)