summaryrefslogtreecommitdiffstats
path: root/doc/ulogd.sgml
blob: a98c053956893908fc68d3f8b64d6d9af6618be7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
<!doctype linuxdoc system>

<!-- $Id$ -->

<article>

<title>ULOGD 2.x - the Netfilter Userspace Logging Daemon</title>
<author>Harald Welte &lt;laforge@netfilter.org&gt, Eric Leblond &lt;eric@inl.fr&gt</author>
<date>Revision 2008/09/03</date>

<abstract>
This is the documentation for <tt>ulogd-2.x</tt>, the second generation
Netfilter Userspace logging daemon.  ulogd makes use of the Linux &gt;= 2.6.14
nfnetlink_log and nfnetlink_conntrack subsystems, but also provides backwards compatibility for Linux
&gt;= 2.4.0 ipt_ULOG.
</abstract>

<toc>

<sect>DESIGN

<sect1>CONCEPT
<p>
ulogd-2.x wants to provide a flexible, almost universal logging daemon for 
netfilter logging.  This encompasses both packet-based logging (logging of
policy violations) and flow-based logging, e.g. for accounting purpose.
<p>
ulogd consists of a small core and a number of plugins.  All the real power
lies in the plugins, and in the user who configures the interactions between those
plugins.
<p>
<descrip>
<tag>Input Plugins</tag>
Input plugins acts data source.  They get data from somewhere outside of ulogd,
and convert it into a list of ulogd keys.
<tag>Filter Plugins</tag>
Filter plugins interpret and/or filter data that was received from the Input
Plugin.  A good example is parsing a raw packet into IPv4 / TCP / ... header
information.
<tag>Output Plugins</tag>
Output plugins describe how and where to put the information gained by the
Input Plugin and processed by one or more Filter Plugins.
The easiest way is to build a line per packet and fprint it to a file. 
Some people might want to log into a SQL database or want an output 
conforming to the IETF IPFIX language.
</descrip>
<p>
By means of the configuration file, the administrator can build any number
of Plugin Stacks.  A plugin stack is a series of plugins, starting with an Input
plugin, none, one or multiple filter plugins, and one output plugin on top.
</p>

<sect1>DETAILS
<p>
The major clue is providing a framework which is as flexible as possible. 
Nobody knows what strange network protocols are out there :) But at the same
time, logging of a packet filter is often very performance critical.
Like all ulogd releases since 0.3.x, the ulogd-2.x core doesn't do any
dynamic allocations at runtime.  Yes, obviously, at startup time the config
file is parsed, and allocations are made.  But after that, everything is
pre-allocated.  As an additional improvement over ulogd-1.x, there are also no
hashtable lookups for key resolval.  All input/output keys of plugins within
every stack are resolved at config file parsing time, and directly
interconnected  by pointers.

<sect>INSTALLATION
<p>
<sect1>Linux kernel
<p>
To use the NFCT or NFLOG input plugin, you will need a 2.6.14 or later kernel.
For old-style ULOG logging, you need a kernel &gt;= 2.4.18.

<sect1>Userspace libraries
<p>
If you plan to use NFCT and NFLOG input plugin, you will need to compile
libnfnetlink, libnetfilter_conntrack and libnetfilter_log libraries which
can be downloaded from <URL URL="http://ftp.netfilter.org/pub/">.
A simple './configure; make; make install' will be enough to have library
installed on your system.


<sect1>ulogd
<sect2>Recompiling the source
<p>
Download the ulogd package from <URL URL="http://ftp.netfilter.org/pub/ulogd/"> and
untar it. 
<p>
If you want to build ulogd with MySQL support, type './configure --with-mysql'. You may also have to specify the path of the mysql libraries using '--with-mysql=path'. To build ulogd without MySQL support, just use './configure'.
<p>
To compile and install the program, call 'make install'.

