Messages in this thread | | | Date | Sat, 26 Feb 2000 22:40:29 +0100 (CET) | From | Santiago Garcia Mantinan <> | Subject | PLIP on 2.2.15pre10 still not as good as 2.0.X :-? |
| |
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/
| |