ISC-DHCP6 does not send replies

Indexer indexer at
Sun Aug 29 14:28:40 UTC 2010

Hash: SHA1

> Connecting to [ff02::1:2]:547 (link-scoped
> All_DHCP_Relay_Agents_and_Servers) or [ff05::1:3]:547 (site-scoped
> All_DHCP_Servers) should get some sort of answer.

I can ping6 to ff02::1:2 successfully.

> Check the routing table on server and client -- on a FreeBSD box, I get:
> % netstat -r | grep ff02
> ff02::%re0         fe80::e2cb:4eff:fe U           re0
> ff02::%fwe0        fe80::1e:8cff:fec2 U          fwe0
> ff02::%fwip0       fe80::21e:8c00:c2: U         fwip0
> ff02::%lo0         localhost          U           lo0
> ff02::%gif0        fe80::e2cb:4eff:fe U          gif0

Here is my routing table on my gateway system, using the same command as yours. 

ff02::/16                         ::1                           UGRS        lo0
ff02::%em0/32                     fe80::216:e6ff:fe7f:972e%em0  U           em0
ff02::%lo0/32                     ::1                           U           lo0
ff02::%tun0/32                    fe80::216:e6ff:fe7f:972e%tun0 UGS        tun0
ff02::%tun2/32                    fe80::216:e6ff:fe7f:972e%tun2 U          tun2
ff02::%tun3/32                    fe80::216:e6ff:fe7f:972e%tun3 U          tun3
ff02::%tun1/32                    fe80::216:e6ff:fe7f:972e%tun1 U          tun1

That ff02::/16 does not look quite right ..... 

> (ie. a route for all network interfaces known on the system, whether
> active or not)
> The next step in debugging is to start capturing packet traces
> (tcpdump(1), wireshark(1)) on both client and server and hunting in
> there for clues.  I know some IPv6 traffic won't get through my wireless
> router, but that device is IPv4 only and the poor thing gets easily
> confused by all this new-fangled IPv6 stuff...

Thankfully, all my gear is quite new, and IPV6 runs happily on it with radvd. I at least know its not my networking gear :) . I also, luckily, have two wireless APs to test (one on RADIUS, one without) so i can rule that out as the cause of the issue as well

> 	Cheers,
> 	Matthew
> PS. On the off chance that it is the firewall.  A good debugging trick
> with pf is to add a 'log' clause to any rule that has a block or reject
> action.  Eg. in lines like the following:
>   # tcpdump -i pflog0 -vv
> and make your client request a new lease.

Did all of this to be 100% sure about this. No ip6 traffic was blocked.

> Now, with IPv6, link-local addresses are always configured, and there
> are a whole new set of prefixes for local-, site- and global- scope
> addresses.  I don't know if dhcp client tries using MAC-broadcast at all
> in the IPv6 case (I would think dhcpd should answer if it does) but the
> link-local address stuff is possibly what's being blocked somewhere.

Yes, the new ipv6 stuff is very interesting. In fact Internode my ISP, use DHCP6 for router prefix advertisement on the pppoe session.

In fact, could that be the issue? I have dhcp6c running from my pppoe session (tun0), and it assigns the prefix to em0. I also am trying to use em0 as the DHCP6 server. This shouldn't be breaking it, but it *could* be?

> -- 
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                  Flat 3
> PGP:     Ramsgate
> JID: matthew at               Kent, CT11 9PW

Thanks again, its greatly appreciated.

William Brown

Version: GnuPG/MacGPG2 v2.0.14 (Darwin)


More information about the freebsd-questions mailing list