GIF tunnel to Hurricane Electric down after upgrade to 2.1-RELEASE



  • I cannot get the IPv6 GIF tunnel to Hurricane Electric up after upgrading to the 2.1-RELEASE (i386) from one of the daily snapshots in late August. System Logs show

    Oct 1 13:50:49 php: /interfaces_assign.php: The command '/sbin/ifconfig gif0 inet6 2001:edited::2 2001:edited::1 prefixlen 64 ' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Invalid argument'
    Oct 1 13:50:49 php: /interfaces_assign.php: The command '/sbin/ifconfig 'gif0' inet delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'

    It was working before the upgrade. I have deleted GIF tunnel, interface, and IPv6 gateway, rebooted, and recreated from scratch and I still get the error. I had checked the allow IPv6 option after I upgraded. The WAN IPv4 address is pingable. Can anyone help?


  • Rebel Alliance Developer Netgate

    That gif error was fixed shortly after release, if you do a gitsync to RELENG_2_1 it should pick up a fix.

    I get that error but mine still works fine, so it may not be related.



  • I am on the NanoBSD version, and do not have Gitsync set up. How do I do this? Thanks.


  • Rebel Alliance Developer Netgate

    gitsync would probably be too disk-intense to run on NanoBSD if you're on a CF.

    It would be simpler to install the system patches package and apply the fix by hand.

    Instructions for the system patches package (and gitsync) are on the doc wiki, check the link in my sig.



  • Thanks. I have the System: Patches package installed and understand how it works, but I cannot find the correct patch in Redmine or Github. Can someone point me to the correct one?


  • Rebel Alliance Developer Netgate



  • Thanks, but I tested and then applied the patch, rebooted, and it still gives me the error.

    Oct 3 10:38:24 php: /interfaces_gif_edit.php: The command '/sbin/ifconfig 'gif0' inet delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
    Oct 3 10:38:24 php: /interfaces_gif_edit.php: The command '/sbin/ifconfig 'gif0' inet delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'

    I even deleted the GIF tunnel and IPv6 interfaces and recreated them, and it still gives the same error message. Any ideas? I've also tried upgrading again to the Sept 14th release from the Sept 11th one, but apparently since they are both 2.1-RELEASE, it won't upgrade.


  • Rebel Alliance Developer Netgate

    If you look at your previous output and this one, you'll see that one of the errors is actually gone.

    I haven't seen the one you're getting now, the patch was only for the error that mentioned prefixlen.  I had guessed that the other delete error was because it couldn't add the first one.

    It may be something else in your interface settings causing that. Given that the error mentions "inet" and not "inet6", it would be IPv4 settings to blame for that.



  • Which interface would that be? I don't think it is a config issue since it was working before. I have the GIF tunnel set up and assigned to a IPv6 only interface with a IPv6 static IP of 2001:::2 /64. The GIF remote end is 2001:::1 /64. The error only comes up when I change any settings on the GIF interface itself. I have even changed the Parent interface to another WAN link with no effect and the same error message. When I look at the Status: Interfaces page for the
    HE_V6_TUN interface (gif0), it reports 2001:
    ::2 /64 as it should, but no input packets or errors. I can ping 2001:
    **::2, but not ::1.

    As you mentions, the prefix error is gone now, so the only one I am getting is
    "php: /interfaces_gif_edit.php: The command '/sbin/ifconfig 'gif0' inet delete' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'"

    Thanks for your help.


  • Rebel Alliance Developer Netgate

    Have you tried to see if it actually works now though?

    Since that particular operation is failing on an IPv4 action and the interface only needs IPv6, I don't see that being a fatal problem.



  • I try a ping to the gateway and a remote IPv6 address (from pfSense) every time I make a change to see if its up, and haven't been able to ping it yet.


Log in to reply