to lo(4) interfaces to have an effect, and that this is not needed
when using IP fast forwarding.
Sponsored by: eXtensible Open Router Project <URL:http://www.xorp.org/>
MFC after: 3 weeks
root is allowed to create raw sockets, then they will be able to create
routing sockets, too. However prison-root is not able to manipulate
routing tables. So when route(8) attempts to write to a routing
socket and recieves EPERM from the kernel, exit rather than moving
on with execution.
Approved by: bmilekic (mentor)
prior sysctl due to the structure growing between calls try again.
Also try again for deleting routes if things fail. We've seen
route -f fail this way which does not actually flush all routes.
This fixes it. It will whine but it will do the work.
PR: 56732
Obtained from: IronPort
answer for the euid. As a result, fix it such that setuid scripts or
programs may call route(8) to do work on their behalf.
Reviewed by: ru
MFC after: 3 days
- /0 if matches ::/128
- /64 if matches 2000::/3 and lowermost 64 bit is all 0
- /128 if matches 2000::/3 and lowermost 64 bit is non-zero 0
Obtained from: KAME/NetBSD
It does not help modern compilers, and some may take some hit from it.
(I also found several functions that listed *every* of its 10 local vars with
"register" -- just how many free registers do people think machines have?)
socket so that routing daemons and other interested parties
know when an interface is attached/detached.
PR: kern/33747
Obtained from: NetBSD
MFC after: 2 weeks
Allow non-superuser to open, listen to, and send safe commands on the
routing socket. Superuser priviledge is required for all commands
but RTM_GET.
Lose `setuid root' bit of route(8).
Reviewed by: wollman, dd
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
to use 0xffffffff (INADDR_NONE) as a netmask value. The fix
is to use inet_addr(3) which doesn't suffer from this problem.
PR: bin/28873
Also, while here, fixed the bug when netmask value was ignored
(RTF_HOST flag was set) if the "destination gateway netmask"
syntax is used, e.g. ``route add 1.2.3.4 127.1 255.255.255.255''.
in revision 1.48. It is pretty valid and often feasible to use
a non-point-to-point interface as the gateway. One might, for
example, use this to route some hosts through an ARP on a local
interface, without having to assign an additional IP address:
Script started on Tue Jun 12 16:16:09 2001
# ifconfig rl0 inet
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.4.115 netmask 0xffffff00 broadcast 192.168.4.255
# netstat -arn -finet | grep -w rl0
192.168.4 link#1 UC 3 0 rl0 =>
192.168.4.65 0:d0:b7:16:9c:c6 UHLW 1 0 rl0 1197
# route add -net 192.168.100 -iface rl0
add net 192.168.100: gateway rl0
# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=255 time=0.551 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=255 time=0.268 ms
^C
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.268/0.410/0.551/0.142 ms
# netstat -arn -finet | grep -w rl0
192.168.4 link#1 UC 3 0 rl0 =>
192.168.4.65 0:d0:b7:16:9c:c6 UHLW 1 0 rl0 1165
192.168.100 link#1 UCSc 1 0 rl0 =>
192.168.100.1 0:d0:b7:16:9c:c6 UHLW 1 4 rl0 1192
Script done on Tue Jun 12 16:17:12 2001
This work was based on kame-20010528-freebsd43-snap.tgz and some
critical problem after the snap was out were fixed.
There are many many changes since last KAME merge.
TODO:
- The definitions of SADB_* in sys/net/pfkeyv2.h are still different
from RFC2407/IANA assignment because of binary compatibility
issue. It should be fixed under 5-CURRENT.
- ip6po_m member of struct ip6_pktopts is no longer used. But, it
is still there because of binary compatibility issue. It should
be removed under 5-CURRENT.
Reviewed by: itojun
Obtained from: KAME
MFC after: 3 weeks
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
