]>
Commit | Line | Data |
---|---|---|
1 | .TH IPL 4 | |
2 | .SH NAME | |
3 | ipl - IP packet log device | |
4 | .SH DESCRIPTION | |
5 | The \fBipl\fP pseudo device's purpose is to provide an easy way to gather | |
6 | packet headers of packets you wish to log. If a packet header is to be | |
7 | logged, the entire header is logged (including any IP options - TCP/UDP | |
8 | options are not included when it calculates header size) or not at all. | |
9 | The packet contents is also logged after the header. | |
10 | .LP | |
11 | .PP | |
12 | Prepending every packet header logged is a structure containing information | |
13 | relevant to the packet following and why it was logged. The structure's | |
14 | format is as follows: | |
15 | .LP | |
16 | .nf | |
17 | struct ipl_ci { | |
18 | u_long sec; /* time when the packet was logged */ | |
19 | u_long usec; | |
20 | u_long plen; /* length of packet data logged */ | |
21 | u_short hlen; /* length of headers logged */ | |
22 | u_short rule; /* rule number (for log ...) or 0 if result = log */ | |
23 | u_long flags:24; /* XXX FIXME do we care about the extra bytes? */ | |
24 | #if (defined(OpenBSD) && (OpenBSD <= 1991011) && (OpenBSD >= 199606)) | |
25 | u_long filler:8; /* XXX FIXME do we care? */ | |
26 | u_char ifname[IFNAMSIZ]; | |
27 | #else | |
28 | u_long unit:8; | |
29 | u_char ifname[4]; | |
30 | #endif | |
31 | }; | |
32 | .nf | |
33 | .PP | |
34 | In the case of the header causing the buffer to finish on a non-32bit | |
35 | boundary, padding will be `appended' to ensure that the next log entry | |
36 | is aligned to a 32bit boundary. | |
37 | .LP | |
38 | .PP | |
39 | If the packet contents is more then 128 bytes, then only 128 bytes of the | |
40 | packet contents is logged. Should the packet contents finish on a non-32bit | |
41 | boundary, then the last few bytes are not logged to ensure the log entry | |
42 | is aligned to a 32bit boundary. | |
43 | ||
44 | \fBipl\fP is a read-only (sequential) character pseudo-device. | |
45 | ||
46 | The ioctls which are loaded with this device can be found under \fBipf(4)\fP. | |
47 | The only ioctl which is used for logging and doesn't affect the filter is: | |
48 | .LP | |
49 | .nf | |
50 | ioctl(fd, SIOCIPFFB, int *) | |
51 | .fi | |
52 | .PP | |
53 | This ioctl flushes the log buffer and returns the number of bytes flushed. | |
54 | .PP | |
55 | There is currently no support for non-blocking IO with this device, meaning | |
56 | all read operations should be considered blocking in nature (if there is no | |
57 | data to read, it will sleep until some is made available). | |
58 | .SH SEE ALSO | |
59 | ipf(4) | |
60 | .SH BUGS | |
61 | Packet headers are dropped when the internal buffer (static size) fills. | |
62 | .SH FILES | |
63 | /dev/ipl0 |