From owner-freebsd-net@FreeBSD.ORG Sun Oct 31 07:40:13 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E98C10656A3 for ; Sun, 31 Oct 2010 07:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 30DC68FC08 for ; Sun, 31 Oct 2010 07:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9V7eC1k062387 for ; Sun, 31 Oct 2010 07:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9V7eCK4062386; Sun, 31 Oct 2010 07:40:12 GMT (envelope-from gnats) Date: Sun, 31 Oct 2010 07:40:12 GMT Message-Id: <201010310740.o9V7eCK4062386@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexander V. Chernikov" Cc: Subject: Re: kern/134931: [route] Route messages sent to all socket listeners regardless of setfib(1) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 07:40:13 -0000 The following reply was made to PR kern/134931; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-followup@FreeBSD.org, count@211.ru Cc: Subject: Re: kern/134931: [route] Route messages sent to all socket listeners regardless of setfib(1) Date: Sun, 31 Oct 2010 10:27:29 +0300 This is a multi-part message in MIME format. --------------040709010609040905070606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This modified patch works well for me on FreeBSD 7.2-RELEASE-p5 amd64 --------------040709010609040905070606 Content-Type: text/plain; name="rtsock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtsock.diff" --- sys/net/rtsock.c.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/net/rtsock.c 2010-10-15 16:52:57.000000000 +0400 @@ -88,6 +88,11 @@ SYSCTL_INT(_net_route, OID_AUTO, netisr_maxqlen, CTLFLAG_RW, &rtsintrq.ifq_maxlen, 0, "maximum routing socket dispatch queue length"); +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + struct walkarg { int w_tmemsize; int w_op, w_arg; @@ -109,7 +114,7 @@ struct rt_metrics_lite *out); static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static void rts_init(void) @@ -128,19 +133,21 @@ rts_input(struct mbuf *m) { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; + int fibnum = -1; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + fibnum = ctx->fibnum; m_tag_delete(m, tag); } else route_proto.sp_protocol = 0; - raw_input(m, &route_proto, &route_src); + raw_input(m, &route_proto, &route_src, fibnum); } /* @@ -729,10 +736,10 @@ */ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } } return (error); @@ -953,7 +960,7 @@ * destination. */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; struct mbuf *m; @@ -968,7 +975,7 @@ rtm->rtm_flags = RTF_DONE | flags; rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } /* @@ -993,7 +1000,7 @@ ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } /* @@ -1005,7 +1012,7 @@ * copies of it. */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; struct sockaddr *sa = NULL; @@ -1061,7 +1068,7 @@ rtm->rtm_errno = error; rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1097,7 +1104,7 @@ __func__)); ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, -1); } static struct mbuf * @@ -1157,7 +1164,7 @@ if (m->m_flags & M_PKTHDR) m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } } @@ -1173,27 +1180,30 @@ m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; /* * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } netisr_queue(NETISR_ROUTE, m); /* mbuf is free'd on failure. */ --- sys/net/raw_usrreq.c.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/net/raw_usrreq.c 2010-10-15 16:52:57.000000000 +0400 @@ -67,7 +67,7 @@ * Raw protocol interface. */ void -raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src) +raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src, int fibnum) { struct rawcb *rp; struct mbuf *m = m0; @@ -81,6 +81,9 @@ if (rp->rcb_proto.sp_protocol && rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (fibnum >= 0 && rp->rcb_socket && + fibnum != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; n = m_copy(m, 0, (int)M_COPYALL); --- sys/net/raw_cb.h.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/net/raw_cb.h 2010-10-15 16:52:57.000000000 +0400 @@ -70,7 +70,7 @@ */ int raw_attach(struct socket *, int); void raw_detach(struct rawcb *); -void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *); +void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *, int); /* * Generic pr_usrreqs entries for raw socket protocols, usually wrapped so --- sys/net/route.c.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/net/route.c 2010-10-15 17:02:25.000000000 +0400 @@ -344,7 +344,7 @@ newrt->rt_ifp->if_addr->ifa_addr; info.rti_info[RTAX_IFA] = newrt->rt_ifa->ifa_addr; } - rt_missmsg(RTM_ADD, &info, newrt->rt_flags, 0); + rt_missmsg(RTM_ADD, &info, newrt->rt_flags, 0, fibnum); } else { KASSERT(rt == newrt, ("locking wrong route")); RT_LOCK(newrt); @@ -370,7 +370,7 @@ */ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } } if (newrt) @@ -591,7 +591,7 @@ info.rti_info[RTAX_GATEWAY] = gateway; info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); } int @@ -1482,7 +1482,7 @@ * notify any listening routing agents of the change */ RT_LOCK(rt); - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); if (cmd == RTM_DELETE) { /* * If we are deleting, and we found an entry, then --- sys/net/route.h.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/net/route.h 2010-10-15 16:52:57.000000000 +0400 @@ -350,8 +350,8 @@ void rt_ieee80211msg(struct ifnet *, int, void *, size_t); void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); --- sys/netinet6/in6.c.orig 2009-06-10 14:31:11.000000000 +0400 +++ sys/netinet6/in6.c 2010-10-15 17:03:36.000000000 +0400 @@ -190,7 +190,7 @@ nrt->rt_ifa = ifa; } - rt_newaddrmsg(cmd, ifa, e, nrt); + rt_newaddrmsg(cmd, ifa, e, nrt, -1); if (cmd == RTM_DELETE) RTFREE_LOCKED(nrt); else { --- sys/sys/mbuf.h.orig 2009-04-15 07:14:26.000000000 +0400 +++ sys/sys/mbuf.h 2010-10-15 16:54:59.000000000 +0400 @@ -851,7 +851,7 @@ #define PACKET_TAG_IPFORWARD 18 /* ipforward info */ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock extra info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ --------------040709010609040905070606-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 1 11:07:02 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8EB1065670 for ; Mon, 1 Nov 2010 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B89B8FC14 for ; Mon, 1 Nov 2010 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B71KW019241 for ; Mon, 1 Nov 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B71r1019239 for freebsd-net@FreeBSD.org; Mon, 1 Nov 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:07:01 GMT Message-Id: <201011011107.oA1B71r1019239@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 11:07:02 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/151690 net network connectivity won't work until dhclient is run o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/151441 net [iwi] iwi module not work properly using HP nc6220 o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 364 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 1 16:53:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8265A106566C for ; Mon, 1 Nov 2010 16:53:08 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id EBADB8FC15 for ; Mon, 1 Nov 2010 16:53:07 +0000 (UTC) Received: (qmail 18772 invoked by uid 0); 1 Nov 2010 16:53:06 -0000 Received: from 79.107.31.205 by rms-eu010.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 01 Nov 2010 17:40:17 +0100 From: "Nikos Vassiliadis" Message-ID: <20101101165305.95100@gmx.com> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #46156728 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: Q8n9dBMRMmA6V9Mnq2NnpEE5MjQ1N503 X-FuHaFi: 0.51000000000000001 Subject: strange entry in the routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 16:53:08 -0000 Hi, While using proxy arp and the same IP address on multiple interfaces, I noticed a strange entry in the routing table. 192.168.73.60      link#1             UHS         2        0    lo0 => 192.168.73.60/32   link#3             U           0        0 epair0 The 192.168.73.60/24 address is assigned on an ethernet interface. Then I assign 192.168.73.60/32 on some epairs with vnets and use proxyall to proxy arp. I believe what I am doing is supported(?) and everything seems to work as expected. Yet this routing table entry is strange. Thanks for any insights, Nikos lab# ifconfig em0: flags=8843 metric 0 mtu 1500        options=9b        ether 08:00:27:17:c3:de        inet 192.168.73.60 netmask 0xffffff00 broadcast 192.168.73.255        inet6 fe80::a00:27ff:fe17:c3de%em0 prefixlen 64 scopeid 0x1        nd6 options=29        media: Ethernet autoselect (1000baseT )        status: active lo0: flags=8049 metric 0 mtu 16384        options=3        inet 127.0.0.1 netmask 0xff000000        inet6 ::1 prefixlen 128        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2        nd6 options=21 lab# netstat -rnfinet Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            192.168.73.1       UGS         0       13    em0 127.0.0.1          link#2             UH          0        0    lo0 192.168.73.0/24    link#1             U           1      113    em0 192.168.73.60      link#1             UHS         0        0    lo0 lab# ifconfig epair create epair0a lab# ifconfig epair create epair1a lab# ifconfig epair0a 192.168.73.60/32 lab# ifconfig epair1a 192.168.73.60/32 lab# arp -an ? (192.168.73.60) at 02:c0:44:00:05:0a on epair1a permanent [ethernet] ? (192.168.73.60) at 02:c0:44:00:03:0a on epair0a permanent [ethernet] ? (192.168.73.1) at 00:13:33:07:90:90 on em0 expires in 970 seconds [ethernet] ? (192.168.73.194) at 70:1a:04:f7:4e:3c on em0 expires in 1194 seconds [ethernet] ? (192.168.73.60) at 08:00:27:17:c3:de on em0 permanent [ethernet] lab# netstat -rnfinet Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            192.168.73.1       UGS         0       13    em0 127.0.0.1          link#2             UH          0        0    lo0 192.168.73.0/24    link#1             U           1      197    em0 192.168.73.60      link#1             UHS         2        0    lo0 => 192.168.73.60/32   link#3             U           0        0 epair0 lab# From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 00:11:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5431065673; Tue, 2 Nov 2010 00:11:37 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 16D668FC0A; Tue, 2 Nov 2010 00:11:36 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 2F49717024; Tue, 2 Nov 2010 03:11:34 +0300 (MSK) Date: Tue, 2 Nov 2010 03:11:34 +0300 From: Maxim Dounin To: Andre Oppermann Message-ID: <20101102001134.GP44164@mdounin.ru> References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA09987.8020205@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Igor Sysoev , Lawrence Stewart Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 00:11:37 -0000 Hello! On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: > On 27.09.2010 10:12, Maxim Dounin wrote: > >Hello! > > > >On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: > > > >[...] > > > >>Andre, could you please take a look at one more patch as well? > >> > >>Igor reported that it still sees 100ms delays with rfc3465 turned > >>on, and it turns out to be similar issue (setting cwnd to 1*MSS) > >>for hosts found in hostcache. > >> > >>The problem with setting cwnd from hostcache was already reported > >>here: > >> > >>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 > >>http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html > >> > >>As using larger cwnd from hostcache may cause problems on > >>congested links (see second thread) I changed code to only use > >>cached cwnd as an upper bound for cwnd (instead of fixing current > >>code). This is also in-line with what we do on connection > >>restarts. > >> > >>We may later consider re-adding usage of larger cwnd from > >>hostcache. But I believe it should be done carefully and > >>probably behind sysctl, off by default. > > > >Ping. > > Thanks for the reminder. I'll disable priming CWND from hostcache. Ping again. I would like to see the patch in question[1] committed and MFC'ed somewhere before 8.2. Andre, if you are just too busy to do it yourself - please say so, I'll ask somebody else to commit it. [1] http://lists.freebsd.org/pipermail/freebsd-net/2010-September/026418.html Maxim Dounin From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 02:28:45 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBF89106566B; Tue, 2 Nov 2010 02:28:45 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2078FC0A; Tue, 2 Nov 2010 02:28:45 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PCzvz-0007yN-Ie; Mon, 01 Nov 2010 15:20:50 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2010 15:20:46 -0400 Message-Id: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Source: X-Source-Args: X-Source-Dir: Cc: net@freebsd.org Subject: RFC: Updated ARP Queue patch... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 02:28:45 -0000 Howdy, This is marked as "Updated" because I first proposed this on arch@ but = am now sending it to a wider audience as I'm hoping to commit it in the near future. Please review the following patch against HEAD: http://people.freebsd.org/~gnn/head-arpqueue2.diff This patch makes two changes to the ARP code: 1) It adds a sysctl configurable queue of packets that are held until an = ARP reply is received or timed out. net.link.ether.inet.maxhold Having the queue addresses a problem in modern systems where programs = that use connectionless=20 protocols for communication will suffer from dropping many packets when = they start up or when an ARP entry moves. 2) Makes the time we wait for an arp reply configurable via another = sysctl. net.link.ether.inet.wait The old, pre 8.0, ARP code would run the timer once per second. The new ARP code sets a timeout of 20 seconds on each entry. Neither value was = specified in RFC 826. As a matter of fact, RFC 826 had this to say about = timeouts: "It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol." This new code does not change the default value of either the arpqueue = (which was always 1 packet) nor does it change the new value of the ARP down = timeout. I have a different patch for 7, which I will propose after I can get = this in to HEAD and MFC'd to 8. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 03:04:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A40971065670 for ; Tue, 2 Nov 2010 03:04:05 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCE58FC15 for ; Tue, 2 Nov 2010 03:04:05 +0000 (UTC) Received: by pwi8 with SMTP id 8so1442187pwi.13 for ; Mon, 01 Nov 2010 20:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=m+sBwiOy17FY1pRKB3U4OcSisfVq32olX/m0Fcl3oOI=; b=sKjFzStrEFEhDOC5jn02aOanb51rXuZihHHwlDO8Won7n/ZIFuqse0fyY4SvZlarzl pNaRtCZw340q3pxnne5VvSF0Hbd2ElOoBZjag/nRZEETpfO9fFALTyDlk0zf3wjXB9o2 Q9HyXcDTsHCBJ8gZhyDKVITBXN7CO1taWlPy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WX+GhAAS1cO6qJ+1sk5bYgl+17vvV3a4sCqmtKmji2LqZe38QAX9k6Fvn/DyUWGjBJ rrCUB/OR1DDfxPW+lLUX7PAMJG4FOM29dA2O2bHirK7xuvM3c8s2o+uYyco/zGFz6UL2 ME9dK9nakLswXgSvPY6WqgXQBBwipDym35OTQ= MIME-Version: 1.0 Received: by 10.142.178.21 with SMTP id a21mr5070010wff.374.1288665627256; Mon, 01 Nov 2010 19:40:27 -0700 (PDT) Received: by 10.142.164.12 with HTTP; Mon, 1 Nov 2010 19:40:27 -0700 (PDT) Date: Mon, 1 Nov 2010 22:40:27 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: MPLS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 03:04:05 -0000 Was reading through the OpenBSD 4.8 release notes. Seems they have a good bit of work/support for MPLS going on. I've seen light mention of it on FreeBSD lists now and then yet am unaware of any committed work. Is MPLS of age such that FreeBSD should have designs on doing it? Would it fit better as a FreeBSD Foundation or GSoC project? General thoughts? From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 10:20:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A281065670 for ; Tue, 2 Nov 2010 10:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A027F8FC08 for ; Tue, 2 Nov 2010 10:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA2AK9Tc096962 for ; Tue, 2 Nov 2010 10:20:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA2AK9YT096961; Tue, 2 Nov 2010 10:20:09 GMT (envelope-from gnats) Date: Tue, 2 Nov 2010 10:20:09 GMT Message-Id: <201011021020.oA2AK9YT096961@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eugene Grosbein Cc: Subject: Re: kern/150920: [ixgbe][igb] Panic when packets are dropped with header split disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Grosbein List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 10:20:09 -0000 The following reply was made to PR kern/150920; it has been noted by GNATS. From: Eugene Grosbein To: bug-followup@freebsd.org Cc: jfv@freebsd.org Subject: Re: kern/150920: [ixgbe][igb] Panic when packets are dropped with header split disabled Date: Tue, 02 Nov 2010 15:41:39 +0600 This problem seems to be fixed in sys/dev/e1000/if_igb.c,v1.60 but not in STABLE (there were no MFC yet). By the way, I'm experiencing kernel panics in em(4) for two distinct very loaded routers based on em-supported NICs (no crashdumps collected yet, sorry). And I see very similar code in if_em.c without a check for NULL pointer before dereferencing, this time without a fix even in HEAD. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 20:10:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF3781065674; Tue, 2 Nov 2010 20:10:29 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B420B8FC21; Tue, 2 Nov 2010 20:10:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA2KATiD009976; Tue, 2 Nov 2010 20:10:29 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA2KAThV009958; Tue, 2 Nov 2010 20:10:29 GMT (envelope-from bschmidt) Date: Tue, 2 Nov 2010 20:10:29 GMT Message-Id: <201011022010.oA2KAThV009958@freefall.freebsd.org> To: faizal.abidin@gmail.com, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/151441: [iwi] iwi module not work properly using HP nc6220 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:10:30 -0000 Synopsis: [iwi] iwi module not work properly using HP nc6220 State-Changed-From-To: open->feedback State-Changed-By: bschmidt State-Changed-When: Tue Nov 2 20:09:00 UTC 2010 State-Changed-Why: Yes, please, more details please. What is the actual issue? Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Tue Nov 2 20:09:00 UTC 2010 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=151441 From owner-freebsd-net@FreeBSD.ORG Tue Nov 2 22:30:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DAEA10656E0 for ; Tue, 2 Nov 2010 22:30:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D39F28FC14 for ; Tue, 2 Nov 2010 22:30:08 +0000 (UTC) Received: (qmail 1343 invoked from network); 2 Nov 2010 22:15:52 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Nov 2010 22:15:52 -0000 Message-ID: <4CD090EF.4020402@freebsd.org> Date: Tue, 02 Nov 2010 23:30:07 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Maxim Dounin , Lawrence Stewart References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> In-Reply-To: <20101102001134.GP44164@mdounin.ru> Content-Type: multipart/mixed; boundary="------------020604060703050200000809" Cc: freebsd-net@freebsd.org, Igor Sysoev Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 22:30:16 -0000 This is a multi-part message in MIME format. --------------020604060703050200000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02.11.2010 01:11, Maxim Dounin wrote: > Hello! > > On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: > >> On 27.09.2010 10:12, Maxim Dounin wrote: >>> Hello! >>> >>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>> >>> [...] >>> >>>> Andre, could you please take a look at one more patch as well? >>>> >>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>> for hosts found in hostcache. >>>> >>>> The problem with setting cwnd from hostcache was already reported >>>> here: >>>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>> >>>> As using larger cwnd from hostcache may cause problems on >>>> congested links (see second thread) I changed code to only use >>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>> code). This is also in-line with what we do on connection >>>> restarts. >>>> >>>> We may later consider re-adding usage of larger cwnd from >>>> hostcache. But I believe it should be done carefully and >>>> probably behind sysctl, off by default. >>> >>> Ping. >> >> Thanks for the reminder. I'll disable priming CWND from hostcache. > > Ping again. > > I would like to see the patch in question[1] committed and MFC'ed > somewhere before 8.2. > > Andre, if you are just too busy to do it yourself - please say so, > I'll ask somebody else to commit it. Thanks for the reminder. After EuroBSDCon Developer Summit I was busy with other work and most of my tcp work was stalled due to review bandwidth issues. Lawrence, could you please spare a few seconds and take a quick look at the attached patch? -- Andre --------------020604060703050200000809 Content-Type: text/plain; name="tcp_input-nometricscwnd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcp_input-nometricscwnd.diff" Index: tcp_input.c =================================================================== --- tcp_input.c (revision 214692) +++ tcp_input.c (working copy) @@ -3340,10 +3340,14 @@ * hostcache when cwnd collapses so next connection doesn't * overloads the path again. * + * XXXAO: Initializing the CWND from the hostcache is broken + * and in its current form not RFC conformant. It is disabled + * until fixed or removed entirely. + * * RFC3390 says only do this if SYN or SYN/ACK didn't got lost. * We currently check only in syncache_socket for that. */ -#define TCP_METRICS_CWND +/* #define TCP_METRICS_CWND */ #ifdef TCP_METRICS_CWND if (metrics.rmx_cwnd) tp->snd_cwnd = max(mss, --------------020604060703050200000809-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 4 05:12:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D783106566B for ; Thu, 4 Nov 2010 05:12:11 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 550218FC12 for ; Thu, 4 Nov 2010 05:12:11 +0000 (UTC) X-ASG-Debug-ID: 1288846383-0d0f33a70001-QdxwpM Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id AH3uI5RQACDyEUgI; Wed, 03 Nov 2010 21:53:03 -0700 (PDT) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Wed, 3 Nov 2010 21:53:03 -0700 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: "Ricky Charlet" , Jack Vogel , Juli Mallett Date: Wed, 3 Nov 2010 21:53:02 -0700 X-ASG-Orig-Subj: RE: em driver problem on vmware Thread-Topic: em driver problem on vmware Thread-Index: Act4DiiarsMAP3YqQ5iNBurl6b/5TwAPlrcgAOO2JUA= Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C6FC072@SJ-EXCH-1.adaranet.com> References: <32AB5C9615CC494997D9ABB1DB12783C024CA4A7BF@SJ-EXCH-1.adaranet.com> <32AB5C9615CC494997D9ABB1DB12783C024CA4A7DF@SJ-EXCH-1.adaranet.com> <32AB5C9615CC494997D9ABB1DB12783C024CA4A7E3@SJ-EXCH-1.adaranet.com> <32AB5C9615CC494997D9ABB1DB12783C024CA4A7EA@SJ-EXCH-1.adaranet.com> <32AB5C9615CC494997D9ABB1DB12783C024CA4A7F3@SJ-EXCH-1.adaranet.com> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024CA4A7F3@SJ-EXCH-1.adaranet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1288846383 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: FreeBSD Net Subject: RE: em driver problem on vmware X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 05:12:11 -0000 FYI, to close this thread off, I just had a build problem, I forgot to b= uild e1000/if_lem.c. Did that and now it works. So this becomes a success report of sorts... if anyone else is hand= cuffed (like me) to 8.0 but you want the 8.1 e1000 driver (for altq), it is= possible to port backwards. However, everyone is by far better served if you can just straight = away use 8.1. --- Ricky Charlet Adara Networks USA 408-433-4942 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Ricky Charlet > Sent: Saturday, October 30, 2010 9:10 AM > To: Jack Vogel; Juli Mallett > Cc: FreeBSD Net > Subject: RE: em driver problem on vmware > > Ah, Thanks for the direction. I'll take it as a self project from here. > And I'll update this thread with my results hopefully by mid next week. > > Ricky > > > From: Jack Vogel [mailto:jfvogel@gmail.com] > Sent: Saturday, October 30, 2010 1:41 AM > To: Juli Mallett > Cc: Ricky Charlet; FreeBSD Net > Subject: Re: em driver problem on vmware > > Uh, the emulated device in vmware is an OLD 82543 or something like > that right? > So, the e1000 driver in 8.1 is split into two parts, em and lem, its > lem that has > all the old pci support, so if you only pulled if_em then you dont > have that code. > > Sounds like maybe you should just install 8.1 on your guest and avoid > these > kinds of problems. > > Regards, > > Jack > > On Fri, Oct 29, 2010 at 11:26 PM, Juli Mallett > > wrote: > dmesg is not cleared at boot; your devices are not being detected, > they merely showed up in a previous boot. > > On Fri, Oct 29, 2010 at 23:13, Ricky Charlet > > wrote: > > Hi Julie, > > > > My entire dmesg output is attached. > > > > With much appreciation > > > > Ricky > > > > > > > >> -----Original Message----- > >> From: juli@clockworksquid.com > [mailto:juli@clockworksquid.com] On > >> Behalf Of Juli Mallett > >> Sent: Friday, October 29, 2010 8:01 PM > >> To: Ricky Charlet > >> Subject: Re: em driver problem on vmware > >> > >> Can you send me your full dmesg? You must be missing some relevant > >> message, because the only circumstances under which you'd see the > >> device attaching but then it wouldn't be present would also generate > >> some error messages. > >> > >> On Fri, Oct 29, 2010 at 19:22, Ricky Charlet > > > >> wrote: > >> > Thanks Jack, > >> > > >> > The failure is that ifconfig is unaware of em0. My > >> em0 is not configured, so link partners are also unaware of it. > >> > ifconfig em0 > >> > ifconfig: interface em0 does not exist > >> > > >> > and you already have my dmes stuff on em0 (which I am now up to > >> agreeing looks positive and would not indicate a problem) > >> > > >> > > >> > My amalgamated file is a private combination of some 8.1, some > 9.0, > >> some stuff a cohort did. We have been motivated to 'upgrade' from > >> e1000 in 8.0 to a newer/modified e1000 because of our desire to > >> incorporate the altq patches. > >> > > >> > For the curious and the diligent, the e1000/if_em.c > >> file I am using is attached. > >> > > >> > Ricky > >> > > >> > > >> > From: Jack Vogel > [mailto:jfvogel@gmail.com] > >> > Sent: Friday, October 29, 2010 7:13 PM > >> > To: Ricky Charlet > >> > Cc: freebsd-net@freebsd.org > >> > Subject: Re: em driver problem on vmware > >> > > >> > I remember seeing the same thing when running a FreeBSD guest on > >> > Linux/KVM, its informational, the code will enable said bits right > >> after > >> > it says that. > >> > > >> > So, the focus should be on the data, you are saying the delivered > >> > driver in 8.0 out of the box works and which driver exactly are > you > >> > trying to use, my last checked in? > >> > > >> > More on the failure, does it ping, does its link partner see > >> anything, > >> > etc, etc.. > >> > > >> > Jack > >> > > >> > On Fri, Oct 29, 2010 at 6:27 PM, Ricky Charlet > >> > aranet.com>> wrote: > >> > FYI, > >> > That dmesg output I get from my franken-driver on vmware is > exactly > >> the same output I get from the *working* bsd80Release on vmware: > >> > > >> > ------------cut-------------------- > >> > [root@npx7511 /usr/src/sys/dev/e1000]# dmesg | grep em0 > >> > em0: port 0x2000- > 0x203f > >> mem 0xd8940000-0xd895ffff,0xd8900000-0xd890ffff irq 18 at device 0.0 > on > >> pci2 > >> > em0: Memory Access and/or Bus Master bits were not set! > >> > em0: [FILTER] > >> > em0: Ethernet address: 00:0c:29:57:d7:7f > >> > -----------paste------------------- > >> > > >> > > >> > So I don't think the clue is hiding in dmesg. > >> > > >> > --- > >> > Ricky Charlet > >> > Adara Networks > >> > USA 408-433-4942 > >> > > >> > -----Original Message----- > >> > From: owner-freebsd-net@freebsd.org net@freebsd.org> > >> net@freebsd.org> [mailto:owner-freebsd- > net@freebsd.org > >> freebsd-net@freebsd.org>] On Behalf > Of Ricky Charlet > >> > Sent: Friday, October 29, 2010 5:07 PM > >> > To: freebsd-net@freebsd.org net@freebsd.org> net@freebsd.org>> > >> > Subject: em driver problem on vmware > >> > > >> > Howdy, > >> > I have freebsd80-release with an upgraded em0 driver from > >> freebsd8.1 (and an appropriate touch of if_var.h). I'm running an > amd64 > >> on a vmware vm. And I see this in dmesg: > >> > > >> > ------------cut------------- > >> > em0: port 0x2000- > 203f > >> mem 0xd8940000-0xd895ffff, 0xd8900000-0xd890ffff irq 18 at device > 0.0 > >> on pci2 > >> > em0: Memory Access and/or Bus Master bits were not set > >> > em0: [FILTER] > >> > em0: Ethernet address: 00:0c:29:57:d7:7f > >> > ------------paste------------ > >> > > >> > Now, I certainly may have done something wrong with my code > >> switch (just copied over the sys/dev/e1000 directory from 8.1 and > >> defined drbr_needs_enqueue in if_var.h). I'll start double checking. > >> > > >> > But, on the other hand, has anyone seen the new em driver > >> working/failing on a vmware vm? > >> > > >> > > >> > Thanks > >> > > >> > > >> > --- > >> > Ricky Charlet > >> > Adara Networks > >> > USA 408-433-4942 > >> > > >> > _______________________________________________ > >> > freebsd-net@freebsd.org net@freebsd.org> net@freebsd.org>> mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net- > >> > unsubscribe@freebsd.org net-unsubscribe@freebsd.org unsubscribe@freebsd.org>>" > >> > _______________________________________________ > >> > freebsd-net@freebsd.org net@freebsd.org> net@freebsd.org>> mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net- > >> > unsubscribe@freebsd.org net-unsubscribe@freebsd.org unsubscribe@freebsd.org>>" > >> > > >> > > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing > list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net- > >> unsubscribe@freebsd.org" > >> > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 4 07:42:31 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B8B1065670 for ; Thu, 4 Nov 2010 07:42:31 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 389C58FC12 for ; Thu, 4 Nov 2010 07:42:30 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 3E1F711B7F2; Thu, 4 Nov 2010 02:42:30 -0500 (CDT) Received: from 172.10.20.2 (84.8.54.77.rev.vodafone.pt [77.54.8.84]) by lavabit.com with ESMTP id TE446NO4XM0F; Thu, 04 Nov 2010 02:42:30 -0500 References: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> In-Reply-To: <8C96F018-EA61-4C38-AC9A-148D1DC06193@freebsd.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Thu, 4 Nov 2010 07:42:24 +0000 To: George Neville-Neil X-Mailer: Apple Mail (2.1081) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: RFC: Updated ARP Queue patch... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 07:42:31 -0000 Hi, On 1 Nov 2010, at 19:20, George Neville-Neil wrote: > Howdy, >=20 > This is marked as "Updated" because I first proposed this on arch@ but = am now sending it to > a wider audience as I'm hoping to commit it in the near future. >=20 > Please review the following patch against HEAD: >=20 > http://people.freebsd.org/~gnn/head-arpqueue2.diff >=20 > This patch makes two changes to the ARP code: >=20 > 1) It adds a sysctl configurable queue of packets that are held until = an ARP reply is received or > timed out. >=20 > net.link.ether.inet.maxhold >=20 > Having the queue addresses a problem in modern systems where programs = that use connectionless=20 > protocols for communication will suffer from dropping many packets = when they start up or when > an ARP entry moves. >=20 > 2) Makes the time we wait for an arp reply configurable via another = sysctl. >=20 > net.link.ether.inet.wait >=20 > The old, pre 8.0, ARP code would run the timer once per second. The = new > ARP code sets a timeout of 20 seconds on each entry. Neither value = was specified > in RFC 826. As a matter of fact, RFC 826 had this to say about = timeouts: >=20 > "It may be desirable to have table aging and/or timeouts. The > implementation of these is outside the scope of this protocol." >=20 > This new code does not change the default value of either the arpqueue = (which was > always 1 packet) nor does it change the new value of the ARP down = timeout. >=20 > I have a different patch for 7, which I will propose after I can get = this in to > HEAD and MFC'd to 8. This looks good to me. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Nov 4 21:36:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0601D1065674 for ; Thu, 4 Nov 2010 21:36:39 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by mx1.freebsd.org (Postfix) with ESMTP id B949C8FC16 for ; Thu, 4 Nov 2010 21:36:38 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D85942D08F2; Thu, 4 Nov 2010 17:20:15 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp43.relay.iad1a.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 425F62D09F2; Thu, 4 Nov 2010 17:20:12 -0400 (EDT) Message-ID: <4CD3238D.7080103@xiplink.com> Date: Thu, 04 Nov 2010 17:20:13 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: yongari@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: if_msk.c patch for yukon ec hanging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:36:39 -0000 Hello, I'd like to summit a patch that fixes a hanging issue related to Rx FIFO overrun on the following chips and rev (tested): ID: CHIP_ID_YUKON_EC REV: CHIP_REV_YU_EC_A2 CHIP_REV_YU_EC_A3 (I haven't tested it on CHIP_REV_YU_EC_A1) @@ -3813,16 +3805,24 @@ GMR_FS_ANY_ERR); } - /* - * Set Rx FIFO flush threshold to 64 bytes + 1 FIFO word - * due to hardware hang on receipt of pause frames. - */ - reg = RX_GMF_FL_THR_DEF + 1; - /* Another magic for Yukon FE+ - From Linux. */ - if (sc->msk_hw_id == CHIP_ID_YUKON_FE_P && - sc->msk_hw_rev == CHIP_REV_YU_FE_P_A0) - reg = 0x178; - CSR_WRITE_2(sc, MR_ADDR(sc_if->msk_port, RX_GMF_FL_THR), reg); + if (sc->msk_hw_id == CHIP_ID_YUKON_EC){ + /* Set Rx FIFO flush threshold to 64 bytes. */ + CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_FL_THR), + RX_GMF_FL_THR_DEF); + } + else { + /* + * Set Rx FIFO flush threshold to 64 bytes + 1 FIFO word + * due to hardware hang on receipt of pause frames. + */ + reg = RX_GMF_FL_THR_DEF + 1; + /* Another magic for Yukon FE+ - From Linux. */ + if (sc->msk_hw_id == CHIP_ID_YUKON_FE_P && + sc->msk_hw_rev == CHIP_REV_YU_FE_P_A0) + reg = 0x178; + CSR_WRITE_2(sc, MR_ADDR(sc_if->msk_port, RX_GMF_FL_THR), reg); + } /* Configure Tx MAC FIFO. */ CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, TX_GMF_CTRL_T), GMF_RST_SET); The symptoms of the problem was that if a large amount of small TCP packets were fired up at the interface it would generate an interrupt from MAC1 with a GMAC status of 0x7 and while the chip Tx would still function the Rx would 'hang'. Triggering a watchdog timeout would make it work again sometimes but calling mskc_reset() didn't worked at all. It turned out that we had an old driver written by Pyun YongHyeon that would work flawlessly on that chip. This patch helps support that old chip. I hope this helps someone, Karim. PS: The patch line numbers are against 'CURRENT' r214406 but should also apply to FBSD 7 and 8. From owner-freebsd-net@FreeBSD.ORG Thu Nov 4 23:29:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622EA1065673 for ; Thu, 4 Nov 2010 23:29:20 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2248FC18 for ; Thu, 4 Nov 2010 23:29:19 +0000 (UTC) Received: (qmail 21052 invoked from network); 4 Nov 2010 23:02:38 -0000 Received: from 71-95-204-2.static.mtpk.ca.charter.com (HELO ask-dev.bur.sol) (ask@mail.dev@71.95.204.2) by smtp.develooper.com with ESMTPA; 4 Nov 2010 23:02:38 -0000 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Nov 2010 16:02:37 -0700 Message-Id: <17903237-CBF6-4CC3-8CA3-29D9BB65538F@develooper.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 23:29:20 -0000 Hi, On a network segment we have both Linux boxes with keepalived (some sort = of vrrp implementation) and FreeBSD boxes with carp enabled. The FreeBSD logs have a gazillion "kernel: carp_input: received len 20 < = sizeof(struct carp_header)" messages. The carp man page makes it seem like we can disable any carp logging = with net.inet.carp.log=3D0; but that doesn't seem to make a difference. The system is running 7.2-RELEASE-p5 (the distribution is pfSense = 1.2.x). Is there another toggle I can use to get rid of the (to us) useless log = messages? I checked that we don't have any overlapping vhid/vrid IDs. Any idea = for how to either just suppress the log message from the kernel or = getting it to log some more details so we can try to make the underlying = problem go away? Thanks! - ask= From owner-freebsd-net@FreeBSD.ORG Fri Nov 5 02:45:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FAA6106564A for ; Fri, 5 Nov 2010 02:45:32 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id D2A958FC08 for ; Fri, 5 Nov 2010 02:45:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id B1923DCB3B; Fri, 5 Nov 2010 02:28:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr+0ivuiC0uj; Fri, 5 Nov 2010 02:28:33 +0000 (GMT) Received: from Tom-Judges-MacBook-Pro.local (unknown [192.168.204.117]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id D333148C40; Fri, 5 Nov 2010 02:28:32 +0000 (GMT) Message-ID: <4CD36BD0.4040409@tomjudge.com> Date: Thu, 04 Nov 2010 21:28:32 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org, ask@develooper.com References: <17903237-CBF6-4CC3-8CA3-29D9BB65538F@develooper.com> In-Reply-To: <17903237-CBF6-4CC3-8CA3-29D9BB65538F@develooper.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 02:45:32 -0000 On 04/11/2010 18:02, Ask Bjørn Hansen wrote: > Hi, > > On a network segment we have both Linux boxes with keepalived (some sort of vrrp implementation) and FreeBSD boxes with carp enabled. > > The FreeBSD logs have a gazillion "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages. > > The carp man page makes it seem like we can disable any carp logging with net.inet.carp.log=0; but that doesn't seem to make a difference. > > The system is running 7.2-RELEASE-p5 (the distribution is pfSense 1.2.x). > > Is there another toggle I can use to get rid of the (to us) useless log messages? > > I checked that we don't have any overlapping vhid/vrid IDs. Any idea for how to either just suppress the log message from the kernel or getting it to log some more details so we can try to make the underlying problem go away? > Take a look at the following page: http://www.tomjudge.com/index.php/FreeBSD/CARP_vs_VRRP It contains a patch to change the CARP protocol ID to something that is not used so these messages go away. Tom From owner-freebsd-net@FreeBSD.ORG Fri Nov 5 10:10:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BCA106566C for ; Fri, 5 Nov 2010 10:10:52 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 916218FC1D for ; Fri, 5 Nov 2010 10:10:51 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id 8194B16663D1 for ; Fri, 5 Nov 2010 11:10:48 +0100 (CET) Date: Fri, 5 Nov 2010 11:10:37 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2787499574-17269222-1288951846=:9984" Subject: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 10:10:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2787499574-17269222-1288951846=:9984 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi, some time ago we migrated a lot of boxes from Linux to FreeBSD. Those machines have a "NVIDIA nForce4 CK804 MCP4" network adapter, supported by nfe(4). Even if nfe(4) at least tries to enable the WOL capability of the NIC it doesn't work and nfe(4) doesn't integrate with FreeBSDs (new) WOL framework. Since we are in need of WOL I spend some minutes to implement it the correct way. Attached are two patches: - if_nfe_wol_8.1.diff against FreeBSD 8.1-RELEASE-p1, this one is used on our servers. - if_nfe_wol_current.diff against -CURRENT r214831. This one is _untested_! But it should work... In case that the patches a stripped by mailman they can be found here: http://deponie.yamagi.org/freebsd/nfe/ This patch works reliable on our machines and nfe(4) runs without any problems with it. But nevertheless my skills in writting network drivers are somewhat limited therefor a review by somewhat with better knowledge of the WOL framework and maybe nfe(4) itself is highly anticipated. Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --2787499574-17269222-1288951846=:9984 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=if_nfe_wol_current.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=if_nfe_wol_current.diff LS0tIGlmX25mZS5jCTIwMTAtMTEtMDUgMTA6NDE6MDQuNjcyMzUxODc5ICsw MTAwDQorKysgaWZfbmZlLmMJMjAxMC0xMS0wNSAxMDo0MTowOS4yNTk2ODk1 ODQgKzAxMDANCkBAIC0xMjUsNiArMTI1LDcgQEANCiBzdGF0aWMgdm9pZCBu ZmVfc3lzY3RsX25vZGUoc3RydWN0IG5mZV9zb2Z0YyAqKTsNCiBzdGF0aWMg dm9pZCBuZmVfc3RhdHNfY2xlYXIoc3RydWN0IG5mZV9zb2Z0YyAqKTsNCiBz dGF0aWMgdm9pZCBuZmVfc3RhdHNfdXBkYXRlKHN0cnVjdCBuZmVfc29mdGMg Kik7DQorc3RhdGljIHZvaWQgbmZlX2VuYWJsZV93b2woc3RydWN0IG5mZV9z b2Z0YyAqKTsNCiANCiAjaWZkZWYgTkZFX0RFQlVHDQogc3RhdGljIGludCBu ZmVkZWJ1ZyA9IDA7DQpAQCAtNTk5LDYgKzYwMCwxMCBAQA0KIAlpZnAtPmlm X2NhcGFiaWxpdGllcyB8PSBJRkNBUF9QT0xMSU5HOw0KICNlbmRpZg0KIA0K KwkvKiBXYWtlIG9uIExBTiBzdXBwb3J0ICovDQorCWlmcC0+aWZfY2FwYWJp bGl0aWVzIHw9IElGQ0FQX1dPTF9NQUdJQzsNCisJaWZwLT5pZl9jYXBlbmFi bGUgPSBpZnAtPmlmX2NhcGFiaWxpdGllczsNCisNCiAJLyogRG8gTUlJIHNl dHVwICovDQogCWVycm9yID0gbWlpX2F0dGFjaChkZXYsICZzYy0+bmZlX21p aWJ1cywgaWZwLCBuZmVfaWZtZWRpYV91cGQsDQogCSAgICBuZmVfaWZtZWRp YV9zdHMsIEJNU1JfREVGQ0FQTUFTSywgTUlJX1BIWV9BTlksIE1JSV9PRkZT RVRfQU5ZLCAwKTsNCkBAIC03NjksNiArNzc0LDEwIEBADQogDQogCU5GRV9M T0NLKHNjKTsNCiAJaWZwID0gc2MtPm5mZV9pZnA7DQorDQorCS8qIERpc2Fi bGUgV09MIGJpdHMgKi8NCisJTkZFX1dSSVRFKHNjLCBORkVfV09MX0NUTCwg MCk7DQorDQogCWlmIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKQ0KIAkJbmZl X2luaXRfbG9ja2VkKHNjKTsNCiAJc2MtPm5mZV9zdXNwZW5kZWQgPSAwOw0K QEAgLTE3NTIsNiArMTc2MSwxMiBAQA0KIAkJCQlpZnAtPmlmX2h3YXNzaXN0 ICY9IH5DU1VNX1RTTzsNCiAJCX0NCiANCisJCWlmICgobWFzayAmIElGQ0FQ X1dPTCkgIT0gMCAmJg0KKwkJCShpZnAtPmlmX2NhcGFiaWxpdGllcyAmIElG Q0FQX1dPTCkgIT0gMCkgew0KKwkJCQlpZiAoKG1hc2sgJiBJRkNBUF9XT0xf TUFHSUMpICE9IDApDQorCQkJCQlpZnAtPmlmX2NhcGVuYWJsZSBePSBJRkNB UF9XT0xfTUFHSUM7DQorCQl9DQorDQogCQlpZiAoaW5pdCA+IDAgJiYgKGlm cC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAhPSAwKSB7DQog CQkJaWZwLT5pZl9kcnZfZmxhZ3MgJj0gfklGRl9EUlZfUlVOTklORzsNCiAJ CQluZmVfaW5pdChzYyk7DQpAQCAtMjc0Niw3ICsyNzYxLDYgQEANCiAJTkZF X1dSSVRFKHNjLCBORkVfU1RBVFVTLCBzYy0+bWlpX3BoeWFkZHIgPDwgMjQg fCBORkVfU1RBVFVTX01BR0lDKTsNCiANCiAJTkZFX1dSSVRFKHNjLCBORkVf U0VUVVBfUjQsIE5GRV9SNF9NQUdJQyk7DQotCU5GRV9XUklURShzYywgTkZF X1dPTF9DVEwsIE5GRV9XT0xfTUFHSUMpOw0KIA0KIAlzYy0+cnh0eGN0bCAm PSB+TkZFX1JYVFhfQklUMjsNCiAJTkZFX1dSSVRFKHNjLCBORkVfUlhUWF9D VEwsIHNjLT5yeHR4Y3RsKTsNCkBAIC0yODA2LDEyICsyODIwLDYgQEANCiAJ LyogYWJvcnQgVHggKi8NCiAJTkZFX1dSSVRFKHNjLCBORkVfVFhfQ1RMLCAw KTsNCiANCi0JLyogZGlzYWJsZSBSeCAqLw0KLQlORkVfV1JJVEUoc2MsIE5G RV9SWF9DVEwsIDApOw0KLQ0KLQkvKiBkaXNhYmxlIGludGVycnVwdHMgKi8N Ci0JbmZlX2Rpc2FibGVfaW50cihzYyk7DQotDQogCXNjLT5uZmVfbGluayA9 IDA7DQogDQogCS8qIGZyZWUgUnggYW5kIFR4IG1idWZzIHN0aWxsIGluIHRo ZSBxdWV1ZXMuICovDQpAQCAtMjkyMyw5ICsyOTMxLDEyIEBADQogCXNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOw0KIA0KIAlORkVfTE9DSyhzYyk7DQor CW5mZV9lbmFibGVfd29sKHNjKTsNCisJTkZFX1VOTE9DSyhzYyk7DQorDQor CU5GRV9MT0NLKHNjKTsNCiAJaWZwID0gc2MtPm5mZV9pZnA7DQogCW5mZV9z dG9wKGlmcCk7DQotCS8qIG5mZV9yZXNldChzYyk7ICovDQogCU5GRV9VTkxP Q0soc2MpOw0KIA0KIAlyZXR1cm4gKDApOw0KQEAgLTMyMTIsMyArMzIyMywx NyBAQA0KIAkJc3RhdHMtPnJ4X2Jyb2FkY2FzdCArPSBORkVfUkVBRChzYywg TkZFX1RYX0JST0FEQ0FTVCk7DQogCX0NCiB9DQorDQorc3RhdGljIHZvaWQN CituZmVfZW5hYmxlX3dvbChzdHJ1Y3QgbmZlX3NvZnRjICpzYykNCit7DQor CXN0cnVjdCBpZm5ldCAqaWZwOw0KKw0KKwlORkVfTE9DS19BU1NFUlQoc2Mp Ow0KKw0KKwlpZnAgPSBzYy0+bmZlX2lmcDsNCisNCisJaWYgKChpZnAtPmlm X2NhcGVuYWJsZSAmIElGQ0FQX1dPTF9NQUdJQykgIT0gMCkNCisJCU5GRV9X UklURShzYywgTkZFX1dPTF9DVEwsIE5GRV9XT0xfTUFHSUMpOw0KK30NCisN Cg== --2787499574-17269222-1288951846=:9984 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=if_nfe_wol_8.1.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=if_nfe_wol_8.1.diff LS0tIGlmX25mZS5jCTIwMTAtMTEtMDUgMTA6MzY6NDMuMzAwNzM4MTYxICsw MTAwDQorKysgaWZfbmZlLmMJMjAxMC0xMS0wNSAxMDozOTowNC43MTI2MDM5 MTYgKzAxMDANCkBAIC0xMjUsNiArMTI1LDcgQEANCiBzdGF0aWMgdm9pZCBu ZmVfc3lzY3RsX25vZGUoc3RydWN0IG5mZV9zb2Z0YyAqKTsNCiBzdGF0aWMg dm9pZCBuZmVfc3RhdHNfY2xlYXIoc3RydWN0IG5mZV9zb2Z0YyAqKTsNCiBz dGF0aWMgdm9pZCBuZmVfc3RhdHNfdXBkYXRlKHN0cnVjdCBuZmVfc29mdGMg Kik7DQorc3RhdGljIHZvaWQgbmZlX2VuYWJsZV93b2woc3RydWN0IG5mZV9z b2Z0YyAqKTsNCiANCiAjaWZkZWYgTkZFX0RFQlVHDQogc3RhdGljIGludCBu ZmVkZWJ1ZyA9IDA7DQpAQCAtNjAwLDYgKzYwMSwxMCBAQA0KIAlpZnAtPmlm X2NhcGFiaWxpdGllcyB8PSBJRkNBUF9QT0xMSU5HOw0KICNlbmRpZg0KIA0K KwkvKiBXYWtlIG9uIExBTiBzdXBwb3J0ICovDQorCWlmcC0+aWZfY2FwYWJp bGl0aWVzIHw9IElGQ0FQX1dPTF9NQUdJQzsNCisJaWZwLT5pZl9jYXBlbmFi bGUgPSBpZnAtPmlmX2NhcGFiaWxpdGllczsNCisNCiAJLyogRG8gTUlJIHNl dHVwICovDQogCWlmIChtaWlfcGh5X3Byb2JlKGRldiwgJnNjLT5uZmVfbWlp YnVzLCBuZmVfaWZtZWRpYV91cGQsDQogCSAgICBuZmVfaWZtZWRpYV9zdHMp KSB7DQpAQCAtNzcwLDYgKzc3NSwxMCBAQA0KIA0KIAlORkVfTE9DSyhzYyk7 DQogCWlmcCA9IHNjLT5uZmVfaWZwOw0KKw0KKwkvKiBEaXNhYmxlIFdPTCBi aXRzICovDQorCU5GRV9XUklURShzYywgTkZFX1dPTF9DVEwsIDApOw0KKw0K IAlpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkNCiAJCW5mZV9pbml0X2xv Y2tlZChzYyk7DQogCXNjLT5uZmVfc3VzcGVuZGVkID0gMDsNCkBAIC0xNzUz LDYgKzE3NjIsMTIgQEANCiAJCQkJaWZwLT5pZl9od2Fzc2lzdCAmPSB+Q1NV TV9UU087DQogCQl9DQogDQorCQlpZiAoKG1hc2sgJiBJRkNBUF9XT0wpICE9 IDAgJiYNCisJCQkoaWZwLT5pZl9jYXBhYmlsaXRpZXMgJiBJRkNBUF9XT0wp ICE9IDApIHsNCisJCQkJaWYgKChtYXNrICYgSUZDQVBfV09MX01BR0lDKSAh PSAwKQ0KKwkJCQkJaWZwLT5pZl9jYXBlbmFibGUgXj0gSUZDQVBfV09MX01B R0lDOw0KKwkJfQ0KKw0KIAkJaWYgKGluaXQgPiAwICYmIChpZnAtPmlmX2Ry dl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgIT0gMCkgew0KIAkJCWlmcC0+ aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX1JVTk5JTkc7DQogCQkJbmZlX2lu aXQoc2MpOw0KQEAgLTI3NDcsNyArMjc2Miw2IEBADQogCU5GRV9XUklURShz YywgTkZFX1NUQVRVUywgc2MtPm1paV9waHlhZGRyIDw8IDI0IHwgTkZFX1NU QVRVU19NQUdJQyk7DQogDQogCU5GRV9XUklURShzYywgTkZFX1NFVFVQX1I0 LCBORkVfUjRfTUFHSUMpOw0KLQlORkVfV1JJVEUoc2MsIE5GRV9XT0xfQ1RM LCBORkVfV09MX01BR0lDKTsNCiANCiAJc2MtPnJ4dHhjdGwgJj0gfk5GRV9S WFRYX0JJVDI7DQogCU5GRV9XUklURShzYywgTkZFX1JYVFhfQ1RMLCBzYy0+ cnh0eGN0bCk7DQpAQCAtMjgwNywxMiArMjgyMSw2IEBADQogCS8qIGFib3J0 IFR4ICovDQogCU5GRV9XUklURShzYywgTkZFX1RYX0NUTCwgMCk7DQogDQot CS8qIGRpc2FibGUgUnggKi8NCi0JTkZFX1dSSVRFKHNjLCBORkVfUlhfQ1RM LCAwKTsNCi0NCi0JLyogZGlzYWJsZSBpbnRlcnJ1cHRzICovDQotCW5mZV9k aXNhYmxlX2ludHIoc2MpOw0KLQ0KIAlzYy0+bmZlX2xpbmsgPSAwOw0KIA0K IAkvKiBmcmVlIFJ4IGFuZCBUeCBtYnVmcyBzdGlsbCBpbiB0aGUgcXVldWVz LiAqLw0KQEAgLTI5MjQsOSArMjkzMiwxMiBAQA0KIAlzYyA9IGRldmljZV9n ZXRfc29mdGMoZGV2KTsNCiANCiAJTkZFX0xPQ0soc2MpOw0KKwluZmVfZW5h YmxlX3dvbChzYyk7DQorCU5GRV9VTkxPQ0soc2MpOw0KKw0KKwlORkVfTE9D SyhzYyk7DQogCWlmcCA9IHNjLT5uZmVfaWZwOw0KIAluZmVfc3RvcChpZnAp Ow0KLQkvKiBuZmVfcmVzZXQoc2MpOyAqLw0KIAlORkVfVU5MT0NLKHNjKTsN CiANCiAJcmV0dXJuICgwKTsNCkBAIC0zMjEzLDMgKzMyMjQsMTcgQEANCiAJ CXN0YXRzLT5yeF9icm9hZGNhc3QgKz0gTkZFX1JFQUQoc2MsIE5GRV9UWF9C Uk9BRENBU1QpOw0KIAl9DQogfQ0KKw0KK3N0YXRpYyB2b2lkDQorbmZlX2Vu YWJsZV93b2woc3RydWN0IG5mZV9zb2Z0YyAqc2MpDQorew0KKwlzdHJ1Y3Qg aWZuZXQgKmlmcDsNCisNCisJTkZFX0xPQ0tfQVNTRVJUKHNjKTsNCisNCisJ aWZwID0gc2MtPm5mZV9pZnA7DQorDQorCWlmICgoaWZwLT5pZl9jYXBlbmFi bGUgJiBJRkNBUF9XT0xfTUFHSUMpICE9IDApDQorCQlORkVfV1JJVEUoc2Ms IE5GRV9XT0xfQ1RMLCBORkVfV09MX01BR0lDKTsNCit9DQorDQo= --2787499574-17269222-1288951846=:9984-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 5 22:47:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA11106564A for ; Fri, 5 Nov 2010 22:47:15 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 958658FC08 for ; Fri, 5 Nov 2010 22:47:15 +0000 (UTC) Received: (qmail 17744 invoked from network); 5 Nov 2010 22:47:15 -0000 Received: from 71-95-204-2.static.mtpk.ca.charter.com (HELO ask-dev.bur.sol) (ask@mail.dev@71.95.204.2) by smtp.develooper.com with ESMTPA; 5 Nov 2010 22:47:15 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: <4CD36BD0.4040409@tomjudge.com> Date: Fri, 5 Nov 2010 15:47:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77F1671C-33AE-4AAB-8442-7653B00F7E04@develooper.com> References: <17903237-CBF6-4CC3-8CA3-29D9BB65538F@develooper.com> <4CD36BD0.4040409@tomjudge.com> To: Tom Judge X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 22:47:15 -0000 On Nov 4, 2010, at 19:28, Tom Judge wrote: >> I checked that we don't have any overlapping vhid/vrid IDs. Any idea = for how to either just suppress the log message from the kernel or = getting it to log some more details so we can try to make the underlying = problem go away? >>=20 >=20 > Take a look at the following page: >=20 > http://www.tomjudge.com/index.php/FreeBSD/CARP_vs_VRRP >=20 > It contains a patch to change the CARP protocol ID to something that = is > not used so these messages go away. Hi Tom, Thank you for the reply. I was hoping we wouldn't have to rebuild the = kernel (doh) since we use a basically abandoned version of pfSense (the = pfSense team are for all their efforts and good work seemingly unable to = get a new release out the door). I agree that it was pretty dumb of the OpenBSD developers to just stomp = on another protocol ID for their (and ours in FreeBSD ...) = implementation. - ask --=20 http://develooper.com/ - http://askask.com/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 6 22:09:43 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9EC9106564A for ; Sat, 6 Nov 2010 22:09:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6668FC16 for ; Sat, 6 Nov 2010 22:09:43 +0000 (UTC) Received: by gwj16 with SMTP id 16so2899885gwj.13 for ; Sat, 06 Nov 2010 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=2ASao07MEb8EjlUzszto3e/whZ+38pZ5Vk9oDgJI55U=; b=mZndzWjbmaWtiq9y6uCZglhUVsnX5lSQaU+hJCcgDFuNsRtmvnLNKAqrOJIq/RUoGg n12Avp+7FTidp7rj/G0XH3air9zY6wooiNEHRFbLo6OXRA2Q77kN54TyfnYZLTsH08RP g4nBqjjEByg0yb3KPcc4sHpZmOL4vN3RE/Ako= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=wuMFrMz/B7VdX0bZni/b8tEaV+6bZMcute6X5sm3kDd8XMOHmGjLuFaMOCDWvTd7Cz dQMYn1yify0C22uQdzA4IEhliH4haQ6hrbYcQul7wDcNzU5pYiCNZLHrVSXzuDdSwexV Y7f4+reabeun7ODDWbCuHT3TP1zUDcXrljjJo= Received: by 10.100.208.12 with SMTP id f12mr1111879ang.38.1289081382471; Sat, 06 Nov 2010 15:09:42 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id g18sm3535359anh.38.2010.11.06.15.09.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 15:09:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 6 Nov 2010 15:09:36 -0700 From: Pyun YongHyeon Date: Sat, 6 Nov 2010 15:09:36 -0700 To: "Mikhail T." Message-ID: <20101106220936.GE22715@michelle.cdnetworks.com> References: <4CC1FD8D.7000108@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC1FD8D.7000108@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Strange problem with sk0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 22:09:43 -0000 On Fri, Oct 22, 2010 at 05:09:33PM -0400, Mikhail T. wrote: > Hello! > > I have a rather bizarre problem with my on-board sk interface... It only > works, when tcpdump is running... > > Seriously. It negotiates with the switch (1000baseT/full-duplex) just > fine, but, unless tcpdump has it open (and in "promiscuous" mode), no > traffic seems to go through. It would not respond to pings -- not even > from the switch itself, nothing. > > But, as soon as I start tcpdump -- even if tcpdump never has anything to > output: > > tcpdump -i sk0 -n src host 10.non.existent.IP > > Traffic starts flowing just fine... Do I simply have flaky hardware? The > motherboard is old, and, for some reason, I need to "remind" sk0, what > its ethernet address upon reboote (it starts off with 00:00:00:00:00:00). > > Any other explanations for what is happening? There are plenty of other > systems (computers, VoIP phone, two TVs) on this switch and all are > fine... I did try different ports on it -- same results. I also tried > forcing things down to 100/half-duplex -- no change... > > Thanks! Yours, > FYI: Fix committed to HEAD(r214898, r214899). Will MFC after 1 week.