Messages

Reported an issue upstream: https://github.com/opnsense/core/issues/8671

The 'infinite' lease time is an acceptable vale for dhcp-range and dhcp-host options in dnsmasq, however, it is not possible to configure that via the UI.

Is this something that is intentional or just some temporary limitation?

https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

BTW, I switched to DnsMasq for DHCP by stopping the ISC and adding ranges to DnsMasq config, but I cannot actually have ISC disabled (to avoid it starting on boot again), because ticking the "Enable DHCP server on the LAN interface" checkbox does nothing, as in the "Apply" button does not show up.

EDIT: nevermind, the ISC configuration page actually somehow has "Save" button on the bottom for any changes, a blast from the past.

I wrote a script to convert the ISC mappings to DnsMasq CSV file, hopefully someone finds that useful:

https://gist.github.com/wrobelda/403fe4e7ff542ce14a4bba9a06e40777

Is there gonna be a migration path? Say, for the static mappings at least? Or is there maybe some script already?

This is pretty nice work. I have no use for it but thanks for sharing @wrobelda.

Thanks, hopefully this will be of help for someone, given how many people appear to have struggled with a similar issue.

For the record, I managed to get my modem working in NCM CDC mode by issuing USB control message to initialize it. I explained the process here: https://forum.opnsense.org/index.php?topic=46335.0

I was struggling with getting Huawei E3131 modem initialize under FreeBSD/OPNSense in CDC ECM mode, even though it worked out-of-the-box with Linux and NetworkManager. What NetworkManager actually does is and equivalent of a simple:

Code Select Expand

echo -e 'AT^NDISDUP=1,1\r' > /dev/cdc-wdm0
sent to the WDM device CDC WDM control interface. Sending this to any of the serial diagnostic or PPP serial ports would *not* work, it has to be sent to WDM interface explicitly.

Unfortunately, FreeBSD/OPNSense does not have module for WDM and as such doesn't expose the cdc-wdm character device like Linux. The workaround here was using usbcontrol to send the USB control message directly to the device, like so:

Code Select Expand

usbconfig -d 8.2 -i 0 do_request 0x21 0 0 2 16 0x41 0x54 0x5e 0x4e 0x44 0x49 0x53 0x44 0x55 0x50 0x3d 0x31 0x2c 0x31 0x0d 0x0a
REQUEST = <OK>
Where,

Code Select Expand

-d 8.2 -i 0 do_request 0x21 0 0 2 16 instructs usbconfig to send a control message of length 0x16 to device at bus 8.2, while the

Code Select Expand

0x41 0x54 0x5e 0x4e 0x44 0x49 0x53 0x44 0x55 0x50 0x3d 0x31 0x2c 0x31 0x0d 0x0a is the byte-encoded "AT^NDISDUP=1,1\r\n" message.

I explained my findings in details in an article here, hopefully this will help others having similar issue:
https://dawidwrobel.com/journal/initializing-lte-modem-using-raw-usb-communication/

So, digging further, I run the mpd command in the foreground:

Code Select Expand

root@gw:/var/etc # /usr/local/sbin/mpd5 -d /var/etc -f mpd_opt2.conf -p /var/run/ppp_opt2.pid -s ppp pppclient
And see the following:

Code Select Expand

EVENT: Registering event EVENT_TIMEOUT ChatTimeout() at chat.c:971
EVENT: Registering event EVENT_TIMEOUT ChatTimeout() done at chat.c:971
EVENT: Registering event EVENT_READ ChatRead() at chat.c:584
EVENT: Registering event EVENT_READ ChatRead() done at chat.c:584
EVENT: Processing event EVENT_READ ChatRead() done
EVENT: Processing event EVENT_READ ChatRead()
EVENT: Registering event EVENT_READ ChatRead() at chat.c:480
EVENT: Registering event EVENT_READ ChatRead() done at chat.c:480
EVENT: Processing event EVENT_READ ChatRead() done
EVENT: Processing event EVENT_READ ChatRead()
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  41 54 49 0d 0d                                   ATI..
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 4d 61 6e 75 66 61 63 74 75 72 65 72 3a 20 68  .Manufacturer: h
[opt2_link0] CHAT:  75 61 77 65 69 0d                                uawei.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 4d 6f 64 65 6c 3a 20 45 33 31 33 31 0d        .Model: E3131.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 52 65 76 69 73 69 6f 6e 3a 20 32 31 2e 31 35  .Revision: 21.15
[opt2_link0] CHAT:  38 2e 30 30 2e 30 30 2e 31 30 32 30 0d           8.00.00.1020.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 49 4d 45 49 3a 20 38 36 33 36 32 35 30 32 34  .IMEI: 863625024
[opt2_link0] CHAT:  31 33 37 31 36 38 0d                             137168.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 2b 47 43 41 50 3a 20 2b 43 47 53 4d 2c 2b 44  .+GCAP: +CGSM,+D
[opt2_link0] CHAT:  53 2c 2b 45 53 0d                                S,+ES.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 0d                                            ..
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a 4f 4b 0d                                      .OK.
[opt2_link0] CHAT: read
[opt2_link0] CHAT:  0a                                               .
[opt2_link0] CHAT: matched set "", goto label "MomIdentGeneriicc"
EVENT: Unregistering event EVENT_TIMEOUT ChatTimeout() at chat.c:1401
EVENT: Unregistering event EVENT_TIMEOUT ChatTimeout() done at chat.c:1401
Label 'MomIdentGeneriicc' not found
[opt2_link0] CHAT: line 391: label "MomIdentGeneriicc" not found
EVENT: Unregistering event EVENT_READ ChatRead() at chat.c:874
EVENT: Unregistering event EVENT_READ ChatRead() done at chat.c:874
EVENT: Unregistering event (null) at chat.c:875
EVENT: Unregistering event (null) done at chat.c:875
[opt2_link0] MODEM: chat script failed
There's an upstream issue for this: https://github.com/opnsense/src/issues/214

