| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
NI_WITHSCOPEID, and our getaddrinfo(3) does nothing special
for it, now.
|
| | |
|
| |
|
|
|
|
|
| |
in Framed-Route, it didn't work. Since ncprange_aton() treats
0.0.0.0 and :: as prefixlen=0, we need to care the case.
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
error) on amd64 when doing pointer subtraction. This bug is already
fixed in gcc-3.3 (waiting for after the branch), and the hack will be
backed out at the first opportunity. This is in the ipv6 code path.
Approved by: re (scottl)
|
| |
|
|
|
|
| |
removed, too.
MFC after: 1 week
|
| | |
|
| |
|
|
|
|
|
|
|
| |
contributor)
- support ipv6cpretry and ipv6cpretries, which are IPv6 versions
of ipcpretry and ipcpretries.
- improve handling of IPv6 link-local addresses
Submitted by: JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Bump version number to 3.0.4
o When talking to a RADIUS server, provide a NAS-Port-Type.
When the NAS-Port-Type is Ethernet, provide a NAS-Port value equal
to the SESSIONID from the environment in direct mode or the
NGM_PPPOE_SESSIONID message in other modes. If no SESSIONID is found,
default to the interface index in client mode or zero in server mode.
When the NAS-Port-Type is ISDN, set the NAS-Port to the minor number
of the physical device (ie, the N in /dev/i4brbchN).
This makes it easier for the RADIUS server to identify the client
WRT accounting data etc.
Prompted by: lsz8425 <lsz8425@mail.cd.hn.cn>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
of 0.0.0.0.
The OpenBSD PF_ROUTE/NET_RT_DUMP sysctl is sending back routes with
RTAX_NETMASK set, but the corresponding sockaddr being 4 zero bytes
(with an address family of zero). ppp was getting confused by this
and ending up interpreting it as a 0.0.0.0/32 routing table
destination and subsequently failing to do anything with the route.
Specifically, after this fix, ppp under OpenBSD can successfully
change and delete the default route again !
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ncprange structure.
Don't write() the netmask for IPv6 sockaddrs to the routing socket if
the prefixlen is 128.
It seems that messages written to the routing socket with the scopeid
set for link local addresses are not understood. Instead, we have to
put the scopeid in the 5th and 6th bytes of the address (see
adjust_linklocal() in ncpaddr.c). I think this may be a bug in the
KAME implementation - it should really understand both forms.
|
| |
|
|
|
| |
Not spotted by: FreeBSD's gcc version 2.95.3 20010315 (release)
Spotted by: OpenBSD's gcc version 2.95.3 20010125 (prerelease)
|
| |
|
|
|
|
|
|
|
|
| |
sizes on a route.
IMHO this shouldn't be necessary (the destination & mask/prefixlen
should be enough), but without it, the default route update under
OpenBSD will fail.
Thanks to: Russell T Hunt <alaric@MIT.EDU>
|
| | |
|
|
|
structures (well, they're treated as opaque).
It's now possible to manage IPv6 interface addresses and routing
table entries and to filter IPV6 traffic whether encapsulated or
not.
IPV6CP support is crude for now, and hasn't been tested against
any other implementations.
RADIUS and IPv6 are independent of eachother for now.
ppp.linkup/ppp.linkdown aren't currently used by IPV6CP
o Understand all protocols(5) in filter rules rather than only a select
few.
o Allow a mask specification for the ``delete'' command. It's now
possible to specifically delete one of two conflicting routes.
o When creating and deleting proxy arp entries, do it for all IPv4
interface addresses rather than doing it just for the ``current''
peer address.
o When iface-alias isn't in effect, don't blow away manually (via ``iface
add'') added interface addresses.
o When listening on a tcp server (diagnostic) socket, bind so that a
tcp46 socket is created -- allowing both IPv4 and IPv6 connections.
o When displaying ICMP traffic, don't display the icmp type twice.
When display traffic, display at least some information about unrecognised
traffic.
o Bump version
Inspired after filtering work by: Makoto MATSUSHITA <matusita@jp.FreeBSD.org>
|