<sect>Configuration
<sect1>iptables NFLOG target
<sect2>Quick Setup
<p>
Just add rules using the NFLOG target to your firewalling chain. A very basic
example:
<tscreen><verb>
iptables -A FORWARD -j NFLOG --nflog-group 32 --nflog-prefix foo 
</verb></tscreen>
<p>
To increase logging performance, try to use the
<tscreen><verb>
--nflog-qthreshold N
</verb></tscreen>
option (where 1 &lt; N &lt;= 50). The number you specify is the amount of packets
batched together in one multipart netlink message. If you set this to 20, the
kernel schedules ulogd only once every 20 packets. All 20 packets are then 
processed by ulogd. This reduces the number of context switches between kernel
and userspace.
<p>
Of course you can combine the NFLOG target with the different netfilter match
modules.  For a more detailed description, have a look at the netfilter
HOWTO's, available on the netfilter homepage.
<sect2>NFLOG target reference
<p>
<descrip>
<tag>--nflog-group N</tag>
The number of the netlink multicast group to which NFLOG'ed packets are sent.
You will have to use the same group number in the NFLOG target and ulogd in
order to make logging work.
<tag>--nflog-range N</tag>
Copyrange.  This works like the 'snaplen' parameter of tcpdump.  You can specify
a number of bytes up to which the packet is copied.  If you say '40', you will
receive the first fourty bytes of every packet. Leave it to <tt>0</tt> to dump
the whole packet.
<tag>--nflog-threshold N</tag>
Queue threshold.  If a packet is matched by the iptables rule, and already N
packets are in the queue, the queue is flushed to userspace.  You can use this
to implement a policy like: Use a big queue in order to gain high performance,
but still have certain packets logged immediately to userspace.
<tag>--nflog-prefix STRING</tag>
A string that is associated with every packet logged by this rule.  You can use
this option to later tell from which rule the packet was logged.
</descrip>

<sect1>iptables ULOG target
<sect2>Quick Setup
<p>
Just add rules using the ULOG target to your firewalling chain. A very basic
example:
<tscreen><verb>
iptables -A FORWARD -j ULOG --ulog-nlgroup 32 --ulog-prefix foo 
</verb></tscreen>
<p>
To increase logging performance, try to use the
<tscreen><verb>
--ulog-qthreshold N
</verb></tscreen>
option (where 1 &lt; N &lt;= 50). The number you specify is the amount of packets
batched together in one multipart netlink message. If you set this to 20, the
kernel schedules ulogd only once every 20 packets. All 20 packets are then 
processed by ulogd. This reduces the number of context switches between kernel
and userspace.
<p>
Of course you can combine the ULOG target with the different netfilter match
modules.  For a more detailed description, have a look at the netfilter
HOWTO's, available on the netfilter homepage.
<sect2>ULOG target reference
<p>
<descrip>
<tag>--ulog-nlgroup N</tag>
The number of the netlink multicast group to which ULOG'ed packets are sent.
You will have to use the same group number in the ULOG target and ulogd in
order to make logging work.
<tag>--ulog-cprange N</tag>
Copyrange.  This works like the 'snaplen' parameter of tcpdump.  You can specify
a number of bytes up to which the packet is copied.  If you say '40', you will
receive the first fourty bytes of every packet. Leave it to <tt>0</tt>
<tag>--ulog-qthreshold N</tag>
Queue threshold.  If a packet is matched by the iptables rule, and already N
packets are in the queue, the queue is flushed to userspace.  You can use this
to implement a policy like: Use a big queue in order to gain high performance,
but still have certain packets logged immediately to userspace.
<tag>--ulog-prefix STRING</tag>
A string that is associated with every packet logged by this rule.  You can use
this option to later tell from which rule the packet was logged.
</descrip>

<sect2>ipt_ULOG module parameters
<p>
The ipt_ULOG kernel module has a couple of module loadtime parameters which can
(and should) be tuned to accomodate the needs of the application:
<descrip>
<tag>nlbufsiz N</tag>
Netlink buffer size. A buffer of the specified size N is allocated for every
netlink group that is used.  Please note that due to restrictions of the kernel
memory allocator, we cannot have a buffer size &gt; 128kBytes.  Larger buffer
sizes increase the performance, since less kernel/userspace context switches
are needed for the same amount of packets.  The backside of this performance
gain is a potentially larger delay. The default value is 4096 bytes, which is
quite small.
<tag>flushtimeout N</tag> 
The flushtimeout determines, after how many clock ticks (on alpha: 1ms, on
x86 and most other platforms: 10ms time units) the buffer/queue is to be
flushed, even if it is not full.  This can be used to have the advantage of a
large buffer, but still a finite maximum delay introduced.  The default value
is set to 10 seconds.
</descrip>
Example:
<tscreen><verb>
modprobe ipt_ULOG nlbufsiz=65535 flushtimeout=100
</verb></tscreen>
This would use a buffer size of 64k and a flushtimeout of 100 clockticks (1 second on x86).

