Re: reply target
Grzegorz Borowiak <[email protected]>
| Newsgroups | gmane.linux.network.bridge.ebtables.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 7 Aug 2003, Bart De Schuymer wrote: > > The target returns EBT_DROP if this was an ARP-request frame or > > EBT_CONTINUE otherwise (i.e. if it was not an ARP-request frame, or if it > > was not even an ARP frame). > > I think it should be forced upon the user to specify -p arp --arp-opcode > request. Then you don't have to check on this in ebt_target_reply (faster, no > need for EBT_CONTINUE). Have a look at the check function of kernel files > ebt_ip.c or ebt_arp.c, they do similar things. OK, I'll try to check if -p ARP was specified, but by now I think I'll leave --arp-opcode not required, because I don't think checking it by --arp-opcode is faster. And there is a clash between ebt_arp.h files in old and new patch, which does not emerge if reply target checks opcode on its own. > There's probably no use in allowing the user to choose between EBT_DROP, > EBT_CONTINUE and EBT_ACCEPT (like --snat-target)? Perhaps add it anyway and > make the default EBT_DROP... OK, very right suggestion. There's no point in limiting to EBT_DROP. > The userspace print function should use ebtables' print_mac function instead > of ether_ntoa (see ebtables.c). I see I'll have to update > extensions/ebt_nat.c to reflect this. OK > Could be a while before I have a closer look at it and commit this to CVS, I'm > kind of busy right now. OK, I'll send you corrected version of patches; it will contain three changes you have pointed. Probably tonight. -- Grzesław ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01