a route to the gateway and caches it in the route structure.
It may happen (if the routing table is screwed) that the gateway
route is the same route as the one being modified, in which case
a kernel reports EDQUOT. Be more verbose about this:
# route add -net 10 192.168.4.65
add net 10: gateway 192.168.4.65
# netstat -rn -finet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.4.65 UGSc 1 7 rl0
10 192.168.4.65 UGSc 0 0 rl0
127.0.0.1 127.0.0.1 UH 0 178 lo0
192.168.4 link#1 UC 2 0 rl0 =>
192.168.4.65 0:d0:b7:16:9c:c6 UHLW 2 0 rl0 1123
Before:
# route change -net 10 10.0.0.1
route: writing to routing socket: Disc quota exceeded
change net 10: gateway 10.0.0.1: Disc quota exceeded
After:
# ./route change -net 10 10.0.0.1
route: writing to routing socket: Disc quota exceeded
change net 10: gateway 10.0.0.1: gateway uses the same route
PR: bin/1093, misc/26833
PR: bin/12489
- Use inet_ntoa(3) where it should have been used. This
part of code simply wasn't converted to the "new" style
after the routename() function was converted from the
protocol-generic version to protocol-specific version
in CSRG revision 5.6.
MFC after: 1 week
argument only. Before that, the `route add default gateway' first tried
the `gateway' as network address and passed its name to getnetbyname(3),
which in the BIND resolution case does the T_PTR lookup on that name.
don't support routes with sin6_scope_id set.
Without this fix, routes with IPv6 scoped addr won't work when it is
assigned by "route" command.
Approved by: jkh
Reviewed by: ume
IPv6 scoped addr display is not yet supported by ifconfig
and route. Now almost of IPv6 apps support it, so its support
in ifconfig and route is important to keep consisetncy, and
to avoid user confusion.
Approved by: jkh
packet divert at kernel for IPv6/IPv4 translater daemon
This includes queue related patch submitted by jburkhol@home.com.
Submitted by: queue related patch from jburkhol@home.com
Reviewed by: freebsd-arch, cvs-committers
Obtained from: KAME project
sizeof(ifr->ifr_addr) for the variable length field ifr->ifr_addr.sa_len.
Otherwise the increment will be wrong in certain cases.
Obtained from: Whistle source tree
For the record: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> suggests
SIOCGIFCONF should be dropped in favor of a sysctl mechanism.
to do with netmasks.. we fed totally bogus data into the kernel
to do with default routes and it just believed us. this led to:
1/ kernel panics
2/ the default route refusing to be deleted or added
(depending on a number of factors, usually it worked ok.)
buffer (so more difficult to exploit but better safe than sorry). Found
by comparing FreeBSD & OpenBSD sources/logs for the auditing process.
Reviewed by: Warner Losh
Obtained from: OpenBSD
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
do it themselves. (Some of these programs actually depended on this
beyond compiling the definition of struct ifinfo!) Also fix up some
other #include messes while we're at it.
Opening the socket is the only privileged operation route requires.
Make a couple of static buffers bigger, and use strncpy() and snprintf() where
there's a chance of overflow.
Fixes PR bin/1903
Partially Submitted by: Ollivier Robert <roberto@keltia.freenix.fr>
Don't look up the network number if we're being asked to add a host route.
Fixes PR bin/1900
Submitted by: Bruce A. Mah <bmah@cs.berkeley.edu> (pr bin/1900)
for gcc >= 2.5 and no-ops for gcc >= 2.6. Converted to use __dead2
or __pure2 where it wasn't already done, except in math.h where use
of __pure was mostly wrong.
Submitted by: archie@whistle.com
This patch allows true interface routing to be controlled
from the command line..
you can now do:
route add default -interface ppp0
even if you have no clue what the address at the other end is..
this is part of a set of changes that allow true "unnumbered links"
such as netcom run between their sites..
In practice you should assign the address from one of your ethernet
interfaces to the local side of the P2P link so that IP doesn't
say that the packet comes from 255.255.255.255, but
there is no need whatsoever to assign an address of any kind
to the remote end of the link.. useful for frame relay links etc also.
