Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system Subject: Re: Question using libiptc Date: Fri, 25 Oct 2013 22:43:25 +0100 Lines: 38 Message-ID: <87a9hxxc02.fsf@sable.mobileactivedefense.com> References: <1c6b1c19-53c5-4659-97d9-47daaded9532@googlegroups.com> <46a627d0-7402-45e1-bf38-254410d6ecb1@googlegroups.com> <87eh79xfto.fsf@sable.mobileactivedefense.com> <8761slf3cl.fsf@araminta.anjou.terraraq.org.uk> <87zjpxdopk.fsf@araminta.anjou.terraraq.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net NnswQ6IvFxh8OQm+t4OZ+wmbRX2G8TiFFPaAzNGE/cScI1VHc= Cancel-Lock: sha1:MvOr8wOResUtMaxleN5l6QCmGgQ= sha1:Q4EvssXFw2nizEXMshvWe55+Hjk= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.system:575 Richard Kettlewell writes: > Richard Kettlewell writes: >> Rainer Weikusat writes: >>> Something I did in the past for an embedded system (based on a 200Mhz >>> ARM9 CPU) after invoking iptables for each rule was found to be a >>> performance problem: I changed that such that it read 'iptables >>> commands' from standard input and executed them. Putting an iptables >>> process on one end of a socketpair (could use SOCK_DGRAM so that there >>> wouldn't be a need to parse the input) and using a simple, bidirectional >>> protocol, eg control process sends command, iptables replies with OK or >>> ERROR, would be an option. >>> >>> This would just require some (fairly simple) modifications to the driver >>> program (iptables) and would then work with all compatible extensions >>> without the need to duplicate the extension-specific code creating the >>> necessary data structures for each and every extension. >> >> Sounds suspiciously like iptables-save? > > I mean iptables-restore, of course. Not quite: restore/ save work with a specific text file format supposed to exchange the complete packet-filter configuration and with some totally bizarre parser implementation. Since I already had code to generate the necessary arguments for calling iptables, all I wanted was to execute these without starting a new process for every rule. It is also somewhat pointless to have the control program create real 'shell command lines' including quoting and then let iptables 'unshellcommand' these instead of just sending the number of arguments in binary, followed by the 'contents' of an argv-vector, ie, a sequence of 0-terminated strings. For this case, the receiving process gets a 'message' including all the necessary information in one go (AF_UNIX SOCK_DGRAM), allocates a char *[] of the required size and populates that with a single pass through the message without the need to do any kind of fancy syntactical analysis.