diff options
author | Brian Haley <brian.haley@hp.com> | 2006-12-12 17:09:49 -0800 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2006-12-13 16:48:25 -0800 |
commit | befffe901649e2cc421d0d150c4379d01658cf6b (patch) | |
tree | a990965641fb181bdf1228d2a347ecdf87ab8742 /net/sctp/socket.c | |
parent | 832e3ca62d6ee1893db05f5202c24ae5331e19ba (diff) | |
download | kernel_goldelico_gta04-befffe901649e2cc421d0d150c4379d01658cf6b.zip kernel_goldelico_gta04-befffe901649e2cc421d0d150c4379d01658cf6b.tar.gz kernel_goldelico_gta04-befffe901649e2cc421d0d150c4379d01658cf6b.tar.bz2 |
[IPV6]: Fix IPV6_UNICAST_HOPS getsockopt().
> Relevant standard (RFC 3493) notes:
>
> The IPV6_UNICAST_HOPS option may be used with getsockopt() to
> determine the hop limit value that the system will use for subsequent
> unicast packets sent via that socket.
>
> I don't reckon -1 could be the hop limit value.
-1 means un-initialized.
> IMHO, the value from
> case 1 (if socket is connected to some destination), otherwise case 2
> (if bound to a scope interface) or ultimately the default hop limit
> ought to be returned instead, as it will be most often correct, while
> the current behavior is always wrong, unless setsockopt() has been used
> first. I don't if some people may think doing a route lookup in
> getsockopt might be overly expensive, but at least the two other cases
> should be ok, particularly the last one.
The following patch seems to work for me, but this code has behaved this
way for a while, so don't know if it will break any existing apps.
Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/sctp/socket.c')
0 files changed, 0 insertions, 0 deletions