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

    System patches - syntax to use?

    Scheduled Pinned Locked Moved pfSense Packages
    4 Posts 2 Posters 1.4k Views
    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 Offline
      Andrew453
      last edited by

      Hi

      I've had a look on the forums but couldn't immediately see the answer to this.

      I'd like to automate a patch to the filter.inc file to disable one of the inbuilt filter rules (it relates to this issue:  https://forum.pfsense.org/index.php?topic=93190.0)

      Basically, in /etc/inc/filter.inc, I want to swap out:

      block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)}

      for

      #  block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)}

      Each time I upgrade, the line gets put back as it was.

      I can see the System_Patches package and am wondering whether this is the sort of thing it's designed to facilitate.  I can't find any info on the syntax to use though when describing patches.  I imagine, given the reference to commit urls etc, that it is designed to mirror the git diff format?

      If someone can point me in the right direction for what I'd need to do to apply the above patch, it would be much appreciated.

      Thank you.

      1 Reply Last reply Reply Quote 0
      • A Offline
        Andrew453
        last edited by

        … ok, it looks like this just calls the standard Unix "patch" command, so the syntax is the git unified diff format.

        The below patch seems to work ok:

        --- etc/inc/filter.inc Fri Apr 15 14:47:06 2016
        +++ etc/inc/filter.inc Fri Apr 15 14:38:30 2016
        @@ -3156,3 +3156,3 @@

        We use the mighty pf, we cannot be fooled.

        -block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} label "Block traffic from port 0"
        +# block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} label "Block traffic from port 0"
        block {$log['block']} quick inet proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)} label "Block traffic to port 0"

        I've seen reference on the web to the "patch" tool applying fuzzy patches where it can.  I'm assuming this means that even if the line numbers change in a subsequent version of pfSense, it should still patch ok.  Is that right please?

        1 Reply Last reply Reply Quote 0
        • jimpJ Offline
          jimp Rebel Alliance Developer Netgate
          last edited by

          Questionable need for that particular change aside…

          The package uses the patch(1) command to apply patches and that will take any of the four formats output by diff(1), but unified diff is probably the easiest to deal with.

          What it can patch is up to the patch command. It can work if the context is correct when the line numbers differ, and I think in some cases if the context is close enough, but you'd have to read the patch(1) docs to know for certain.

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • A Offline
            Andrew453
            last edited by

            Thanks.

            Re the need to disable that filter rule, there's a debate about it in the other thread referenced above.

            For whatever reason, the inbound multicast traffic for IPTV for TalkTalk in the UK comes in on port 0.  So if you don't comment out that rule, you don't get any TV.

            Rightly or wrongly, that's the reason for the edit.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.