On Wed, 6 Oct 2010 21:20:36 +0200, "Sven-Ola Tuecke" <sven-ola@xxxxxx> wrote: > Hi Jan, > > Am Mittwoch, 6. Oktober 2010, um 20:01:11 schrieb Jan Engelhardt: > > [...snip...] > >> And.. I take it you want a review? > > No - I'm only interested in a working solution. Of course, I take what I > can > get to make it better if required. > >> - NAT, even if NAT66, still interferes with ETE connectivity. Think >> FTP-SSL connections. That may not be your problem, but it's the Working >> Group's and the Draft's. > > Yes - there are protocols that rely on addresses such as SIP, active FTP > etc. > I don't plan to add NAT helpers for them, thats pointless somehow. FWIW: FTP EPSV/EPRT extensions remove the need for layer-7 IPs and work with NAT44 and NAT66 nicely where the firewall supports them. >> - There are pointless casts from/to void* > > That's for kernel-2.4: The target firmware uses that old kernel for Flash > space > reasons. Only 1.75 Mb Flash and 8 Mb RAM. > Are there really working IPv6-enabled 2.4 kernels in use? >> - You should document what MAP66_lock is protecting. > > OK. They lock printk()s on SMP. Unnecessary without #DEBUG > > Again, thank you very much, > // Sven-Ola NAT66 is designed to work stateless AFAICT. As such the mapping likely does not need conntrack at all. Is there perhapse some way to only configure the map once but have it apply to both src and dst depending on the packet direction? Why is /128 not allowed? that would be extremely useful for roaming devices internal firewalls and high-security setups with multi-homing. AYJ -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