<sect1>ulogd
<p>
ulogd is what this is all about, so let's describe it's configuration...
<sect2>ulogd configfile syntax reference
<p>
All configurable parameters of ulogd are in the configfile, typically located
at '/etc/ulogd.conf'.
<p>
The following configuration parameters are available:
<descrip>
<tag>logfile</tag>
The main logfile, where ulogd reports any errors, warnings and other unexpected conditions. Apart from a regular filename, the following special values can be used; ``syslog'' to log via the unix syslog(3) mechanism.  ``stdout'' to log to stdout.
<tag>loglevel</tag>
This specifies, how verbose the logging to logfile is. Currently defined
loglevels are: 1=debug information, 3=informational messages, 5=noticable
exceptional conditions, 7=error conditions, 8=fatal errors, program abort.
<tag>plugin</tag>
This option is followed by a filename of a ulogd plugin, which ulogd should load
upon initialization. This option may appear more than once.
<tag>stack</tag>
This option is followed by a list of plugin instances which will start with an input plugin, contains optionnal
filtering plugin and finish by an output plugin. This option may appear more than once.
</descrip>
<sect2>ulogd commandline option reference
<p>
Apart from the configfile, there are a couple of commandline options to ulogd:
<descrip>
<tag>-h --help</tag>
Print a help message about the commandline options.
<tag>-V --version</tag>
Print version information about ulogd.
<tag>-d --daemon</tag> 
For off into daemon mode.  Unless you are debugging, you will want to use this
most of the time.
<tag>-c --configfile</tag>
Using this commandline option, an alternate config file can be used.  This is
important if multiple instances of ulogd are to be run on a single machine.
<tag>-i --info</tag>
Display informations about the plugin whom filename is given as argument.
</descrip>

<sect>Signals / Logrotate
<p>
ulogd understands two kinds of signals:
<descrip>
<tag>SIGHUP</tag>
Close and re-open all logfiles.  This is mainly intended for logrotate scripts.
Also closes and re-opens database connections.
<tag>SIGUSR1</tag>
Reload configuration file.  This is not fully implemented yet.
</descrip>

<sect>Available plugins
<p>
It is important to understand that ulogd without plugins does nothing.  It will receive packets, and do nothing with them.
<p>
There are two kinds of plugins, interpreter and output plugins.  Interpreter
plugins parse the packet, output plugins write the interpreted information to
some logfile/database/...
<p>
You can get information about plugins by running
<code>
ulogd -i path/to/plugin/file.so
</code>

<sect1>Input plugins
<p>
ulogd comes with the following input plugins:

<sect2>ulogd_inppkt_NFLOG.so
<p>
This interfaces the new nfnetlink_log interface.  To compile, you need
libnetfilter_log installed in your system.
<descrip>
<tag>group</tag>
The number of the netlink multicast group to which NFLOG'ed packets are sent.
You will have to use the same group number in the NFLOG target (--nflog-group) and in the input plugin.
<tag>addressfamily</tag>
You will need to specify the value of the protocol if you are not loging IPv4 packet.
addressfamily is 7 to bridged packet and 10 for IPv6 packet.
<tag>numeric_label</tag>
You can use this label to store information relative to the logging. The administrator can define a convention which can be used later to differenciate packet. For example, it can store the severity of the logged event.
<tag>netlink_socket_buffer_size</tag>
Specify the base socket buffer size. This start value will be increased if needed up to netlink_socket_buffer_maxsize. 
<tag>netlink_socket_buffer_maxsize</tag>
Specify the base socket buffer maximum size.
</descrip>

<sect2>ulogd_inpflow_NFCT.so
<p>
This interfaces the nfnetlink_conntrack kernel subsystem, and provides
flow-based logging.  To compile, you need libnetfilter_conntrack installed on
your system.
<descrip>
<tag>pollinterval</tag>
Change connection tracking dump interval.
<tag>hash_enable</tag>
If set to 1 (default) a internal hash will be stored and only destroy event will reach the output plugin.
It set to 0, all events are reveived by the output plugin.
<tag>hash_buckets</tag>
Size of the internal hash bucket.
<tag>hash_max_entries</tag>
Maximum number of entries in the internal connection hash.
<tag>event_mask</tag>
Select event received from kernel based on a mask. Event types are defined as follows:
<itemize>
<item>Creation event: 0x00000001</item>
<item>Update event: 0x00000002</item>
<item>Destroy event: 0x00000004</item>
</itemize>
<tag>netlink_socket_buffer_size</tag>
Specify the base socket buffer size. This start value will be increased if needed up to netlink_socket_buffer_maxsize. 
<tag>netlink_socket_buffer_maxsize</tag>
Specify the base socket buffer maximum size.
</descrip>



