Re: Recommendations for 10gbps NIC
Thanks for everyone's input. I ended up buying a Chelsio 420-CR. It works well, and with all four existing 10GBASE-SR SFP+ modules I had lying around. I won't need the the performance offered by netmap in the foreseeable future (at which support for it may exist), so that was not critical. I had tried Intel first, which resulted in this saga: http://lists.freebsd.org/pipermail/freebsd-net/2013-June/035709.html. I have not yet tested the SFP+ modules in the Intel card with -CURRENT, because I'm not ready to upgrade the machine in question to -CURRENT. Aside from allowing a wider variety of SFP+ modules in 9.x, the Chelsio card also has the benefit of supporting hot-plugging of SFP+ modules. -Boris On 07/24/13 16:26, Boris Kochergin wrote: Hi. I am looking for recommendations for a 10gbps NIC from someone who has successfully used it on FreeBSD. It will be used on FreeBSD 9.1-R/amd64 to capture packets. Some desired features are: - PCIe - LC connectors - 10GBASE-SR - Either single- or dual-port - Multiqueue Specific part numbers would be appreciated. Thank you. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Recommendations for 10gbps NIC
Hi. I am looking for recommendations for a 10gbps NIC from someone who has successfully used it on FreeBSD. It will be used on FreeBSD 9.1-R/amd64 to capture packets. Some desired features are: - PCIe - LC connectors - 10GBASE-SR - Either single- or dual-port - Multiqueue Specific part numbers would be appreciated. Thank you. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection
Cool. Any idea of when soon might be? And about that list of supported SFP+ modules? Is any Intel 10-GBASE-SR SFP+ module guaranteed to work with this card and driver? -Boris On 06/09/13 22:09, Jack Vogel wrote: There will be a driver update soon with the way it should be done, it will be in the core driver code and not as here in the shared code. Regards, Jack PS Oh, and the email address should be 'free...@intel.com' now rather than freebsdnic, it still ultimately just gets to me however. On Sun, Jun 9, 2013 at 10:42 AM, Weiß, Jürgen we...@uni-mainz.de wrote: With the following patch the ixgbe (ix) driver accepts any SFP. --- ixgbe_phy.c.orig2012-10-01 18:38:31.0 +0200 +++ ixgbe_phy.c 2012-11-13 16:23:18.650609931 +0100 @@ -1186,6 +1186,7 @@ } ixgbe_get_device_caps(hw, enforce_sfp); + enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) !((hw-phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) || (hw-phy.sfp_type == ixgbe_sfp_type_1g_cu_core1) || Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection
Thanks, but this does not work. ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.8 port 0xece0-0xecff mem 0xdf36-0xdf37,0xdf3c-0xdf3f,0xdf33c000-0xdf33 irq 45 at device 0.1 on pci6 ix0: Using MSIX interrupts with 9 vectors ix0: Unsupported SFP+ Module ix0: Hardware Initialization Failure device_attach: ix0 attach returned 5 -Boris On 06/09/13 13:42, Weiß, Jürgen wrote: With the following patch the ixgbe (ix) driver accepts any SFP. --- ixgbe_phy.c.orig2012-10-01 18:38:31.0 +0200 +++ ixgbe_phy.c 2012-11-13 16:23:18.650609931 +0100 @@ -1186,6 +1186,7 @@ } ixgbe_get_device_caps(hw, enforce_sfp); + enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) !((hw-phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) || (hw-phy.sfp_type == ixgbe_sfp_type_1g_cu_core1) || Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, we...@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection
I had originally sent this to the freebsd...@mailbox.intel.com address mentioned in the ixgbe(4) man page, but it unfortunately bounced. I am running FreeBSD 9.1-RELEASE/amd64 and have a 82598EB 10-Gigabit AF Dual Port Network Connection controller. I've been trying to get a working SFP+ module for it to do 10-GBASE-SR. The /usr/src/sys/dev/ixgbe/README file, on line 100, says that the following SFP+ module has received some testing: Avago SFP+ SR bailed, 10g single rate AFBR-700SDZ I bought one, inserted into the controller, booted up, and was greeted by this message: ix0: port 0xecc0-0xecdf mem 0xdf34-0xdf35,0xdf38-0xdf3b,0xdf338000-0xdf33bfff irq 38 at device 0.0 on pci6 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: Unsupported SFP+ Module ix0: Hardware Initialization Failure device_attach: ix0 attach returned 5 ix0: port 0xece0-0xecff mem 0xdf36-0xdf37,0xdf3c-0xdf3f,0xdf33c000-0xdf33 irq 45 at device 0.1 on pci6 Anyone know why this happened? Can you point me to a complete list of SFP+ modules that will work with the controller? Let me know if you need any other information. Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
mbuf tuning on 9.1
Hi. I have a FreeBSD 9.1/amd64 machine. It runs HAProxy and runs out of various things frequently. Sometimes it's mbufs. netstat -m: 68202/1698/69900 mbufs in use (current/cache/total) 41449/1229/42678/2622144 mbuf clusters in use (current/cache/total/max) 41449/1175 mbuf+clusters out of packet secondary zone in use (current/cache) 26405/538/26943/3276800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 205568K/5034K/210603K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines How can I increase mbufs, as they appear above, and mbuf clusters, as they appear above? Thank you. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: mbuf tuning on 9.1
Additionally, can someone clarify the meaning of total vs. max for these values? -Boris On 03/12/13 17:23, Paul A. Procacci wrote: How can I increase mbufs, as they appear above, and mbuf clusters, as they appear above? You can modify the sysctl's associated with mbufs to suit your needs. https://wiki.freebsd.org/NetworkPerformanceTuning The following link describes what mbufs are and sysctl's governing their operation. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: MSS rewrite / MSS clamping?
On 02/05/11 23:07, Jason Fesler wrote: I'm in search of MSS clamping for FreeBSD servers; in particular, for IPv6. I'm finding pretty much nothing (except iptables..) on the net. Am I chasing wild geese? pf.conf(5) mentions a max-mss option for traffic normalization. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
NDP Ethernet address display
Hi. I noticed that ndp(8) doesn't zero-pad Ethernet addresses, which is
inconsistent with arp(8):
# ndp -an
...
2001:470:897b::1 0:30:48:b1:1b:9c em0 permanent R
# arp -an
...
? (128.238.9.201) at 00:30:48:b1:1b:9c on em0 permanent [ethernet]
As everything else I can think of zero-pads them, this makes it a little
annoying to grep for addresses, etc. Is this intentional? It is the case
in 7.x through CURRENT and the fix is quite simple:
--- /usr/src/usr.sbin/ndp/ndp.c.orig2011-01-07 19:16:17.0 -0500
+++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 19:15:36.0 -0500
@@ -828,7 +828,7 @@
if (sdl-sdl_alen) {
cp = (u_char *)LLADDR(sdl);
- snprintf(hbuf, sizeof(hbuf), %x:%x:%x:%x:%x:%x,
+ snprintf(hbuf, sizeof(hbuf),
%02x:%02x:%02x:%02x:%02x:%02x,
cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]);
} else
snprintf(hbuf, sizeof(hbuf), (incomplete));
-Boris
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NDP Ethernet address display
On 01/07/11 20:26, Sergey Kandaurov wrote:
On 8 January 2011 03:26, Boris Kocherginsp...@acm.poly.edu wrote:
Hi. I noticed that ndp(8) doesn't zero-pad Ethernet addresses, which is
inconsistent with arp(8):
# ndp -an
...
2001:470:897b::1 0:30:48:b1:1b:9c em0 permanent R
# arp -an
...
? (128.238.9.201) at 00:30:48:b1:1b:9c on em0 permanent [ethernet]
As everything else I can think of zero-pads them, this makes it a little
annoying to grep for addresses, etc. Is this intentional? It is the case in
7.x through CURRENT and the fix is quite simple:
--- /usr/src/usr.sbin/ndp/ndp.c.orig2011-01-07 19:16:17.0 -0500
+++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 19:15:36.0 -0500
@@ -828,7 +828,7 @@
if (sdl-sdl_alen) {
cp = (u_char *)LLADDR(sdl);
- snprintf(hbuf, sizeof(hbuf), %x:%x:%x:%x:%x:%x,
+ snprintf(hbuf, sizeof(hbuf),
%02x:%02x:%02x:%02x:%02x:%02x,
cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]);
} else
snprintf(hbuf, sizeof(hbuf), (incomplete));
Or rather use getnameinfo() for that as NetBSD/KAME does, and
NetBSD's getnameinfo() AF_LINK support was merged at 6.3 time.
(See ndp.c#rev1.87 at KAME, ndp.c#rev1.35 at NetBSD).
Sure.
-Boris
--- /usr/src/usr.sbin/ndp/ndp.c.orig2011-01-07 19:16:17.0 -0500
+++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 21:00:20.0 -0500
@@ -80,6 +80,7 @@
#include sys/socket.h
#include sys/sysctl.h
#include sys/time.h
+#include sys/types.h
#include sys/queue.h
#include net/if.h
@@ -824,12 +825,12 @@
struct sockaddr_dl *sdl;
{
static char hbuf[NI_MAXHOST];
- u_char *cp;
if (sdl-sdl_alen) {
- cp = (u_char *)LLADDR(sdl);
- snprintf(hbuf, sizeof(hbuf), %x:%x:%x:%x:%x:%x,
- cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]);
+ if (getnameinfo((struct sockaddr *)(void *)sdl,
+ (socklen_t)sdl-sdl_len,
+ hbuf, sizeof(hbuf), NULL, 0, NI_NUMERICHOST) != 0)
+ snprintf(hbuf, sizeof(hbuf), invalid);
} else
snprintf(hbuf, sizeof(hbuf), (incomplete));
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NDP Ethernet address display
On 01/07/11 21:09, Doug Barton wrote: On 01/07/2011 18:01, Boris Kochergin wrote: - snprintf(hbuf, sizeof(hbuf), %x:%x:%x:%x:%x:%x, There are numerous examples of this string in the tree. Some of them seem like they may be correct, but many of them are obviously printing out mac addresses and should be converted, one way or another: http://dougbarton.us/mac-padding.txt In any case, thanks to Xin for fixing this one so quickly. :) Doug The sscanf() calls are definitely fine. I made sure to test that bit in ndp(8). Thanks, Xin! -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Workaround for mpd5 and 8.0 broken proxy arp?
J. English wrote: Hello All, I've recently set up a FreeBSD 8.0 VPN server with mpd5 for people to connect remotely. However, looking at my mpd.log shows that I'm having problems with proxy-arp: [B-1] IFACE: No interface to proxy arp on for 192.168.1.185 In googling for solutions, I came across others who have posted to this list who have had similar problems. It also looks like a problem report has been submitted for proxy arp being broken in 8.0 RELENG. My options are 1) to wait until proxy arp is fixed (don't know how long that will take), or 2) go back and implement my VPN using 7.2 (would require a lot of effort). I was wondering if anyone else could suggest other alternatives that would allow my external clients to access my intranet without proxy arp. How about a userspace implementation of proxy ARP, like the one in the choparp/pkg-descr port? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Workaround for mpd5 and 8.0 broken proxy arp?
Boris Kochergin wrote: J. English wrote: Hello All, I've recently set up a FreeBSD 8.0 VPN server with mpd5 for people to connect remotely. However, looking at my mpd.log shows that I'm having problems with proxy-arp: [B-1] IFACE: No interface to proxy arp on for 192.168.1.185 In googling for solutions, I came across others who have posted to this list who have had similar problems. It also looks like a problem report has been submitted for proxy arp being broken in 8.0 RELENG. My options are 1) to wait until proxy arp is fixed (don't know how long that will take), or 2) go back and implement my VPN using 7.2 (would require a lot of effort). I was wondering if anyone else could suggest other alternatives that would allow my external clients to access my intranet without proxy arp. How about a userspace implementation of proxy ARP, like the one in the choparp/pkg-descr port? -Boris Oops. I meant the net-mgmt/choparp port. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: CARP vs. if_bridge
Boris Kochergin wrote: Max Laier wrote: On Thursday 18 February 2010 18:02:55 Boris Kochergin wrote: Ahoy. I'm seeing what appears to be erroneous interaction between CARP and if_bridge on multiple machines with a variety of Ethernet controllers and architectures. I've observed it on 7.2-R and 8.0-R. The test setup is simple enough: CARP master: FreeBSD t30 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #5: Sun Feb 14 20:22:41 EST 2010 r...@t30:/usr/obj/usr/src/sys/T30 i386 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:04:5a:a8:e0:bf inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 CARP backup: FreeBSD ultra5 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Feb 18 15:19:39 UTC 2010 bo...@ultra5:/usr/obj/usr/src/sys/GENERIC.carp sparc64 hme0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 08:00:20:f5:65:d4 media: Ethernet autoselect xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9RXCSUM,VLAN_MTU ether 00:01:03:2c:06:6d inet 192.168.0.3 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 100 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:e6:09:2d:da:bc id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: xl0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 20 member: hme0 flags=8SPAN ifmaxaddr 0 port 1 priority 128 path cost 20 In summary, I have a basic CARP configuration and, on the backup CARP machine, a bridge with the CARP device's physical interface in it. The purpose of this setup is the ability to monitor traffic passing through that interface using another machine. If the master CARP machine is disconnected from the network, the CARP interface on the backup machine correctly changes to the MASTER state, but does not act on traffic bound for the shared IP address--192.168.0.1. tcpdump shows the traffic coming in on the correct physical interface, but it is never replied to, or, in the case of routing, forwarded. Removing xl0 from the bridge on the backup machine instantly fixes this, and the shared IP address behaves as expected. Adding xl0 back to the bridge while the backup CARP interface is in the MASTER state keeps things running correctly, so the problem is only observed when xl0 is part of the bridge during the CARP transition from BACKUP to MASTER. Thoughts? I assume the bridge filters out the traffic as it thinks the destination is elsewhere (it has previously seen ARPs from the other MASTER entering via xl0). It shouldn't do that, but that's a different story. You can try to force edge or ptp status on xl0, not sure if this does the trick, but it's worth a try. Regards, Max Sure. No go, though, I'm afraid. It's not an operational show-stopper for me, at least. In the worst case, I can always hack up a PCAP program to copy the frames around in user space. -Boris For the archives, in the off chance that someone else encounters this: http://acm.poly.edu/wiki/Userspace_SPAN_Port -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: CARP vs. if_bridge
Max Laier wrote: On Thursday 18 February 2010 18:02:55 Boris Kochergin wrote: Ahoy. I'm seeing what appears to be erroneous interaction between CARP and if_bridge on multiple machines with a variety of Ethernet controllers and architectures. I've observed it on 7.2-R and 8.0-R. The test setup is simple enough: CARP master: FreeBSD t30 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #5: Sun Feb 14 20:22:41 EST 2010 r...@t30:/usr/obj/usr/src/sys/T30 i386 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:04:5a:a8:e0:bf inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 CARP backup: FreeBSD ultra5 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Feb 18 15:19:39 UTC 2010 bo...@ultra5:/usr/obj/usr/src/sys/GENERIC.carp sparc64 hme0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 08:00:20:f5:65:d4 media: Ethernet autoselect xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9RXCSUM,VLAN_MTU ether 00:01:03:2c:06:6d inet 192.168.0.3 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 100 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:e6:09:2d:da:bc id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: xl0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 20 member: hme0 flags=8SPAN ifmaxaddr 0 port 1 priority 128 path cost 20 In summary, I have a basic CARP configuration and, on the backup CARP machine, a bridge with the CARP device's physical interface in it. The purpose of this setup is the ability to monitor traffic passing through that interface using another machine. If the master CARP machine is disconnected from the network, the CARP interface on the backup machine correctly changes to the MASTER state, but does not act on traffic bound for the shared IP address--192.168.0.1. tcpdump shows the traffic coming in on the correct physical interface, but it is never replied to, or, in the case of routing, forwarded. Removing xl0 from the bridge on the backup machine instantly fixes this, and the shared IP address behaves as expected. Adding xl0 back to the bridge while the backup CARP interface is in the MASTER state keeps things running correctly, so the problem is only observed when xl0 is part of the bridge during the CARP transition from BACKUP to MASTER. Thoughts? I assume the bridge filters out the traffic as it thinks the destination is elsewhere (it has previously seen ARPs from the other MASTER entering via xl0). It shouldn't do that, but that's a different story. You can try to force edge or ptp status on xl0, not sure if this does the trick, but it's worth a try. Regards, Max Sure. No go, though, I'm afraid. It's not an operational show-stopper for me, at least. In the worst case, I can always hack up a PCAP program to copy the frames around in user space. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
CARP vs. if_bridge
Ahoy. I'm seeing what appears to be erroneous interaction between CARP and if_bridge on multiple machines with a variety of Ethernet controllers and architectures. I've observed it on 7.2-R and 8.0-R. The test setup is simple enough: CARP master: FreeBSD t30 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #5: Sun Feb 14 20:22:41 EST 2010 r...@t30:/usr/obj/usr/src/sys/T30 i386 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:04:5a:a8:e0:bf inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 CARP backup: FreeBSD ultra5 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Feb 18 15:19:39 UTC 2010 bo...@ultra5:/usr/obj/usr/src/sys/GENERIC.carp sparc64 hme0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 08:00:20:f5:65:d4 media: Ethernet autoselect xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9RXCSUM,VLAN_MTU ether 00:01:03:2c:06:6d inet 192.168.0.3 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 carp0: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.0.1 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 100 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:e6:09:2d:da:bc id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: xl0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 20 member: hme0 flags=8SPAN ifmaxaddr 0 port 1 priority 128 path cost 20 In summary, I have a basic CARP configuration and, on the backup CARP machine, a bridge with the CARP device's physical interface in it. The purpose of this setup is the ability to monitor traffic passing through that interface using another machine. If the master CARP machine is disconnected from the network, the CARP interface on the backup machine correctly changes to the MASTER state, but does not act on traffic bound for the shared IP address--192.168.0.1. tcpdump shows the traffic coming in on the correct physical interface, but it is never replied to, or, in the case of routing, forwarded. Removing xl0 from the bridge on the backup machine instantly fixes this, and the shared IP address behaves as expected. Adding xl0 back to the bridge while the backup CARP interface is in the MASTER state keeps things running correctly, so the problem is only observed when xl0 is part of the bridge during the CARP transition from BACKUP to MASTER. Thoughts? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Can't load NFS server module with a custom 8.0 kernel
Hi. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel (configuration file at http://acm.poly.edu/~spawk/ACM) and I am unable to use the NFS server module on it. After loading the nfssvc module, attempting to load the nfsserver module fails and the following appears in dmesg: Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create undefined Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type I see a reference to the problem at http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. Am I missing something or has it never gotten resolved? Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifconfig: BRDGADD tun0: Invalid argument
Got it. Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
ifconfig: BRDGADD tun0: Invalid argument
Ahoy. I have an 8.0-RELEASE/i386 machine (installed clean from the CD, so no kernel/world mismatches are possible) on which I am trying to add a tun device to a bridge: # ifconfig tun0 create # ifconfig bridge0 create # ifconfig ... tun0: flags=8010POINTOPOINT,MULTICAST metric 0 mtu 1500 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 5e:e7:af:1b:14:d3 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 # ifconfig bridge0 addm tun0 ifconfig: BRDGADD tun0: Invalid argument # ifconfig tun0 promisc # ifconfig bridge0 addm tun0 ifconfig: BRDGADD tun0: Invalid argument I have looked at http://lists.freebsd.org/pipermail/freebsd-net/2007-December/016114.html, but none of the three possibilities appear to apply. Any clues? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: PF and DHCP
Jonathan Belson wrote: Hiya I have a server which acts as a gateway between the internet and my internal network. The external interface receives its IP address via DHCP. I set up pf.conf to allow DHCP packets via ports 67/68, but I notice that when the server boots, the DHCP exchange happens /before/ PF gets started. Does this mean that adding rules for DHCP isn't necessary (my firewall rules are block in/pass out, with a bit of NAT thrown in)? To address just this question, it is a good idea to leave the rules that allow DHCP in there, as the DHCP client will need to renew its lease later, while the firewall is running. -Boris Does this mean that when my machine boots, there's a window between the interfaces coming up and the firewall being enabled? Thanks, --Jon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: PCI card for wlan AP
Joost Mulders wrote: Howdy, Can you recommend a WLAN PCI card for AP use in my FreeBSD residential gateway. I'm looking for a 802.11 a/b/g card, no need for n yet. Recommendations and works for me's are highly appreciated. Thank you, Joost ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org I have a ton of these that I'm very happy with: http://www.newegg.com/Product/Product.aspx?Item=N82E16833127075 The heavily-used ones exhibit the problem described at: http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html ...but that's a driver, not a hardware, issue. The one in the router at my house doesn't exhibit the problem, the two differences there being that the machine is 7.0-RELEASE, and there are only a couple of clients connected to it, as opposed to the ~30 connected to my heavily-used ones. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: PCI card for wlan AP
Rui Paulo wrote: On 7 Oct 2009, at 20:04, Boris Kochergin wrote: The heavily-used ones exhibit the problem described at: http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html ...but that's a driver, not a hardware, issue. The one in the router at my house doesn't exhibit the problem, the two differences there being that the machine is 7.0-RELEASE, and there are only a couple of clients connected to it, as opposed to the ~30 connected to my heavily-used ones. Are you sure you have sufficient RAM to hold 30 users? What you seem to be saying is that the ath driver is leaking mbufs and hence you get a panic, right? -- Rui Paulo Pretty sure. The Soekris has 256 MB of RAM. I suspect that it's a leak because things are usually great, even with ~30 users, with the 80211node portion from vmstat -m only taking a few hundred KiB of RAM. Every few days, it spikes to over 100 MiB, and the ath0: ath_rx_proc: no mbuf! kernel messages appear, often followed by a panic. I haven't had time to try another rate-control algorithm, as per the responses to my post, but I'll report back when I do get around to it. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kmem_map too small panics with Soekris/Atheros access point
Stef Walter wrote: Boris Kochergin wrote: ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org More information: I upgraded it to a 7.2-STABLE with August 20th sources and increased kern.ipc.nmbclusters to 65536 in hopes of getting the panic less often. I managed to catch it in a state where there were a bunch of ath0: ath_rx_proc: no mbuf! messages in the kernel buffer. One line of vmstat -m stood out as the leak: 80211node 12677 101401K - 120901 16,512 ifconfig ath0 down freed the memory. Is there any other useful information I can provide if I catch it again? Someone suggested the output of vmstat -z off list, and I will have that next time. This might be a long shot: Back when I deployed some similar devices on FreeBSD 6.0 there was a leak when using oddball ath_rate driver. I believe it went away when I used ath_rate_sample. But according to 'man 4 ath' nothing else besides ath_rate_sample exists anymore. Cheers, Stef ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org I, too, recall the days when you had multiple rate-control algorithms to choose from, but that doesn't appear to be the case anymore. As a workaround, I wrote a little script that checks if that part of the driver is using more than 200 KiB of memory and run it every minute via cron. It seems to be doing its job so far: #!/bin/sh memory=`vmstat -m | grep 80211node | tr -s ' ' | cut -f4 -d' ' | sed 's/[^0-9]//g'` if [ $memory -gt 200 ]; then ifconfig ath0 down ifconfig ath0 up fi -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kmem_map too small panics with Soekris/Atheros access point
Boris Kochergin wrote: Ahoy. I've got two Soekris Net5501s with Atheros 5212 cards in them, acting as access points. They are both running 7.2-RELEASE and at times each one has up to 30 machines associated with it. Relevant information about them can be found at http://acm.poly.edu/~spawk/ap/;. After a few days, they panic with: panic: kmem_malloc(32768): kmem_map too small: 86142976 total allocated Indeed, vm.kmem_size on each of them is 86228992. I had nowhere to write a core dump to, but the root issue seems to be that all kernel memory was exhausted, which sounds like a memory leak somewhere. Is that a known problem with that release and hardware configuration? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org More information: I upgraded it to a 7.2-STABLE with August 20th sources and increased kern.ipc.nmbclusters to 65536 in hopes of getting the panic less often. I managed to catch it in a state where there were a bunch of ath0: ath_rx_proc: no mbuf! messages in the kernel buffer. One line of vmstat -m stood out as the leak: 80211node 12677 101401K - 120901 16,512 ifconfig ath0 down freed the memory. Is there any other useful information I can provide if I catch it again? Someone suggested the output of vmstat -z off list, and I will have that next time. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ath0 unable to DHCP as part of a bridge
Sin wrote: Hello, I'm using FreeBSD 7-STABLE. I have 6 NICs as a bridged interface, one of which is a ath0 wireless NIC. I don't understand if this acting the way it should. If I try to dhclient on interfact ath0 I'll get the request no problems. But if I dhclient to bridge0 interface, it acts like there's no server - Even though its bridged.Also note if I connect a cable to any of the wired NICs, dhclient will then work on bridge0 interface. The setup is kinda complicated, but i'm hoping someone may have a different view on it. One thing that confused me is that the line in /etc/rc.conf ifconfig_ath0=WPA - it does not matter if this line is before or after the bridge declaration. Compiled into the kernel: options NETGRAPH options NETGRAPH_L2TP options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_MPPC_ENCRYPTION optionsIPFIREWALL optionsIPFIREWALL_VERBOSE optionsIPFIREWALL_VERBOSE_LIMIT optionsIPFIREWALL_DEFAULT_TO_ACCEPT device if_bridge #Bridge interface device gre #IP over IP tunneling FreeBSD domainname 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Aug 29 05:39:09 EDT 2009 r...@domainname:/tmp/CVS/src/sys/i386/compile/TESTROUTER i386 test# kldstat Id Refs AddressSize Name 13 0xc040 556810 kernel 21 0xc0957000 6a49cacpi.ko test# ifconfig -a sk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:0f:3d:88:18:31 media: Ethernet autoselect (none) status: no carrier vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2808VLAN_MTU,WOL_UCAST,WOL_MAGIC ether 00:05:5d:75:1a:12 media: Ethernet autoselect (none) status: no carrier vr1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2808VLAN_MTU,WOL_UCAST,WOL_MAGIC ether 00:05:5d:e9:61:79 media: Ethernet autoselect (none) status: no carrier ath0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 inet 192.168.0.251 netmask 0xff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid dts channel 2 (2417 Mhz 11g) bssid 00:17:9a:9e:f3:82 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst roaming MANUAL bintval 30 sk1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:11:95:d7:25:e3 media: Ethernet autoselect (none) status: no carrier sk2: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:11:95:d7:25:ee media: Ethernet autoselect (none) status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 96:25:58:f9:dd:3d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 3 priority 128 path cost 55 member: vr0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 55 member: sk2 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 6 priority 128 path cost 55 member: sk1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 5 priority 128 path cost 55 member: sk0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 1 priority 128 path cost 55 member: ath0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 4 priority 128 path cost 76923 - 7.1-RELEASE upgrade to stable without mergemaster - world and kenel built from this supfile: test# cat /tmp/CVS/supfile *default tag=RELENG_7 *default host=cvsup1.ca.FreeBSD.org *default prefix=/tmp/CVS *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all example of the exact issue as found in the command line: test# dhclient bridge0 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on bridge0 to 255.255.255.255 port
kmem_map too small panics with Soekris/Atheros access point
Ahoy. I've got two Soekris Net5501s with Atheros 5212 cards in them, acting as access points. They are both running 7.2-RELEASE and at times each one has up to 30 machines associated with it. Relevant information about them can be found at http://acm.poly.edu/~spawk/ap/;. After a few days, they panic with: panic: kmem_malloc(32768): kmem_map too small: 86142976 total allocated Indeed, vm.kmem_size on each of them is 86228992. I had nowhere to write a core dump to, but the root issue seems to be that all kernel memory was exhausted, which sounds like a memory leak somewhere. Is that a known problem with that release and hardware configuration? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025)
The following reply was made to PR kern/129508; it has been noted by GNATS. From: Boris Kochergin sp...@acm.poly.edu To: bug-follo...@freebsd.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Wed, 13 May 2009 15:38:47 -0400 As a workaround, lowering the MTU of the 802.11 interfaces on all of the access points made the panic go away, until one of the machines that was panicking was upgraded to 7.2-RELEASE. Afterward, a panic with a different backtrace started occuring: Unread portion of the kernel message buffer: in_cksum_skip: out of data by 21295 delayed m_pullup, m-len: 22 off: 28410 p: 97 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x44032cbf fault code = supervisor read, page not present instruction pointer = 0x20:0xc05a9b54 stack pointer = 0x28:0xc1f274cc frame pointer = 0x28:0xc1f274d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 19 (irq5: xl0) trap number = 12 panic: page fault Uptime: 7d15h55m48s Physical memory: 246 MB Dumping 58 MB: 43 27 11 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 244 dumptid = curthread-td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 #1 0xc0542599 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0542955 in panic (fmt=Could not find the frame base for panic.) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0754ee1 in trap_fatal (frame=0xc1f2748c, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0754ad0 in trap_pfault (frame=0xc1f2748c, usermode=0, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc075439a in trap (frame=0xc1f2748c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc073c3fb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc05a9b54 in m_tag_locate (m=0xc3004300, cookie=0, type=21, t=0x0) at /usr/src/sys/kern/uipc_mbuf2.c:391 #8 0xc043ef81 in m_tag_find (m=0xc3004300, type=21, start=0x0) at mbuf.h:957 #9 0xc043eee1 in pf_get_mtag (m=0xc3004300) at pf_mtag.h:70 #10 0xc044c44e in pf_test (dir=2, ifp=0xc20b6c00, m0=0xc1f276f0, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6776 #11 0xc0459f3f in pf_check_out (arg=0x0, m=0xc1f276f0, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3687 #12 0xc061da71 in pfil_run_hooks (ph=0xc07dee60, mp=0xc1f277b4, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #13 0xc064557e in ip_output (m=0xc3004300, opt=0x0, ro=0xc21b1aa4, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:443 #14 0xc06359d3 in in_gif_output (ifp=0xc2103400, family=18, m=0xc3004300) at /usr/src/sys/netinet/in_gif.c:244 #15 0xc061b3cd in gif_output (ifp=0xc2103400, m=0xc238c100, dst=0xc219c560, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #16 0xc061b009 in gif_start (ifp=0xc2103400) at /usr/src/sys/net/if_gif.c:351 #17 0xc0612c39 in bridge_enqueue (sc=0xc222c800, dst_ifp=0xc2103400, m=0x0) at /usr/src/sys/net/if_bridge.c:1742 #18 0xc0614d9c in bridge_broadcast (sc=0xc222c800, src_if=0xc2196000, m=0xc238c100, runfilt=1) at /usr/src/sys/net/if_bridge.c:2386 #19 0xc0613951 in bridge_forward (sc=0xc222c800, sbif=0xc22c8400, m=0xc238c100) at /usr/src/sys/net/if_bridge.c:2046 #20 0xc0613ed5 in bridge_input (ifp=0xc2196000, m=0xc3068600) at /usr/src/sys/net/if_bridge.c:2168 #21 0xc061b6da in gif_input (m=0xc3068600, af=18, ifp=0xc2196000) at /usr/src/sys/net/if_gif.c:563 #22 0xc0635d34 in in_gif_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/in_gif.c:342 #23 0xc063d905 in encap4_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #24 0xc064190f in ip_input (m=0xc3068600) at /usr/src/sys/netinet/ip_input.c:664 #25 0xc061d61a in netisr_dispatch (num=2, m=0xc3068600) at /usr/src/sys/net/netisr.c:185 #26 0xc0619d16 in ether_demux (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:834 #27 0xc0619af2 in ether_input (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:692 #28 0xc06a1924 in xl_rxeof (sc=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2022 #29 0xc06a23ce in xl_intr (arg=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2257 #30 0xc0518ca0 in ithread_execute_handlers (p=0xc20aa000, ie=0xc2009900) at /usr/src/sys/kern/kern_intr.c:1088 #31 0xc0518e67 in ithread_loop (arg=0xc20d3c80) at /usr/src/sys/kern/kern_intr.c:1175 #32 0xc0516d23 in fork_exit (callout=0xc0518de0 ithread_loop, arg=0xc20d3c80, frame=0xc1f27d38) at /usr/src/sys/kern/kern_fork.c:810 #33 0xc073c470 in fork_trampoline () at /usr/src/sys
Re: Network Card
ovi freebsd wrote: Kaushal Shriyan wrote: On Tue, Apr 21, 2009 at 5:07 PM, Ingo Flaschberger i...@xip.at wrote: Dear Kaushal, I have two lan cards em0 and rl0 on my system. is there a way to know on freebsd which is onboard or pci card ?. The issue is my system is located at remote location. perhaps lspci -v helps. or something like dmidecode (at linux, does not know the freebsd name), then you can readout the mb-name. Kind regards, Ingo Flaschberger Hi Ingo I did pciconf -lv and ran dmidecode. I could not figure it out which one was onboard or pci ? Do you want me to paste the output of that commands Please suggest Thanks and Regards Kaushal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org It is possible to find you the manufacturer of the motherboard? If yes, it would be easy to know which is onboard and which is on PCI since are different network chipsets. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org As an extension of this, what CPU is in the machine? I have never seen an AMD motherboard come with an onboard Intel controller. That is not to say that one doesn't exist, but that it is very rare. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Multi-BSS problem with Atheros 5212
Sam Leffler wrote: Sam Leffler wrote: Boris Kochergin wrote: Ahoy. I'm having trouble with multiple hostap-mode wlan pseudo-devices. The machine is an 8-CURRENT from yesterday: # uname -a FreeBSD test 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Apr 7 16:54:56 UTC 2009 r...@test:/usr/obj/usr/src/sys/GENERIC i386 # dmesg | grep ath ath0: Atheros 5212 mem 0xf410-0xf410 irq 11 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 # cat /etc/rc.conf wlans_ath0=wlan0 wlan1 wlan2 create_args_wlan0=wlanmode hostap bssid create_args_wlan1=wlanmode hostap bssid create_args_wlan2=wlanmode hostap bssid ifconfig_wlan0=ssid wlan0 wepmode off up ifconfig_wlan1=ssid wlan1 wepmode off up ifconfig_wlan2=ssid wlan2 wepmode off up # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:90:27:72:c4:f3 inet 10.0.0.128 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan0 channel 11 (2462 Mhz 11g) bssid 00:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 06:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan1 channel 11 (2462 Mhz 11g) bssid 06:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0a:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan2 channel 11 (2462 Mhz 11g) bssid 0a:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The client is a 7.0 machine with another 5212 card: # uname -a FreeBSD peer 7.0-RELEASE-p10 FreeBSD 7.0-RELEASE-p10 #0: Mon Mar 23 09:26:18 EDT 2009 r...@peer:/usr/obj/usr/src/sys/PEER i386 # dmesg | grep ath ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: Atheros 5212 mem 0xa841-0xa841 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:d1:42:21:5a ath0: mac 7.9 phy 4.5 radio 5.6 The three SSIDs configured on the CURRENT machine show up in a scan: # ifconfig ath0 scan | grep wlan wlan0 00:18:e7:33:5e:24 11 54M -66:-93 100 ES WME wlan1 06:18:e7:33:5e:24 11 54M -65:-93 100 ES WME wlan2 0a:18:e7:33:5e:24 11 54M -65:-93 100 ES WME The client is only able to associate with wlan1, however. When scanning channels while attempting to associate with any of the other ones, it gets stuck on channel 11 for a while before moving on, which seems relevant. Also interesting is the fact that if i do ifconfig ath0 down on the CURRENT machine, followed by, for example, ifconfig ath0 ssid wlan0 (which did not associate before) on the client, followed by ifconfig ath0 up on the CURRENT machine, the client will associate with wlan0, but will not be able to associate with wlan1 or wlan2. Any ideas? wlandebug scan+auth+assoc on the client machine will show you why you cannot associate. You can also enable the same info on the ap side to see what it thinks is happening. FWIW I just setup 3 vap's as you did above and hooked them into a bridge. I verified I could associate and pass traffic using a MBPro. No problems. I also destroyed the bridge and re-tested w/o issues. Regardless the debug msgs should identify what your problem is. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org I booted the hostap machine up and set wlandebug to scan+auth+assoc on wlan0, wlan1, and wlan2. I then inserted the PCMCIA card into the client machine, set wlandebug to scan+auth+assoc on it (ath0), and executed ifconfig ath0 ssid wlan0 up. I let it scan around
Multi-BSS problem with Atheros 5212
Ahoy. I'm having trouble with multiple hostap-mode wlan pseudo-devices. The machine is an 8-CURRENT from yesterday: # uname -a FreeBSD test 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Apr 7 16:54:56 UTC 2009 r...@test:/usr/obj/usr/src/sys/GENERIC i386 # dmesg | grep ath ath0: Atheros 5212 mem 0xf410-0xf410 irq 11 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 # cat /etc/rc.conf wlans_ath0=wlan0 wlan1 wlan2 create_args_wlan0=wlanmode hostap bssid create_args_wlan1=wlanmode hostap bssid create_args_wlan2=wlanmode hostap bssid ifconfig_wlan0=ssid wlan0 wepmode off up ifconfig_wlan1=ssid wlan1 wepmode off up ifconfig_wlan2=ssid wlan2 wepmode off up # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:90:27:72:c4:f3 inet 10.0.0.128 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan0 channel 11 (2462 Mhz 11g) bssid 00:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 06:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan1 channel 11 (2462 Mhz 11g) bssid 06:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs wlan2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0a:18:e7:33:5e:24 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid wlan2 channel 11 (2462 Mhz 11g) bssid 0a:18:e7:33:5e:24 country US ecm authmode OPEN privacy OFF txpower 23 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The client is a 7.0 machine with another 5212 card: # uname -a FreeBSD peer 7.0-RELEASE-p10 FreeBSD 7.0-RELEASE-p10 #0: Mon Mar 23 09:26:18 EDT 2009 r...@peer:/usr/obj/usr/src/sys/PEER i386 # dmesg | grep ath ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) ath0: Atheros 5212 mem 0xa841-0xa841 irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:14:d1:42:21:5a ath0: mac 7.9 phy 4.5 radio 5.6 The three SSIDs configured on the CURRENT machine show up in a scan: # ifconfig ath0 scan | grep wlan wlan0 00:18:e7:33:5e:24 11 54M -66:-93 100 ES WME wlan1 06:18:e7:33:5e:24 11 54M -65:-93 100 ES WME wlan2 0a:18:e7:33:5e:24 11 54M -65:-93 100 ES WME The client is only able to associate with wlan1, however. When scanning channels while attempting to associate with any of the other ones, it gets stuck on channel 11 for a while before moving on, which seems relevant. Also interesting is the fact that if i do ifconfig ath0 down on the CURRENT machine, followed by, for example, ifconfig ath0 ssid wlan0 (which did not associate before) on the client, followed by ifconfig ath0 up on the CURRENT machine, the client will associate with wlan0, but will not be able to associate with wlan1 or wlan2. Any ideas? -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: El día Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribió: Matthias Apitz wrote: I will try to collect a better tcpdump of the dhclient packets on the weekend and as well figure out what kind of model the AP is; would it be helpful to connect with a Windows XP laptop (which seems to work) to gather some information of the Wifi and other network parameters? how this could be seen in Windows? maybe there is some special compression of the payload of the packages in place? Having a packet trace of a working connection to compare would be very helpful. What would be the best tool in WinXP to log Wifi traffic, like tcpdump does? I see some 'Tcpdump for Windows' as http://microolap.com/products/network/tcpdump/ but it seems that it does not work for wireless adapters; any hints? matthias http://www.wireshark.org/download.html -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Strange Server Problems
Kevin wrote: Thanks for your reply, Joe! There is nothing in either system log or Apache log files. Apache doesn't seem to have got the requests at all. Very strange. On Sat, Feb 28, 2009 at 7:27 AM, Joe Mays jfm...@launchpad.win.net wrote: I have a dedicated server running FreeBSD 7.0 release, it has been running well for two months. Suddenly, some websites stopped responding, all websites hosted on this server are simple PHP sites, if one site is working, all of them should work. I checked the bind/apache/mysql, everything is fine (otherwise no websiets would be working). Could anyone please give me some hints? Where should I start to look into this problem? Well, logs, obviously. Does anything appear in the apache error log when you try to hit the sites? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org Apache doesn't write to the access log until a request is complete, so it may be worth bumping the LogLevel value to something more verbose. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025)
The following reply was made to PR kern/129508; it has been noted by GNATS. From: Boris Kochergin sp...@acm.poly.edu To: bug-follo...@freebsd.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Thu, 26 Feb 2009 23:34:06 -0500 For anyone who was unenthusiastic about this due to the infrequency of the problem, this has become less of a debugging nightmare. Due to increased network load, the panic occurs about once a day, on average, now with 7.1-RELEASE-p2. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: if_gif/if_bridge problem
Eugene Grosbein wrote: On Thu, Oct 23, 2008 at 03:29:10PM -0400, Boris Kochergin wrote: #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 241 dumptid = curthread-td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0558861 in panic (fmt=Could not find the frame base for panic. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07bf79d in trap (frame=0xe9f3f63c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:538 #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, mtu=1500, if_hwassist_flags=0, sw_csum=769) at /usr/src/sys/netinet/ip_output.c:726 #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at /usr/src/sys/net/if_gif.c:352 #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, m=0x0) at /usr/src/sys/net/if_bridge.c:1714 #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at /usr/src/sys/net/if_bridge.c:2189 #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at /usr/src/sys/net/if_gif.c:564 #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/in_gif.c:326 #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #20 0xc065819f in ip_input (m=0xc614e700) at /usr/src/sys/netinet/ip_input.c:665 #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at /usr/src/sys/net/netisr.c:185 #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:834 #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:692 #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) at /usr/src/sys/kern/kern_intr.c:1036 #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at /usr/src/sys/kern/kern_intr.c:1121 #28 0xc0530b8c in fork_exit (callout=0xc05329e0 ithread_loop, arg=0xc56f2430, frame=0xe9f3fd38) at /usr/src/sys/kern/kern_fork.c:781 #29 0xc079edc0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 Very nice backtrace. If your system runs without patches, you should send PR with all details included (system version, interface configuration, backtrace and how-to-repeat recipe. Please report back PR number once you get it. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] I've encountered the problem on a machine running RELENG_7 without the patch and have filed a PR. Its number is 129508. Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_gif/if_bridge problem
Eugene Grosbein wrote: On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: Ahoy. I've been using the patch for a while, and, recently, when the load on the wireless network I needed it for has increased, I've started getting kernel panics that I think the patch is responsible for. The panics are usually foreshadowed by messages in the style of Sep 3 11:34:14 unique kernel: delayed m_pullup, m-len: 22 off: 38333 p: 97 in the kernel buffer. I like to think that I've eliminated the possibility of bad hardware by changing the motherboard, memory, and Ethernet controllers in the machine, and have tried both Eugene's original patchset and the one that was committed to 7-STABLE, with the same ill effects. Any ideas about what might be wrong, or shall I set about getting a backtrace? Thanks. Yes, you should. And I think you no more need my patches after Andrew's fixes to gif(4). But if you need my changes to lagg(4), you should now use version corrected to apply to recent RELENG_7: ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz There were no functional changes, only context changes after Anrew's commit. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] Pardon the delay, but here it is. Let me know if I can provide anything else. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc05bfb83 stack pointer = 0x28:0xe9f3f67c frame pointer = 0x28:0xe9f3f6a4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 25 (irq18: xl0) trap number = 12 panic: page fault cpuid = 1 Uptime: 20h30m4s Physical memory: 2551 MB Dumping 325 MB: 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 241 dumptid = curthread-td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0558861 in panic (fmt=Could not find the frame base for panic. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07bf79d in trap (frame=0xe9f3f63c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:538 #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, mtu=1500, if_hwassist_flags=0, sw_csum=769) at /usr/src/sys/netinet/ip_output.c:726 #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at /usr/src/sys/net/if_gif.c:352 #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, m=0x0) at /usr/src/sys/net/if_bridge.c:1714 #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at /usr/src/sys/net/if_bridge.c:2189 #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at /usr/src/sys/net/if_gif.c:564 #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/in_gif.c:326 #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #20 0xc065819f in ip_input (m=0xc614e700) at /usr/src/sys/netinet/ip_input.c:665 #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at /usr/src/sys/net/netisr.c:185 #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:834 #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at /usr/src/sys/net/if_ethersubr.c:692 #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) at /usr/src/sys/kern/kern_intr.c:1036 #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at /usr
Re: if_gif/if_bridge problem
Eugene Grosbein wrote: Eugene, I take it the fix that applies on Boris's case is the M_BCAST|M_MCAST setting on the mbuf? I would like to test/commit this. I see you have already got it :-) Also, why to you add support for adding a bridge to a lagg interface? I needed to force lagg(4) to aggregate two EtherIP tunnels and now I have it working :-) Eugene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] Ahoy. I've been using the patch for a while, and, recently, when the load on the wireless network I needed it for has increased, I've started getting kernel panics that I think the patch is responsible for. The panics are usually foreshadowed by messages in the style of Sep 3 11:34:14 unique kernel: delayed m_pullup, m-len: 22 off: 38333 p: 97 in the kernel buffer. I like to think that I've eliminated the possibility of bad hardware by changing the motherboard, memory, and Ethernet controllers in the machine, and have tried both Eugene's original patchset and the one that was committed to 7-STABLE, with the same ill effects. Any ideas about what might be wrong, or shall I set about getting a backtrace? Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
One-liner for setting IPv6 address and IPv4 endpoints on gif interface?
Hi, list. I set up an IPv6-over-IPv4 tunnel from Hurricane Electric using a gif(4) interface using the commands: ifconfig gif0 tunnel [source IPv4] [destination IPv4] ifconfig gif0 inet6 [source IPv6] [destination IPv6] prefixlen 128 route -n add -inet6 default [destination IPv6] I'm wondering whether there's a one-liner for executing the first two commands, or some non-one-liner way of making it happen through /etc/rc.conf. Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Supported wifi express card
Someone I know got a http://www.buy.com/prod/thinkpad-11a-b-g-wireless-lan-mini-pci-express-adapter-network-adapter/q/loc/101/201992199.html and it works well. -Boris Paolo Pisati wrote: Hi, as the subjects says i'm looking for a freebsd-supported wifi express card. I know i should look for an atheros-based card, but it's really difficult to find which chip a card is using without trying it out first. Googling around, it seems the belkin n express card is what i'm looking for, but i'm open to suggestions. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone seen this error on em ?
[EMAIL PROTECTED] wrote: Jun 9 18:23:59 ... kernel: em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x2000-0x201f mem 0xd802-0xd803,0xd800 -0xd801 irq 18 at device 0.0 on pci4 Jun 9 18:23:59 ... kernel: em0: Using MSI interrupt Jun 9 18:23:59 ... kernel: em0: Setup of Shared code failed Jun 9 18:23:59 ... kernel: device_attach: em0 attach returned 6 I've never seen the returned 6 thing. Plugging a cable into the other em device on the motherboard, a super micro, currently works, but it looks like bad hardware to me. Thoughts? Later, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] Just a me, too. Also on a Supermicro board, and it happens on some boots, but not all. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
if_bridge/if_em packet corruption on last bridged em interface in SPAN mode
Hi, list. We needed to replicate a gigabit SPAN port on a Cisco switch, and, due to the fact that gigabit Ethernet hubs don't seem to exist and that other devices that perform a similar function are costly, I've built my own in the form of a FreeBSD 7.0-RELEASE/amd64 machine. Its motherboard is an MSI K9A2 Platinum and its CPU an AMD Athlon X2 BE-2400. It has four dual-port PCI-E Intel gigabit Ethernet controllers, one single-port PCI-E Intel gigabit Ethernet controller, and one PCI Intel gigabit Ethernet controller. There is an if_bridge device with em4 added to it via addm and the eight other em interfaces added to it via span. So, all traffic received on em4 should be sent out all other em interfaces. To test out the functionality, I used the em4 interface to generate some light ICMP traffic and made sure it could be seen on the other interfaces. I noticed that the last interface on the bridge was sending out slightly corrupted traffic. By last interface, I mean em0 here: bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 6a:14:34:4f:87:45 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: em4 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP member: em9 flags=8SPAN member: em8 flags=8SPAN member: em7 flags=8SPAN member: em6 flags=8SPAN member: em5 flags=8SPAN member: em3 flags=8SPAN member: em2 flags=8SPAN member: em1 flags=8SPAN member: em0 flags=8SPAN By slightly corrupted, I mean this: 12:37:36.807117 IP 10.0.0.106 10.0.0.1: ICMP echo request, id 23557, seq 139, length 64 12:37:36.807436 IP truncated-ip - 21420 bytes missing! 10.0.0.1 10.0.0.106: ICMP echo reply, id 23557, seq 139, length 21484 12:37:37.808061 IP 10.0.0.106 10.0.0.1: ICMP echo request, id 23557, seq 140, length 64 12:37:37.808441 IP truncated-ip - 21420 bytes missing! 10.0.0.1 10.0.0.106: ICMP echo reply, id 23557, seq 140, length 21484 12:37:37.963351 STP 802.1d, Config, Flags [none], bridge-id 8000.00:03:9f:8d:38:07.8009, length 43 12:37:38.809115 IP 10.0.0.106 10.0.0.1: ICMP echo request, id 23557, seq 141, length 64 12:37:38.809329 IP truncated-ip - 21420 bytes missing! 10.0.0.1 10.0.0.106: ICMP echo reply, id 23557, seq 141, length 21484 12:37:39.810008 IP 10.0.0.106 10.0.0.1: ICMP echo request, id 23557, seq 142, length 64 12:37:39.810333 IP truncated-ip - 16300 bytes missing! 10.0.0.1 10.0.0.106: ICMP echo reply, id 23557, seq 142, length 16364 12:37:39.963378 STP 802.1d, Config, Flags [none], bridge-id 8000.00:03:9f:8d:38:07.8009, length 43 12:37:40.811013 IP 10.0.0.106 10.0.0.1: ICMP echo request, id 23557, seq 143, length 64 12:37:40.811402 IP truncated-ip - 21420 bytes missing! 10.0.0.1 10.0.0.106: ICMP echo reply, id 23557, seq 143, length 21484 The corruption goes away when I run tcpdump -n -i em0 and returns when I kill it. If I remove em0 from the bridge, the corruption begins to occur with em1 (when it previously did not), and so forth--it always happens with the last interface on the bridge. The machine runs a GENERIC kernel. Attached are its dmesg, pciconf -lv, and ifconfig output. Thanks. -Boris Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Wed Apr 16 20:08:13 UTC 2008 root@:/usr/obj/usr/src/sys/HUB Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) X2 Dual Core Processor BE-2400 (2300.18-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x60fb2 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch Cores per package: 2 usable memory = 2140438528 (2041 MB) avail memory = 2065874944 (1970 MB) ACPI APIC Table: 122107 APIC0947 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.1 irqs 0-23 on motherboard acpi0: 122107 RSDT0947 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900
Re: USB wireless AP?
Do you know about http://ralink.rapla.net/? The RT2500-based cards listed there are supported by the ural(4) driver. There's a discouraging comment about using them for access points in the man page, though: CAVEATS The ural driver does not support automatic adaptation of the transmit speed in IBSS and HostAP operating modes. -Boris Ivan Voras wrote: Hi, I'm planning to set up an AP by adding an USB wifi card to a 7.0-RELEASE machine, and I'm interested in a couple of things: - First, hardware compatibility - AFAIK only some cards support AP mode? Can anyone recommend such USB wireless hardware, preferably in terms of product names instead of chip names? I see the following cards in a local store: BANDRIDGE CWN4002G, CANYON WF-518D, CANYON WF-518, LINKSYS WUSB54GC. - Are there any tips tricks additional to the instructions on http://www.freebsd.org/doc/en/books/handbook/network-wireless.html ? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB wireless AP?
Ivan Voras wrote: Boris Kochergin wrote: Do you know about http://ralink.rapla.net/? The RT2500-based cards listed there are supported by the ural(4) driver. There's a discouraging comment about using them for access points in the man page, though: CAVEATS The ural driver does not support automatic adaptation of the transmit speed in IBSS and HostAP operating modes. That's too bad - it seems the Linsys' card is supported by ural. I looked around for Linux information on the same topic, and given the problems they have, I think I'll even settle for IBSS. Are there any practical differences between HOSTAP and IBSS when used by a very small number of users? I've never used IBSS, but I have enough spare 802.11 hardware to try it out. I'll let you know. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Howto send a limited broadcast?
tmm wrote: Bruce M. Simpson wrote: tmm wrote: So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Use the IP_ONESBCAST option and send to the network broadcast address for that subnet. The stack will change it into 255.255.255.255 on output. See man page ip(4) for details. It's a hack, but it's largely due to how the stack has worked historically. BMS Thanks. I wasn't aware of that option. But now I find that this option is not present in my (eCos port of) FreeBSD stack. Either it was removed during the port, or the ported version is too old. Perhaps the best thing for me to do is to look at the 'normal' FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST is implemented. Then perhaps I could do the same thing in my FreeBSD stack. Is there a way for me to download the FreeBSD source code without actually downloading, burning, and installing FreeBSD? Looking around the FreeBSD website I don't see a source download link. thanks, Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] You can get them via CVS: http://www.freebsd.org/doc/en/books/handbook/cvsup.html. Also, although it, too, may be considered hacky, if the system you're working on has pcap(3), you could just manually craft the broadcast frame and send it out the interface yourself. I can provide some sample code. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Howto send a limited broadcast?
tmm wrote: Boris Kochergin wrote: tmm wrote: Bruce M. Simpson wrote: tmm wrote: So, can anyone suggest how I can send a limited broadcast (on an interface that has been initalized with an IP and a subnet)? Use the IP_ONESBCAST option and send to the network broadcast address for that subnet. The stack will change it into 255.255.255.255 on output. See man page ip(4) for details. It's a hack, but it's largely due to how the stack has worked historically. BMS Thanks. I wasn't aware of that option. But now I find that this option is not present in my (eCos port of) FreeBSD stack. Either it was removed during the port, or the ported version is too old. Perhaps the best thing for me to do is to look at the 'normal' FreeBSD stack (as opposed to the eCos one) and see how IP_ONESBCAST is implemented. Then perhaps I could do the same thing in my FreeBSD stack. Is there a way for me to download the FreeBSD source code without actually downloading, burning, and installing FreeBSD? Looking around the FreeBSD website I don't see a source download link. thanks, Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] You can get them via CVS: http://www.freebsd.org/doc/en/books/handbook/cvsup.html. Also, although it, too, may be considered hacky, if the system you're working on has pcap(3), you could just manually craft the broadcast frame and send it out the interface yourself. I can provide some sample code. -Boris Yes, that is what I was looking for - I'll use cvsup/csup to get the sources. I don't have pcap, but I do have access to the lower layers of the stack, so yes, I would be interested in seeing your code. Doing something like that might turn out to be a better solution for me. Thanks a lot. Tom. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] http://acm.poly.edu/~spawk/arpCounterattack.tbz That's some code I wrote a while ago that detects ARP attacks against a configured set of IP/Ethernet address pairs on broadcast networks, and sends out gratuitous ARP requests in an attempt to correct the situation. The relevant function here is sendGratuitousARPRequest() in arpCounterattack.hpp. It constructs a gratuitous ARP frame and sends it out the configured interface. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
if_gif/if_bridge problem
Hi, list. As per the comment in the if_bridge(4) man page, I'm trying to
tunnel Ethernet through IP for the purpose of having multiple 802.11
access points all feed into a concentrator, which will perform NAT.
I have the concentrator with the following setup (gif0 through gif1 are
IPv4-over-IPv6 tunnels and I don't believe them to be relevant to the
problem, but I'm open to being wrong):
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8VLAN_MTU
ether 00:04:ac:58:a4:c3
inet6 fe80::204:acff:fe58:a4c3%fxp0 prefixlen 64 scopeid 0x1
inet 128.238.9.202 netmask 0xff00 broadcast 128.238.9.255
inet6 2001:4830:2401::1 prefixlen 64
inet6 3ffe:401d:ff:186a::1 prefixlen 64
media: Ethernet autoselect (100baseTX full-duplex)
status: active
bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
1500
ether 3e:7f:e8:ef:f6:a4
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: gif6 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
gif6: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280
tunnel inet 128.238.9.202 -- 128.238.35.81
inet 10.0.0.1 -- 10.0.0.2 netmask 0xff00
inet6 fe80::204:acff:fe58:a4c3%gif6 prefixlen 64 scopeid 0xa
The concentrator performs NAT with pf. The only line in /etc/pf.conf is
nat on fxp0 from bridge0:network to any - (fxp0) static-port. It also
runs dhcpd, whose configuration file is:
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.200;
option routers 192.168.0.1;
option domain-name poly.edu;
option domain-name-servers 128.238.9.202, 4.2.2.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
default-lease-time 3600;
max-lease-time 3600;
}
I have an access point with the following setup:
ath0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
0 mtu 1500
ether 00:18:e7:32:b1:9d
media: IEEE 802.11 Wireless Ethernet autoselect hostap
(autoselect hostap)
status: associated
ssid acm channel 1 (2412 Mhz 11g) bssid 00:18:e7:32:b1:9d
authmode OPEN privacy OFF deftxkey 1 wepkey 1:104-bit txpower 31.5
scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7
roam:rate11g 5 protmode CTS burst dtimperiod 1
gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280
tunnel inet 128.238.35.81 -- 128.238.9.202
inet 10.0.0.2 -- 10.0.0.1 netmask 0xff00
bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
1500
ether 4a:0a:2d:b1:17:ae
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: gif0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
member: ath0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
Clients are able to associate with the access point, and are able to
acquire an IP via DHCP:
# dhclient ral0
DHCPREQUEST on ral0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.199 -- renewal in 1800 seconds.
However, nothing after this seems to work. I've started debugging by
attempting to ping 192.168.0.1 (the concentrator) from the client, and
this is what happens:
On the client:
# tcpdump -n -i ral0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ral0, link-type EN10MB (Ethernet), capture size 96 bytes
10:41:58.628796 arp who-has 192.168.0.1 tell 192.168.0.199
10:41:59.630223 arp who-has 192.168.0.1 tell 192.168.0.199
10:42:00.631064 arp who-has 192.168.0.1 tell 192.168.0.199
On the access point:
# tcpdump -n -i bridge0
tcpdump: WARNING: bridge0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge0, link-type EN10MB (Ethernet), capture size 68 bytes
09:52:23.065926 arp who-has 192.168.0.1 tell 192.168.0.199
09:52:24.067110 arp who-has 192.168.0.1 tell 192.168.0.199
09:52:25.067883 arp who-has 192.168.0.1 tell 192.168.0.199
On the concentrator:
# tcpdump -n -i bridge0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes
09:51:32.483177 arp who-has 192.168.0.1 tell 192.168.0.199
09:51:33.484216 arp who-has 192.168.0.1 tell 192.168.0.199
09:51:34.484948 arp who-has 192.168.0.1 tell 192.168.0.199
So, the tunnels and bridges appear to be sending the traffic around
properly, but the concentrator machine isn't replying to ARP requests
for its bridge0 interface's IP. This is where I'm stuck. Any help is
appreciated.
-Boris
Re: if_gif/if_bridge problem
Eugene Grosbein wrote: On Tue, Feb 26, 2008 at 09:57:48AM -0500, Boris Kochergin wrote: bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3e:7f:e8:ef:f6:a4 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: gif6 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP [skip] So, the tunnels and bridges appear to be sending the traffic around properly, but the concentrator machine isn't replying to ARP requests for its bridge0 interface's IP. This is where I'm stuck. Any help is appreciated. The problem is that if_bridge(4) won't work this way - with only one gif-member without patching. I've faced this recently and debugged it in detail. Then I've produced a patch and now I run it over a month in production without a problem: ftp://www.kuzbass.ru/pub/freebsd/lagg-0.1.tgz Description inside, in Russian. In short: if_gif(4) no more kills ethernet frames returned by if_bridge(4) as designated for upper levels of TCP/IP stack but really passes them there. If the patched system does not have EtherIP-tunnels then the patch affects nothing, so it's safe to apply it. Also, you need not to reboot the system if you load if_gif/if_bridge as modules, just rebuld and reload these. The patch applies to all of 6.2, 6.3-PRERELEASE and 7.0-PRERELEASE, and works (tested). My task was a bit more complex so the patch touches if_lagg(4) too but you need not use lagg(4) if you do not need it. The patch just contains the solution for your problem too. You can read detailed discussion in Russian there: http://groups.google.com/group/fido7.ru.unix.bsd/browse_thread/thread/d6787b865515a66a/488d738afc265b19 Eugene Grosbein I just tested it on my 7.0-RC1 setup and it did indeed take care of the problem. Thank you very much! -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Routing outbound IP packets on multihomed box
Hi. I've come across this problem but solved it with a PF rule of this form, if that's an option for you: pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any This tells PF to send all packets sent from 169.229.126.9 through the vlan256 interface with a next-hop address of 169.229.126.1. -Boris Christopher Cowart wrote: Hello, I have a server with two NICs: em0:169.229.79.139/25 vlan526:169.229.126.9/24 The default gateway is 169.229.79.129. The router for the 126 subnet is 169.229.126.1. netstat -rn: | DestinationGatewayFlagsRefs Use Netif Expire | default169.229.79.129 UGS 0 102537em0 | 127.0.0.1 127.0.0.1 UH 0 217lo0 | 169.229.79.128/25 link#1 UC 00em0 | 169.229.79.129 00:15:c7:b9:f4:80 UHLW24em0 1193 | 169.229.79.139 00:11:25:ab:42:70 UHLW1 589lo0 | 169.229.126/24 link#9 UC 00 vlan52 | 169.229.126.1 00:15:c7:b9:f4:80 UHLW1 34 vlan52 1200 | 169.229.126.9 00:18:f8:09:d3:a5 UHLW18lo0 The IP address on em0 works exactly as one would expect. I have full IP connectivity to it from other subnets. The problem is I can't get 2-way connectivity with the IP address on vlan526. Using my workstation on a third subnet (169.229.127.38/24), I cannot ping 169.229.126.9. I leave the ping running and do some tcpdumps on the server. $ sudo tcpdump -ni vlan526 host 169.229.127.38 | 14:14:37.002920 IP 169.229.127.38 169.229.126.9: ICMP echo | request, id 15733, seq 35, length 64 | 14:14:38.003037 IP 169.229.127.38 169.229.126.9: ICMP echo | request, id 15733, seq 36, length 64 Notice there are no echo replies. That's because they're being sent here: $ sudo tcpdump -ni em0 host 169.229.127.38 | 14:15:42.006997 IP 169.229.126.9 169.229.127.38: ICMP echo reply, | id 15733, seq 100, length 64 | 14:15:43.007118 IP 169.229.126.9 169.229.127.38: ICMP echo reply, | id 15733, seq 101, length 64 I repeated this last snoop with a -w and loaded it into ethereal. The echo replies being sent out on em0 indeed have a source address of 169.229.126.9. The router (169.229.79.139) drops these packets on the floor, because their source address isn't routable on that interface. Because routing is based on destination, not source address, I'm not sure how to get packets sourced from the 126 subnet to the router on the 126 subnet. I tried the following ipfw rule right after allow loopback traffic (my second rule): fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 Still no luck. Has anyone set up a multihomed box on *different* subnets before without routing them through the FreeBSD box? Does anyone have any pointers or things I should be looking at? Thanks, ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hang with Ralink RT2661
Sepherosa Ziehau wrote: On 5/27/07, Boris Kochergin [EMAIL PROTECTED] wrote: Hi. I got an SMC SMCWPCI-GM card the other day, which is one of these: May 27 01:16:55 router kernel: ral0: Ralink Technology RT2661 mem 0xf400-0xf4007fff irq 10 at device 13.0 on pci0 May 27 01:16:55 router kernel: ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) I put it into a Pentium III machine (which has PCI 2.2, per the ral(4) man page) running a 7-CURRENT build from earlier today with a GENERIC kernel, and attempted to connect to my wireless network, the access point of which is an Atheros 5212 card, which has been serving Prism and other Atheros cards for months. The RT2661 card associated fine and was able to carry out lightweight operations like pinging and HTTP requests, but when I attempted to use it to send or receive any heavy traffic (a few dozen KiB/second), the system froze. I was able to toggle the caps lock/num lock lights, and if I did something to make the system beep (i.e. by pressing ALT+F10 when there was no virtual terminal running there), the beep would ring out endlessly. It may also be worth mentioning that the system was unresponsive to ACPI (via the power button) and that the same RT2661 card in the same machine has no trouble sniffing over 2 MiB/second of traffic via tcpdump. I'll be happy to provide any other information that may be deemed useful. Thanks. Try changing ~line160 of dev/ral/rt2661reg.h From #define RT2661_SHORT_PREAMBLE (1 19) #define RT2661_MRR_ENABLED (1 20) #define RT2661_MRR_CCK_FALLBACK(1 23) to #define RT2661_SHORT_PREAMBLE (1 18) #define RT2661_MRR_ENABLED (1 19) #define RT2661_MRR_CCK_FALLBACK(1 22) This will make the situation better. Except the above wrongly configured MMR register values, rt2661 parts' TX intr processing is completely wrong; The channel TX power is incorrect too, for 11bg the difference between the correct one and the value that driver is using is small, but for 11a, the channel TX power will be completely wrong. Best Regards, sephe Doesn't seem to have any effect. Thanks, though. I guess I'll wait for SAM_WIFI to become available in -CURRENT. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
System hang with Ralink RT2661
Hi. I got an SMC SMCWPCI-GM card the other day, which is one of these: May 27 01:16:55 router kernel: ral0: Ralink Technology RT2661 mem 0xf400-0xf4007fff irq 10 at device 13.0 on pci0 May 27 01:16:55 router kernel: ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) I put it into a Pentium III machine (which has PCI 2.2, per the ral(4) man page) running a 7-CURRENT build from earlier today with a GENERIC kernel, and attempted to connect to my wireless network, the access point of which is an Atheros 5212 card, which has been serving Prism and other Atheros cards for months. The RT2661 card associated fine and was able to carry out lightweight operations like pinging and HTTP requests, but when I attempted to use it to send or receive any heavy traffic (a few dozen KiB/second), the system froze. I was able to toggle the caps lock/num lock lights, and if I did something to make the system beep (i.e. by pressing ALT+F10 when there was no virtual terminal running there), the beep would ring out endlessly. It may also be worth mentioning that the system was unresponsive to ACPI (via the power button) and that the same RT2661 card in the same machine has no trouble sniffing over 2 MiB/second of traffic via tcpdump. I'll be happy to provide any other information that may be deemed useful. Thanks. -Boris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
