Re: kern/116330: [nfe]: network problems under -current, nfe(4) and jumbo packets
Synopsis: [nfe]: network problems under -current, nfe(4) and jumbo packets Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Sep 27 07:20:53 UTC 2007 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=116330 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels
Hello there, I have problems with racoon hanging in sbwait state with ipsec-tools 0.6.7 or getting into a tailspin on ipsec-tools 0.7. The problem is that the pfkey interface breaks down with a lot of VPN tunnels and spd entries. The FreeBSd PR is here. http://www.freebsd.org/cgi/query-pr.cgi?pr=115651 I have 390 discrete IPSEC VPN tunnels and endpoints. I have loaded this all up into one config. I am using pfSense as the platform of choice. pfSense 1.2-RC2 specifically which is based on FreeBSD 6.2 Stable p7. Note that I am also a pfSense developer. At this current time I have exactly 112 IPSEC tunnels active. I am using 3des-sha1 with a 3600 lifetime for phase 1 and aes128-sha1 with a 28800 lifetime for phase2. On ipsec-tools 0.6.7 I can go by for several days before the racoon process wedges itself into a hanging sbwait state (0% cpu). On ipsec-tools 0.7 the situation is significantly worse and it starts churning 100% cpu somewhere every 1-4 hours. Basically where 0.6.7 was difficult 0.7 has become unworkable. The hardware in question is a Dell PE860 with 6 gigabit nics (about 2mbps ipsec traffic at most) with a DualCore Xeon 3050 2.13Ghz. With 1GB ram. In the pfSense kernel we use this patch. http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/RELENG_6_2/socketvar.h.diff Which helps significantly. Without this patch the situation is the same as I have described above but will be reached at about 30-40 active tunnels instead of the 112 I have now. I really need a reliable solution to this problem. Kind regards, Seth Mos pfSense Developer ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels
On Thu, Sep 27, 2007 at 04:01:32PM +0200, Seth Mos wrote: > Hello there, Hi. > I have problems with racoon hanging in sbwait state with ipsec-tools 0.6.7 > or getting into a tailspin on ipsec-tools 0.7. > > The problem is that the pfkey interface breaks down with a lot of VPN > tunnels and spd entries. The FreeBSd PR is here. > http://www.freebsd.org/cgi/query-pr.cgi?pr=115651 Yep. Unfortunately, this is a well know issue for a quite long time. > I have 390 discrete IPSEC VPN tunnels and endpoints. I have loaded this > all up into one config. I am using pfSense as the platform of choice. > pfSense 1.2-RC2 specifically which is based on FreeBSD 6.2 Stable p7. Note > that I am also a pfSense developer. > > At this current time I have exactly 112 IPSEC tunnels active. I am using > 3des-sha1 with a 3600 lifetime for phase 1 and aes128-sha1 with a 28800 > lifetime for phase2. > > On ipsec-tools 0.6.7 I can go by for several days before the racoon > process wedges itself into a hanging sbwait state (0% cpu). On ipsec-tools > 0.7 the situation is significantly worse and it starts churning 100% cpu > somewhere every 1-4 hours. > > Basically where 0.6.7 was difficult 0.7 has become unworkable. That's strange, I don't remind any change between 0.6 and 0.7 which may generate such difference. And, to be more exact, I don't remember anything in 0.6 branch (or in any other public branch) which may help things work better in such setup. > The hardware in question is a Dell PE860 with 6 gigabit nics (about 2mbps > ipsec traffic at most) with a DualCore Xeon 3050 2.13Ghz. With 1GB ram. > > In the pfSense kernel we use this patch. > http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/RELENG_6_2/socketvar.h.diff > Which helps significantly. Without this patch the situation is the same as > I have described above but will be reached at about 30-40 active tunnels > instead of the 112 I have now. The first thing you can try is that patch in racoon: --- src/libipsec/pfkey.c1 Aug 2007 11:52:18 - 1.13.4.1 +++ src/libipsec/pfkey.c27 Sep 2007 14:44:27 - @@ -1801,7 +1801,12 @@ pfkey_open() */ (void)setsockopt(so, SOL_SOCKET, SO_SNDBUF, &bufsiz, sizeof(bufsiz)); (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); - + bufsiz = 256 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); + bufsiz = 512 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); + bufsiz = 1024 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); __ipsec_errcode = EIPSEC_NO_ERROR; return so; } (you may have problems to directly apply this patch because it's a copy/paste, but it's quite easy to report manually). And as we have more and more requests about such problems, I'll probably directly commit it for ipsec-tools 0.7.1 / HEAD. But I'm quite sure it will not completly solve your problem, it will just raise the limit. Yvan. -- NETASQ http://www.netasq.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ng_nat+ng_netflow+mpd4 - ?
Hello
I want to count ALL traffic pass trought my gateway, but tool's such as
softflowd I don't want to use because there is already ng_netflow and I
want use nat from netgraph, may I :)?
I have:
#ifconfig
rl0: flags=8843 mtu 1500
options=8
inet 10.11.2.1 netmask 0xff00 broadcast 10.11.2.255
rl1: flags=8843 mtu 1500
options=8
inet 192.168.100.99 netmask 0xff00 broadcast 192.168.100.255
plip0: flags=108810 mtu 1500
pfsync0: flags=0<> mtu 2020
syncpeer: 224.0.0.240 maxupd: 128
pflog0: flags=0<> mtu 33208
lo0: flags=8049 mtu 16384
inet 127.0.0.1 netmask 0xff00
# uname -r
6.2-RELEASE-p7
rl0 - local network
rl1 - internet
#cat KERNEL
options LIBALIAS
options NETGRAPH
options NETGRAPH_ASYNC
options NETGRAPH_BPF
options NETGRAPH_BRIDGE
options NETGRAPH_CISCO
options NETGRAPH_DEVICE
options NETGRAPH_ECHO
options NETGRAPH_EIFACE
options NETGRAPH_ETHER
options NETGRAPH_GIF
options NETGRAPH_GIF_DEMUX
options NETGRAPH_TAG
options NETGRAPH_TCPMSS
options NETGRAPH_FEC
options NETGRAPH_HOLE
options NETGRAPH_IFACE
options NETGRAPH_IP_INPUT
options NETGRAPH_KSOCKET
options NETGRAPH_L2TP
options NETGRAPH_LMI
options NETGRAPH_NETFLOW
options NETGRAPH_ONE2MANY
options NETGRAPH_PPP
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_PPPOE
options NETGRAPH_PPTPGRE
options NETGRAPH_RFC1490
options NETGRAPH_SOCKET
options NETGRAPH_SPLIT
options NETGRAPH_TEE
options NETGRAPH_TTY
options NETGRAPH_UI
options NETGRAPH_VJC
options NETGRAPH
options NETGRAPH_IPFW
options NETGRAPH_NAT
options NETGRAPH_NETFLOW
options NETGRAPH_SPLIT
options NETGRAPH_KSOCKET
options NETGRAPH_SOCKET
options NETGRAPH_IFACE
options NETGRAPH_TCPMSS
flow-capture + ng_netflow + this script working fine
#ngctl -f /ng_netflow
#cat /ng_netflow
mkpeer rl1: tee lower left
name rl1:lower tee0
connect rl1: rl1:lower upper right
mkpeer tee0: one2many left2right many0
name tee0:left2right one2many0
connect tee0: one2many0: right2left many1
mkpeer one2many0: netflow one iface0
name one2many0:one netflow
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow: setifindex { iface=0 index=2 }
msg netflow:export connect inet/127.0.0.1:
I find this script:
When I apply ipfw rules my coputer lost network. I mixed in rules in/out
and 70/71. But nat+netflow don't working. I use ipfw-rules only 200 and
201, but it's doesn't working:
/sbin/ipfw add 110 ngtee 30 ip from any to any out via ng*
/sbin/ipfw add 111 ngtee 30 ip from any to any in via ng*
/sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to $EXT_IP out
via rl1
/sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not $LOCAL_NET in
via rl1
#!/bin/sh
EXT_IP="192.168.100.99"
LOCAL_NET="10.11.2.0/24"
/usr/sbin/ngctl mkpeer ipfw: nat 70 out
/usr/sbin/ngctl name ipfw:70 nat
/usr/sbin/ngctl connect ipfw: nat: 71 in
/usr/sbin/ngctl msg nat: setaliasaddr $EXT_IP
/usr/sbin/ngctl mkpeer ipfw: netflow 30 iface0
/usr/sbin/ngctl name ipfw:30 netflow
/usr/sbin/ngctl msg netflow: setdlt {iface=0 dlt=12}
/usr/sbin/ngctl msg netflow: setifindex {iface=0 index=1}
/usr/sbin/ngctl mkpeer netflow: ksocket export
inet/dgram/udp
/usr/sbin/ngctl msg netflow:export connect
inet/127.0.0.1:
/sbin/ipfw add 6400 allow all from any to any
/sbin/sysctl net.inet.ip.fw.one_pass=0
/sbin/ipfw add 110 ngtee 30 ip from any to any out via ng*
/sbin/ipfw add 111 ngtee 30 ip from any to any in via ng*
/sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to
$EXT_IP out via rl1
/sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not
$LOCAL_NET in via rl1
/usr/local/bin/flow-capture -n 287 -w /var/db/flows/
0.0.0.0/127.0.0.1/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
Ivan Voras wrote: Hi, I have a machine that panics almost daily in route.c, in rt_check(). This panic has been reported by several users, including Marcel Moolenaar for a machine in freebsd.org. The problem is present in both 6-STABLE and 7-CURRENT, and apparently it manifests on SMP machines, both i386 and AMD64. The panic backtrace looks like this: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 I've asked this before of others without getting an answer: is it possible that your gateway route is disappearing (e.g. router going offline, flaky switch, cable unplugged, etc)? I have seen this panic (only) in that situation. Kris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
Ivan Voras wrote: On 27/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: Ivan Voras wrote: Hi, I have a machine that panics almost daily in route.c, in rt_check(). This panic has been reported by several users, including Marcel Moolenaar for a machine in freebsd.org. The problem is present in both 6-STABLE and 7-CURRENT, and apparently it manifests on SMP machines, both i386 and AMD64. The panic backtrace looks like this: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 I've asked this before of others without getting an answer: is it possible that your gateway route is disappearing (e.g. router going offline, flaky switch, cable unplugged, etc)? I have seen this panic (only) in that situation. If there is a way to find this out from the machine itself, I can try and look it up, otherwise I don't (and cannot) know. The infrastructure is a bit big but AFAIK it's nothing special. Should I just call mtx_initialized() before the line and bail out if it isn't? OTOH I need a stable patch that will be committed. You will need to evaluate based on other evidence. e.g. if you've noticed other network flakiness on this machine to do with the gateway. If my guess is correct then it's likely to be a race with something else removing the gateway route without locking it, which means that it's not always going to panic and you may notice other effects from it going away. Checking mtx_initialized won't help in that case because the race is still there. You'd need to check the places that can remove it and make sure they are all correctly locking the route first. Kris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
On 27/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Ivan Voras wrote: > > Hi, > > > > I have a machine that panics almost daily in route.c, in rt_check(). > > This panic has been reported by several users, including Marcel > > Moolenaar for a machine in freebsd.org. > > > > The problem is present in both 6-STABLE and 7-CURRENT, and apparently it > > manifests on SMP machines, both i386 and AMD64. > > > > The panic backtrace looks like this: > > > > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 > > I've asked this before of others without getting an answer: is it > possible that your gateway route is disappearing (e.g. router going > offline, flaky switch, cable unplugged, etc)? I have seen this panic > (only) in that situation. If there is a way to find this out from the machine itself, I can try and look it up, otherwise I don't (and cannot) know. The infrastructure is a bit big but AFAIK it's nothing special. Should I just call mtx_initialized() before the line and bail out if it isn't? OTOH I need a stable patch that will be committed. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
On 27/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: > You will need to evaluate based on other evidence. e.g. if you've > noticed other network flakiness on this machine to do with the gateway. No, I don't think there's anything like that. The panics began when I upgraded to 7-current, the machine was stable under 6-stable. It might be a coincidence or the new code is just more optimized and exposes parallelism more. > Checking mtx_initialized won't help in that case because the race is > still there. You'd need to check the places that can remove it and make > sure they are all correctly locking the route first. I can only grep... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
Ivan Voras wrote: On 27/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: You will need to evaluate based on other evidence. e.g. if you've noticed other network flakiness on this machine to do with the gateway. No, I don't think there's anything like that. The panics began when I upgraded to 7-current, the machine was stable under 6-stable. It might be a coincidence or the new code is just more optimized and exposes parallelism more. Yes, that is not really relevant, the same condition could have been occurring on your network prior to the upgrade. You may not notice if e.g. your switch is momentarily dropping carrier every now and then. Checking mtx_initialized won't help in that case because the race is still there. You'd need to check the places that can remove it and make sure they are all correctly locking the route first. I can only grep... OK, it likely needs more detailed investigation than that ;-) Kris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
Kris Kennaway wrote: > OK, it likely needs more detailed investigation than that ;-) Hmm, grepping has found one straw-chance: I found that if_stf.c calls rtfree() instead of RTFREE_LOCKED (I cannot tell if RTFREE_LOCKED is really needed in this situation or RTFREE is needed), and a diff to my 6-STABLE kernel configuration shows that I left IPv6 in this time. Apparently, this was patched 4 days ago so I'll try two things: 1) build with the new (patched) version and 2) if that doesn't work (probably won't), I'll remove IPv6 from the kernel and try again. Each of this steps will probably take something like 2 days (the average time between panics is ~~ 1 day) until I can say if there's some progress. signature.asc Description: OpenPGP digital signature
Re: bridging ath
On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: > current i386 thinkpad t41 > > ifconfig_lo0="inet 127.0.0.1/8" > cloned_interfaces="bridge0" > ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" > ifconfig_em0="up" > ifconfig_ath0="ssid rgnet up" > defaultrouter="192.168.0.1" > > with ether plugged in, i can ping it. unplug ether and no ping over > ath0. other hosts are on same ssid and working. I will try to reproduce this in the weekend. Just to make sure, you are pinging 192.168.0.3 from a remote wireless node connected to ath0, and unplugging em0 causes this to fail? Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
Andrew Thompson wrote: > On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: >> current i386 thinkpad t41 >> >> ifconfig_lo0="inet 127.0.0.1/8" >> cloned_interfaces="bridge0" >> ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" >> ifconfig_em0="up" >> ifconfig_ath0="ssid rgnet up" >> defaultrouter="192.168.0.1" >> >> with ether plugged in, i can ping it. unplug ether and no ping over >> ath0. other hosts are on same ssid and working. > > I will try to reproduce this in the weekend. Just to make sure, you are > pinging 192.168.0.3 from a remote wireless node connected to ath0, and > unplugging em0 causes this to fail? connect both wireless and ether. it is pingable. disconnect ether. no can ping. reduce to ifconfig_ath0="inet 192.168.0.3/24 ssid rgnet up" with no em0, bridge, ... and it is pingable. randy randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
On Thu, Sep 27, 2007 at 01:19:42PM -1000, Randy Bush wrote: > > Just to be sure... > > good questions, thanks for asking > > > net.inet.ip.forwarding=1 > > # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > > > net.link.ether.bridge.enable=1 > > net.link.ether.bridge.config=em0,ath0 > > # sysctl net.link.ether.bridge.enable > sysctl: unknown oid 'net.link.ether.bridge.enable' > # sysctl -a | grep bridge > net.link.bridge.ipfw: 0 > net.link.bridge.log_stp: 0 > net.link.bridge.pfil_local_phys: 0 > net.link.bridge.pfil_member: 1 > net.link.bridge.pfil_bridge: 1 > net.link.bridge.ipfw_arp: 0 > net.link.bridge.pfil_onlyip: 1 > dev.pcib.0.%desc: ACPI Host-PCI bridge > dev.pcib.1.%desc: ACPI PCI-PCI bridge > dev.pcib.2.%desc: ACPI PCI-PCI bridge > dev.hostb.0.%desc: Host to PCI bridge > dev.agp.0.%desc: Intel 82855 host to AGP bridge > dev.isab.0.%desc: PCI-ISA bridge > > oops! have i left something out of kernel or kld load? No, Michael's example was for old-bridge which is depreciated. You had the config right. Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: bridging ath
> -Original Message- > From: Andrew Thompson [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 27, 2007 4:22 PM > To: Randy Bush > Cc: Michael K. Smith - Adhost; FreeBSD Net > Subject: Re: bridging ath > > On Thu, Sep 27, 2007 at 01:19:42PM -1000, Randy Bush wrote: > > > Just to be sure... > > > > good questions, thanks for asking > > > > > net.inet.ip.forwarding=1 > > > > # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 1 > > > > > net.link.ether.bridge.enable=1 > > > net.link.ether.bridge.config=em0,ath0 > > > > # sysctl net.link.ether.bridge.enable > > sysctl: unknown oid 'net.link.ether.bridge.enable' > > # sysctl -a | grep bridge > > net.link.bridge.ipfw: 0 > > net.link.bridge.log_stp: 0 > > net.link.bridge.pfil_local_phys: 0 > > net.link.bridge.pfil_member: 1 > > net.link.bridge.pfil_bridge: 1 > > net.link.bridge.ipfw_arp: 0 > > net.link.bridge.pfil_onlyip: 1 > > dev.pcib.0.%desc: ACPI Host-PCI bridge > > dev.pcib.1.%desc: ACPI PCI-PCI bridge > > dev.pcib.2.%desc: ACPI PCI-PCI bridge > > dev.hostb.0.%desc: Host to PCI bridge > > dev.agp.0.%desc: Intel 82855 host to AGP bridge > > dev.isab.0.%desc: PCI-ISA bridge > > > > oops! have i left something out of kernel or kld load? > > No, Michael's example was for old-bridge which is depreciated. You had > the config right. > Thanks Andrew! In reading http://www.freebsd.org/cgi/man.cgi?query=if_bridge&sektion=4 it looks like either device if_bridge or if_bridge_load="YES" in loader.conf is all that's needed. For testing purposes, you might want to disable the filtering configuration with: sysctl net.link.bridge.pfil_member=0 sysctl net.link.bridge.pfil_bridge=0 Regards, Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: bridging ath
> > Andrew Thompson wrote: > > On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: > >> current i386 thinkpad t41 > >> > >> ifconfig_lo0="inet 127.0.0.1/8" > >> cloned_interfaces="bridge0" > >> ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" > >> ifconfig_em0="up" > >> ifconfig_ath0="ssid rgnet up" > >> defaultrouter="192.168.0.1" > >> > >> with ether plugged in, i can ping it. unplug ether and no ping over > >> ath0. other hosts are on same ssid and working. > > > > I will try to reproduce this in the weekend. Just to make sure, you > are > > pinging 192.168.0.3 from a remote wireless node connected to ath0, > and > > unplugging em0 causes this to fail? > > connect both wireless and ether. it is pingable. disconnect ether. no > can ping. > > reduce to > ifconfig_ath0="inet 192.168.0.3/24 ssid rgnet up" > with no em0, bridge, ... and it is pingable. > > randy > Just to be sure... net.inet.ip.forwarding=1 net.link.ether.bridge.enable=1 net.link.ether.bridge.config=em0,ath0 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
> Just to be sure... good questions, thanks for asking > net.inet.ip.forwarding=1 # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 > net.link.ether.bridge.enable=1 > net.link.ether.bridge.config=em0,ath0 # sysctl net.link.ether.bridge.enable sysctl: unknown oid 'net.link.ether.bridge.enable' # sysctl -a | grep bridge net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.hostb.0.%desc: Host to PCI bridge dev.agp.0.%desc: Intel 82855 host to AGP bridge dev.isab.0.%desc: PCI-ISA bridge oops! have i left something out of kernel or kld load? randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
> You can only bridge a wireless card in hostap mode. after your earlier comment, i tried that too :( it's not that i think i have not done something stupid. i just can't find it :) randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
Randy Bush wrote: Be sure apbridge is enabled not running in hostap mode, not an access point You can only bridge a wireless card in hostap mode. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
> Be sure apbridge is enabled not running in hostap mode, not an access point > you can use tcpdump to check traffic on each interface to isolate the issue. the ath interface 00:28:26.699253 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 218, length 64 00:28:26.699295 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 218, length 64 00:28:27.710208 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 219, length 64 00:28:27.710220 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 219, length 64 00:28:27.848283 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:28.718895 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 220, length 64 00:28:28.718904 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 220, length 64 00:28:28.974345 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:29.597966 arp who-has ap0.h.psg.com tell hawi0.psg.com 00:28:29.774936 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 221, length 64 00:28:29.774950 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 221, length 64 00:28:29.896361 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:30.407955 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:30.746231 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 222, length 64 00:28:30.746241 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 222, length 64 00:28:31.721041 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 223, length 64 00:28:31.721050 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 223, length 64 00:28:31.841701 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:31.943904 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:32.752380 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 224, length 64 00:28:32.752389 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 224, length 64 00:28:33.480206 IP dhcp1.psg.com.netbios-ns > 192.168.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 00:28:33.481099 arp who-has 192.168.0.100 tell dhcp1.psg.com 00:28:33.684970 IP dhcp1.psg.com.netbios-ns > 192.168.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 00:28:33.758003 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 225, length 64 00:28:33.758015 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 225, length 64 00:28:33.889567 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:34.773510 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 226, length 64 00:28:34.773518 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 226, length 64 00:28:35.794872 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 227, length 64 00:28:35.794880 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 227, length 64 00:28:35.843019 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:36.756975 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 228, length 64 00:28:36.756984 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 228, length 64 00:28:37.775456 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 229, length 64 00:28:37.775465 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 229, length 64 00:28:37.883867 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:38.805287 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 230, length 64 00:28:38.805296 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 230, length 64 the bridge interface 00:29:14.161340 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 265, length 64 00:29:15.165895 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 266, length 64 00:29:16.150938 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 267, length 64 00:29:17.152661 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 268, length 64 00:29:18.167323 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 269, length 64 00:29:19.177189 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 270, length 64 00:29:20.195071 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 271, length 64 randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
> device if_bridge > or > if_bridge_load="YES" in loader.conf is all that's needed. if_bridge.ko is automagically loaded, no extra charge > For testing purposes, you might want to disable the filtering > configuration with: > sysctl net.link.bridge.pfil_member=0 > sysctl net.link.bridge.pfil_bridge=0 no help. but thanks. i am sure i am doing something stupid. randy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
Randy Bush wrote: Andrew Thompson wrote: On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: current i386 thinkpad t41 ifconfig_lo0="inet 127.0.0.1/8" cloned_interfaces="bridge0" ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" ifconfig_em0="up" ifconfig_ath0="ssid rgnet up" defaultrouter="192.168.0.1" with ether plugged in, i can ping it. unplug ether and no ping over ath0. other hosts are on same ssid and working. I will try to reproduce this in the weekend. Just to make sure, you are pinging 192.168.0.3 from a remote wireless node connected to ath0, and unplugging em0 causes this to fail? connect both wireless and ether. it is pingable. disconnect ether. no can ping. reduce to ifconfig_ath0="inet 192.168.0.3/24 ssid rgnet up" with no em0, bridge, ... and it is pingable. Be sure apbridge is enabled so the 802.11 layer does intra-bss bridging; otherwise traffic must be fwd'd by a bridge component (should be on by default). Also you can use tcpdump to check traffic on each interface to isolate the issue. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridging ath
Sam Leffler wrote: Randy Bush wrote: Be sure apbridge is enabled not running in hostap mode, not an access point You can only bridge a wireless card in hostap mode. Sorry, engage brain before opening mouth. I don't know what you're trying to do but you're looking in the wrong place and I suspect you're confused about some stuff. When you attach your wired nic to a bridge and and turn the bridge on the nic gets set in promiscuous mode. This is likely why you can ping the other wireless station through the wired nic. To ping the wireless station through your AP then AP must either fwd the packet directly or bridge it using some mechanism. You cannot bridge a wireless interface unless it's operating as an ap. Either way it's an issue at the AP. You can diagnose all this with tcpdump. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ng_nat+ng_netflow+mpd4 - ?
[EMAIL PROTECTED] пишет:
I want to count ALL traffic pass trought my gateway, but tool's such as
softflowd I don't want to use because there is already ng_netflow and I
want use nat from netgraph, may I :)?
options NETGRAPH
...
options NETGRAPH_TCPMSS
You do not need to build it statically. All of them can be loaded as
modules.
flow-capture + ng_netflow + this script working fine
#ngctl -f /ng_netflow
#cat /ng_netflow
mkpeer rl1: tee lower left
name rl1:lower tee0
connect rl1: rl1:lower upper right
mkpeer tee0: one2many left2right many0
name tee0:left2right one2many0
connect tee0: one2many0: right2left many1
mkpeer one2many0: netflow one iface0
name one2many0:one netflow
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow: setifindex { iface=0 index=2 }
msg netflow:export connect inet/127.0.0.1:
It looks overcomplicated to me. There is no need to use tee and one2many
there as ng_netflow supports passing traffic via it and supports
multiple interfaces. It can be connected just to the interface
upper/lower hooks. If you REALLY wish to count both directions on ALL
interfaces (and have double traffic accounting) you could connect
netflow node twice in different directions.
/sbin/ipfw add 110 ngtee 30 ip from any to any out via ng*
/sbin/ipfw add 111 ngtee 30 ip from any to any in via ng*
If you are using mpd4 to operate ng inetrfaces then you can just use
it's internal ng_netflow support.
/sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to
$EXT_IP out via rl1
/sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not
$LOCAL_NET in via rl1
Recheck twice IP in those rules. What you mean by them?
--
Alexander Motin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
