IPv6, routing and gif(4)

I use the Hurricane Electric Free IPv6 Tunnel Broker service, without difficulty.

gif0 is up, following a take-down for test purposes.

Problem

Code:
root@mowa219-gjp4-8570p-freebsd:~ # ping -6 freshports.org
ping: UDP connect: No route to host
root@mowa219-gjp4-8570p-freebsd:~ #

How can I regain a route?

Experience has taught me that it might be most reliable to shutdown now then exit to multi-user mode. I'd like an approach that's less disruptive.



ifconfig wlan0 && ifconfig gif0 the inet and tunnel inet lines look OK, to me. Matches for:
  1. the IPv4 address that's recently used for Wi-Fi with iwn(4)
  2. the Server IPv4 Address that is given on the Hurricane Electric side.
Code:
root@mowa219-gjp4-8570p-freebsd:~ # ifconfig wlan0 | grep "inet"
        inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255
root@mowa219-gjp4-8570p-freebsd:~ # ifconfig gif0 | grep tunnel
        tunnel inet 192.168.1.7 --> {Server IPv4 Address}
root@mowa219-gjp4-8570p-freebsd:~ #

The Client IPv4 Address that is set on the Hurricane Electric side matches the current WAN IP Address of my router.

A restart of the router (without changing its address) has not resolved the issue.
 
Observations

I regained a route following this trio of commands:
  1. service rtsold restart
  2. service routing restart
  3. service dhclient restart wlan0
At the time, it felt like clutching at straws, not methodical. Prior commands included, amongst other things, service netif restart and service netif restart wlan0.

Then, I recalled:

Restart the /etc/rc.d/routing 'service'; service routing restart. Restarting netif removes routes associated with those interfaces from the routing table, which will need to be added back. With interfaces that use DHCP this is not a problem as those routes will get added dynamically after the DHCP has succeeded. …

From my /etc/rc.conf:

Code:
cloned_interfaces="gif0"
create_args_gif0="tunnel 192.168.1.7 {Server IPv4 Address} mtu 1480"
ifconfig_gif0_ipv6="inet6 2001:⋯:⋯:⋯::2 2001:⋯:⋯:⋯:1 prefixlen 128 NOAUTO"

Not using DHCP.

I guess, that's what required service routing restart (and service rtsold restart was unnecessary). True?

TIA
 
Back
Top