ping6 Address family not supported by protocol family

Hi,

I am getting this error when ping6ing:

Code:
user@freebsd:/home/rnst % ping6 google.com
PING6(56=40+8+8 bytes) 2a01:3::3:73 --> 2a00:1450:400f:802::100e
ping6: sendmsg: Address family not supported by protocol family
ping6: wrote google.com 16 chars, ret=-1
ping6: sendmsg: Address family not supported by protocol family
ping6: wrote google.com 16 chars, ret=-1
ping6: sendmsg: Address family not supported by protocol family
ping6: wrote google.com 16 chars, ret=-1
^C
--- google.com ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

user@freebsd:/home/rnst %

Steps to reproduce it:

0. Machine with IPv4 connectivity.

1. /etc/pf.conf allowing ICMPv6 (and ICMPv4) messages in and out (but I think this is not a firewalling issue because it also happens with pf disabled).

2. Create a TUN (layer 3) software interface with BROADCAST flag. This will be the originating edge of a tunnel to another machine with IPv6 connectivity.

3. Add IPv6 and IPv4 address to TUN interface and replace the default IPv6 (only, leaving IPv4 one) route:

Code:
/sbin/ifconfig tun3 inet6 2a01:3::3:73/64
/sbin/ifconfig tun3 inet 192.168.5.3

/sbin/route -6 del default
/sbin/route -6 add default 2a01:3::3:73

At this point the interface is created, IP addresses assigned and routing table modified:

Code:
user@freebsd:/home/rnst % /sbin/ifconfig tun3
tun3: flags=43<UP,BROADCAST,RUNNING> metric 0 mtu 1500

options=80000<LINKSTATE>
inet6 2a01:3::3:73 prefixlen 64
inet 192.168.5.3 netmask 0xffffff00 broadcast 192.168.9.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Opened by PID 7759

user@freebsd:/home/rnst %

Code:
default  2a01:3::3:73  UGS  tun3

3. Now, try to ping6 and get the error.

I have seen three threads where this error is shown but any of them has been useful to fix it. Any suggestion of help will be very appreciated.

Thanks in advance,
Ernesto
 
Hi,

adding

Code:
int multi=1;  
if (ioctl(fd, TUNSIFHEAD, &multi) < 0) {  
    close(fd);  
    return -1;  
}

and taking into account that the first 4 bytes are the address family in network byte order, has fixed the problem.

Regards,
E
 
I create the tunnel "programmatically" within my own application (didn't mention this detail).
 
Back
Top