pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162023-10-08T18:08:33ZpfSense bugtracker
Redmine pfSense - Bug #14854 (Resolved): Packets are passed through dummynet twice when using ``route-to`...https://redmine.pfsense.org/issues/148542023-10-08T18:08:33Znasir ahmed
<p>When using a traffic shaper limiter to set bandwidth to say 10mbps in the download using any scheduler, if the gateway is left to default the limiter works as expected but if a specific gateway or a gateway group is specified the limiter works as if it was set to 5mbps.<br />This was verified on a fresh installation of pfSense 2.7.0 using two wan links and one lan. pfSense 2.6.x works fine.</p> pfSense - Bug #9450 (Resolved): Multiwan gateway group fail-over not working as expected (possibl...https://redmine.pfsense.org/issues/94502019-04-03T06:01:07Znasir ahmed
<p>Multiwan gateway group fail-over not working as expected. After a link state change is triggered by dpinger (rc.gateway_alarm is called) due to a higher priority link recovery, the rc.filter_configure_sync script fails to add the recovered gateway back to the gateway group because of a race condition.</p>
<p>The race condition:<br />rc.filter_configure_sync calls <strong>get_gwgroup_members_inner()</strong> function in gwlb.inc, which manages gateway inclusion/exclusion. But this function relies on <strong>get_dpinger_status()</strong> which reads live gateway status form the dpinger instance monitoring the triggering gateway, and By the time <strong>get_dpinger_status()</strong> reads the current values, they may have fluctuated back to the gateway down range.<br />This, prevents <strong>get_gwgroup_members_inner()</strong> from reactivation the gateway. In contrast, dpinger waits the "Alert interval" period which defaults to 1000 millisecond to check again for alarm conditions. By that time the loss and delay average values may move again out of the alarm range and dpinger may not trigger another gateway down alarm.</p>
<p>This bug results in pfsense and dpinger maintaining unmatched internal states for that particular gateway. In the described scenario the gateway status will be UP in dpinger and DOWN in pfsense. These unmatched states will be maintained until a new gateway event is triggered or a filter reload is called for any other reason.</p>
<p>As a solution I would suggest that the dpinger trigger values, should be written to a file by rc.gateway_alarm and kept for at least "Alert interval" long, and then deleted. Further more, <strong>get_gwgroup_members_inner()</strong> should read gateway loss and delay values from this file as long as it exists.</p>