ipt_limit module with sun4u architectures

ipt_limit module with sun4u architectures

[Jose Monteiro]

I'm running iptables-1.2.9 on a debian/sun4u system, and not being able to load the limit module has become a real headache. 
Is there any workaround for this problem?

tia,

Jose

Re: ipt_limit module with sun4u architectures

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On Tue, Feb 10, 2004 at 06:43:38PM +0000, Jose Monteiro wrote:
> I'm running iptables-1.2.9 on a debian/sun4u system, and not being
> able to load the limit module has become a real headache.  Is there
> any workaround for this problem?

I'm not aware of any possible workaround that would not make all 32bit
architectures require to recompile their iptables userspace :(

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=94

> tia,
> Jose

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipt_limit module with sun4u architectures

[Jose Monteiro]

On Sat, Feb 14, 2004 at 09:22:27PM +0100, Harald Welte wrote:
> I'm not aware of any possible workaround that would not make all 32bit
> architectures require to recompile their iptables userspace :(
> 
> https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=94

The thing is, old ultrasparcs can be reused as firewalls. But now, the os/software issue comes.

Suppose for instance, that management demands messenger audio/video through the firewall, even after being told about the riscs involved. sysadmins refuse to trade the existing sun4u/ipfilter solution for a m$ one, and they happen to have an unused ultrasparc.

porting intel's upnp sdk for solaris is out of the question, so other unix must be loaded. thinking of a *bsd is pointless because the existing ports of this sdk do not cleanly (if at all) compiles under a sun4u.

So we are left with the linux solution. debian's sparc port is ok, and upnpd/linux-igd compiles fine.

Now comes the iptables logging issue. If we log, the firewall is DoS'ed with a simple nmapping, so ipt_limit must be used, and because it cannot be used in 64bit/kernel 32bit/userland architectures, we are left with a perfectly running firewall but without any logging of its activity.

Since this bug is already very old (2003-05-29), and probably there aren't that few sun4u/linux/iptables users as it could be supposed (partly because of the line of reasoning above, who knows), i was coming for the help of you guys to see if a patch is made available.

Thx,
Jose

Re: ipt_limit module with sun4u architectures

[Henrik Nordstrom]

On Thu, 19 Feb 2004, Jose Monteiro wrote:

> Since this bug is already very old (2003-05-29), and probably there
> aren't that few sun4u/linux/iptables users as it could be supposed
> (partly because of the line of reasoning above, who knows), i was coming
> for the help of you guys to see if a patch is made available.

The problem is that there has not been found a clear way to detect the
64-bit kernel / 32-bit user situation, probably because there is no 
iptables developers working in such environment.

A simple patch is to when you compile the userspace replace the pointer 
within the ipt_ratelimit structure with a "long long".

So instead of

	/* Ugly, ugly fucker. */
	struct ipt_rateinfo *master;

You have

        /* Ugly, ugly fucker. */
#ifdef __KERNEL__
	struct ipt_rateinfo *master;
#else
        long long ugly_fucker;
#endif

The problem is that this can not be done universially until a clean way to 
defermine what that ugly_fucker should be to match the size and alignment 
of a pointer within the kernel.

Regards
Henrik