tcpdump filter for out/in traffic
Здравствуйте, Questions. There will be very usefull to have options for tcpdump to monitor incomint or outgoing traffic regardless of src/dst IPs or ports or protocol For example: kes# tcpdump -n -i rl4 out EXPECTED: show traffic outgoing on rl4 ACTUAL: tcpdump: syntax error kes# tcpdump -n -i rl4 in EXPECTED: show traffic incoming on rl4 ACTUAL: tcpdump: syntax error -- С уважением, KES mailto:kes-...@yandex.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tcpdump filter for out/in traffic
On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: There will be very usefull to have options for tcpdump to monitor incomint or outgoing traffic regardless of src/dst IPs or ports or protocol For example: kes# tcpdump -n -i rl4 out EXPECTED: show traffic outgoing on rl4 ACTUAL: tcpdump: syntax error kes# tcpdump -n -i rl4 in EXPECTED: show traffic incoming on rl4 ACTUAL: tcpdump: syntax error Hi! I use following trick for that: tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' or just 'me' if you need not watch other interfaces this way. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tcpdump filter for out/in traffic
On Sun, Jan 4, 2009 at 10:56 AM, Eugene Grosbein eu...@kuzbass.ru wrote: On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: There will be very usefull to have options for tcpdump to monitor incomint or outgoing traffic regardless of src/dst IPs or ports or protocol For example: kes# tcpdump -n -i rl4 out EXPECTED: show traffic outgoing on rl4 ACTUAL: tcpdump: syntax error kes# tcpdump -n -i rl4 in EXPECTED: show traffic incoming on rl4 ACTUAL: tcpdump: syntax error Hi! I use following trick for that: tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' or just 'me' if you need not watch other interfaces this way. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org don't even need an option you just have to filter the traffic correctly using tcpdump which Eugene already point out ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set
Hi,
On Thu, Jan 01, 2009 at 11:42:12PM -0800, Doug Barton wrote:
In working on cross-platform support for mergemaster I came across the
following problem. I set MAKEOBJDIRPREFIX to be that of the temproot
environment, which works fine when you do not specify a TARGET_ARCH.
When you do specify TARGET_ARCH there is a conflict between
src/Makefile.inc1 and share/mk/bsd.obj.mk.
The former does this:
.if ${MACHINE} == ${TARGET} !defined(CROSS_BUILD_TESTING)
OBJTREE=${MAKEOBJDIRPREFIX}
.else
OBJTREE=${MAKEOBJDIRPREFIX}/${TARGET}
.endif
OBJTREE is a variable internal to Makefile.inc1; it's then assigned to
a MAKEOBJDIRPREFIX environment variable which make(1) understands and
uses to find the actual object directory.
however the latter does this:
.if defined(MAKEOBJDIRPREFIX)
CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
CANONICALOBJDIR is what we (BSD, FreeBSD) choose to be a canonical
object directory out of the list of possible object directories
make(1) understands; the list is documented in the manpage:
: 1. ${MAKEOBJDIRPREFIX}/`pwd`
: 2. ${MAKEOBJDIR}
: 3. obj.${MACHINE}
: 4. obj
: 5. /usr/obj/`pwd`
That is, 1 and 5.
There's no conflict between bsd.obj.mk and Makefile.inc1; the former
creates a canonical object directory with the default obj target,
${MAKEOBJDIRPREFIX}/`pwd` or /usr/obj/`pwd`, and Makefile.inc1 only
changes the value of MAKEOBJDIRPREFIX environment variable.
bsd.obj.mk doesn't (and shouldn't) know anything about OBJTREE which
is internal to Makefile.inc1.
When trying to install the stuff in src/etc/sendmail install(1) cannot
find the file because it is built in foo/obj but it's looking for it
in foo/obj/$target
You should set MAKEOBJDIRPREFIX to the same value for build and
install targets. If you set it only for the install target,
you'll get what you describe; let's see...
The simplest fix I found was to do the following in bsd.obj.mk:
Index: bsd.obj.mk
===
--- bsd.obj.mk(revision 186676)
+++ bsd.obj.mk(working copy)
@@ -43,7 +43,7 @@
.include bsd.own.mk
.if defined(MAKEOBJDIRPREFIX)
-CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
+CANONICALOBJDIR:=${OBJTREE}${.CURDIR}
.else
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
This change is plain wrong and shouldn't be committed.
However I would be happy with any solution that makes it work. It's
trivial to test with 'mergemaster -i -D/temp/dir/for/root -A arm'
The problem is that Makefile.inc1 sets MAKEOBJDIRPREFIX for world-
related targets specially, taking into account the value of ${TARGET},
to be able to use a single directory to build worlds for different
architectures.
mergemaster.sh uses obj and all targets which aren't cross-build
aware (don't take ${TARGET} into account) to build etc/ bits, and then
distribution target (which is cross-build aware) to install then.
The effect of this is that you end up with build and install targets
having different ideas of MAKEOBJDIRPREFIX. The fix is to use cross-aware
versions of obj and all targets:
%%%
Index: mergemaster.sh
===
RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.63
diff -u -p -r1.63 mergemaster.sh
--- mergemaster.sh 2 Jan 2009 00:37:59 - 1.63
+++ mergemaster.sh 4 Jan 2009 20:18:40 -
@@ -588,8 +588,8 @@ case ${RERUN} in
;;
esac
${MM_MAKE} DESTDIR=${TEMPROOT} ${ARCHSTRING} distrib-dirs
- MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} obj
SUBDIR_OVERRIDE=etc
- MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} all
SUBDIR_OVERRIDE=etc
+ MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} _obj
SUBDIR_OVERRIDE=etc
+ MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} everything
SUBDIR_OVERRIDE=etc
MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj ${MM_MAKE} ${ARCHSTRING} \
DESTDIR=${TEMPROOT} distribution;} ||
{ echo '';
%%%
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lzo2 shows insane speed gap
Christian Weisgerber wrote: Bruce Cran br...@cran.org.uk wrote: I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without malloc debugging (malloc.conf - aj) 'make test' takes 25s; after removing malloc.conf thus turning on debugging, it takes over 10 minutes. Wow! That. Is. It. Toggling malloc debugging option J makes the slow machines fast and vice versa. Athlon 64 X2 5200+ 2.6 GHz, FreeBSD 8.0-CURRENT amd64 ~60 min 19 seconds. I guess that falls under the obvious configuration differences to check, but since it usually doesn't cause a significant slowdown I completely forgot about it. Embarrassing. But still. Two orders of magnitude? That is a pathological case. Probably it means that lzo2 is doing pathological numbers of mallocs. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bsd.obj.mk does not set CANONICALOBJDIR correctly when TARGET_ARCH and MAKEOBJDIRPREFIX are set
Ruslan Ermilov wrote:
mergemaster.sh uses obj and all targets which aren't cross-build
aware (don't take ${TARGET} into account) to build etc/ bits, and then
distribution target (which is cross-build aware) to install then.
The effect of this is that you end up with build and install targets
having different ideas of MAKEOBJDIRPREFIX. The fix is to use cross-aware
versions of obj and all targets:
Thanks for responding. I was working on this the other day and
discovered that the reason my suggested change worked was really an
unintended side effect. Your suggestion works great, so I've committed it.
Doug
--
This .signature sanitized for your protection
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tcpdump filter for out/in traffic
On Monday 05 January 2009 02:26:38 Eugene Grosbein wrote: On Sun, Jan 04, 2009 at 04:05:00PM +0200, KES wrote: There will be very usefull to have options for tcpdump to monitor incomint or outgoing traffic regardless of src/dst IPs or ports or protocol For example: kes# tcpdump -n -i rl4 out EXPECTED: show traffic outgoing on rl4 ACTUAL: tcpdump: syntax error kes# tcpdump -n -i rl4 in EXPECTED: show traffic incoming on rl4 ACTUAL: tcpdump: syntax error Hi! I use following trick for that: tcpdump -n -p -i rl4 ether src me-rl4 # for outgoing tcpdump -n -p -i tl4 not ether src me-rl4 # for incoming And add MAC-address of rl4 to /etc/ethers with name 'me-rl4' or just 'me' if you need not watch other interfaces this way. I think it's more a question for the tcpdump maintainers. Also, in out don't necessarily mean traffic from your MAC address or the inverse. eg if you are running a bridge then in out will mean something different. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
