[no subject]

2012-05-15 Thread Шевченко Илья
Dk sqoexmncn p`gbhrh ahgmeq` menaundhl` j`weqrbemm` h dnqrsom` pejk`l`. B
m`xe bpel nqmnbm{l qpedqrbnl pejk`l{ bkerq Hmrepmer, on qjnk|js d`er
bnglnfmnqr| p`qxhphr| cp`mhv{, nap`rhr| m` qea bmhl`mhe h ophbkew| mnb{u
jkhemrnb hg whqk` xhpnjni `sdhrnphh "bqelhpmni o`srhm{".

Opedk`c`el B`l sqksch on qngd`mh~ Hmrepmer-q`irnb h kncnrhonb.

Cnrnb{i q`ir ond jk~w nr 8 000 psakei.

Kncnrho{ nr 1000 psakei.



Re: Latest libpcap 1.2.0 diff (2012-05-11)

2012-05-15 Thread Lawrence Teo
On Tue, May 15, 2012 at 08:06:43PM +0100, Stuart Henderson wrote:
> On 2012/05/15 14:19, Lawrence Teo wrote:
> > If anyone would like to test the diff, the programs in base that link to
> > libpcap and would also require testing are:
> > 
> > - /usr/libexec/spamlogd
> > - /usr/sbin/pppd
> > - /usr/sbin/tcpdump
> > - /sbin/tcpdump
> 
> I think you meant pflogd ;)

Oops, yes, thank you for catching that!

Lawrence



Re: Latest libpcap 1.2.0 diff (2012-05-11)

2012-05-15 Thread Stuart Henderson
On 2012/05/15 14:19, Lawrence Teo wrote:
> I sent a diff to update libpcap in base in November 2011 [1].  Here's
> the latest version that fixes a bug I found after running regression
> tests on all pcap-based ports in the ports tree.

For the record Lawrence has done a huge bunch of testing on this
already, but if you rely on anything in ports or base which uses pcap
please do verify that it doesn't break anything for you.

> If anyone would like to test the diff, the programs in base that link to
> libpcap and would also require testing are:
> 
> - /usr/libexec/spamlogd
> - /usr/sbin/pppd
> - /usr/sbin/tcpdump
> - /sbin/tcpdump

I think you meant pflogd ;)



Latest libpcap 1.2.0 diff (2012-05-11)

2012-05-15 Thread Lawrence Teo
I sent a diff to update libpcap in base in November 2011 [1].  Here's
the latest version that fixes a bug I found after running regression
tests on all pcap-based ports in the ports tree.

If anyone would like to test the diff, the programs in base that link to
libpcap and would also require testing are:

- /usr/libexec/spamlogd
- /usr/sbin/pppd
- /usr/sbin/tcpdump
- /sbin/tcpdump

There's also a test program in /usr/src/regress/lib/libpthread/pcap/
that uses libpcap.

I have set up a simple page at the following URL to keep track of my own
progress and to encourage more widespread testing.

http://lteo.net/libpcap/

If you do test it, I would really appreciate it if you could please let
me know your feedback, both positive and negative.

Thank you!
Lawrence

[1] http://marc.info/?l=openbsd-tech&m=132029368027597&w=2



How to apply:

cd /usr/src/lib/libpcap
patch < libpcap-1.2.0-20120511.diff
make obj
make includes
make
make install

cd /usr/src/usr.sbin/tcpdump
make obj && make && make install

cd /usr/src/libexec/spamlogd
make obj && make && make install

cd /usr/src/sbin/pflogd
make obj && make && make install

cd /usr/src/usr.sbin/pppd
make obj && make && make install

Index: Makefile
===
RCS file: /cvs/src/lib/libpcap/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile13 Aug 2009 19:54:58 -  1.20
+++ Makefile11 May 2012 04:35:01 -
@@ -25,11 +25,15 @@ MLINKS= pcap.3 pcap_open_live.3 pcap.3 p
pcap.3 pcap_sendpacket.3 pcap.3 pcap_next_ex.3 \
pcap.3 pcap_setdirection.3 pcap.3 pcap_dump_file.3 \
pcap.3 pcap_dump_ftell.3 pcap.3 pcap_fopen_offline.3 \
-   pcap.3 pcap_dump_flush.3
+   pcap.3 pcap_dump_flush.3 pcap.3 pcap_create.3 \
+   pcap.3 pcap_set_snaplen.3 pcap.3 pcap_set_promisc.3 \
+   pcap.3 pcap_can_set_rfmon.3 pcap.3 pcap_set_rfmon.3 \
+   pcap.3 pcap_set_timeout.3 pcap.3 pcap_set_buffer_size.3 \
+   pcap.3 pcap_activate.3 pcap.3 pcap_statustostr.3
 
 DEFS=  -DHAVE_SYS_IOCCOM_H -DHAVE_SYS_SOCKIO_H -DHAVE_ETHER_HOSTTON \
-DHAVE_STRERROR -DHAVE_SOCKADDR_SA_LEN -DLBL_ALIGN -DHAVE_IFADDRS_H \
-   -DINET6
+   -DINET6 -DHAVE_BSD_IEEE80211
 
 CFLAGS+=-I. -I${.CURDIR} -Dyylval=pcap_yylval ${DEFS}
 
Index: pcap-bpf.c
===
RCS file: /cvs/src/lib/libpcap/pcap-bpf.c,v
retrieving revision 1.20
diff -u -p -r1.20 pcap-bpf.c
--- pcap-bpf.c  26 Mar 2006 20:58:51 -  1.20
+++ pcap-bpf.c  11 May 2012 04:35:01 -
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include 
+
 #include "pcap-int.h"
 
 #ifdef HAVE_OS_PROTO_H
@@ -46,6 +48,12 @@
 
 #include "gencode.h"
 
+static int find_802_11(struct bpf_dltlist *);
+static int monitor_mode(pcap_t *, int);
+
+static int pcap_activate_bpf(pcap_t *p);
+static int pcap_setfilter_bpf(pcap_t *p, struct bpf_program *fp);
+
 int
 pcap_stats(pcap_t *p, struct pcap_stat *ps)
 {
@@ -54,7 +62,7 @@ pcap_stats(pcap_t *p, struct pcap_stat *
if (ioctl(p->fd, BIOCGSTATS, (caddr_t)&s) < 0) {
snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "BIOCGSTATS: %s",
pcap_strerror(errno));
-   return (-1);
+   return (PCAP_ERROR);
}
 
ps->ps_recv = s.bs_recv;
@@ -76,11 +84,11 @@ pcap_read(pcap_t *p, int cnt, pcap_handl
if (p->break_loop) {
/*
 * Yes - clear the flag that indicates that it
-* has, and return -2 to indicate that we were
-* told to break out of the loop.
+* has, and return PCAP_ERROR_BREAK to indicate
+* that we were told to break out of the loop.
 */
p->break_loop = 0;
-   return (-2);
+   return (PCAP_ERROR_BREAK);
}
 
cc = p->cc;
@@ -95,6 +103,21 @@ pcap_read(pcap_t *p, int cnt, pcap_handl
 
case EWOULDBLOCK:
return (0);
+
+   case ENXIO:
+   /*
+* The device on which we're capturing
+* went away.
+*
+* XXX - we should really return
+* PCAP_ERROR_IFACE_NOT_UP, but
+* pcap_dispatch() etc. aren't
+* defined to retur that.
+*/
+   snprintf(p->errbuf, PCAP_ERRBUF_SIZE,
+   "The interface went down");
+   return (PCAP_ERROR);
+
 #if defined(sun) && !defined(BSD)
/*
 * Due to a SunOS bug, after 2^31 bytes, the kernel
@@ -112,7 +135,7 @@ pcap_read(pcap_t *p, int cnt, pcap_handl
}
 

Re: pf logs: def/(short) pass in , but should say block

2012-05-15 Thread Leonardo Guardati
On 05/14/2012 08:41 PM, Alexander Bluhm wrote:
> 
> The variable action does not hold the final action at this place.
> It could be PF_SYNPROXY_DROP PF_DEFER PF_DIVERT PF_AFRT, we don't
> want to log this.  It is rewrittren in the switch (action) block
> below.


> 
> Moving the logging after the switch is not an option as the mbuf
> *m0 might get freed there.

Can *m0 freeing be postponed?

> 
> We could do PFLOG_PACKET(&pd, reason, action == PF_PASS ?  PF_PASS
> : PF_DROP, ri->r, a, ruleset) for most cases.  Unfortunately PF_AFRT
> could be set to PF_DROP in some cases.

Also PF_PASS could be set to PF_DROP by pf_refragment6() in pf.c:7025

> 
> Any ideas for a better fix?

If *m0 could be freed at the very end of pf_test(), it would be possible
to move PFLOG_PACKET() ( and pf_counters_inc() ) to the end right before
the *m0 freeing.

The only cases where this cannot be controlled is when pf_route() or
pf_route6() is called ( the case PF_AFRT: and default: of the last
switch(action) ).
Maybe in those cases *m0 can be copied before passing it to pf_route()
so it can be used by PFLOG_PACKET().

But probably this would impact badly the performances.


Leonardo