Still SIP unfriendly
-
Is it still possible to call the user's script on a filter reload with the current version?
With the previous version(s) I used<afterfilterchangeshellcmd>/usr/local/etc/rc.d/reset_state.sh</afterfilterchangeshellcmd>where reset_state.sh was a script which kills all the states.
The problem that today after the short ISP outage I've got via DHCP the same WAN IP with the same Gateway IP as before and SIP registrations from my server were not possible until I manually killed the states through the web gui.
My understanding that the states now get killed automatically only if WAN IP get changed. -
That tag no longer exists in 2.1, appears it was only in 2.0x releases. It's generally not necessary to run something every time the filter reloads. Wiping states at every filter reload would be problematic in many cases. When a WAN IP change doesn't occur, there should be no reason to drop any states. What do your SIP states look like when this happens? What does the SIP traffic being sent by your server look like?
-
@cmb:
What do your SIP states look like when this happens?
What does the SIP traffic being sent by your server look like?I noticed the issue early in the morning and simply forgot to note the current states before killing them. Will definitely save the data next time. Not sure, but probably I've seen NO_TRAFFIC:SINGLE, SINGLE:NO_TRAFFIC like it was described in https://forum.pfsense.org/index.php/topic,18053.msg112830.html#msg112830.
My server sends SIP register messages over UDP to a number of servers on Internet. pfSense is configured to preserve the source port number for that particular local IP. -
First, make sure you are refusing a DHCP address from your cable modem (if applicable). Mine was helpfully offering an address on 192.168.100.0/24 when the ISP went down, which caused some problems.
Second, I finally fixed mine as described here:
https://forum.pfsense.org/index.php/topic,70418.msg385188.html#msg385188. Read that thread for more info. Seems the fix for 2.1 did not work (at least for me), and is not getting any traction for 2.1.1 either. -
charliem,
thanks a lot for pointing to that thread but I'm a bit lost after reading it…
Are you saying that the changes described here are not applicable for 2.1.1? If I'm wrong - please advise which particular patch should I apply.
I don't have a cable modem, Ethernet cable goes from ISP directly to my router. -
If you don't have a cable modem, just forget the first part.
There were a few patches trying to fix this before 2.1 was released, but they do not work for me in 2.1, and as far as I know, nothing in 2.1.1 has changed in this area. I have not tested 2.1.1 development versions yet, but I'm just going by the revision history of /etc/inc/filter.inc
Sorry, I see how my earlier post is confusing: I had said 're-apply' that commit in my earlier message because it was later backed out. IE, it is replaced in 2.1 and 2.1.1 with a 'more refined' version of the attempted fix that does not work for me and several others.
If you want to experiment, simple apply patch https://redmine.pfsense.org/projects/pfsense/repository/revisions/c59dd719e0a6d9ee8deecaa7bff0d6ee8c76e4ca to your 2.1 or 2.1.1 system. Actual patch is https://redmine.pfsense.org/projects/pfsense/repository/revisions/c59dd719e0a6d9ee8deecaa7bff0d6ee8c76e4ca/diff/etc/inc/filter.inc It worked for me.
-
Rolled back to 2.1 release, replaced the filter.inc, will keep monitoring the behavior…
Thank you!