Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Still SIP unfriendly

    Scheduled Pinned Locked Moved
    2.1.1 Snapshot Feedback and Problems - RETIRED
    3
    7
    1.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      AndrewZ
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • A
          AndrewZ
          last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • C
            charliem
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • A
              AndrewZ
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • C
                charliem
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • A
                  AndrewZ
                  last edited by

                  Rolled back to 2.1 release, replaced the filter.inc, will keep monitoring the behavior…
                  Thank you!

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post