pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-01-24T10:46:57ZpfSense bugtracker
Redmine pfSense - Bug #15185 (Incomplete): Problem with Widgets OpenVPN in Pfsense 2.7.2 after upgradehttps://redmine.pfsense.org/issues/151852024-01-24T10:46:57ZPrzemyslaw Przybyl
<p>After Upgrade with 2.7.0 to 2.7.1 next to 2.7.2.</p>
<p>Widgets OpenVPN - Servers, OpenVPN - Clients, OpenVPN - Client Exports and Dwnloading Packages OpenVpn in Widget Client Eports are loading very slow, about 1-2 minutes. In the shell Pfsense I can see only one process at 100% php-fpm. Tunning parameters in php-fpm "/usr/local/etc/php-fpm.conf" doesn't working.</p>
<p>386 root 1 133 0 163M 64M CPU15 15 2:16 100.00% php-fpm<br />41229 root 1 68 0 159M 63M accept 15 1:09 0.00% php-fpm<br />387 root 1 68 0 163M 65M accept 6 0:47 0.00% php-fpm<br />53332 root 1 68 0 159M 61M accept 3 0:34 0.00% php-fpm<br />385 root 1 20 0 107M 27M kqread 3 0:04 0.00% php-fpm</p> pfSense - Bug #15098 (New): Wireguard crashes on boot if PPPoE is the default gatewayhttps://redmine.pfsense.org/issues/150982023-12-15T20:06:02ZOskar Stroka
<p>This only seems to happen after a fresh boot, and only if any PPPoE connection is the default gateway. <br />Even the service watchdog can't bring wireguard back up. <br />The workaround is to go to "Status" - "Interfaces", disconnect the PPPoE line and enable it again. <br />After that wireguard will start without a problem.<br />I've only noticed this issue after moving to newer / better hardware.</p> pfSense - Bug #15067 (Feedback): Secondary node attempts to delete the ``admins`` group when sync...https://redmine.pfsense.org/issues/150672023-12-05T20:40:48ZCraig Coonrad
<p>Version: 23.09-RELEASE</p>
<p>Error message:</p>
<pre>
Dec 5 20:37:30 fw102.local php-fpm[77756]: /xmlrpc.php: The command '/usr/sbin/pw groupdel -g 'admins'' returned exit code '64', the output was 'pw: Bad id 'admins': invalid'
</pre> pfSense - Bug #14757 (New): Special character encoding - crash on save / config restorehttps://redmine.pfsense.org/issues/147572023-09-06T22:14:21ZAlex G
<p>I have posted this in the forum and could verify / reproduce the problem.<br />I upgraded from version 2.6.0 to 2.7.0 and when there are some changes made the system restores an old config.</p>
<p>The problem is located at the description field of user and groups. If there is a "ü& in the the description it crashes on save. Details with screenshots in the forum post link below.</p>
<p>[[<a class="external" href="https://forum.netgate.com/topic/182658/not-wanted-autmatic-config-restore?_=1694018191854">https://forum.netgate.com/topic/182658/not-wanted-autmatic-config-restore?_=1694018191854</a>]]</p> pfSense - Bug #14613 (New): Incorrect wireguard control panel status managementhttps://redmine.pfsense.org/issues/146132023-07-26T14:59:29Zhao zhang
<p><img src="https://redmine.pfsense.org/attachments/download/5201/clipboard-202307262256-rlh8k.png" alt="" /><br />Wireguard can still be clicked on to start while in the boot state and is unresponsive when clicked on, making wireguard uncontrollable.<br />pfsense2.7<br />pfSense-pkg-WireGuard 0.2.0_2</p> pfSense - Bug #13374 (New): UI: status_logs_filter.php -- after resolution hides last column with...https://redmine.pfsense.org/issues/133742022-07-23T04:03:21ZAram Mirzadeh
<p>If both the source and destination column are long enough the last column of the data is hidden and cannot be viewed. This also occurs if {i} resolution of the ip address results in a long name. (ex: ec2-54-71-80-151.us-west-2.compute.amazonaws.com).</p>
<p>Attached is a screen shot of the first column -- then another column pasted in to show the longer text that cased the issue.</p>
<p>I'm testing this on 22.01 - 2.6 on a SG1100</p> pfSense - Bug #12905 (New): Add VLAN Re-assignment to Import Interface Mismatch Wizardhttps://redmine.pfsense.org/issues/129052022-03-05T20:31:08ZKris Phillips
<p>Currently if an interface is assigned to an interface in an imported config, there is no way to re-assign the interface the VLAN is "tied" to. We should add an option to allow VLAN parent interfaces to be reassigned without manually editing the config.xml before import. Otherwise all but the most basic of configs will run into issues.</p>
<p>For example: If a config consists of :</p>
<p>WAN --> igb0<br />LAN --igb1<br />DMZ --> igb1.10</p>
<p>And the new interfaces are ix0 and ix1, you will be able to map WAN and LAN, but not DMZ at the config restore section under Diagnostics --> Backup and Restore. This will cause an interface mismatch which will trigger the interface assignments screen in the console no matter what you do here, forcing you to basically redo everything you already did. If this could just be mapped with something like a "assign to interface as VLAN" checkbox and allow you to check the interface, this wouldn't be an issue.</p> pfSense - Bug #12828 (New): pfSense keeps crashing (Fatal trap 12: page fault while in kernel mode)https://redmine.pfsense.org/issues/128282022-02-18T16:58:50Zhugo s
<p>Description</p>
<p>pfSense 2.6.0 keeps rebooting and crashing after I created more than one wireless interface in 5ghz.</p>
<p>I am using a PCengines (AMD GX-412TC SOC) with a wle200nx wireless card, I had no issues with PFsense 2.4.X .</p>
<p>using the following settings:<br /><mode>hostap</mode><br /><standard>11na</standard><br /><protmode>off</protmode><br /><ssid>CleanPig</ssid><br /><channel>36</channel></p>
<p>this is a follow up on the ticket - <a class="external" href="https://redmine.pfsense.org/issues/12788">https://redmine.pfsense.org/issues/12788</a> which I could not reopen.</p>
<p>As recommended in the previous ticket I have tried pfsense 2.6.0 and this isn't related with FreeBSD, or at least not directly.</p>
<p>The following workaround fixed the crash:<br />1) create multiple 2.4GHZ networks<br />2) save them<br />3) change them to 5GHZ</p>
<p>I assume the web interface is doing something wrong when interfacing with the wireless card when the settings are filled the first time...</p> pfSense - Bug #11093 (New): ral(4) driver non-functional in arm64https://redmine.pfsense.org/issues/110932020-11-21T10:45:54ZSteve Wheeler
<p>Devices using the ral(4) driver do not function in arm64 images.</p>
<p>The driver attaches correctly and the interface us available to assign and bring up but you cannot actually connect to it. In hostap mode the advertised SSID comes and goes and disappears if you try to connect a client to it.</p>
<p>The console shows the following errors:<br /><pre>
ral0: need multicast update callback
ral0: can't map mbuf (error 27)
ral0: can't map mbuf (error 27)
ral0: can't map mbuf (error 27)
ral0: device timeout
</pre></p>
<p>Tested in:<br /><pre>
2.5.0-DEVELOPMENT (arm64)
built on Sat Nov 21 06:54:36 EST 2020
FreeBSD 12.2-STABLE
</pre></p> pfSense - Bug #8570 (New): Empty (dn)shaper config gets populated with newlinehttps://redmine.pfsense.org/issues/85702018-06-13T03:10:58ZZsolt Zsiros
<p>Whenever I change something in fw rules the shaper and dnspaher config changes from 'empty' to 'newline':<br /><pre>
- <shaper></shaper>
+ <shaper>
+ </shaper>
.
.
- <dnshaper></dnshaper>
+ <dnshaper>
+ </dnshaper>
</pre></p>
<p>After midnight it gets cleaned and reverted to the original 'empty' value:<br /><pre>
- <shaper>
- </shaper>
+ <shaper></shaper>
.
.
- <dnshaper>
- </dnshaper>
+ <dnshaper></dnshaper>
</pre></p>
<p>I know that both versions are syntactically correct and identical, but this change (and the following auto-revert) are triggering my configuration backup system -> every second change in it is unnecessary pollution.</p>
<p>I am not sure if this has to be fixed in /src/etc/inc/shaper.inc or somewhere else.</p> pfSense - Bug #8464 (New): Wireless USB card does not connect to WiFi automatically after reboot/...https://redmine.pfsense.org/issues/84642018-04-17T03:35:41ZConstantine Kormashev
<p>Wireless USB card on Realtek RTL8192SU chipset in BSS mode does not connect to WiFi until wilreless interface is set to down and after to up state manually. E.g. after device reboot.<br />There is not any problem with forwarding in case device already connected to WiFi, problem happens only after device reboot/halt.<br />Tried with Dlink DWA131 (Realtek RTL8192SU) on 3100 and 2220.<br />During down/up interface there are messages in console:<br /><pre>
rsu0: rsu_join_bss: still scanning! (attempt 0)
rsu0_wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost
</pre></p> pfSense - Bug #7986 (New): WLAN card no longer properly initialized under 2.4.0https://redmine.pfsense.org/issues/79862017-10-22T19:31:31ZPeter Voigtpvoigt@uos.de
<p>I have installed pfSense on an APU2C4 (bios 4.0.7) with a 32 GiB mSATA and a Compex WLE200NX (Atheros AR9280).</p>
<p>I did a fresh installation on this hardware with pfSense 2.4.0 because I want a GPT/ZFS installation. I could restore my 2.3.4p1 configuration from the webGUI and the machine is working fine except one smaller WLAN related issue.</p>
<p>The WLE200NX card is cloned and configured for 11an mode. This configuration worked very stable unter 2.3.x at 5 GHz and an automatically selected channel width of 40 MHz. Now under pfSense 2.4.0 I can observe to issues:</p>
<p>1.) After every reboot the card is initialized in 11ng mode instead of 11na.</p>
<p>2.) I can force the card in 11an mode by just saving the settings on the interface configuration page of the webGUI without doing any configuration changes. However, the card never uses 40 MHz channel width.</p>
<p>Today I investigated the WLAN settings in files /var/etc/hostapd_ath0_wlan0.conf and /var/etc/hostapd_ath0_wlan1.conf. I am not sure but I strongly suppose that two settings are missing: "hw_mode=g" and<br />"ieee80211n=1" to achieve 11na mode with 40 MHz channel width.</p>
<p>Unfortunately, I cannot test the settings because every attempt to manually add these settings to the configuration files is useless because the interfaces need a restart. If I force a restart by saving the settings in the webGUI, I lose my manual additions.</p>
<p>The current issue is published in the following thread of the forum: <a class="external" href="https://forum.pfsense.org/index.php?topic=138260.msg756022#msg756022">https://forum.pfsense.org/index.php?topic=138260.msg756022#msg756022</a></p> pfSense - Bug #6029 (New): Unhelpful error messages in xmlparse*.inc and generallyhttps://redmine.pfsense.org/issues/60292016-03-25T14:41:07ZStilez y
<p>Although it shouldn't happen, a quick forum check shows that errors used to arise some years ago with bare GUI error messages such as <em>"XML error: LABEL_TEXT at line NNN cannot occur more than once"</em> where NNN is not immediately meaningful to a user.</p>
<p>I just got one of these and traced it to functions in xmlparse.inc and xmlparse_attr.inc. What struck me is that the functions in these two files generate error messages - but not helpful ones.</p>
<p>"XML error" isn't immediately tied to something the user knows to be happening since XML tends to be internal. "LABEL_TEXT" will be an XML item, again internal and unlikely to be known to most users. The line number isn't a line in current code but a line in the XML parsed data, which is a transient line number often in a transient datastream, and lost at error generation, and again not something the user could identify usefully. There is no indication what else this could mean or how it's been generated to help a user debug, or seek meaningful help.</p>
<p>Bug hunters often can't help very much or do more than "tell us again if you find out more", when almost no information can be obtained and the user is not skilled in PHP.</p>
<p>Bug request:</p>
<p>1) Can a better system of error handling be standardised in the codebase. Perhaps as simple as log_error() containing an optional arg to add an abbreviated call stack trace to the log so the log at least shows where an obscure error originated and give bug hunters a better chance to locate the issue.</p>
<p>2) can particular attention be paid to ensure that, when an error kills the usual GUI output (as these errors from the XML parser do), or the error is in a ".inc" file, the user is left with a sensible set of debug data on a white screen and not a "one liner" of a single sprintf() without solid debug info, as was the case here. For example the actual line number or codebase function which raised the error would be helpful but it's not in these messages.</p>
<p>A good quality error message handler, especially one able to appropriately trap die() or termination or other fatals to ensure proper debug info will always be shown/logged, would be very useful all round. We don't have that - yet!</p> pfSense - Bug #4740 (New): Intel wireless kernel panic in infrastructure mode with WPAhttps://redmine.pfsense.org/issues/47402015-06-03T06:44:51ZVladimir Chernyshovls_sons@mail.ru
<p>I've got permanent kernel panic and reboot with intel wireless 4965 minipcie card in WAN infrastructure mode when wpa is activated.</p>
<p>It seems to me the reason is absence of timeout after wpa_supplicant is started, at least the patch below helped me</p>
<p>--- /etc/inc/interfaces.inc.orig 2015-06-03 14:32:10.000000000 <ins>0300<br /></ins>++ /etc/inc/interfaces.inc 2015-06-03 14:33:01.000000000 +0300<br /><code>@ -2714,9 +2714,9 </code>@<br /> unset($wlcmd_args, $wlcmd);</p>
<p>- sleep(1);<br /> /* execute hostapd and wpa_supplicant if required in shell */<br /> mwexec("/bin/sh {$g['tmp_path']}/" . escapeshellarg($if) . "_setup.sh");<br />+ sleep(1);</p>
<pre><code>return 0;</code></pre> pfSense - Bug #3889 (Confirmed): Non relevant changes in config.xmlhttps://redmine.pfsense.org/issues/38892014-09-24T05:52:34ZGrischa Zengel
<p>Version 2.1.5:</p>
<p>I push the configs to git for QA.<br />I have a lot of changes in empty tags (from short to long format and vice versa). I understand if the library change the tags could be rewritten but I get both directions on one change.</p>
<p>This is a cut from one change:<br /><pre>
- <certref/>
- <caref/>
+ <certref></certref>
+ <caref></caref>
- <time>1411401880</time>
- <description><![CDATA[admin@1.1.1.1: /vpn_openvpn_server.php made unknown change]]></description>
+ <time>1411549537</time>
+ <description><![CDATA[admin@1.1.1.1: /vpn_ipsec_phase1.php made unknown change]]></description>
- <ipaddr></ipaddr>
+ <ipaddr/>
- <gwredir></gwredir>
+ <gwredir/>
- <passtos></passtos>
- <client2client></client2client>
- <dynamic_ip></dynamic_ip>
+ <passtos/>
+ <client2client/>
+ <dynamic_ip/>
</pre></p>
<p>2. Perhaps the config.xml can be rewritten (from long to short or v.v.) once and not only for the changed section.</p>