ISC-DHCP6 does not send replies

[Matthew Seaman]

On 29/08/2010 08:44:08, Indexer wrote:

> When i change the subnet block to subnet6 
> 
> 2001:44b8:7988:c60::/64 {
> 
> The client still sends solicits to the server, but now the server no
> longer receives them. Checking wether the client could connect to
> ff02::1:2 came back with " UDP connect: No route to host"

As far as I can tell, the subnet6 statement was the only error in the
config you posted.  Hmmm... I'm thinking the problem is perhaps your
firewall.  ... but you've tried disabling the firewall completely.
Probably not that then.

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.

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

(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...

	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:

block log all
block in log quick from no-route to any
block in log quick from urpf-failed to any
antispoof log quick for lo0
block in log quick on $ext_if from <ssh-bruteforce>

etc. etc.

Then run tcpdump on the pflog0 interface:

   # tcpdump -i pflog0 -vv

and make your client request a new lease.

In the IPv4 case, the first packets the client sends are not *IP*
packets -- they are pure ethernet packets, sent to the broadcast MAC
address ff:ff:ff:ff:ff:ff, and don't necessarily have any IP address
data (either IPv4 or IPv6) in them at all.  If MAC-broadcast fails, then
dhcp client will fall back to using the IPv4 link-local address range
169.254.0.0/16 (RFC3927). However, if your dhcp client does that, then
it's usually an indication you aren't going to get an address.

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.

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100829/55325fc3/signature.pgp