<sect2>ulogd_inppkt_ULOG.so
<p>
The good old ipt_ULOG input plugin.  This basically emulates ulogd-1.x which
didn't have input plugins.
<descrip>
<tag>nlgroup</tag>
The number of the netlink multicast group to which ULOG'ed packets are sent.
You will have to use the same group number in the ULOG target and nin the input plugin.
<tag>numeric_label</tag>
You can use this label to store information relative to the logging. The administrator can define a convention which can be used later to differenciate packet. For example, it can store the severity of the logged event.
</descrip>




<sect1>Interpreter plugins
<p>
ulogd comes with the following interpreter plugins:

<sect2>ulogd_raw2packet_BASE.so
<p>
Basic interpreter plugin for nfmark, timestamp, mac address, ip header, tcp
header, udp header, icmp header, ah/esp header... Most people will want to load
this very important plugin.

<sect2>ulogd_filter_PWSNIFF.so
<p>
Example interpreter plugin to log plaintext passwords as used with FTP and
POP3. Don't blame me for writing this plugin! The protocols are inherently
insecure, and there are a lot of other tools for sniffing passwords... it's
just an example.

<sect2>ulogd_filter_IFINDEX.so
<p>
Filter plugin that provides translation from the numerical ifindex (e.g. '1') to the
network interface name (e.g. 'eth4').

<sect2>ulogd_LOCAL.so
<p>
This is a 'virtual interpreter'.  It doesn't really return any information on
the packet itself, rather the local system time and hostname.  Please note that
the time is the time at the time of logging, not the packets receive time.

<sect2>ulogd_filter_HWHDR.so
<p>
This plugin convert hardware header to string. In the case of ethernet packet,
it basically convert mac address to a string represetation.

<sect2>ulogd_filter_IP2BIN.so
<p>
This plugin convert IP addresses to a binary form usable by databases like MySQL.

<sect2>ulogd_filter_IP2STR.so
<p>
This plugin convert IP addresses to string.

<sect2>ulogd_filter_PRINTFLOW.so
<p>
Convert the keys relative to a flow in a string readable by human.

<sect2>ulogd_filter_PRINTPKT.so
<p>
Convert the keys relative to a packet in a string readable by human. This plugin has
to be used to print packet in the format similar to the LOG target format.

<sect2>ulogd_filter_MARK.so
<p>
When this plugin is put in a stack, only messages were the mark (packet mark or connection
mark) matches the given mark/mask will be logged.
<descrip>
<tag>mark</tag>
Define the mark which will be used to check packet or flow.
<tag>mask</tag>
Define the mask which will be used to check packet or flow.
</descrip>

<sect1>Output plugins
<p>
ulogd comes with the following output plugins:

<sect2>ulogd_output_OPRINT.so
<p>
A very simple output module, dumping all packets in the format
<tscreen><verb>
===>PACKET BOUNDARY
key=value
key=value
...
===>PACKET BOUNDARY
...
</verb></tscreen>
to a file.  The only useful application is debugging.
<p>The module defines the following configuration directives:
<descrip>
<tag>dumpfile</tag>
The filename where it should log to. The default is
<tt>/var/log/ulogd.pktlog</tt>
</descrip>

<sect2>ulogd_output_LOGEMU.so
<p>
An output module which tries to emulate the old syslog-based LOG targed as far
as possible. Logging is done to a seperate textfile instead of syslog, though.
<p>
The module defines the following configuration directives:
<descrip>
<tag>file</tag>The filename where it should log to. The default is
<tt>/var/log/ulogd.syslogemu</tt>
<tag>sync</tag>Set this to 1 if you want to have your logfile written
synchronously. This may reduce performance, but makes your log-lines appear
immediately.  The default is <tt>0</tt>
</descrip>

<sect2>ulogd_output_MYSQL.so
<p>
An output plugin for logging into a mysql database. This is only compiled if
you have the mysql libraries installed, and the configure script was able to
detect them. (that is: --with-mysql was specified for ./configure)

<p>
The plugin automagically runs a procedure with arguments taken from a  the configurable
 table; It
connects to mysql during the startup phase of ulogd and obtains a list of the
columns in the table. Then it tries to resolve the column names against keys of
interpreter plugins. This way you can easily select which information you want
to log - just by the layout of the table.

<p>
If, for example, your table contains a field called 'ip_saddr', ulogd will
resolve this against the key 'ip.saddr' and put the ip address as 32bit
unsigned integer into the corresponding argument of table.

<p>
The file '<tt>doc/mysql-ulogd2.sql</tt>' contains a schema for both packet and flow logging.