That having said, not being able to find these errors anywhere in the logs is problematic, to be honest.

I appreciate quick response here, but the docs inconsistencies aside, I am still struggling figuring out my connection and finding any relevant logs.

What I found as well is that OPNSense uses MPD to handle the PPP connections, but I still can't find any meaningful logs anywhere.

(Also, the docs directing users to PPP section of FreeBSD for additional debugging is probably also outdated, isn't it? I suppose it should be directing to MPD docs maybe, e.g. https://mpd.sourceforge.net/doc5/mpd63.html#63 ?)

As of 25.1, the Docs seem outdated, the location where PPP/Wireless logs files should be found is no longer available in the UI.
I also checked the /var/logs/ppps and only have some old logs there. Nothing of particular verbosity in /var/log/system/latest, either, except:

2025-02-12T20:29:06   Warning   opnsense   /interfaces.php: interface_ppps_configure() waiting threshold exceeded - device ppp0 is still not up   
2025-02-12T20:28:46   Notice   kernel   <6>ng0: changing name to 'ppp0'   
2025-02-12T20:28:24   Warning   rtsold   <rtsock_input_ifannounce> interface ppp0 removed   
2025-02-12T20:24:48   Notice   kernel   <118> aero2BDI (ppp0) ->   
2025-02-12T20:24:41   Warning   opnsense   /usr/local/etc/rc.bootup: interface_ppps_configure() waiting threshold exceeded - device ppp0 is still not up

I just discussed the outdated docs thing upstream here: https://github.com/opnsense/docs/issues/668#issuecomment-2654576884 and was told the logs are actually in general log. So am I missing something? Is there a way to make the PPP connectivity more verbose?

EDIT: OK, I see the manual suggests troubleshooting using standard FreeBSD procedures (https://docs.opnsense.org/manual/how-tos/cellular.html).

EDIT2. FreeBSD docs mention (https://docs.freebsd.org/en/books/handbook/ppp-and-slip/#_debugging) the syslog can be configured to output ppp logs to their own file. OPNSense's /etc/syslog.d/ppp.conf is configured to do that exactly, but /var/log/ppp.log doesn't exist. That's odd, isn't it?

Hi,

I need to set local_header_rewrite_clients = permit_mynetworks in postfix configuration, so I added it to  /usr/local/etc/postfix/main.cf accordingly, restart the service, yet the old, default permit_inet_interfaces value persists, confirmed by postconf -d , as well as the actual behavior of postfix in that aspect.

For the record, I applied other options the same way and they work just fine, so postfix doesn't like this particular one for some reason. I searched the Internet and couldn't find anything specific to postfix itself that would make it ignore that switch, hence I wonder if this is some OPNSense or FreeBSD peculiarity that I am missing?

Any ideas?

Having same issue trying to toggle a firewall rule:

Code Select Expand

curl -k -u "user":"pass" "https://opnsense/api/firewall/filter/toggleRule/702cdc85-cf43-437a-9882-4beba77fb35c/0" -X POST -d ""
{"result":"failed"}%

This is same as in this example: https://docs.opnsense.org/development/api/plugins/firewall.html

The uuid is a correct one, I can do:

Code Select Expand

url -k -u key:pass "https:/opnsense/api/firewall/filter/getRule?uuid=702cdc85-cf43-437a-9882-4beba77fb35c"

and obtain a complete JSON with details.

Also getting same error with a simpler:

Code Select Expand

curl -k -u key:pass "https://opnsense/api/firewall/filter/toggleRule/702cdc85-cf43-437a-9882-4beba77fb35c/1"

How does one actually obtain some more meaningful reason for an error?

EDIT: my issue was due to the Firewall Plugin API only supporting rules that were added using its own UI; see https://github.com/opnsense/docs/pull/437

(nvm)

why should it forward these frames

But also setting the interface/bridge to promiscuous should lift any such restrictions, yet that didn't help, either.