Hi!
There is still a thing on 2.2 that is not working as well as it used to be
in 2.0, 2.0 made a destination MAC in the linux way
(FC:FC:the4bytesoftheremoteip) whenever it didn't knew the destination
mac (for example when in NOARP mode), this allowes it to work even
against a 2.2.14 with the bug, while 2.2 sends 0:0:0:0:0:0 the first time
and its local MAC next times and this is a little weird.
You can see this in this two examples, on both the local machine is a
2.2.14 and the local and remote machines are set NOARP, what I'm dumping
is the first two pings of the remote machine just after booting, both
times both machines don't have any arp information about the other.
Remote is a 2.2.15pre10...
17:13:58.048588 fc:fc:c0:a8:1:3 0:0:0:0:0:0 0800 98: 192.168.1.3 >
192.168.1.243: icmp: echo request
17:14:13.726340 fc:fc:c0:a8:1:3 fc:fc:c0:a8:1:3 0800 98: 192.168.1.3 >
192.168.1.243: icmp: echo request
Remote is a 2.0.38...
20:25:32.682510 fc:fc:c0:a8:1:3 fc:fc:c0:a8:1:f3 0800 98: 192.168.1.3 >
192.168.1.243: icmp: echo request
20:25:32.682746 fc:fc:c0:a8:1:f3 fc:fc:c0:a8:1:f3 0800 98: 192.168.1.243 >
192.168.1.3: icmp: echo reply
20:25:33.684043 fc:fc:c0:a8:1:3 fc:fc:c0:a8:1:f3 0800 98: 192.168.1.3 >
192.168.1.243: icmp: echo request
20:25:33.684148 fc:fc:c0:a8:1:f3 fc:fc:c0:a8:1:f3 0800 98: 192.168.1.243 >
192.168.1.3: icmp: echo reply
Well, I believe that it would be good to have back the 2.0.38 way to make
up the remote MAC when in NOARP mode.
Also, when in ARP mode, 2.2.15pre10 makes the ARP replies to the right
destination MAC, but afterwards it keeps on sending the packages to its
local MAC, instead of learning the MAC fron this ARP for the rest of the
packages, like 2.0.38 did, this was also a good thing that it's lost :-(
About the patch aplied to plip.c on 2.2.15pre2 and afterwards... well, I
don't know why was the line at net/ethernet/eth.c in function
eth_type_trans changed from...
else if(dev->flags&(IFF_PROMISC/*|IFF_ALLMULTI*/))
on 2.2.13 to
else if(1 /*dev->flags&IFF_PROMISC*/)
on 2.2.14 and on, but I think this could affect more drivers other than
PLIP and the patch aplied on 2.2.14pre2 adding this new function
(plip_type_trans) wich does the same as eth_type_trans but without the
code on this if... doesn't seem the best solution, I mean, for manteining
the code and all that, or for future drivers like plip, would they also
need an special funtion?
Sorry if someone feels bad about me saying all this, I know I'm no-one at
all, and it wasn't my intention. It is just my opinion, if I had time I
would change it myself to see if it pleased you, but unfortunately I don't
have much time right now :-(
Regards...
Manty/BestiaTester -> http://manty.i.am
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST