In your previous mail you wrote:
This information is retrived using IPV6_PATHMTU.
struct ip6_mtuinfo mtuinfo;
mtuinfo.ip6m_addr = addr; /* address */
getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, sizeof(&mtuinfo));
=> I am sorry but this tries to give some data (here the address) to the kernel
via a getsockopt(). This is both not implementable on many kernels and
not compliant with standard getsockopt() definition.
For instance on my FreeBSD 3.x I have:
GETSOCKOPT(2) FreeBSD System Calls Manual GETSOCKOPT(2)
NAME
getsockopt, setsockopt - get and set options on sockets
SYNOPSIS
#include <sys/types.h>
#include <sys/socket.h>
int
getsockopt(int s, int level, int optname, void *optval, int *optlen)
int
setsockopt(int s, int level, int optname, const void *optval, int optlen)
DESCRIPTION
...
The parameters optval and optlen are used to access option values for
setsockopt(). For getsockopt() they identify a buffer in which the value
for the requested option(s) are to be returned. For getsockopt(), optlen
is a value-result parameter, initially containing the size of the buffer
pointed to by optval, and modified on return to indicate the actual size
of the value returned. If no option value is to be supplied or returned,
optval may be NULL.
I've looked at getsockopt() definition on some other OSs, the only difference
is some say NULL, some say 0...
Regards
[EMAIL PROTECTED]
PS: of course the connected option (not the #3) has not this problem.
I believe the path MTU is a PCB property then for an unconnected PCB
the path MTU should be the largest compatible interface MTU (or the
specified MTU if IPV6_USE*MTU is set).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
