libiptc - frustrating

libiptc - frustrating

[Karsten Römke]

Hi!

A long time ago (means 12 month or something like this)
I wrote c++-Classes around some functionality of libiptc and
iptables. Used iptables-1.2.6a.
Now, I'm changing my linux version and they actually use 1.2.7a,
maybe patched, it's a suse 8.2.

Hmm, same program works on old-Version and leads to a segmentation
fault in the new version. (Kernel differs too).

I remember that I need some time to analyse iptables and the calls
to libiptc and I think I understand it half (maybe).
My needs are only the insertion / deletion of  redirection-rules, if the 
source
of the packet was a specified IP. Furthermore I create a new chain out
of my program.

OK, cause it was some work I now thought:
"look for examples in the archive" and I found:

 >We said it before and we say it again. libiptc was never intended to 
be used
 >by anything else but iptables.c self. Its not an "open" API to be used by
 >any C-program. It might be and will be changed without any notice possible
 >making your c-program not working anymore.

Uuups - horrible for me :-)

Question: how can I insert a rule from a running daemon in the fastest way:
1) calling a system("iptables ..."), don't know if the syntas is correct
2) doing the work again of analyzing the source code again
3) linking iptables.o to my application. I remember, that I've not done that
    because iptables never frees any memory - only allocates - not 
useful for a
    long time running program.
    If I'm not right with this, excuse me, I just have something in mind 
like this :-)

Thank you

	Karsten

Re: libiptc - frustrating

[Harald Welte]

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

On Thu, Oct 02, 2003 at 05:49:45PM +0200, Karsten Römke wrote:
> OK, cause it was some work I now thought:
> "look for examples in the archive" and I found:
> 
> >We said it before and we say it again. libiptc was never intended to 
> >be used by anything else but iptables.c self. Its not an "open" API
> >to be used by any C-program. It might be and will be changed without
> >any notice possible making your c-program not working anymore.
> 
> Uuups - horrible for me :-)

yes, unfortunately...

> Question: how can I insert a rule from a running daemon in the fastest way:
> 1) calling a system("iptables ..."), don't know if the syntas is correct
> 2) doing the work again of analyzing the source code again
> 3) linking iptables.o to my application. I remember, that I've not done that
>    because iptables never frees any memory - only allocates - not 
> useful for a
>    long time running program.

this should be fixed now.

You have to consider a fourth option:
4) running iptables-restore --noflash and piping commands to stdin.

Depending on your usage scenario (how frequent do you have ruleset
changes?) this might be the fastest one.

> Thank you
> 	Karsten

-- 
- 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: Type: application/pgp-signature, Size: 189 bytes --]

Re: libiptc - frustrating

[Karsten Römke]

Harald Welte schrieb:
>>Question: how can I insert a rule from a running daemon in the fastest way:
>>1) calling a system("iptables ..."), don't know if the syntas is correct
>>2) doing the work again of analyzing the source code again
>>3) linking iptables.o to my application. I remember, that I've not done that
>>   because iptables never frees any memory - only allocates - not 
>>useful for a
>>   long time running program.
> 
> 
> this should be fixed now.

that would be nice, I think it's the easiest way for me

> 
> You have to consider a fourth option:
> 4) running iptables-restore --noflash and piping commands to stdin.


yes, I simply forgot this, will try this way, even if there are no more
memory leeks.
Can I use 1.2.7a or should I switch to 1.2.8?

> 
> Depending on your usage scenario (how frequent do you have ruleset
> changes?) this might be the fastest one.
It's for controlling internet access of pupil at a school.
I think every 1,5 h I have something about 100 changes in the tables.

Thank you
	Karsten

Re: libiptc - frustrating

[Karsten Römke]

Hello again!
Im looking for the following way of adding rules to the tables.
>>3) linking iptables.o to my application. I remember, that I've not done that
>>   because iptables never frees any memory - only allocates - not 
>>useful for a
>>   long time running program.
> 
> 
> this should be fixed now.
> 
> You have to consider a fourth option:
> 4) running iptables-restore --noflash and piping commands to stdin.
After looking to the code - iptables-restore calls do_command - same
what iptables-standalone does.

But again back to memory problems, I modified libiptc and iptables.c so that
I just print every allocation and deallocation of memory. The output at the
end of this mail is one example which shows 11 times malloc/calloc and 6 
times free.

I have never done programming on such a kernel-near level, so in the moment
I'm just counting :-). There are 5 allocations of memory remaining, so 
my question:

Is there some memory allocated which is used by the kernel (or somebody 
else, maybe
rustys hamster)? I hope this question isn't to stupid - hmm probably it 
is. If
iptables allocates some memory and is terminated then the memory should 
be free'd again
by the kernel?

Slightly off-topic: does somebody know what happens with the memory, if 
I do a
system call like system("iptables ....")? If some memory is allocated 
from iptables
and not deallocated again - does the linux kernel cares about 
deallocating this
memory.

ok it's enough up to now, wishing a nice weekend and thank you

Karsten


ah, here's the example:
stopping access of one host
(redirecting to own web-server on port 5042 which sends only ascii-art)

kspace9:/usr/local/iptables-1.2.7aMod # ./iptables -t nat -p tcp -I iAccess
-s 10.4.1.1 -j REDIRECT --to-port 5042

leads to the output of modified iptables:

In do_command case j calling fw_calloc
Calling malloc in merge_options
Calling alloc for addr in parse_hostnetwork
Calling alloc for addr in parse_hostnetwork
malloc in alloc_handle
malloc in populate_cace for h->cache_chain_heads
Calling fw_malloc in generate_entry
malloc in alloc_handle

free on (*handle)->cache_chain_heads in insert_rule
free on *handle in insert_rule

malloc in commit for repl
malloc in commit for repl->counters
malloc in commit for newcounters

3xfree on repl->counters, repl, newcounters in commit

free on *handle in commit, set *handle to NULL

Re: libiptc - frustrating

[Harald Welte]

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

On Sat, Oct 04, 2003 at 10:39:11AM +0200, Karsten Römke wrote:

> Is there some memory allocated which is used by the kernel (or somebody 
> else, maybe rustys hamster)? I hope this question isn't to stupid -
> hmm probably it is. If iptables allocates some memory and is
> terminated then the memory should be free'd again by the kernel?

no. There is nothing 'special' about iptables, it's an ordinary
userspace program, adhering to all 'normal' rules.  So there are still
leaks, obviously.  Patches welcome :)

> Slightly off-topic: does somebody know what happens with the memory, if 
> I do a system call like system("iptables ....")? If some memory is
> allocated from iptables and not deallocated again - does the linux
> kernel cares about deallocating this memory.

the iptables process terminates, and all memory is free'd by the kernel.
also just like normal processes.

> Karsten

-- 
- 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: Type: application/pgp-signature, Size: 189 bytes --]