I'm sorry, I was absent for two weeks, and was not able to
answer the questions about post-1.3.99 route and arp code.
Now I try to answer all of them "in batch".
If I missed something, please resend your bug report.
1. Q. <99.5 arp oopses.
A. I hope this ugly bug was fixed at 1.99.5.
2. Q. "Magic" routes broke pppd, dummy ...
A. "Magic" routes are disabled in 1.99.5, but I do not
think that they was cause of this grief.
It is bug in route.c:
/*
* "Magic" device route is allowed to point to loopback,
* discard it too.
*/
if (f->fib_info->fib_dev != dev &&
#ifdef NO_ANK_FIX
(dev != &loopback_dev || f->fib_dst != dev->pa_addr)) {
#else
(f->fib_info->fib_dev != &loopback_dev || f->fib_dst != dev->pa_addr)) {
#endif
fp = &f->fib_next;
continue;
Please, fix it and remove #ifdef COMING_IN_2_1
at the end of route.c.
Does it work?
3. Q. "route add -net 127.0.0.1" does not work.
A. Correct. This command is not valid, and it was never valid.
(but worked and was equivalent to "route add -net 127.0.0.0")
The most correct way to add route:
route add -net 127.0.0.0 netmask 255.0.0.0 lo
If you do not specify netmask and/or device, kernel tries to
guess them.
3 different situations are possible:
route add -net 127.0.0.0 lo
Kernel gets netmask from device mask.
route add -net 127.0.0.0 netmask 255.0.0.0
Kernel searches for device with netmask closest
to 255.0.0.0 and matching address.
route add -net 127.0.0.0
Kernel searches for device with matching address
and the longest mask.
The rules for this search are more clever and more strict now.
4. scldad@sdc.COM.AU (Stephen Davies) wrote:
> I noticed that none of my RPC services were available...
I believe, you deleted "route add ..." in rc scripts.
1.99.5 disabled magic routes.
5. alan@cymru.NET (Alan Cox) wrote:
> Yes. A route is auto added for each device with its netmask. That makes
> various bits of BSD code work that assume this way of working. Unlike BSD
> you can delete these routes trivially if you want to pull something funny.
No-no-no! It does not! It adds only loopback routes.
It is impossible to add interface route with
current SIOCSIF* interface. The problem is that device address
and netmask are set by different ioctls and kernel cannot know
when the pair (address,mask) is valid.
BSD emulation would be possible, if we created new ioctl(SIOCSIFCONF)
that sets all parameters of device (addr,mask,flags,dstaddr,brdaddr)
atomically. (and disabled SIOCSIFADDR etc. to avoid confusion)
6. davidm@cs.SU.oz.AU (David Monro) wrote:
> elara:~ # route add -net default dev eth0
> elara:~ # route add -net default gw 200.0.0.0 dev eth0
.......
> Ouch. The route with the null gateway seems to propagate up the table and allow
> adding further default routes at will - very strange. This works on both the
> 1.3.100 and pre2.0.2 boxen.
It is not bug. You added direct default route,
and kernel believes that all the Internet is on your ethernet.
BTW, it is one of the most convenient configurations in LAN.
All the workstations are setup to have direct default route to ethernet,
and routers have "default" proxy arp entry
(Cisco and linux-post99 can make it). That's all, hosts need not know
interface mask, gateways etc. Interface address is the only configuration
parameter.
> 0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Why not? It is valid too.
Alexey Kuznetsov.
PS. Well, I lied about pictures 8)