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

    Rc.newwanip issue

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 3 Posters 1.2k 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
      Andrew453
      last edited by

      Hi

      I'm using a USB NIC (yes … I know) to provide an additional port on by pfSense box so that ntopng can monitor traffic on a separate LAN (it's connected to a port mirror on that LAN).  The USB NIC doesn't have it's own IP address, as it's just used to monitor packets.

      The problem is that the USB NIC (as is often the case) isn't very stable and the connection momentarily drops out every few days for a microsecond.  That of itself doesn't matter, but it triggers a hotplug event which causes all the services/packages on pfSense to restart.  That does matter, because things like IGMP proxy are interrupted for everyone on all interfaces.  See the log below:

      Feb 16 15:49:59	php-fpm	86053	[pfBlockerNG] Starting cron process.
      Feb 16 15:49:59	php-fpm	86053	/rc.start_packages: Restarting/Starting all packages.
      Feb 16 15:49:58	check_reload_status		Starting packages
      Feb 16 15:49:58	php-fpm	73831	/rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 0.0.0.0 -> - Restarting packages.
      Feb 16 15:49:56	php-fpm	73831	/rc.newwanip: Started IGMP proxy service.
      Feb 16 15:49:56	igmpproxy	52691	select() failure; Errno(4): Interrupted system call
      Feb 16 15:49:56	php-fpm	73831	/rc.newwanip: Creating rrd update script
      Feb 16 15:49:56	php-fpm	73831	/rc.newwanip: Resyncing OpenVPN instances for interface LANM.
      Feb 16 15:49:56	php-fpm	73831	/rc.newwanip: Ignoring IPsec reload since there are no tunnels on interface opt2
      Feb 16 15:49:35	php-fpm	73831	/rc.newwanip: IP has changed, killing states on former IP 0.0.0.0.
      Feb 16 15:49:35	php-fpm	73831	/rc.newwanip: rc.newwanip: on (IP address: ) (interface: LANM[opt2]) (real interface: ue0).
      Feb 16 15:49:35	php-fpm	73831	/rc.newwanip: rc.newwanip: Info: starting on ue0.
      Feb 16 15:49:33	check_reload_status		Reloading filter
      Feb 16 15:49:33	check_reload_status		rc.newwanip starting ue0
      Feb 16 15:49:33	php-fpm	61983	/rc.linkup: Hotplug event detected for LANM(opt2) static IP ( )
      Feb 16 15:49:33	check_reload_status		Reloading filter
      Feb 16 15:49:33	php-fpm	61983	/rc.linkup: Hotplug event detected for LANM(opt2) static IP ( )
      Feb 16 15:49:32	check_reload_status		Linkup starting ue0
      Feb 16 15:49:32	kernel		ue0: link state changed to UP
      Feb 16 15:49:32	kernel		ue0: link state changed to DOWN
      Feb 16 15:49:32	check_reload_status		Linkup starting ue0
      
      

      It's relatively easy for me to modify rc.newwanip or rc.linkup to trap and prevent the reload in these particular circumstances by way of a specific patch/workaround on my installation, but am wondering whether actually these scripts should be amended more generally for everyone.

      Much of the need to reload packages proceeds on the basis that, for example, the IP address has changed.  Here it hasn't (the interface doesn't have an IP address - ipv4 and ipv6 configuration type is set to "none" for the interface) so I would have thought a reload is unnecessary in any event.

      Is a fix for this something that the devs think should be built into pfSense more generally? - i.e. checking more specifically to see what has actually changed and what requires reloading/refreshing, and only taking those actions rather than kicking off multiple different processes.

      I appreciate this is in the context of a "workaround" and that the real underlying issue is the USB NIC, but thought I'd mention it anyway.

      1 Reply Last reply Reply Quote 0
      • M
        morgancj
        last edited by

        I have similar issue, and since this has not been talked about, I'd like to bump it.

        bump.

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          OK, so how do we know that the Link Down/Up event was not a genuine event on the port?

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