<p>
The module defines the following configuration directives:
<descrip>
<tag>table</tag>
Name of the table which ulogd will use to build arguments list.
<tag>procedure</tag> 
Stored procedure that will be run with the argument specified in the
table variable.
<tag>db</tag>
Name of the mysql database.
<tag>host</tag>
Name of the mysql database host.
<tag>port</tag>
TCP port number of mysql database server.
<tag>user</tag>
Name of the mysql user.
<tag>pass</tag>
Password for mysql.
<tag>reconnect</tag>
Number of reconnection attempt before declaring the output plugin as
dead.
<tag>connect_timeout</tag>
Database connection timeout.
</descrip>

<sect2>ulogd_output_PGSQL.so
<p>
An output plugin for logging into a postgresql database. This is only compiled
if you have the pgsql libraries installed, and the configure script was able to
detect them. (that is: --with-pgsql was specified for ./configure)

<p>
The plugin automagically runs a procedure with arguments taken from a  the configurable
 table; It
connects to pgsql during the startup phase of ulogd and obtains a list of the
columns in the table. Then it tries to resolve the column names against keys of
interpreter plugins. This way you can easily build your own procedure and select it
arguments just by modifying the layout of the table.

<p>
If, for example, your table contains a field called 'ip_saddr', ulogd will
resolve this against the key 'ip.saddr' and put the ip address as 32bit
unsigned integer into the table.

<p>
The file '<tt>doc/pgsql-ulogd2.sql</tt>' contains a schema for both packet and flow logging.

<p>
The module defines the following configuration directives:
<descrip>
<tag>table</tag>
Name of the table which ulogd will use to build arguments list.
<tag>procedure</tag> 
Stored procedure that will be run with the argument specified in the
table variable.
<tag>schema</tag>
PGSQL schema to use.
<tag>db</tag>
Name of the database.
<tag>host</tag>
Name of the mysql database host.
<tag>port</tag>
TCP port number of database server.
<tag>user</tag>
Name of the sql user.
<tag>pass</tag>
Password for sql user.
<tag>reconnect</tag>
Number of reconnection attempt before declaring the output plugin as
dead.
<tag>connect_timeout</tag>
Database connection timeout.
</descrip>

<sect2>ulogd_output_PCAP.so
<p>
An output plugin that can be used to generate libpcap-style packet logfiles.
This can be useful for later analysing the packet log with tools like tcpdump
or ethereal.

The module defines the following configuration directives:
<descrip>
<tag>file</tag>
The filename where it should log to.  The default is:
<tt>/var/log/ulogd.pcap</tt>
<tag>sync</tag>
Set this to <tt>1</tt> if you want to have your pcap logfile written
synchronously.  This may reduce performance, but makes your packets appear
immediately in the file on disk.  The default is <tt>0</tt>
</descrip>

<sect2>ulogd_output_SQLITE3.so
<p>
An output plugin for logging into a SQLITE v3 database. This is only compiled
if you have the sqlite libraries installed, and the configure script was able to
detect them. (that is: --with-sqlite3 was specified for ./configure)

<p>
The plugin automagically inserts the data into the configured table; It
opens the sqlite db during the startup phase of ulogd and obtains a list of the
columns in the table. Then it tries to resolve the column names against keys of
interpreter plugins. This way you can easily select which information you want
to log - just by the layout of the table.

<p>
If, for example, your table contains a field called 'ip_saddr', ulogd will
resolve this against the key 'ip.saddr' and put the ip address as 32bit
unsigned integer into the table.

<p>
You may want to have a look at the file '<tt>doc/sqlite3.table</tt>' as an
example table including fields to log all keys from ulogd_BASE.so. Just delete
the fields you are not interested in, and create the table.

<p>
The module defines the following configuration directives:
<descrip>
<tag>table</tag>
Name of the table to which ulogd should log.
<tag>db</tag>
Name of the database.
<tag>buffer</tag>
Size of the sqlite buffer.
</descrip>
</sect2>

<sect2>ulogd_output_SYSLOG.so
<p>
An output plugin that really logs via syslogd. Lines will look exactly like printed with traditional LOG target.

<p>
The module defines the following configuration directives:
<descrip>
<tag>facility</tag>
The syslog facility (LOG_DAEMON, LOG_KERN, LOG_LOCAL0 .. LOG_LOCAL7, LOG_USER)
<tag>level</tag>
The syslog level (LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG)
</descrip>
</sect2>

<sect> QUESTIONS / COMMENTS
<p>
All comments / questions / ... are appreciated.
<p>
Just drop a note to netfilter-devel@vger.kernel.org.
<p> 
The preferred method for reporting bugs is the netfilter bugzilla system,
available at <URL URL="http://bugzilla.netfilter.org/">.

</article>