From owner-freebsd-net@FreeBSD.ORG Sun May 8 13:09:40 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 C4683106566B;
Sun, 8 May 2011 13:09:40 +0000 (UTC)
(envelope-from melifaro@ipfw.ru)
Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru
[IPv6:2a02:978:2:1000::3])
by mx1.freebsd.org (Postfix) with ESMTP id A294E8FC0A;
Sun, 8 May 2011 13:09:38 +0000 (UTC)
Received: from ws.su29.net (v6.mpls.in [IPv6:2a02:978:2::5])
by no.spam.no.ddos.ru (Postfix) with ESMTPA id 66AFF35AE93;
Sun, 8 May 2011 17:08:48 +0400 (MSD)
Message-ID: <4DC695FC.3080700@ipfw.ru>
Date: Sun, 08 May 2011 17:09:16 +0400
From: "Alexander V. Chernikov" <melifaro@ipfw.ru>
User-Agent: Thunderbird 2.0.0.24 (X11/20100515)
MIME-Version: 1.0
To: freebsd-net@freebsd.org, freebsd-current@freebsd.org
X-Enigmail-Version: 0.96.0
Content-Type: multipart/mixed; boundary="------------000003040104050700090603"
Cc:
Subject: [patch] permit fib to be set on interface
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 08 May 2011 13:09:41 -0000
This is a multi-part message in MIME format.
--------------000003040104050700090603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the moment the only possible way to set packet fib from userland is
ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows
with every fib.
Additionally, there is no way to set packet fib before netgraph
processing: L2 ipfw hook is called after ng_ether_input()
Those reasons (not mentioning kern/134931) makes it hard to use multiple
routing tables.
The following path:
* adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib
* adds IFF_CUSTOMFIB interface flags
* adds ifi_fib field to if_data structure
* adds 'fib' keyword for ifconfig(8)
Example:
16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15
vlan 2 vlandev em0
16:42 [0] zfscurr0# ifconfig vlan2
vlan2: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,CUSTOMFIB>
metric 0 mtu 1500 fib 15
options=3<RXCSUM,TXCSUM>
ether 08:00:27:c5:29:d4
inet 10.11.12.13 netmask 0xfffffffc broadcast 10.11.12.15
inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 2 parent interface: em0
Interface fib is applied on inbound only (for forwarded packets fib
decision should be done on inbound, for locally-originated packets there
is setfib(1))
How to install:
** WARNING - world (libc actually) rebuild required !! **
Apply both patches (abi first)
rebuild kernel (ROUTETABLES define required) && world
reboot (you should have console access)
use ifconfig(8) to set fib
Comments on source code:
Since we need fib to be set before ng_ether_input() we cannot set fib on
per-netisr basis which is easier.
Patch is split into 2 pieces.
struct if_data is exported to userland via:
* rtsock sysctl_iflist() sysctl (used by libc getifaddr(3) only)
* ifmib(4) interfaces (used by bsnmpd and others)
abi_ifdata patch permits if_data changes (actually, tail-adding) without
ABI breaking (and it doesn't break ABI by itself)
fibs patch does the rest described.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3GlfwACgkQwcJ4iSZ1q2ncmQCfYT01sjTLcuxZsYyJA/hH7lFb
sjIAn3r5aXIhtMK5zxyBWOLm+vKYehfY
=PvjZ
-----END PGP SIGNATURE-----
--------------000003040104050700090603
Content-Type: text/plain;
name="fibs_20110508-9.0-CURRENT-r221313M.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="fibs_20110508-9.0-CURRENT-r221313M.diff"
Index: sbin/ifconfig/ifconfig.8
===================================================================
--- sbin/ifconfig/ifconfig.8 (revision 221313)
+++ sbin/ifconfig/ifconfig.8 (working copy)
@@ -294,6 +294,17 @@
Fill interface index
(lowermost 64bit of an IPv6 address)
automatically.
+.It Cm fib Ar fib_number
+Specify interface fib. Fib
+.Ar fib_number
+is assigned to all frames received on that interface. Fib is not inherited,
+e.g. vlans or other sub-interfaces gets default fib (0) irrespective of parent
+interface fib.
+.Ar CUSTOMFIB
+flag is added to interface flags if non-zero fib is set. Kernel needs to be compiled
+with the option
+.Cd "options ROUTETABLES"
+for this to work.
.It Cm ipdst
This is used to specify an Internet host who is willing to receive
IP packets encapsulating IPX packets bound for a remote network.
Index: sbin/ifconfig/ifconfig.c
===================================================================
--- sbin/ifconfig/ifconfig.c (revision 221313)
+++ sbin/ifconfig/ifconfig.c (working copy)
@@ -823,6 +823,16 @@
}
static void
+setifib(const char *val, int dummy __unused, int s,
+ const struct afswtch *afp)
+{
+ strncpy(ifr.ifr_name, name, sizeof (ifr.ifr_name));
+ ifr.ifr_fib = atoi(val);
+ if (ioctl(s, SIOCSIFIB, (caddr_t)&ifr) < 0)
+ warn("ioctl (set fib)");
+}
+
+static void
setifname(const char *val, int dummy __unused, int s,
const struct afswtch *afp)
{
@@ -880,7 +890,7 @@
#define IFFBITS \
"\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \
"\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \
-"\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP"
+"\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP\30CUSTOMFIB"
#define IFCAPBITS \
"\020\1RXCSUM\2TXCSUM\3NETCONS\4VLAN_MTU\5VLAN_HWTAGGING\6JUMBO_MTU\7POLLING" \
@@ -919,6 +929,8 @@
printf(" metric %d", ifr.ifr_metric);
if (ioctl(s, SIOCGIFMTU, &ifr) != -1)
printf(" mtu %d", ifr.ifr_mtu);
+ if (((ifa->ifa_flags & IFF_CUSTOMFIB) > 0) && (ioctl(s, SIOCGIFIB, &ifr) != -1))
+ printf(" fib %d", ifr.ifr_fib);
putchar('\n');
for (;;) {
@@ -1169,6 +1181,7 @@
DEF_CMD("compress", IFF_LINK0, setifflags),
DEF_CMD("noicmp", IFF_LINK1, setifflags),
DEF_CMD_ARG("mtu", setifmtu),
+ DEF_CMD_ARG("fib", setifib),
DEF_CMD_ARG("name", setifname),
};
Index: share/man/man9/ifnet.9
===================================================================
--- share/man/man9/ifnet.9 (revision 221313)
+++ share/man/man9/ifnet.9 (working copy)
@@ -522,6 +522,10 @@
See
.Sx Interface Capabilities Flags
for details.
+.It Dv IFF_CUSTOMFIB
+.Aq D
+This interface has custom (non-zero) FIB set.
+Every packet received on that interface inherits interface fib.
.El
.Ss "Interface Capabilities Flags"
Interface capabilities are specialized features an interface may
@@ -1172,8 +1176,9 @@
.It Dv SIOCGIFFLAGS
.It Dv SIOCGIFMETRIC
.It Dv SIOCGIFMTU
+.It Dv SIOCGIFIB
.It Dv SIOCGIFPHYS
-Get interface capabilities, flags, metric, MTU, medium selection.
+Get interface capabilities, flags, metric, MTU, fib, medium selection.
(No call-down to driver.)
.Pp
.It Dv SIOCSIFCAP
@@ -1228,6 +1233,16 @@
additional sanity checking and for actually modifying the MTU in the
interface structure.
.Pp
+.It Dv SIOCSIFIB
+Sets interface FIB.
+Caller must have appropriate privilege.
+FIB
+values greater than
+.Va net.fibs
+are considered invalid.
+.Dv IFF_CUSTOMFIB
+flag is set if new fib is not set to 0.
+.Pp
.It Dv SIOCADDMULTI
.It Dv SIOCDELMULTI
Add or delete permanent multicast group memberships on the interface.
Index: sys/kern/kern_jail.c
===================================================================
--- sys/kern/kern_jail.c (revision 221313)
+++ sys/kern/kern_jail.c (working copy)
@@ -3630,6 +3630,7 @@
case PRIV_NET_LAGG:
case PRIV_NET_GIF:
case PRIV_NET_SETIFVNET:
+ case PRIV_NET_SETIFIB:
/*
* 802.11-related privileges.
Index: sys/netgraph/ng_iface.c
===================================================================
--- sys/netgraph/ng_iface.c (revision 221313)
+++ sys/netgraph/ng_iface.c (working copy)
@@ -56,6 +56,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -777,6 +778,10 @@
/* First chunk of an mbuf contains good junk */
if (harvest.point_to_point)
random_harvest(m, 16, 3, 0, RANDOM_NET);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
return (0);
}
Index: sys/dev/ppbus/if_plip.c
===================================================================
--- sys/dev/ppbus/if_plip.c (revision 221313)
+++ sys/dev/ppbus/if_plip.c (working copy)
@@ -81,6 +81,7 @@
*/
#include "opt_plip.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -585,6 +586,10 @@
if (bpf_peers_present(sc->sc_ifp->if_bpf))
lptap(sc->sc_ifp, top);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(top, sc->sc_ifp->if_fib);
+#endif
/* mbuf is free'd on failure. */
netisr_queue(NETISR_IP, top);
ppb_lock(ppbus);
@@ -637,6 +642,10 @@
if (bpf_peers_present(sc->sc_ifp->if_bpf))
lptap(sc->sc_ifp, top);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(top, sc->sc_ifp->if_fib);
+#endif
/* mbuf is free'd on failure. */
netisr_queue(NETISR_IP, top);
ppb_lock(ppbus);
Index: sys/dev/lmc/if_lmc.c
===================================================================
--- sys/dev/lmc/if_lmc.c (revision 221313)
+++ sys/dev/lmc/if_lmc.c (working copy)
@@ -77,6 +77,7 @@
# include "opt_inet.h" /* INET */
# include "opt_inet6.h" /* INET6 */
# include "opt_netgraph.h" /* NETGRAPH */
+# include "opt_route.h" /* ROUTETABLES */
# ifdef HAVE_KERNEL_OPTION_HEADERS
# include "opt_device_polling.h" /* DEVICE_POLLING */
# endif
@@ -2527,6 +2528,10 @@
{
softc_t *sc = IFP2SC(ifp);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(mbuf, ifp->if_fib);
+#endif
# if INET
if (mbuf->m_data[0]>>4 == 4)
netisr_dispatch(NETISR_IP, mbuf);
Index: sys/dev/iicbus/if_ic.c
===================================================================
--- sys/dev/iicbus/if_ic.c (revision 221313)
+++ sys/dev/iicbus/if_ic.c (working copy)
@@ -30,6 +30,7 @@
/*
* I2C bus IP driver
*/
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -311,6 +312,10 @@
top = m_devget(sc->ic_ifbuf + ICHDRLEN, len, 0, sc->ic_ifp, 0);
if (top) {
mtx_unlock(&sc->ic_lock);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(top, sc->ic_ifp->if_fib);
+#endif
netisr_dispatch(NETISR_IP, top);
mtx_lock(&sc->ic_lock);
}
Index: sys/dev/usb/net/uhso.c
===================================================================
--- sys/dev/usb/net/uhso.c (revision 221313)
+++ sys/dev/usb/net/uhso.c (working copy)
@@ -26,6 +26,8 @@
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
+#include "opt_route.h"
+
#include <sys/param.h>
#include <sys/types.h>
#include <sys/sockio.h>
@@ -1754,6 +1756,10 @@
/* Dispatch to IP layer */
BPF_MTAP(sc->sc_ifp, m);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
m = m0 != NULL ? m0 : NULL;
mtx_lock(&sc->sc_mtx);
Index: sys/net/if.c
===================================================================
--- sys/net/if.c (revision 221313)
+++ sys/net/if.c (working copy)
@@ -33,6 +33,7 @@
#include "opt_compat.h"
#include "opt_inet6.h"
#include "opt_inet.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/types.h>
@@ -2078,6 +2079,12 @@
ifr->ifr_mtu = ifp->if_mtu;
break;
+#ifdef ROUTETABLES
+ case SIOCGIFIB:
+ ifr->ifr_fib = ifp->if_fib;
+ break;
+#endif
+
case SIOCGIFPHYS:
ifr->ifr_phys = ifp->if_physical;
break;
@@ -2307,6 +2314,28 @@
break;
}
+#ifdef ROUTETABLES
+ case SIOCSIFIB:
+ {
+ error = priv_check(td, PRIV_NET_SETIFIB);
+ if (error)
+ return (error);
+ if (ifr->ifr_fib > rt_numfibs)
+ return (EINVAL);
+
+ ifp->if_fib = ifr->ifr_fib;
+
+ if (ifp->if_fib == 0)
+ ifp->if_flags &= ~IFF_CUSTOMFIB;
+ else
+ ifp->if_flags |= IFF_CUSTOMFIB;
+
+ /* XXX we should generate rt_ifmsg here */
+
+ break;
+ }
+#endif
+
case SIOCADDMULTI:
case SIOCDELMULTI:
if (cmd == SIOCADDMULTI)
Index: sys/net/if.h
===================================================================
--- sys/net/if.h (revision 221313)
+++ sys/net/if.h (working copy)
@@ -104,6 +104,7 @@
u_long ifi_hwassist; /* HW offload capabilities, see IFCAP */
time_t ifi_epoch; /* uptime at attach or stat reset */
struct timeval ifi_lastchange; /* time of last administrative change */
+ u_short ifi_fib; /* interface fib */
};
/*-
@@ -151,6 +152,7 @@
#define IFF_STATICARP 0x80000 /* (n) static ARP */
#define IFF_DYING 0x200000 /* (n) interface is winding down */
#define IFF_RENAMING 0x400000 /* (n) interface is being renamed */
+#define IFF_CUSTOMFIB 0x800000 /* (n) interface belongs to custom FIB */
/*
* Old names for driver flags so that user space tools can continue to use
@@ -240,6 +242,7 @@
int ifm_addrs; /* like rtm_addrs */
int ifm_flags; /* value of if_flags */
u_short ifm_index; /* index for associated ifp */
+ u_short ifm_datalen; /* length of ifm_data */
struct if_data ifm_data;/* statistics and other data about if */
};
@@ -315,6 +318,7 @@
int ifru_media;
caddr_t ifru_data;
int ifru_cap[2];
+ int ifru_fib;
} ifr_ifru;
#define ifr_addr ifr_ifru.ifru_addr /* address */
#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
@@ -331,6 +335,7 @@
#define ifr_reqcap ifr_ifru.ifru_cap[0] /* requested capabilities */
#define ifr_curcap ifr_ifru.ifru_cap[1] /* current capabilities */
#define ifr_index ifr_ifru.ifru_index /* interface index */
+#define ifr_fib ifr_ifru.ifru_fib /* interface index */
};
#define _SIZEOF_ADDR_IFREQ(ifr) \
Index: sys/net/if_stf.c
===================================================================
--- sys/net/if_stf.c (revision 221313)
+++ sys/net/if_stf.c (working copy)
@@ -76,6 +76,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -781,6 +782,10 @@
*/
ifp->if_ipackets++;
ifp->if_ibytes += m->m_pkthdr.len;
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(NETISR_IPV6, m);
}
Index: sys/net/if_atmsubr.c
===================================================================
--- sys/net/if_atmsubr.c (revision 221313)
+++ sys/net/if_atmsubr.c (working copy)
@@ -40,6 +40,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_natm.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -332,6 +333,10 @@
return;
}
}
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
}
Index: sys/net/if_fwsubr.c
===================================================================
--- sys/net/if_fwsubr.c (revision 221313)
+++ sys/net/if_fwsubr.c (working copy)
@@ -32,6 +32,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -626,7 +627,10 @@
m_freem(m);
return;
}
-
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
}
Index: sys/net/if_arcsubr.c
===================================================================
--- sys/net/if_arcsubr.c (revision 221313)
+++ sys/net/if_arcsubr.c (working copy)
@@ -41,6 +41,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -608,6 +609,10 @@
m_freem(m);
return;
}
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
}
Index: sys/net/if_ethersubr.c
===================================================================
--- sys/net/if_ethersubr.c (revision 221313)
+++ sys/net/if_ethersubr.c (working copy)
@@ -691,7 +691,10 @@
ETHER_HDR_LEN - ETHER_TYPE_LEN);
m_adj(m, ETHER_VLAN_ENCAP_LEN);
}
-
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
/* Allow ng_ether(4) to claim this frame. */
if (IFP2AC(ifp)->ac_netgraph != NULL) {
KASSERT(ng_ether_input_p != NULL,
Index: sys/net/if_gif.c
===================================================================
--- sys/net/if_gif.c (revision 221313)
+++ sys/net/if_gif.c (working copy)
@@ -32,6 +32,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -609,6 +610,10 @@
ifp->if_ipackets++;
ifp->if_ibytes += m->m_pkthdr.len;
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
}
Index: sys/net/if_iso88025subr.c
===================================================================
--- sys/net/if_iso88025subr.c (revision 221313)
+++ sys/net/if_iso88025subr.c (working copy)
@@ -43,6 +43,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -679,7 +680,10 @@
goto dropanyway;
break;
}
-
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
return;
Index: sys/net/if_var.h
===================================================================
--- sys/net/if_var.h (revision 221313)
+++ sys/net/if_var.h (working copy)
@@ -215,6 +215,7 @@
* to anything.
*/
#define if_mtu if_data.ifi_mtu
+#define if_fib if_data.ifi_fib
#define if_type if_data.ifi_type
#define if_physical if_data.ifi_physical
#define if_addrlen if_data.ifi_addrlen
Index: sys/net/if_fddisubr.c
===================================================================
--- sys/net/if_fddisubr.c (revision 221313)
+++ sys/net/if_fddisubr.c (working copy)
@@ -40,6 +40,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/systm.h>
@@ -550,6 +551,10 @@
ifp->if_noproto++;
goto dropanyway;
}
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
return;
Index: sys/net/if_tun.c
===================================================================
--- sys/net/if_tun.c (revision 221313)
+++ sys/net/if_tun.c (working copy)
@@ -20,6 +20,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/param.h>
#include <sys/priv.h>
@@ -936,6 +937,10 @@
ifp->if_ibytes += m->m_pkthdr.len;
ifp->if_ipackets++;
CURVNET_SET(ifp->if_vnet);
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
netisr_dispatch(isr, m);
CURVNET_RESTORE();
return (0);
Index: sys/net/if_spppfr.c
===================================================================
--- sys/net/if_spppfr.c (revision 221313)
+++ sys/net/if_spppfr.c (working copy)
@@ -29,6 +29,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#endif
#ifdef NetBSD1_3
@@ -280,6 +281,10 @@
if (! (ifp->if_flags & IFF_UP))
goto drop;
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
/* Check queue. */
if (netisr_queue(isr, m)) { /* (0) on success. */
if (debug)
Index: sys/net/if_spppsubr.c
===================================================================
--- sys/net/if_spppsubr.c (revision 221313)
+++ sys/net/if_spppsubr.c (working copy)
@@ -26,6 +26,7 @@
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipx.h"
+#include "opt_route.h"
#include <sys/systm.h>
#include <sys/kernel.h>
@@ -737,6 +738,11 @@
goto drop;
SPPP_UNLOCK(sp);
+
+#ifdef ROUTETABLES
+ /* Set mbuf fib from interface fib */
+ M_SETFIB(m, ifp->if_fib);
+#endif
/* Check queue. */
if (netisr_queue(isr, m)) { /* (0) on success. */
if (debug)
Index: sys/sys/sockio.h
===================================================================
--- sys/sys/sockio.h (revision 221313)
+++ sys/sys/sockio.h (working copy)
@@ -110,6 +110,9 @@
#define SIOCSIFVNET _IOWR('i', 90, struct ifreq) /* move IF jail/vnet */
#define SIOCSIFRVNET _IOWR('i', 91, struct ifreq) /* reclaim vnet IF */
+#define SIOCGIFIB _IOWR('i', 92, struct ifreq) /* get IF fib */
+#define SIOCSIFIB _IOW('i', 93, struct ifreq) /* set IF fib */
+
#define SIOCSDRVSPEC _IOW('i', 123, struct ifdrv) /* set driver-specific
parameters */
#define SIOCGDRVSPEC _IOWR('i', 123, struct ifdrv) /* get driver-specific
Index: sys/sys/priv.h
===================================================================
--- sys/sys/priv.h (revision 221313)
+++ sys/sys/priv.h (working copy)
@@ -337,6 +337,7 @@
#define PRIV_NET_GIF 416 /* Administer gif interface. */
#define PRIV_NET_SETIFVNET 417 /* Move interface to vnet. */
#define PRIV_NET_SETIFDESCR 418 /* Set interface description. */
+#define PRIV_NET_SETIFIB 419 /* Set interface fib */
/*
* 802.11-related privileges.
--------------000003040104050700090603
Content-Type: text/plain; name="abi_ifdata_20110502-9.0-CURRENT-r221313M.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="abi_ifdata_20110502-9.0-CURRENT-r221313M.diff"
Index: lib/libc/net/getifaddrs.c
===================================================================
--- lib/libc/net/getifaddrs.c (revision 221313)
+++ lib/libc/net/getifaddrs.c (working copy)
@@ -163,11 +163,11 @@
if (ifm->ifm_addrs & RTA_IFP) {
idx = ifm->ifm_index;
++icnt;
- dl = (struct sockaddr_dl *)(void *)(ifm + 1);
+ dl = (struct sockaddr_dl *)((void *)&ifm->ifm_data + ifm->ifm_datalen);
dcnt += SA_RLEN((struct sockaddr *)(void*)dl) +
ALIGNBYTES;
#ifdef HAVE_IFM_DATA
- dcnt += sizeof(ifm->ifm_data);
+ dcnt += ifm->ifm_datalen;
#endif /* HAVE_IFM_DATA */
ncnt += dl->sdl_nlen + 1;
} else
@@ -274,7 +274,7 @@
ifm = (struct if_msghdr *)(void *)rtm;
if (ifm->ifm_addrs & RTA_IFP) {
idx = ifm->ifm_index;
- dl = (struct sockaddr_dl *)(void *)(ifm + 1);
+ dl = (struct sockaddr_dl *)((void *)&ifm->ifm_data + ifm->ifm_datalen);
cif = ift;
ift->ifa_name = names;
Index: sys/net/if.h
===================================================================
--- sys/net/if.h (revision 221313)
+++ sys/net/if.h (working copy)
@@ -240,6 +240,7 @@
int ifm_addrs; /* like rtm_addrs */
int ifm_flags; /* value of if_flags */
u_short ifm_index; /* index for associated ifp */
+ u_short ifm_datalen; /* length of ifm_data */
struct if_data ifm_data;/* statistics and other data about if */
};
Index: sys/net/if_mib.c
===================================================================
--- sys/net/if_mib.c (revision 221313)
+++ sys/net/if_mib.c (working copy)
@@ -107,7 +107,15 @@
ifmd.ifmd_snd_maxlen = ifp->if_snd.ifq_maxlen;
ifmd.ifmd_snd_drops = ifp->if_snd.ifq_drops;
- error = SYSCTL_OUT(req, &ifmd, sizeof ifmd);
+ /*
+ * If requested length is less than sizeof(struct ifmibdata) this
+ * possible means that struct if_data has changed (since ifmibdata
+ * has 16 bytes free for additional fields) and userland program
+ * uses older struct if_data version. We return minimum of requested
+ * length and actual legth to make SYSCTL_OUT() return 0 istead of
+ * ENOMEM
+ */
+ error = SYSCTL_OUT(req, &ifmd, MIN(sizeof(ifmd), req->oldlen));
if (error || !req->newptr)
goto out;
Index: sys/net/rtsock.c
===================================================================
--- sys/net/rtsock.c (revision 221313)
+++ sys/net/rtsock.c (working copy)
@@ -112,6 +112,7 @@
int32_t ifm_addrs;
int32_t ifm_flags;
uint16_t ifm_index;
+ uint16_t ifm_datalen;
struct if_data32 ifm_data;
};
#endif
@@ -1165,6 +1166,7 @@
ifm = mtod(m, struct if_msghdr *);
ifm->ifm_index = ifp->if_index;
ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags;
+ ifm->ifm_datalen = sizeof(struct if_data);
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = 0;
rt_dispatch(m, NULL);
@@ -1491,6 +1493,7 @@
ifm32->ifm_index = ifp->if_index;
ifm32->ifm_flags = ifp->if_flags |
ifp->if_drv_flags;
+ ifm32->ifm_datalen = sizeof(struct if_data32);
copy_ifdata32(&ifp->if_data, &ifm32->ifm_data);
ifm32->ifm_addrs = info.rti_addrs;
error = SYSCTL_OUT(w->w_req, (caddr_t)ifm32,
@@ -1501,6 +1504,7 @@
ifm = (struct if_msghdr *)w->w_tmem;
ifm->ifm_index = ifp->if_index;
ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags;
+ ifm->ifm_datalen = sizeof(struct if_data);
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = info.rti_addrs;
error = SYSCTL_OUT(w->w_req, (caddr_t)ifm, len);
--------------000003040104050700090603--
From owner-freebsd-net@FreeBSD.ORG Sun May 8 17:23:41 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 47FB5106566B
for <net@freebsd.org>; Sun, 8 May 2011 17:23:41 +0000 (UTC)
(envelope-from tuexen@fh-muenster.de)
Received: from mail-n.franken.de (drew.ipv6.franken.de
[IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa])
by mx1.freebsd.org (Postfix) with ESMTP id 36C768FC0C
for <net@freebsd.org>; Sun, 8 May 2011 17:23:40 +0000 (UTC)
Received: from [192.168.1.192] (p508FDFFE.dip.t-dialin.net [80.143.223.254])
(Authenticated sender: macmic)
by mail-n.franken.de (Postfix) with ESMTP id 07FAB1C0B4611
for <net@freebsd.org>; Sun, 8 May 2011 19:23:37 +0200 (CEST)
From: Michael Tuexen <tuexen@fh-muenster.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 8 May 2011 19:23:37 +0200
Message-Id: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de>
To: net@freebsd.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc:
Subject: netstat fix
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 08 May 2011 17:23:41 -0000
Dear all,
netstat -bi currently shows on one of my systems something like:
Name Mtu Network Address Ipkts Ierrs Idrop =
Ibytes Opkts Oerrs Obytes Coll
ix0 9000 <Link#1> 00:1b:21:55:1e:b8 0 0 0 =
0 0 0 0 0
ix0 9000 10.16.0.0 10.16.0.5 0 - - =
0 0 - 0 -
ix0 9000 fe80::21b:21f fe80::21b:21ff:fe 0 - - =
0 2 - 152 -
...
usbus 0 <Link#18> 0 0 0 =
0 0 0 0 0
fwip0 1500 <Link#19> =
00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00 0 0 0 =
0 0 0 0 0
fwe0* 1500 <Link#20> 02:30:05:0b:40:e4 0 0 0 =
0 0 0 0 0
The point here is that for one row the entry in the Address column is =
not limited to 17 characters
as it is in all other cases. The following patch fixes this:
Index: usr.bin/netstat/if.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- usr.bin/netstat/if.c (revision 221601)
+++ usr.bin/netstat/if.c (working copy)
@@ -394,7 +394,7 @@
n =3D cp - sa->sa_data + 1;
cp =3D sa->sa_data;
hexprint:
- while (--n >=3D 0)
+ while ((--n >=3D 0) && (m < 30))
m +=3D printf("%02x%c", *cp++ & =
0xff,
n > 0 ? ':' : ' ');
m =3D 32 - m;
The current code does not enforce any limit on the length of AF_LINK
addresses (and the ones which are not handled specifically with =
netstat).
All other addresses are truncated (see the IPv6 addresses above).
With the patch the above output is:
Name Mtu Network Address Ipkts Ierrs Idrop =
Ibytes Opkts Oerrs Obytes Coll
ix0 9000 <Link#1> 00:1b:21:55:1e:b8 0 0 0 =
0 0 0 0 0
ix0 9000 10.16.0.0 10.16.0.5 0 - - =
0 0 - 0 -
ix0 9000 fe80::21b:21f fe80::21b:21ff:fe 0 - - =
0 2 - 152 -
...
usbus 0 <Link#18> 0 0 0 =
0 0 0 0 0
fwip0 1500 <Link#19> 00:30:05:b3:50:0b: 0 0 0 =
0 0 0 0 0
fwe0* 1500 <Link#20> 02:30:05:0b:40:e4 0 0 0 =
0 0 0 0 0
Any objections against committing the patch? Or suggestions?
Best regards
Michael=
From owner-freebsd-net@FreeBSD.ORG Mon May 9 05:50:09 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 A26A2106566B
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 05:50: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 93EBC8FC0C
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 05:50: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 p495o9ea048624
for <freebsd-net@freefall.freebsd.org>; Mon, 9 May 2011 05:50:09 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p495o9Ld048623;
Mon, 9 May 2011 05:50:09 GMT (envelope-from gnats)
Date: Mon, 9 May 2011 05:50:09 GMT
Message-Id: <201105090550.p495o9Ld048623@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Richard Johnson <raj@new.mischievous.us>
Cc:
Subject: Re: kern/141741: Etherlink III NIC won't work after upgrade to FBSD
8, If I run tcpdump - it works.
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Richard Johnson <raj@new.mischievous.us>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 05:50:09 -0000
The following reply was made to PR kern/141741; it has been noted by GNATS.
From: Richard Johnson <raj@new.mischievous.us>
To: bug-followup@FreeBSD.org, robert@maerzkegeneral.com
Cc:
Subject: Re: kern/141741: Etherlink III NIC won't work after upgrade to FBSD 8, If I run tcpdump - it works.
Date: Sun, 8 May 2011 22:09:46 -0700
I'm seeing this same problem now that I installed FreeBSD 8.2 on my =
laptop. Sometimes it will lock up even from just doing "ifconfig -a". =
I can get it to come back if I do "ifconfig ep0 up" a few times after =
waiting a while. I'm guessing it has to do with the "ep0: WARNING: =
using obsoleted if_watchdog interface" upon startup.
/raj
From owner-freebsd-net@FreeBSD.ORG Mon May 9 11:07:11 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 0985C106564A
for <freebsd-net@FreeBSD.org>; Mon, 9 May 2011 11:07:11 +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 EC4328FC1C
for <freebsd-net@FreeBSD.org>; Mon, 9 May 2011 11:07:10 +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 p49B7ArX070692
for <freebsd-net@FreeBSD.org>; Mon, 9 May 2011 11:07:10 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49B7AZf070690
for freebsd-net@FreeBSD.org; Mon, 9 May 2011 11:07:10 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Date: Mon, 9 May 2011 11:07:10 GMT
Message-Id: <201105091107.p49B7AZf070690@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: gnats set sender to
owner-bugmaster@FreeBSD.org using -f
From: FreeBSD bugmaster <bugmaster@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 11:07:11 -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/156667 net [em] em0 fails to init on CURRENT after March 17
o kern/156493 net [msk] Marvell Yukon 2 device works only few seconds
o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e
o kern/156328 net [icmp]: host can ping other subnet but no have IP from
o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report
o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re
o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec
o kern/156226 net [lagg]: failover does not announce the failover to swi
o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr
o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc
o kern/155680 net [multicast] problems with multicast
s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W
o kern/155636 net [msk] msk driver locks marvel yukon 88E8057 NIC
o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr
o kern/155597 net [panic] Kernel panics with "sbdrop" message
o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel
o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga
o kern/155420 net [vlan] adding vlan break existent vlan
o bin/155365 net [patch] routed(8): if.c in routed fails to compile if
o kern/155177 net [route] [panic] Panic when inject routes in kernel
o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4)
o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel
o kern/155004 net [bce] [panic] kernel panic in bce0 driver
o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP
s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD
o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t
o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod
o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R
o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output
o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat
o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u
o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph
o kern/154255 net [nfs] NFS not responding
o kern/154214 net [stf] [panic] Panic when creating stf interface
o kern/154185 net race condition in mb_dupcl
o kern/154169 net [multicast] [ip6] Node Information Query multicast add
o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic
o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf?
o conf/154062 net [vlan] [patch] change to way of auto-generatation of v
o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh
o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to
o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g
o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia
o kern/153497 net [netgraph] netgraph panic due to race conditions
o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes
o kern/153308 net [em] em interface use 100% cpu
o kern/153244 net [em] em(4) fails to send UDP to port 0xffff
o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph
o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e
o kern/152828 net [em] poor performance on 8.1, 8.2-PRE
o kern/152569 net [net]: Multiple ppp connections and routing table prob
o kern/152360 net [dummynet] [panic] Crash related to dummynet.
o kern/152235 net [arp] Permanent local ARP entries are not properly upd
o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out
o kern/151690 net [ep] network connectivity won't work until dhclient is
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/150920 net [ixgbe][igb] Panic when packets are dropped with heade
o bin/150642 net netstat(1) doesn't print anything for SCTP sockets
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 bin/150224 net ppp(8) does not reassign static IP after kill -KILL co
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/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/149117 net [inet] [patch] in_pcbbind: redundant test
o kern/149086 net [multicast] Generic multicast join failure in 8.1
o kern/148018 net [flowtable] flowtable crashes on ia64
o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11
o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only
o kern/147155 net [ip6] setfb not work with ipv6
o kern/146845 net [libc] close(2) returns error 54 (connection reset by
f kern/146792 net [flowtable] flowcleaner 100% cpu's core load
o kern/146719 net [pf] [panic] PF or dumynet kernel panic
o kern/146534 net [icmp6] wrong source address in echo reply
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/145825 net [panic] panic: soabort: so_count
o kern/145728 net [lagg] Stops working lagg between two servers.
f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi
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/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/144231 net bind/connect/sendto too strict about sockaddr length
o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem
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/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 kern/143034 net [panic] system reboots itself in tcp code [regression]
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
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] Cannot attach (unable to attach hardware
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/140346 net [wlan] High bandwidth use causes loss of wlan connecti
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
p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef
o kern/139117 net [lagg] + wlan boot timing (EBUSY)
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/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/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
p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2
o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i
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/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t
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/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/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 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/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 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/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 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/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/126339 net [ipw] ipw driver drops the connection
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/125617 net [ath] [panic] ath(4) related panic
o kern/125501 net [ath] atheros cardbus driver hangs
f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa
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/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 <ipv6_addr> -interfac
o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool
o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0
f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node
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/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
s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net
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 <host> -iface <nic> 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
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 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
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]
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
o kern/97306 net [netgraph] NG_L2TP locks after connection with failed
o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv
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/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
p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip
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 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
361 problems total.
From owner-freebsd-net@FreeBSD.ORG Mon May 9 15:18:13 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8DCD61065670
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 15:18:13 +0000 (UTC)
(envelope-from kickbsd@yandex.ru)
Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6])
by mx1.freebsd.org (Postfix) with ESMTP id 41EDA8FC08
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 15:18:13 +0000 (UTC)
Received: from web63.yandex.ru (web63.yandex.ru [77.88.46.54])
by forward1.mail.yandex.net (Yandex) with ESMTP id A35851240C4E
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 19:02:24 +0400 (MSD)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
t=1304953344; bh=Du6IBGS+Mt9BW7Fa3kckE6aTKQRKXfptn5IZWa+dCUw=;
h=From:To:Subject:MIME-Version:Message-Id:Date:
Content-Transfer-Encoding:Content-Type;
b=TCui6o5ZipeWmkxZNZVOzEKmU9ad6kbUm4d/8cg1kQ35+TEHzg3EXabRkKFZB6GW3
8d1BiSqzigtM9BlSYDUiTs7yso6ja+1WwLtYAB2OVsEhBUUG22+kxGaR6Jrqerj/dU
tTI7m+oPosYtXyNBzRxNVVz9QDPp8fYFyWb6aR8I=
Received: from localhost (localhost.localdomain [127.0.0.1])
by web63.yandex.ru (Yandex) with ESMTP id 9374CB18040
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 19:02:24 +0400 (MSD)
X-Yandex-Spam: 1
Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by
mail.yandex.ru with HTTP; Mon, 09 May 2011 19:02:23 +0400
From: Darren Baginski <kickbsd@yandex.ru>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Message-Id: <686421304953344@web63.yandex.ru>
Date: Mon, 09 May 2011 19:02:23 +0400
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Subject: PF and ipv6 strange behavior on FreeBSD
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 15:18:13 -0000
Hi!
I've noticed rather strange pf behavior on FreeBSD box (8.2 and 7.4 in particular)
Consider this rule
pass out proto tcp from self to any flags S/SA keep state
despite the fact pf starts after netif
if doesn't not create rule
pass out inet6 proto tcp from 2001:xxx:xxx:xxx:ffff:ffff:ffff:ff26 to any flags S/SA keep state
where 2001:xxx:xxx:xxx:ffff:ffff:ffff:ff26 my ipv6 addres,
but it creates
pass out inet proto tcp from 116.x.x.26 to any flags S/SA keep state
where 116.x.x.26 my ipv4 address on the same interface.
All above happens *only* after reboot.
BUT if I log in on already working machine and issue pfctl -f /etc/pf.conf , pf creates rule in question.
Perhaps that happens because of pf starts to 'earlier' , and ipv6 has no time to check IP duplicates on link and pf start before ipv6 address is up on interface?
Any Ideas and suggestion are very welcome, since I reproduced the same problem on 7.4 and that issue is rather annoying.
Thank you!
From owner-freebsd-net@FreeBSD.ORG Mon May 9 16:23:56 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 1212C1065679
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 16:23:56 +0000 (UTC)
(envelope-from mwoliver@gmail.com)
Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com
[209.85.220.182])
by mx1.freebsd.org (Postfix) with ESMTP id 80F988FC12
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 16:23:55 +0000 (UTC)
Received: by vxc34 with SMTP id 34so8006904vxc.13
for <freebsd-net@freebsd.org>; Mon, 09 May 2011 09:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=TjueRImkPf0VZfcOIsWKqPjnmDvIiqsaD4ZF+lP7ezI=;
b=U59VlrvIa0reDuzsBW57veYX8xmrIqGdixcu/c6BDBNMx1v9OaJuEc/eSxwmD1kZR3
THDQ5z2QpNkDIUlqQXZ5uPkpyM4ZKSehrBqWeHBQG4Kj0kSeA6UvcZFUPdSUjY/9AGCv
BqkkroyNF24qdQf7naZIlYh2uFAQjE6A8c17M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=wBNIv4wx844qU19+isOhLQpBCHJBHAvgjw1vYqaG61NfiZ+fJGuqyRIYecRwpOQEM9
6vFKglBrKMFFbM59exmyzozgPoXG2W5an4GyWoPIPLfl0KV/8ad4rgd5F62j9HkRVA/a
WJO+O9PEJPPF2Ede5HzbelSTrsGJh63vbfgGk=
MIME-Version: 1.0
Received: by 10.52.185.98 with SMTP id fb2mr132622vdc.198.1304956386270; Mon,
09 May 2011 08:53:06 -0700 (PDT)
Received: by 10.220.99.1 with HTTP; Mon, 9 May 2011 08:53:06 -0700 (PDT)
In-Reply-To: <686421304953344@web63.yandex.ru>
References: <686421304953344@web63.yandex.ru>
Date: Mon, 9 May 2011 11:53:06 -0400
Message-ID: <BANLkTi=ymAyRzax+Hc+oNQ6boc=RjUgVLg@mail.gmail.com>
From: Mike Oliver <mwoliver@gmail.com>
To: Darren Baginski <kickbsd@yandex.ru>
Content-Type: text/plain; charset=UTF-8
Cc: freebsd-net@freebsd.org
Subject: Re: PF and ipv6 strange behavior on FreeBSD
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 16:23:56 -0000
On Mon, May 9, 2011 at 11:02, Darren Baginski <kickbsd@yandex.ru> wrote:
> Hi!
>
> I've noticed rather strange pf behavior on FreeBSD box (8.2 and 7.4 in particular)
I noticed something similar...
http://lists.freebsd.org/pipermail/freebsd-pf/2006-April/002098.html
and filed a PR for it (which is still open):
http://www.freebsd.org/cgi/query-pr.cgi?pr=96343&cat=conf
Now, that was back when CURRENT was 7.0 and likely lots of things have
changed since then, but maybe the patch I submitted in the PR can help
you figure out where the sequence is out of order. If you can find it
then please submit a patch.
Thanks,
Mike
--
Mike Oliver, KT2T
+1-863-738-2334
kt2t@arrl.net -or- mwoliver@gmail.com
Twitter: @mwoliver
From owner-freebsd-net@FreeBSD.ORG Mon May 9 16:32:22 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6B63B1065678
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 16:32:22 +0000 (UTC)
(envelope-from kickbsd@yandex.ru)
Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9])
by mx1.freebsd.org (Postfix) with ESMTP id 1D1358FC14
for <freebsd-net@freebsd.org>; Mon, 9 May 2011 16:32:21 +0000 (UTC)
Received: from web41.yandex.ru (web41.yandex.ru [77.88.46.3])
by forward4.mail.yandex.net (Yandex) with ESMTP id 50C9850145D;
Mon, 9 May 2011 20:32:20 +0400 (MSD)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
t=1304958740; bh=SoE+YPDklxA5C4OIlJGUZs19uOjqjmgxNUcABcKhXvI=;
h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id:
Date:Content-Transfer-Encoding:Content-Type;
b=ndnQdRYBdcO/VaqBFNVH0UEypWeHp2XzmPbWyqq8GSMflbFe93v2grrFL8VrmvBZ5
7xIQmer/oxeLjQnPYyie27GamvOSR5Tkc1fkc54kQ7HN7hTHh2ipx9aHlXz3HtnOKy
8vwUHJEkylquPWFVQOj4aBypt6KTbbSTgLSEzKro=
Received: from localhost (localhost.localdomain [127.0.0.1])
by web41.yandex.ru (Yandex) with ESMTP id 3AA916481B8;
Mon, 9 May 2011 20:32:20 +0400 (MSD)
X-Yandex-Spam: 1
Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by
mail.yandex.ru with HTTP; Mon, 09 May 2011 20:32:19 +0400
From: Darren Baginski <kickbsd@yandex.ru>
To: Mike Oliver <mwoliver@gmail.com>
In-Reply-To: <BANLkTi=ymAyRzax+Hc+oNQ6boc=RjUgVLg@mail.gmail.com>
References: <686421304953344@web63.yandex.ru>
<BANLkTi=ymAyRzax+Hc+oNQ6boc=RjUgVLg@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <726451304958739@web41.yandex.ru>
Date: Mon, 09 May 2011 20:32:19 +0400
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=koi8-r
Cc: freebsd-net@freebsd.org
Subject: Re: PF and ipv6 strange behavior on FreeBSD
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 16:32:22 -0000
Thank you! You are right, exactly the same issue as in PR you mentioned.
09.05.2011, 19:53, "Mike Oliver" <mwoliver@gmail.com>:
> On Mon, May 9, 2011 at 11:02, Darren Baginski <kickbsd@yandex.ru>; wrote:
>
>> šHi!
>>
>> šI've noticed rather strange pf behavior on FreeBSD box (8.2 and 7.4 in particular)
>
> I noticed something similar...
>
> http://lists.freebsd.org/pipermail/freebsd-pf/2006-April/002098.html
>
> and filed a PR for it (which is still open):
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=96343&cat=conf
>
> Now, that was back when CURRENT was 7.0 and likely lots of things have
> changed since then, but maybe the patch I submitted in the PR can help
> you figure out where the sequence is out of order. šIf you can find it
> then please submit a patch.
>
> Thanks,
> Mike
>
> --
> Mike Oliver, KT2T
> +1-863-738-2334
> kt2t@arrl.net -or- mwoliver@gmail.com
> Twitter: @mwoliver
From owner-freebsd-net@FreeBSD.ORG Mon May 9 20:20:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 CF92B106564A
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 20:20:10 +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 A74378FC1C
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 20:20:10 +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 p49KKALB073490
for <freebsd-net@freefall.freebsd.org>; Mon, 9 May 2011 20:20:10 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49KKAjG073489;
Mon, 9 May 2011 20:20:10 GMT (envelope-from gnats)
Date: Mon, 9 May 2011 20:20:10 GMT
Message-Id: <201105092020.p49KKAjG073489@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Eugene Grosbein <egrosbein@rdtc.ru>
Cc:
Subject: Re: kern/153497: [netgraph] netgraph panic due to race conditions
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Eugene Grosbein <egrosbein@rdtc.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 20:20:10 -0000
The following reply was made to PR kern/153497; it has been noted by GNATS.
From: Eugene Grosbein <egrosbein@rdtc.ru>
To: bug-followup@FreeBSD.ORG
Cc: mike tancsa <mike@sentex.net>
Subject: Re: kern/153497: [netgraph] netgraph panic due to race conditions
Date: Tue, 10 May 2011 03:15:52 +0700
Hi!
Could you check out latest RELENG_8?
glebius@ mad several changes eliminating races that made my mpd servers pretty stable.
Changes have been MFC'd.
Eugene Grosbein
From owner-freebsd-net@FreeBSD.ORG Mon May 9 20:40:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 7818B1065673
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 20:40:10 +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 69EDA8FC12
for <freebsd-net@hub.freebsd.org>; Mon, 9 May 2011 20:40:10 +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 p49KeAXo093106
for <freebsd-net@freefall.freebsd.org>; Mon, 9 May 2011 20:40:10 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49KeA0K093105;
Mon, 9 May 2011 20:40:10 GMT (envelope-from gnats)
Date: Mon, 9 May 2011 20:40:10 GMT
Message-Id: <201105092040.p49KeA0K093105@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Mike Tancsa <mike@sentex.net>
Cc:
Subject: Re: kern/153497: [netgraph] netgraph panic due to race conditions
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Mike Tancsa <mike@sentex.net>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 20:40:10 -0000
The following reply was made to PR kern/153497; it has been noted by GNATS.
From: Mike Tancsa <mike@sentex.net>
To: Eugene Grosbein <egrosbein@rdtc.ru>
Cc: bug-followup@FreeBSD.ORG
Subject: Re: kern/153497: [netgraph] netgraph panic due to race conditions
Date: Mon, 09 May 2011 16:34:49 -0400
On 5/9/2011 4:15 PM, Eugene Grosbein wrote:
> Hi!
>
> Could you check out latest RELENG_8?
>
> glebius@ mad several changes eliminating races that made my mpd servers pretty stable.
> Changes have been MFC'd.
I am no longer seeing any netgraph panics, but the box is still crashing
after about 15 days uptime now. As soon as I track down more
information, I will open a new ticket.
---Mike
>
> Eugene Grosbein
>
>
--
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
From owner-freebsd-net@FreeBSD.ORG Tue May 10 10:13:46 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8BC9E106564A;
Tue, 10 May 2011 10:13:46 +0000 (UTC)
(envelope-from adrian@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id 635048FC18;
Tue, 10 May 2011 10:13:46 +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 p4AADkS6072581;
Tue, 10 May 2011 10:13:46 GMT
(envelope-from adrian@freefall.freebsd.org)
Received: (from adrian@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AADkgu072577;
Tue, 10 May 2011 10:13:46 GMT (envelope-from adrian)
Date: Tue, 10 May 2011 10:13:46 GMT
Message-Id: <201105101013.p4AADkgu072577@freefall.freebsd.org>
To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org
From: adrian@FreeBSD.org
Cc:
Subject: Re: kern/140796: [ath] [panic] Cannot attach (unable to attach
hardware; HAL status 3) under 8, panic in 7.x
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 10:13:46 -0000
Synopsis: [ath] [panic] Cannot attach (unable to attach hardware; HAL status 3) under 8, panic in 7.x
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: adrian
Responsible-Changed-When: Tue May 10 10:13:04 UTC 2011
Responsible-Changed-Why:
Reassigning to freebsd-wireless
Submitter: is this still a problem for you?
http://www.freebsd.org/cgi/query-pr.cgi?pr=140796
From owner-freebsd-net@FreeBSD.ORG Tue May 10 10:14:24 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 3F82E1065678;
Tue, 10 May 2011 10:14:24 +0000 (UTC)
(envelope-from adrian@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id 182258FC0C;
Tue, 10 May 2011 10:14:24 +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 p4AAENMi072970;
Tue, 10 May 2011 10:14:23 GMT
(envelope-from adrian@freefall.freebsd.org)
Received: (from adrian@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AAEN2l072966;
Tue, 10 May 2011 10:14:23 GMT (envelope-from adrian)
Date: Tue, 10 May 2011 10:14:23 GMT
Message-Id: <201105101014.p4AAEN2l072966@freefall.freebsd.org>
To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org
From: adrian@FreeBSD.org
Cc:
Subject: Re: kern/125617: [ath] [panic] ath(4) related panic
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 10:14:24 -0000
Synopsis: [ath] [panic] ath(4) related panic
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: adrian
Responsible-Changed-When: Tue May 10 10:13:54 UTC 2011
Responsible-Changed-Why:
Reassigning to freebsd-wireless
Submitter: is this still a problem for you?
http://www.freebsd.org/cgi/query-pr.cgi?pr=125617
From owner-freebsd-net@FreeBSD.ORG Tue May 10 10:14:57 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 1E2981065677;
Tue, 10 May 2011 10:14:57 +0000 (UTC)
(envelope-from adrian@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id EAC5B8FC22;
Tue, 10 May 2011 10:14:56 +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 p4AAEuaU073019;
Tue, 10 May 2011 10:14:56 GMT
(envelope-from adrian@freefall.freebsd.org)
Received: (from adrian@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AAEups073015;
Tue, 10 May 2011 10:14:56 GMT (envelope-from adrian)
Date: Tue, 10 May 2011 10:14:56 GMT
Message-Id: <201105101014.p4AAEups073015@freefall.freebsd.org>
To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org
From: adrian@FreeBSD.org
Cc:
Subject: Re: kern/125501: [ath] atheros cardbus driver hangs
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 10:14:57 -0000
Synopsis: [ath] atheros cardbus driver hangs
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: adrian
Responsible-Changed-When: Tue May 10 10:14:30 UTC 2011
Responsible-Changed-Why:
Reassign to freebsd-wireless
Submitter: is this still a problem for you w/ freebsd-8 or freebsd-head?
http://www.freebsd.org/cgi/query-pr.cgi?pr=125501
From owner-freebsd-net@FreeBSD.ORG Tue May 10 19:13:27 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 C1D751065674;
Tue, 10 May 2011 19:13:27 +0000 (UTC)
(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id 82FA08FC18;
Tue, 10 May 2011 19:13:27 +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 p4AJDRmn068916;
Tue, 10 May 2011 19:13:27 GMT
(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AJDRqP068912;
Tue, 10 May 2011 19:13:27 GMT (envelope-from linimon)
Date: Tue, 10 May 2011 19:13:27 GMT
Message-Id: <201105101913.p4AJDRqP068912@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc:
Subject: Re: kern/156877: [dummynet] [panic] dummynet move_pkt() null ptr
dereference
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 19:13:27 -0000
Old Synopsis: [panic] dummynet move_pkt() null ptr dereference
New Synopsis: [dummynet] [panic] dummynet move_pkt() null ptr dereference
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue May 10 19:13:03 UTC 2011
Responsible-Changed-Why:
reclassify.
http://www.freebsd.org/cgi/query-pr.cgi?pr=156877
From owner-freebsd-net@FreeBSD.ORG Tue May 10 20:40:08 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 9B8C11065673
for <freebsd-net@hub.freebsd.org>; Tue, 10 May 2011 20:40:08 +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 70FAB8FC13
for <freebsd-net@hub.freebsd.org>; Tue, 10 May 2011 20:40:08 +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 p4AKe87Q048000
for <freebsd-net@freefall.freebsd.org>; Tue, 10 May 2011 20:40:08 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AKe8BW047999;
Tue, 10 May 2011 20:40:08 GMT (envelope-from gnats)
Date: Tue, 10 May 2011 20:40:08 GMT
Message-Id: <201105102040.p4AKe8BW047999@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Przemyslaw Frasunek <przemyslaw@frasunek.com>
Cc:
Subject: Re: kern/122290: [netgraph] [panic] Netgraph related "kmem_map too
small" panics
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Przemyslaw Frasunek <przemyslaw@frasunek.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2011 20:40:08 -0000
The following reply was made to PR kern/122290; it has been noted by GNATS.
From: Przemyslaw Frasunek <przemyslaw@frasunek.com>
To: bug-followup@FreeBSD.org
Cc:
Subject: Re: kern/122290: [netgraph] [panic] Netgraph related "kmem_map too
small" panics
Date: Tue, 10 May 2011 22:30:31 +0200
It seems to be fixed, as I didn't experience any panics on recent 7.x and 8.x
releases.
This PR can be closed now.
From owner-freebsd-net@FreeBSD.ORG Wed May 11 23:12:17 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F13FD106564A
for <net@freebsd.org>; Wed, 11 May 2011 23:12:17 +0000 (UTC)
(envelope-from oberman@es.net)
Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2])
by mx1.freebsd.org (Postfix) with ESMTP id E056D8FC15
for <net@freebsd.org>; Wed, 11 May 2011 23:12:17 +0000 (UTC)
Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29])
by mailgw.es.net (8.14.3/8.14.3) with ESMTP id p4BNCHJK024405
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <net@freebsd.org>; Wed, 11 May 2011 16:12:17 -0700
Received: from ptavv.es.net (localhost [127.0.0.1])
by ptavv.es.net (Tachyon Server) with ESMTP id 737751CC2C
for <net@freebsd.org>; Wed, 11 May 2011 16:12:17 -0700 (PDT)
To: net@freebsd.org
Date: Wed, 11 May 2011 16:12:17 -0700
From: "Kevin Oberman" <oberman@es.net>
Message-Id: <20110511231217.737751CC2C@ptavv.es.net>
Cc:
Subject: Performance crash when setting TOS bits
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2011 23:12:18 -0000
Under FreeBSD 8.2 we have found that something goes haywire when TOS
bits are set. When the TOS is 0 (default), we can get 9 Gbps performance
with one of our test systems running perfSONAR
(http://www.perfsonar.net). When we set the TOS bits to 32, the
performance drops to about 4Mbps. This does not happen with FreeBSD 7.3.
We ran a tcptrace on the data and found very large numbers of
retransmits and duplicate ACKs. I would attach the traces, but I know
the mail list would remove them.
Has anyone else seen this? Any idea what might be happening?
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
From owner-freebsd-net@FreeBSD.ORG Thu May 12 00:55:13 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6141B1065675
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 00:55:13 +0000 (UTC)
(envelope-from rj@cyclaero.com)
Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160])
by mx1.freebsd.org (Postfix) with ESMTP id EF6268FC13
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 00:55:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1305161711; l=2418;
s=domk; d=cyclaero.com;
h=Mime-Version:To:Date:Subject:Content-Transfer-Encoding:Content-Type:
From:X-RZG-CLASS-ID:X-RZG-AUTH;
bh=Z5jMVIi1sd+VItCVvRFvMZhnAoA=;
b=IOm515rFw8SROf8WUO+cl3+sIcXDBsSSsu3/U/42AvM2ksgcQdhgb8lpj4ZwbSLABn/
7UUn6B9J8VprZroRXfy4tB5fK7ldOON6qOawHc4omJJjKEJ3IzEU0e5Kj0ULkfm3Qn/sN
ffeMgGMkoFItsktajD+aMmPLi8nXoOShBP4=
X-RZG-AUTH: :O2kGeEG7b/pS1E6gSHOyjPKyNsg/5l1He+DgCy9/8FSej6CwUyslcvR13AejfvgZQ88TEw==
X-RZG-CLASS-ID: mo00
Received: from rolf.projectworld.net
(189-54-106-151-nd.cpe.vivax.com.br [189.54.106.151])
by post.strato.de (mrclete mo21) (RZmta 25.18)
with (AES128-SHA encrypted) ESMTPA id 607078n4BLEXDZ
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 02:43:39 +0200 (MEST)
From: "Dr. Rolf Jansen" <rj@cyclaero.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 May 2011 21:43:35 -0300
Message-Id: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com>
To: freebsd-net@freebsd.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: multiple clients behind the same NAT connecting a L2TP/IPsec VPN
server behind another NAT
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 00:55:13 -0000
I have setup a VPN-Server on my FreeBSD 8.2 Release i386 machine, using =
the following requisites:
- customized GENERIC Kernel builded with the following
additional options and devices:
IPSEC, IPSEC_FILTERTUNNEL, IPSEC_NAT_T, crypto, enc
- ports/security/ipsec-tools (v0.8.0)
compiled with NATT enabled and NATTF disabled
- ports/net/mpd5 (v5.5)
The server sits in the DMZ behind a SOHO router. Everything is working =
fine so far. I can establish connections from multiple external clients =
at the same time. Even connections from within a NAT'ed local network =
via the internet to my L2TP/IPsec server do work.
The only remaining problem is, that from behind the same NAT only one =
client works well. As soon as a connection between a second client and =
the server has been established, the communication of both break down. =
The racoon log shows nothing noticeable here, and according to the log =
both connections are established successfully, anyhow, the communication =
is blocked.
racoon is configured to generate unique policies.
When a client disconnects from the server, racoon usually purges 2 =
IPsec-SA shortly after. The interesting thing in the case of 2 clients =
from the same NAT is, that it purges one IPsec-SA from the client just =
disconnected, and 1 belonging to the client that is still connected. So, =
it seems that the internal SA house holding of racoon got confused.
I am investigating this already for some days, and finally I would like =
to ask to the experts, whether this is perhaps an issue of the =
ipsec-tools (racoon/setkey), and not with my setup. I am willing to =
spent more time on this only if there is some chance that this can be =
resolved.
So, is there anybody out there, who can successfully establish VPN =
connections from multiple clients behind the same NAT to a L2TP/IPsec =
Server running ipsec-tools and mpd5?
If yes, please may we discuss more in detail my setup?
If no, I would be still grateful for some insights.
BTW: Using only mpd5, I setup also a PPTP-VPN server running in parallel =
to the L2TP/IPsec one. Multiple PPTP-VPN clients behind the same NAT =
work perfectly well with my server - So, I tend to believe that it is =
really an issue with the IPsec part and not with the L2TP (mpd5) part of =
my setup.
Many thanks in advance for any reply
Best regards
Rolf
From owner-freebsd-net@FreeBSD.ORG Thu May 12 09:17:56 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6FA4C106564A
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 09:17:56 +0000 (UTC)
(envelope-from vanhu@zeninc.net)
Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25])
by mx1.freebsd.org (Postfix) with ESMTP id E74778FC18
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 09:17:55 +0000 (UTC)
Received: from astro.zen.inc (astro.zen.inc [192.168.1.239])
by smtp.zeninc.net (smtpd) with ESMTP id 950402798BD
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 11:02:21 +0200 (CEST)
Received: by astro.zen.inc (Postfix, from userid 1000)
id 84D6F1701A; Thu, 12 May 2011 11:02:21 +0200 (CEST)
Date: Thu, 12 May 2011 11:02:21 +0200
From: VANHULLEBUS Yvan <vanhu@FreeBSD.org>
To: freebsd-net@freebsd.org
Message-ID: <20110512090221.GA647@zeninc.net>
References: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com>
User-Agent: All mail clients suck. This one just sucks less.
Subject: Re: multiple clients behind the same NAT connecting a L2TP/IPsec
VPN server behind another NAT
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 09:17:56 -0000
Hi.
On Wed, May 11, 2011 at 09:43:35PM -0300, Dr. Rolf Jansen wrote:
> I have setup a VPN-Server on my FreeBSD 8.2 Release i386 machine, using the following requisites:
>
> - customized GENERIC Kernel builded with the following
> additional options and devices:
> IPSEC, IPSEC_FILTERTUNNEL, IPSEC_NAT_T, crypto, enc
>
> - ports/security/ipsec-tools (v0.8.0)
> compiled with NATT enabled and NATTF disabled
On a FreeBSD 8.2, NATTF enabled/disabled will change nothing, it is
just here to ensure NAT-T support is available and break compilation
if it is not.
> - ports/net/mpd5 (v5.5)
>
>
> The server sits in the DMZ behind a SOHO router. Everything is
> working fine so far. I can establish connections from multiple
> external clients at the same time. Even connections from within a
> NAT'ed local network via the internet to my L2TP/IPsec server do
> work.
Which is already good news, as no one AFAIK really worked hard on such
setups...
> The only remaining problem is, that from behind the same NAT only
> one client works well. As soon as a connection between a second
> client and the server has been established, the communication of
> both break down. The racoon log shows nothing noticeable here, and
> according to the log both connections are established successfully,
> anyhow, the communication is blocked.
Sounds like something (racoon ? kernel ? both ?) handles ports in a
bad way in transport mode....
Could you send an example of such generated policies/SAs ?
Be careful to use setkey from ipsec-tools (/usr/local/sbin) and NOT
from system (/sbin/setkey) to have all NAT-T related informations.
> racoon is configured to generate unique policies.
A bit more strange.... SAs should be really hard linked with SPDs, and
even with a confusion with ports, they should be considered as NOT be
for the same tunnel.....
> When a client disconnects from the server, racoon usually purges 2
> IPsec-SA shortly after. The interesting thing in the case of 2
> clients from the same NAT is, that it purges one IPsec-SA from the
> client just disconnected, and 1 belonging to the client that is
> still connected. So, it seems that the internal SA house holding of
> racoon got confused.
See in racoon's debug (-dd to have more verbose) if decision comes
from racoon, from peer (I don't think so) or from the kernel (via a
PFKey message).
Be careful if you send such output to the ML, as it includes some
confidential datas (IPs, PSKs, etc....).
> I am investigating this already for some days, and finally I would
> like to ask to the experts, whether this is perhaps an issue of the
> ipsec-tools (racoon/setkey), and not with my setup. I am willing to
> spent more time on this only if there is some chance that this can
> be resolved.
There is "some chance", but this may involve userland and/or kernel
patching...
>
> So, is there anybody out there, who can successfully establish VPN
> connections from multiple clients behind the same NAT to a
> L2TP/IPsec Server running ipsec-tools and mpd5?
I know that multiple NAT-T behind the same peer will work in *TUNNEL*
mode, but I never tested that in TRANSPORT mode.
> BTW: Using only mpd5, I setup also a PPTP-VPN server running in
> parallel to the L2TP/IPsec one. Multiple PPTP-VPN clients behind the
> same NAT work perfectly well with my server - So, I tend to believe
> that it is really an issue with the IPsec part and not with the L2TP
> (mpd5) part of my setup.
I don't know MPD so much, but it really does look like an IPsec
related issue.
Yvan.
From owner-freebsd-net@FreeBSD.ORG Thu May 12 10:19:06 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 6B7431065670
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 10:19:06 +0000 (UTC)
(envelope-from michael@gameservice.ru)
Received: from mail.mzlab.net (mail.mzlab.net [66.197.153.197])
by mx1.freebsd.org (Postfix) with ESMTP id 461678FC14
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 10:19:05 +0000 (UTC)
Date: Thu, 12 May 2011 13:01:23 +0300
From: Michael <michael@gameservice.ru>
X-Priority: 3 (Normal)
Message-ID: <17710363528.20110512130123@gameservice.ru>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
Subject: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 10:19:06 -0000
Hello.
I'm running nginx in load balancing mode for java application with
around 400 requests/second. For every request, nginx is doing a
HTTP/1.0 connection without keep alive to jetty. Several
times per minute this connection takes 3 seconds complete. I don't see
2 or 1 seconds response from upstream, only 3 seconds. Listen backlog is not
overflowed.
I searched for this delay in google, and found similar problem in Linux:
http://kerneltrap.org/mailarchive/linux-net/2008/3/26/1264734/thread
http://kerneltrap.org/mailarchive/linux-net/2008/2/4/713224/thread
And Windows:
http://stackoverflow.com/questions/1875151/delay-in-multiple-tcp-connections-from-java-to-the-same-machine/1927486#1927486
Can you advice what should i tune in FreeBSD to fix this problem?
Michael
From owner-freebsd-net@FreeBSD.ORG Thu May 12 10:56:51 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 47F8E106566B
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 10:56:51 +0000 (UTC)
(envelope-from dudu@dudu.ro)
Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com
[209.85.216.175])
by mx1.freebsd.org (Postfix) with ESMTP id 0C09A8FC14
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 10:56:50 +0000 (UTC)
Received: by qyk35 with SMTP id 35so3278788qyk.13
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 03:56:50 -0700 (PDT)
Received: by 10.229.87.143 with SMTP id w15mr15659qcl.170.1305195971147; Thu,
12 May 2011 03:26:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.31.73 with HTTP; Thu, 12 May 2011 03:25:31 -0700 (PDT)
In-Reply-To: <17710363528.20110512130123@gameservice.ru>
References: <17710363528.20110512130123@gameservice.ru>
From: Vlad Galu <dudu@dudu.ro>
Date: Thu, 12 May 2011 12:25:31 +0200
Message-ID: <BANLkTim24BgYU=HsU_7mS_zFyv0j0BXCUA@mail.gmail.com>
To: Michael <michael@gameservice.ru>
Content-Type: text/plain; charset=KOI8-R
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 10:56:51 -0000
2011/5/12 Michael <michael@gameservice.ru>
> Hello.
>
> I'm running nginx in load balancing mode for java application with
> around 400 requests/second. For every request, nginx is doing a
> HTTP/1.0 connection without keep alive to jetty. Several
> times per minute this connection takes 3 seconds complete. I don't see
> 2 or 1 seconds response from upstream, only 3 seconds. Listen backlog is
> not
> overflowed.
>
> I searched for this delay in google, and found similar problem in Linux:
> http://kerneltrap.org/mailarchive/linux-net/2008/3/26/1264734/thread
> http://kerneltrap.org/mailarchive/linux-net/2008/2/4/713224/thread
>
> And Windows:
>
> http://stackoverflow.com/questions/1875151/delay-in-multiple-tcp-connections-from-java-to-the-same-machine/1927486#1927486
>
> Can you advice what should i tune in FreeBSD to fix this problem?
>
Hello Michael,
net.inet.tcp.finwait2_timeout and net.inet.tcp.fast_finwait2_recycle are
your friends.
--
Good, fast & cheap. Pick any two.
From owner-freebsd-net@FreeBSD.ORG Thu May 12 11:09:05 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 605761065670
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 11:09:05 +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 1FD0B8FC13
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 11:09:04 +0000 (UTC)
Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81])
by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 85D591702B;
Thu, 12 May 2011 14:49:39 +0400 (MSD)
Date: Thu, 12 May 2011 14:49:39 +0400
From: Maxim Dounin <mdounin@mdounin.ru>
To: Michael <michael@gameservice.ru>
Message-ID: <20110512104939.GS42265@mdounin.ru>
References: <17710363528.20110512130123@gameservice.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17710363528.20110512130123@gameservice.ru>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 11:09:05 -0000
Hello!
On Thu, May 12, 2011 at 01:01:23PM +0300, Michael wrote:
> I'm running nginx in load balancing mode for java application with
> around 400 requests/second. For every request, nginx is doing a
> HTTP/1.0 connection without keep alive to jetty. Several
> times per minute this connection takes 3 seconds complete. I don't see
> 2 or 1 seconds response from upstream, only 3 seconds. Listen backlog is not
> overflowed.
3 seconds delay usually indicate packet loss somewhere along the
path. You have to examine your network between nginx and your app
to find out where (and why) packets are lost.
Some basic steps on FreeBSD include looking though "netstat -id",
"netstat -s" output, "vmstat -z" output and your ethernet
controller stats via "sysctl dev.<driver>" (if any).
You may also want to check if you by accident have some statefull
firewall between nginx and backend. E.g. pf(4) known to drop
some packets when it aproaches limit on state table size. Check
"pfctl -s info" and friends if you are using pf.
Maxim Dounin
From owner-freebsd-net@FreeBSD.ORG Thu May 12 11:22:36 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 222BA106566C
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 11:22:36 +0000 (UTC)
(envelope-from prvs=1113d0acf6=killing@multiplay.co.uk)
Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23])
by mx1.freebsd.org (Postfix) with ESMTP id 97D288FC12
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 11:22:35 +0000 (UTC)
X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 12 May 2011 12:10:43 +0100
X-Spam-Processed: mail1.multiplay.co.uk, Thu, 12 May 2011 12:10:37 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
mail1.multiplay.co.uk
X-Spam-Level:
X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST
shortcircuit=ham autolearn=disabled version=3.2.5
Received: from r2d2 ([188.220.16.49])
by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23])
(MDaemon PRO v10.0.4) with ESMTP id md50013264492.msg
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 12:07:30 +0100
X-MDRemoteIP: 188.220.16.49
X-Return-Path: prvs=1113d0acf6=killing@multiplay.co.uk
X-Envelope-From: killing@multiplay.co.uk
X-MDaemon-Deliver-To: freebsd-net@freebsd.org
Message-ID: <6E72E86D69D444C98EFA193A23CCD994@multiplay.co.uk>
From: "Steven Hartland" <killing@multiplay.co.uk>
To: "Vlad Galu" <dudu@dudu.ro>,
"Michael" <michael@gameservice.ru>
References: <17710363528.20110512130123@gameservice.ru>
<BANLkTim24BgYU=HsU_7mS_zFyv0j0BXCUA@mail.gmail.com>
Date: Thu, 12 May 2011 12:03:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="KOI8-R"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 11:22:36 -0000
----- Original Message -----
From: "Vlad Galu" <dudu@dudu.ro>
> Hello Michael,
>
> net.inet.tcp.finwait2_timeout and net.inet.tcp.fast_finwait2_recycle are
> your friends.
You should only need this if the connection isn't being closed down cleanly
from both ends.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
From owner-freebsd-net@FreeBSD.ORG Thu May 12 13:50:09 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 37FF5106566C
for <freebsd-net@hub.freebsd.org>; Thu, 12 May 2011 13:50: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 0C5F78FC08
for <freebsd-net@hub.freebsd.org>; Thu, 12 May 2011 13:50: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 p4CDo8Vf083365
for <freebsd-net@freefall.freebsd.org>; Thu, 12 May 2011 13:50:08 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4CDo8Nj083364;
Thu, 12 May 2011 13:50:08 GMT (envelope-from gnats)
Date: Thu, 12 May 2011 13:50:08 GMT
Message-Id: <201105121350.p4CDo8Nj083364@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Alessandro Dellavedova <alessandro.dellavedova@ifom-ieo-campus.it>
Cc:
Subject: Re: bin/136994: [patch] ifconfig(8) print carp mac address
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Alessandro Dellavedova <alessandro.dellavedova@ifom-ieo-campus.it>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 13:50:09 -0000
The following reply was made to PR bin/136994; it has been noted by GNATS.
From: Alessandro Dellavedova <alessandro.dellavedova@ifom-ieo-campus.it>
To: bug-followup@FreeBSD.org,
Artis.Caune@gmail.com
Cc:
Subject: Re: bin/136994: [patch] ifconfig(8) print carp mac address
Date: Thu, 12 May 2011 15:22:13 +0200
I second this, it would be really nice to see the virtual MAC address of =
the CARP interfaces.
Any chance to see it committed anytime soon ?
Regards,
Alessandro
From owner-freebsd-net@FreeBSD.ORG Thu May 12 14:36:27 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2535B106567A;
Thu, 12 May 2011 14:36:27 +0000 (UTC)
(envelope-from linimon@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
[IPv6:2001:4f8:fff6::28])
by mx1.freebsd.org (Postfix) with ESMTP id EF00A8FC1F;
Thu, 12 May 2011 14:36:26 +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 p4CEaQYt028634;
Thu, 12 May 2011 14:36:26 GMT
(envelope-from linimon@freefall.freebsd.org)
Received: (from linimon@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4CEaQWK028630;
Thu, 12 May 2011 14:36:26 GMT (envelope-from linimon)
Date: Thu, 12 May 2011 14:36:26 GMT
Message-Id: <201105121436.p4CEaQWK028630@freefall.freebsd.org>
To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
From: linimon@FreeBSD.org
Cc:
Subject: Re: kern/156978: [lagg][patch] Take lagg rlock before checking flags
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 14:36:27 -0000
Synopsis: [lagg][patch] Take lagg rlock before checking flags
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu May 12 14:36:20 UTC 2011
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=156978
From owner-freebsd-net@FreeBSD.ORG Thu May 12 14:31:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 882E9106564A
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 14:31:10 +0000 (UTC)
(envelope-from sample@email.cz)
Received: from mxl1.seznam.cz (mxl1.seznam.cz [77.75.72.44])
by mx1.freebsd.org (Postfix) with ESMTP id 149588FC12
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 14:31:09 +0000 (UTC)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=email.cz;
h=To:Date:From:Received:Subject:Content-Transfer-Encoding:Content-Type:Mime-Version:Message-Id:X-Country:X-Abuse:X-Seznam-User:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys;
b=SARZ14k7kWxiNyCexsVr4qCRXYCm1xLpCNaOMLat11yWz4esgQvu5IE4mI29nfVAM
fYijJPe9WnSKqIinvA7XrhM+SFENByPh/irWuxgoXjxW9AsjBY9bvXWH39nWPuoQZM2
tDdyp7hCTAzsVUVKthYstHxhxRUdc0hFHDhArCo=
To: freebsd-net@freebsd.org
Date: Thu, 12 May 2011 16:20:03 +0200 (CEST)
From: sample@email.cz
Received: from hosting.kcorp.sk (hosting.kcorp.sk [213.81.159.83]) by
email.seznam.cz (Email.Seznam.cz) with HTTP for sample@email.cz;
Thu, 12 May 2011 16:20:02 +0200 (CEST)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Message-Id: <54805.960.2090-2700-1520430731-1305210003@email.cz>
X-Country: SK
X-Abuse: abuse@seznam.cz
X-Seznam-User: sample@email.cz
X-Virus-Info: clean
X-Seznam-SPF: neutral
X-Seznam-DomainKeys: neutral
X-Mailman-Approved-At: Thu, 12 May 2011 15:39:19 +0000
Subject: FreeBSD 7 and FreeBSD 8 OpenVPN problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 14:31:10 -0000
Hi,
I have a problem with the different behavior of OpenVPN under FreeBSD 7 and FreeBSD 8. Problem is as follows. I have created an OpenVPN server and IPSEC tunnel. I have a client which is connecting via OpenVPN to LAN.
This is working properly (client is able to reach all computers inside LAN and their services) in both cases - FreeBSD 7 and 8. The problem occurs when I want to connect (e.g. PING) the LAN interface of FreeBSD - for example "em0" with IP 192.168.1.1.
On FreeBSD 7 (server) when I run tcpdump, I see packets coming from the OpenVPN network on the FreeBSD LAN interface ("em0" with IP 192.168.1.1) - everything works as should.
On FreeBSD 8 (server) - the ping from the client to LAN interface "em0" is working (I get reply from ip 192.168.1.1 (em0) on client PC), but when I run tcpdump on the LAN interface (192.168.1.1 - em0), I don't see any ICMP packets. (I wonder, what is answering me then?).
I found out the problem when I needed to configure NAT from OpenVPN to IPsec network. The NAT (PF) is working on FreeBSD 7.3! So the OpenVPN client is able to access the servers behind IPsec.
When I tried to do the same for FreeBSD 8.2 (8.1), It does not work! It's simple, because the packet does not reach the interface, NAT does not apply.
I've tried it on two machines with FreeBSD 7.3 and FreeBSD 8.1 and 8.2.
Did you meet that kind of problem?
From owner-freebsd-net@FreeBSD.ORG Thu May 12 16:09:02 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 31DE41065672
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 16:09:02 +0000 (UTC)
(envelope-from ptyll@nitronet.pl)
Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27])
by mx1.freebsd.org (Postfix) with ESMTP id E0CBA8FC1B
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 16:09:01 +0000 (UTC)
Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.75 (FreeBSD))
(envelope-from <ptyll@nitronet.pl>) id 1QKXrr-000ArZ-4J
for freebsd-net@freebsd.org; Thu, 12 May 2011 17:31:59 +0200
Date: Thu, 12 May 2011 17:29:25 +0200
From: Pawel Tyll <ptyll@nitronet.pl>
X-Priority: 3 (Normal)
Message-ID: <1562548807.20110512172925@nitronet.pl>
To: Luigi Rizzo <rizzo@iet.unipi.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Nitronet.pl
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: ptyll@nitronet.pl
X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false
Cc: Brandon Gooch <jamesbrandongooch@gmail.com>, freebsd-ipfw@freebsd.org,
Jack Vogel <jfvogel@gmail.com>, freebsd-net@freebsd.org
Subject: Re:
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 16:09:02 -0000
Hi guys and lists,
Hope I won't bring bad luck on myself by posting this too early, but
here goes.
Apparently during the last 3 weeks my bi-weekly crashing problem has
been solved. That, or world built without openssl was the reason.
$ uprecords
# Uptime | System Boot up
----------------------------+---------------------------------------------------
-> 1 18 days, 09:06:00 | FreeBSD 8.2-STABLE Sun Apr 24 08:22:05 2011
2 16 days, 07:06:18 | FreeBSD 8.2-STABLE Tue Apr 5 06:13:14 2011
3 15 days, 08:27:58 | FreeBSD 8.2-STABLE Sun Mar 20 20:42:15 2011
4 15 days, 05:42:23 | FreeBSD 8.2-PRERELEASE Wed Dec 22 16:19:55 2010
5 14 days, 22:31:42 | FreeBSD 8.2-PRERELEASE Sun Jan 9 03:07:59 2011
6 14 days, 05:25:46 | FreeBSD 8.2-PRERELEASE Mon Jan 24 01:55:34 2011
7 13 days, 15:04:37 | FreeBSD 8.2-STABLE Mon Mar 7 05:34:55 2011
8 13 days, 00:49:00 | FreeBSD 8.2-PRERELEASE Sat Feb 19 23:47:06 2011
9 12 days, 15:42:45 | FreeBSD 8.2-PRERELEASE Mon Feb 7 07:30:07 2011
10 2 days, 18:57:20 | FreeBSD 8.2-STABLE Thu Apr 21 13:22:53 2011
----------------------------+---------------------------------------------------
NewRec 2 days, 01:59:41 | since Tue May 10 15:28:23 2011
up 140 days, 13:41:21 | since Wed Dec 22 16:19:55 2010
down 0 days, -10:-26:-4 | since Wed Dec 22 16:19:55 2010
%up 100.311 | since Wed Dec 22 16:19:55 2010
Cheers. :)
From owner-freebsd-net@FreeBSD.ORG Thu May 12 16:21:54 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 8394F106566B
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 16:21:54 +0000 (UTC)
(envelope-from lacombar@gmail.com)
Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com
[209.85.160.182])
by mx1.freebsd.org (Postfix) with ESMTP id 3F9798FC0A
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 16:21:54 +0000 (UTC)
Received: by gyg13 with SMTP id 13so732610gyg.13
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 09:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=QjvhUvpe/w61P1BN1CwJ7eEx3TZCn0+ABk8IGVjysQQ=;
b=wbrxz6aE9Yfu4m1ZvdZ42lZQZ3I/yWKQJ+BbPglifLaaXicbnafbPKDG5VUGQy/Nf7
d7ILfo+UwSVngj8RDU2/5DgFUUmg18kn+DOyvXlbGi1E2Agl51pL8x+e3iqf1kCWLeDY
AyU4oa4lZ6zKy3aaWbHW2GDQy6Yh4bgOmY1ow=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=WOP0nvoL/IpQfnatd59TyzkrlhTDVr42UF4e77ila+NVj1l4TvL38Xhx8J1V53KCnK
EajjlCEfev2iBNIgclHeqd8WUFGlU/oyb5kEZNjgDScj+BCKz4e0E8mc9S/T4z38M/an
pkF/uvPEpZU9t5oKiFkARdlemoHrZZ/ijfxUE=
MIME-Version: 1.0
Received: by 10.42.152.199 with SMTP id j7mr453892icw.404.1305217313445; Thu,
12 May 2011 09:21:53 -0700 (PDT)
Received: by 10.42.178.70 with HTTP; Thu, 12 May 2011 09:21:53 -0700 (PDT)
In-Reply-To: <54805.960.2090-2700-1520430731-1305210003@email.cz>
References: <54805.960.2090-2700-1520430731-1305210003@email.cz>
Date: Thu, 12 May 2011 12:21:53 -0400
Message-ID: <BANLkTik8RKD=zXMHCMGCxrvbaL9bPgLn7g@mail.gmail.com>
From: Arnaud Lacombe <lacombar@gmail.com>
To: sample@email.cz
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: freebsd-net@freebsd.org
Subject: Re: FreeBSD 7 and FreeBSD 8 OpenVPN problem
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 16:21:54 -0000
Hi,
On Thu, May 12, 2011 at 10:20 AM, <sample@email.cz> wrote:
> Hi,
>
> I have a problem with the different behavior of OpenVPN under FreeBSD 7 a=
nd FreeBSD 8. Problem is as follows. I have created an OpenVPN server and I=
PSEC tunnel. I have a client which is connecting via OpenVPN to LAN.
>
> This is working properly (client is able to reach all computers inside LA=
N and their services) in both cases - FreeBSD 7 and 8. The problem occurs w=
hen I want to connect (e.g. PING) the LAN interface of FreeBSD - for exampl=
e "em0" with IP 192.168.1.1.
>
> On FreeBSD 7 (server) when I run tcpdump, I see packets coming from the O=
penVPN network on the FreeBSD LAN interface ("em0" with IP 192.168.1.1) - e=
verything works as should.
>
> On FreeBSD 8 (server) - the ping from the client to LAN interface "em0" i=
s working (I get reply from ip 192.168.1.1 (em0) on client PC), but when I =
run tcpdump on the LAN interface (192.168.1.1 - em0), I don't see any ICMP =
packets. (I wonder, what is answering me then?).
>
I wonder if this does not have to do with how OpenVPN re-inject packet
in the kernel, what path it follows, and where the bpf hook are. I am
not sure of what would be expected when sniffing on an interface.
Would you intend to see only the traffic going in and out the physical
interface ? or would you intend to see all the the traffic matching a
parameter associated with an interface (IP address, ...) ?
You should also have an internal route trough `lo0' for local traffic.
I found out that even without that route, local traffic go trough
`lo0', with all the consequences, like IPv4 checksum not being
computed [which does not even seem to be tunable btw.].
- Arnaud
From owner-freebsd-net@FreeBSD.ORG Thu May 12 20:42:42 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 EFB8D1065674
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 20:42:42 +0000 (UTC)
(envelope-from michael@gameservice.ru)
Received: from mail.mzlab.net (mail.mzlab.net [66.197.153.197])
by mx1.freebsd.org (Postfix) with ESMTP id CC42D8FC0C
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 20:42:42 +0000 (UTC)
Date: Thu, 12 May 2011 23:42:36 +0300
From: Michael <michael@gameservice.ru>
X-Priority: 3 (Normal)
Message-ID: <1419802131.20110512234236@gameservice.ru>
To: Vlad Galu <dudu@dudu.ro>
In-Reply-To: <BANLkTim24BgYU=HsU_7mS_zFyv0j0BXCUA@mail.gmail.com>
References: <17710363528.20110512130123@gameservice.ru>
<BANLkTim24BgYU=HsU_7mS_zFyv0j0BXCUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 20:42:43 -0000
2011/5/12 Vlad Galu <dudu@dudu.ro>
VG> net.inet.tcp.finwait2_timeout and
VG> net.inet.tcp.fast_finwait2_recycle are
VG> your friends.
net.inet.tcp.fast_finwait2_recycle: 1
net.inet.tcp.finwait2_timeout: 60000
I will try to tune finwat2_timeout, but i don't see a lot of
FIN_WAIT in netstat -na (around 300)
Michael
From owner-freebsd-net@FreeBSD.ORG Thu May 12 20:50:33 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 BB77F106564A
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 20:50:33 +0000 (UTC)
(envelope-from michael@gameservice.ru)
Received: from mail.mzlab.net (mail.mzlab.net [66.197.153.197])
by mx1.freebsd.org (Postfix) with ESMTP id 8EDA18FC15
for <freebsd-net@freebsd.org>; Thu, 12 May 2011 20:50:33 +0000 (UTC)
Date: Thu, 12 May 2011 23:50:22 +0300
From: Michael <michael@gameservice.ru>
X-Priority: 3 (Normal)
Message-ID: <1069574542.20110512235022@gameservice.ru>
To: Maxim Dounin <mdounin@mdounin.ru>
In-Reply-To: <20110512104939.GS42265@mdounin.ru>
References: <17710363528.20110512130123@gameservice.ru>
<20110512104939.GS42265@mdounin.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2011 20:50:33 -0000
MD> 3 seconds delay usually indicate packet loss somewhere along the
MD> path. You have to examine your network between nginx and your app
MD> to find out where (and why) packets are lost.
I don't think i have packet loss, traffic is going via loopback
MD> Some basic steps on FreeBSD include looking though "netstat -id",
MD> "netstat -s" output, "vmstat -z" output and your ethernet
MD> controller stats via "sysctl dev.<driver>" (if any).
I don't see dropped packets on lo0 with netstat -id
What should i see in "netstat -s" and "vmstat -z"?
MD> You may also want to check if you by accident have some statefull
MD> firewall between nginx and backend.
I have only ipfw rules, and the first rule is accepting local
traffic: 00005 8211184509 4547370329265 allow ip from me to me
can this be the problem?
Michael
From owner-freebsd-net@FreeBSD.ORG Fri May 13 08:10:12 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 4EF4E1065670
for <freebsd-net@hub.freebsd.org>; Fri, 13 May 2011 08:10:12 +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 3EE7F8FC08
for <freebsd-net@hub.freebsd.org>; Fri, 13 May 2011 08:10:12 +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 p4D8AClb020751
for <freebsd-net@freefall.freebsd.org>; Fri, 13 May 2011 08:10:12 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4D8AC7B020750;
Fri, 13 May 2011 08:10:12 GMT (envelope-from gnats)
Date: Fri, 13 May 2011 08:10:12 GMT
Message-Id: <201105130810.p4D8AC7B020750@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: David Xu <davidxu@freebsd.org>
Cc:
Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: David Xu <davidxu@freebsd.org>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 08:10:12 -0000
The following reply was made to PR kern/156493; it has been noted by GNATS.
From: David Xu <davidxu@freebsd.org>
To: bug-followup@freebsd.org, cy6erGn0m@gmail.com
Cc:
Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds
Date: Fri, 13 May 2011 16:08:57 +0800
On CURRENT, I have same problem, dmesg shows my machine has following
hardware configuration:
mskc0: <Marvell Yukon 88E8057 Gigabit Ethernet> port 0xe800-0xe8ff mem
0xfebfc000-0xfebfffff irq 17 at device 0.0 on pci3
msk0: <Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00> on
mskc0
msk0: Ethernet address: 90:fb:a6:9b:bd:c5
miibus0: <MII bus> on msk0
e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto,
auto-flow
I have to disable workaround in if_msk.c to make it work:
Index: dev/msk/if_msk.c
===================================================================
--- dev/msk/if_msk.c (revision 221829)
+++ dev/msk/if_msk.c (working copy)
@@ -1228,7 +1228,7 @@
case CHIP_ID_YUKON_EC_U:
case CHIP_ID_YUKON_EX:
case CHIP_ID_YUKON_FE_P:
- case CHIP_ID_YUKON_UL_2:
+// case CHIP_ID_YUKON_UL_2:
case CHIP_ID_YUKON_OPT:
CSR_WRITE_2(sc, B0_CTST, Y2_HW_WOL_OFF);
From owner-freebsd-net@FreeBSD.ORG Fri May 13 10:54:45 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 46B881065673
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 10:54:45 +0000 (UTC)
(envelope-from cy6ergn0m@gmail.com)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com
[209.85.210.182])
by mx1.freebsd.org (Postfix) with ESMTP id 0DBA98FC12
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 10:54:44 +0000 (UTC)
Received: by iyj12 with SMTP id 12so2780351iyj.13
for <multiple recipients>; Fri, 13 May 2011 03:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=HtbqyXiIEDM9/YP82EP2y4b3EoQZrhJStpzykfxpmfM=;
b=pds8IHLGNc74/YI8ekzEbJa4rT3M+4rh8orYML7OOBncRCLrVFBiEf9nyQn4OVeS2o
WALylkYgoCgZ2Gtt0vXI50cEVQN/RxP+hRjLaYH0GHh3qCU8sV7nu/wy/0Quugg0wXFI
t0Knwgq6olL3HoNU8TG9gQmr7WQQmlniurV6E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=fA/uv+1qIVqOFMwCgfZ/ETeWe7b16tzWy1xJxxUcavh+OTLINA+70j5fCsQcIxjSzt
aZbh1ix9exFR7q/WksEQCuAGFvJqhTuwvQ8CxHIvbO7s3MFGtT8P91DaHFNRa22IS68J
gcMrgkMiN61BUs7SqauJngQaBmnW7wQ53zPh8=
MIME-Version: 1.0
Received: by 10.231.208.142 with SMTP id gc14mr968546ibb.115.1305284084109;
Fri, 13 May 2011 03:54:44 -0700 (PDT)
Received: by 10.231.32.72 with HTTP; Fri, 13 May 2011 03:54:44 -0700 (PDT)
In-Reply-To: <201105130810.p4D8AC7B020750@freefall.freebsd.org>
References: <201105130810.p4D8AC7B020750@freefall.freebsd.org>
Date: Fri, 13 May 2011 14:54:44 +0400
Message-ID: <BANLkTimqZ+SYJhWkgqRwW3kcZr+sMKsu9w@mail.gmail.com>
From: cyberGn0m <cy6ergn0m@gmail.com>
To: David Xu <davidxu@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-net@freebsd.org
Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 10:54:45 -0000
I also found that this bug is applicable to latest Linux kernels but not to
older kernel versions. So if something was ported from Linux.. perhaps it
affected FreeBSD too.
2011/5/13 David Xu <davidxu@freebsd.org>
> The following reply was made to PR kern/156493; it has been noted by GNAT=
S.
>
> From: David Xu <davidxu@freebsd.org>
> To: bug-followup@freebsd.org, cy6erGn0m@gmail.com
> Cc:
> Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few
> seconds
> Date: Fri, 13 May 2011 16:08:57 +0800
>
> On CURRENT, I have same problem, dmesg shows my machine has following
> hardware configuration:
>
> mskc0: <Marvell Yukon 88E8057 Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfebfc000-0xfebfffff irq 17 at device 0.0 on pci3
> msk0: <Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00> on
> mskc0
> msk0: Ethernet address: 90:fb:a6:9b:bd:c5
> miibus0: <MII bus> on msk0
> e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto,
> auto-flow
>
>
> I have to disable workaround in if_msk.c to make it work:
>
> Index: dev/msk/if_msk.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- dev/msk/if_msk.c (revision 221829)
> +++ dev/msk/if_msk.c (working copy)
> @@ -1228,7 +1228,7 @@
> case CHIP_ID_YUKON_EC_U:
> case CHIP_ID_YUKON_EX:
> case CHIP_ID_YUKON_FE_P:
> - case CHIP_ID_YUKON_UL_2:
> +// case CHIP_ID_YUKON_UL_2:
> case CHIP_ID_YUKON_OPT:
> CSR_WRITE_2(sc, B0_CTST, Y2_HW_WOL_OFF);
>
>
> _______________________________________________
> 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"
>
--=20
-----------------------------------------------------------------
=D0=92=D1=81=D0=B5=D0=B3=D0=BE =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=
=D0=B5=D0=B3=D0=BE
<y6erGn0m.
From owner-freebsd-net@FreeBSD.ORG Fri May 13 11:17:23 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 675E0106564A
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 11:17:23 +0000 (UTC)
(envelope-from dudu@dudu.ro)
Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com
[209.85.216.54])
by mx1.freebsd.org (Postfix) with ESMTP id 1D58F8FC0C
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 11:17:22 +0000 (UTC)
Received: by qwc9 with SMTP id 9so1638635qwc.13
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 04:17:22 -0700 (PDT)
Received: by 10.229.88.198 with SMTP id b6mr1015158qcm.208.1305285442198; Fri,
13 May 2011 04:17:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.31.73 with HTTP; Fri, 13 May 2011 04:16:42 -0700 (PDT)
In-Reply-To: <AANLkTi=mO65OoDTcz2gxpsB075-+WdjKTFe9Chm_MY=Y@mail.gmail.com>
References: <AANLkTimSs48ftRv8oh1wTwMEpgN1Ny3B1ahzfS=AbML_@mail.gmail.com>
<AANLkTimfh3OdXOe1JFo5u6JypcLrcWKv2WpSu8Uv-tgv@mail.gmail.com>
<AANLkTi=rWobA40UtCTSeOzEz65TMw8vfCcxtMWBBme+u@mail.gmail.com>
<20110313011632.GA1621@michelle.cdnetworks.com>
<AANLkTi=dci-cKVuvpXCs40u8u=5LGzey6s5-jYXEPM7s@mail.gmail.com>
<20110330171023.GA8601@michelle.cdnetworks.com>
<AANLkTi=mO65OoDTcz2gxpsB075-+WdjKTFe9Chm_MY=Y@mail.gmail.com>
From: Vlad Galu <dudu@dudu.ro>
Date: Fri, 13 May 2011 13:16:42 +0200
Message-ID: <BANLkTinrZbhc8p=OLCJdAfdi-d17s2nR_A@mail.gmail.com>
To: freebsd-net@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Subject: Re: bge(4) on RELENG_8 mbuf cluster starvation
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 11:17:23 -0000
On Wed, Mar 30, 2011 at 7:17 PM, Vlad Galu <dudu@dudu.ro> wrote:
>
>
> On Wed, Mar 30, 2011 at 7:10 PM, YongHyeon PYUN <pyunyh@gmail.com> wrote:
>
>> On Wed, Mar 30, 2011 at 05:55:47PM +0200, Vlad Galu wrote:
>> > On Sun, Mar 13, 2011 at 2:16 AM, YongHyeon PYUN <pyunyh@gmail.com>
>> wrote:
>> >
>> > > On Sat, Mar 12, 2011 at 09:17:28PM +0100, Vlad Galu wrote:
>> > > > On Sat, Mar 12, 2011 at 8:53 PM, Arnaud Lacombe <lacombar@gmail.com
>> >
>> > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > On Sat, Mar 12, 2011 at 4:03 AM, Vlad Galu <dudu@dudu.ro> wrote:
>> > > > > > Hi folks,
>> > > > > >
>> > > > > > On a fairly busy recent (r219010) RELENG_8 machine I keep
>> getting
>> > > > > > -- cut here --
>> > > > > > 1096/1454/2550 mbufs in use (current/cache/total)
>> > > > > > 1035/731/1766/262144 mbuf clusters in use
>> (current/cache/total/max)
>> > > > > > 1035/202 mbuf+clusters out of packet secondary zone in use
>> > > > > (current/cache)
>> > > > > > 0/117/117/12800 4k (page size) jumbo clusters in use
>> > > > > > (current/cache/total/max)
>> > > > > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
>> > > > > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
>> > > > > > 2344K/2293K/4637K bytes allocated to network
>> (current/cache/total)
>> > > > > > 0/70128196/37726935 requests for mbufs denied
>> > > > > (mbufs/clusters/mbuf+clusters)
>> > > > > > ^^^^^^^^^^^^^^^^^^^^^
>> > > > > > -- and here --
>> > > > > >
>> > > > > > kern.ipc.nmbclusters is set to 131072. Other settings:
>> > > > > no, netstat(8) says 262144.
>> > > > >
>> > > > >
>> > > > Heh, you're right, I forgot I'd doubled it a while ago. Wrote that
>> from
>> > > the
>> > > > top of my head.
>> > > >
>> > > >
>> > > > > Maybe can you include $(sysctl dev.bge) ? Might be useful.
>> > > > >
>> > > > > - Arnaud
>> > > > >
>> > > >
>> > > > Sure:
>> > >
>> > > [...]
>> > >
>> > > > dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller,
>> ASIC
>> > > rev.
>> > > > 0x004101
>> > > > dev.bge.1.%driver: bge
>> > > > dev.bge.1.%location: slot=0 function=0
>> > > > dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1014
>> > > > subdevice=0x02c6 class=0x020000
>> > > > dev.bge.1.%parent: pci5
>> > > > dev.bge.1.forced_collapse: 2
>> > > > dev.bge.1.forced_udpcsum: 0
>> > > > dev.bge.1.stats.FramesDroppedDueToFilters: 0
>> > > > dev.bge.1.stats.DmaWriteQueueFull: 0
>> > > > dev.bge.1.stats.DmaWriteHighPriQueueFull: 0
>> > > > dev.bge.1.stats.NoMoreRxBDs: 680050
>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > This indicates bge(4) encountered RX buffer shortage. Perhaps
>> > > bge(4) couldn't fill new RX buffers for incoming frames due to
>> > > other system activities.
>> > >
>> > > > dev.bge.1.stats.InputDiscards: 228755931
>> > >
>> > > This counter indicates number of frames discarded due to RX buffer
>> > > shortage. bge(4) discards received frame if it failed to allocate
>> > > new RX buffer such that InputDiscards is normally higher than
>> > > NoMoreRxBDs.
>> > >
>> > > > dev.bge.1.stats.InputErrors: 49080818
>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > Something is wrong here. Too many frames were classified as error
>> > > frames. You may see poor RX performance.
>> > >
>> > > > dev.bge.1.stats.RecvThresholdHit: 0
>> > > > dev.bge.1.stats.rx.ifHCInOctets: 2095148839247
>> > > > dev.bge.1.stats.rx.Fragments: 47887706
>> > > > dev.bge.1.stats.rx.UnicastPkts: 32672557601
>> > > > dev.bge.1.stats.rx.MulticastPkts: 1218
>> > > > dev.bge.1.stats.rx.BroadcastPkts: 2
>> > > > dev.bge.1.stats.rx.FCSErrors: 2822217
>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > > FCS errors are too high. Please check cabling again(I'm assuming
>> > > the controller is not broken here). I think you can use vendor's
>> > > diagnostic tools to verify this.
>> > >
>> > > > dev.bge.1.stats.rx.AlignmentErrors: 0
>> > > > dev.bge.1.stats.rx.xonPauseFramesReceived: 0
>> > > > dev.bge.1.stats.rx.xoffPauseFramesReceived: 0
>> > > > dev.bge.1.stats.rx.ControlFramesReceived: 0
>> > > > dev.bge.1.stats.rx.xoffStateEntered: 0
>> > > > dev.bge.1.stats.rx.FramesTooLong: 0
>> > > > dev.bge.1.stats.rx.Jabbers: 0
>> > > > dev.bge.1.stats.rx.UndersizePkts: 0
>> > > > dev.bge.1.stats.tx.ifHCOutOctets: 48751515826
>> > > > dev.bge.1.stats.tx.Collisions: 0
>> > > > dev.bge.1.stats.tx.XonSent: 0
>> > > > dev.bge.1.stats.tx.XoffSent: 0
>> > > > dev.bge.1.stats.tx.InternalMacTransmitErrors: 0
>> > > > dev.bge.1.stats.tx.SingleCollisionFrames: 0
>> > > > dev.bge.1.stats.tx.MultipleCollisionFrames: 0
>> > > > dev.bge.1.stats.tx.DeferredTransmissions: 0
>> > > > dev.bge.1.stats.tx.ExcessiveCollisions: 0
>> > > > dev.bge.1.stats.tx.LateCollisions: 0
>> > > > dev.bge.1.stats.tx.UnicastPkts: 281039183
>> > > > dev.bge.1.stats.tx.MulticastPkts: 0
>> > > > dev.bge.1.stats.tx.BroadcastPkts: 1153
>> > > > -- and here --
>> > > >
>> > > > And now, that I remembered about this as well:
>> > > > -- cut here --
>> > > > Name Mtu Network Address Ipkts Ierrs Idrop
>> Opkts
>> > > > Oerrs Coll
>> > > > bge1 1500 <Link#2> 00:11:25:22:0d:ed 32321767025 278517070
>> > > 37726837
>> > > > 281068216 0 0
>> > > > -- and here --
>> > > > The colo provider changed my cable a couple of times so I'd not
>> blame it
>> > > on
>> > > > that. Unfortunately, I don't have access to the port statistics on
>> the
>> > > > switch. Running netstat with -w1 yields between 0 and 4
>> errors/second.
>> > > >
>> > >
>> > > Hardware MAC counters still show high number of FCS errors. The
>> > > service provider should have to check possible cabling issues on
>> > > the port of the switch.
>> > >
>> >
>> > After swapping cables and moving the NIC into another switch, there are
>> some
>> > improvements. However:
>> > -- cut here --
>> > dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC
>> rev.
>> > 0x004101
>> > dev.bge.1.%driver: bge
>> > dev.bge.1.%location: slot=0 function=0
>> > dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1014
>> > subdevice=0x02c6 class=0x020000
>> > dev.bge.1.%parent: pci5
>> > dev.bge.1.forced_collapse: 0
>> > dev.bge.1.forced_udpcsum: 0
>> > dev.bge.1.stats.FramesDroppedDueToFilters: 0
>> > dev.bge.1.stats.DmaWriteQueueFull: 0
>> > dev.bge.1.stats.DmaWriteHighPriQueueFull: 0
>> > dev.bge.1.stats.NoMoreRxBDs: 243248 <- this
>> > dev.bge.1.stats.InputDiscards: 9945500
>> > dev.bge.1.stats.InputErrors: 0
>>
>> There are still discarded frames but I believe it's not related
>> with any cabling issues since you don't have FCS or alignment
>> errors.
>>
>> > dev.bge.1.stats.RecvThresholdHit: 0
>> > dev.bge.1.stats.rx.ifHCInOctets: 36697296701
>> > dev.bge.1.stats.rx.Fragments: 0
>> > dev.bge.1.stats.rx.UnicastPkts: 549334370
>> > dev.bge.1.stats.rx.MulticastPkts: 113638
>> > dev.bge.1.stats.rx.BroadcastPkts: 0
>> > dev.bge.1.stats.rx.FCSErrors: 0
>> > dev.bge.1.stats.rx.AlignmentErrors: 0
>> > dev.bge.1.stats.rx.xonPauseFramesReceived: 0
>> > dev.bge.1.stats.rx.xoffPauseFramesReceived: 0
>> > dev.bge.1.stats.rx.ControlFramesReceived: 0
>> > dev.bge.1.stats.rx.xoffStateEntered: 0
>> > dev.bge.1.stats.rx.FramesTooLong: 0
>> > dev.bge.1.stats.rx.Jabbers: 0
>> > dev.bge.1.stats.rx.UndersizePkts: 0
>> > dev.bge.1.stats.tx.ifHCOutOctets: 10578000636
>> > dev.bge.1.stats.tx.Collisions: 0
>> > dev.bge.1.stats.tx.XonSent: 0
>> > dev.bge.1.stats.tx.XoffSent: 0
>> > dev.bge.1.stats.tx.InternalMacTransmitErrors: 0
>> > dev.bge.1.stats.tx.SingleCollisionFrames: 0
>> > dev.bge.1.stats.tx.MultipleCollisionFrames: 0
>> > dev.bge.1.stats.tx.DeferredTransmissions: 0
>> > dev.bge.1.stats.tx.ExcessiveCollisions: 0
>> > dev.bge.1.stats.tx.LateCollisions: 0
>> > dev.bge.1.stats.tx.UnicastPkts: 64545266
>> > dev.bge.1.stats.tx.MulticastPkts: 0
>> > dev.bge.1.stats.tx.BroadcastPkts: 313
>> >
>> > and
>> > 0/1710531/2006005 requests for mbufs denied
>> (mbufs/clusters/mbuf+clusters)
>> > -- and here --
>> >
>> > I'll start gathering some stats/charts on this host to see if I can
>> > correlate the starvation with other system events.
>> >
>>
>> Now MAC statistics counter show no abnormal things which in turn
>> indicates the mbuf starvation came from other issues. The next
>> thing is to identify which process or kernel subsystem consumes a
>> lot of mbuf clusters.
>>
>>
> Thanks for the feedback. Oh, there is a BPF consumer listening on bge1.
> After noticing
> http://www.mail-archive.com/freebsd-net@freebsd.org/msg25685.html, I
> decided to shut it down for a while. It's pretty weird, my BPF buffer size
> is set to 4MB and traffic on that interface is nowhere near that high. I'll
> get back as soon as I have new data.
>
>
>> >
>> >
>> > > However this does not explain why you have large number of mbuf
>> > > cluster allocation failure. The only wild guess I have at this
>> > > moment is some process or kernel subsystems are too slow to release
>> > > allocated mbuf clusters. Did you check various system activities
>> > > while seeing the issue?
>> > >
>>
>
>
>
> --
> Good, fast & cheap. Pick any two.
>
I've finally managed to see what triggers the symptom. It's a SYN flood.
Tweaking the syncache and disabling PF made no measurable difference. What
is odd is that the clock swi starts eating up more than 50% of the CPU. I
tried both ACPI-fast and TSC. The machine is UP, so when the clock swi takes
50% of the CPU and the netisr swi takes another 50%, there isn't much CPU
time left for user processes.
--
Good, fast & cheap. Pick any two.
From owner-freebsd-net@FreeBSD.ORG Fri May 13 13:01:57 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 287EB106566B
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 13:01:57 +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 D6FBF8FC17
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 13:01:56 +0000 (UTC)
Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81])
by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 0B76117020;
Fri, 13 May 2011 17:01:54 +0400 (MSD)
Date: Fri, 13 May 2011 17:01:54 +0400
From: Maxim Dounin <mdounin@mdounin.ru>
To: Michael <michael@gameservice.ru>
Message-ID: <20110513130154.GV42265@mdounin.ru>
References: <17710363528.20110512130123@gameservice.ru>
<20110512104939.GS42265@mdounin.ru>
<1069574542.20110512235022@gameservice.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1069574542.20110512235022@gameservice.ru>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: freebsd-net@freebsd.org
Subject: Re: Random TCP 3 second delay
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 13:01:57 -0000
Hello!
On Thu, May 12, 2011 at 11:50:22PM +0300, Michael wrote:
>
> MD> 3 seconds delay usually indicate packet loss somewhere along the
> MD> path. You have to examine your network between nginx and your app
> MD> to find out where (and why) packets are lost.
> I don't think i have packet loss, traffic is going via loopback
Packet loss is quite possible over loopback as well, though it's
usually caused by some resource shortage or policy rules in
action.
BTW, please make sure you don't have net.inet.tcp.nolocaltimewait
set.
> MD> Some basic steps on FreeBSD include looking though "netstat -id",
> MD> "netstat -s" output, "vmstat -z" output and your ethernet
> MD> controller stats via "sysctl dev.<driver>" (if any).
> I don't see dropped packets on lo0 with netstat -id
> What should i see in "netstat -s" and "vmstat -z"?
In netstat - look for various drops and overflows, most notably
syncache and others tcp-related. In vmstat -z - look for
allocation failures and/or full zones, most notably mbufs and
other tcp-related zones.
> MD> You may also want to check if you by accident have some statefull
> MD> firewall between nginx and backend.
> I have only ipfw rules, and the first rule is accepting local
> traffic: 00005 8211184509 4547370329265 allow ip from me to me
>
> can this be the problem?
AFAIK it shouldn't, but you may want to check sysctl
net.inet.ip.fw.dyn_count and net.inet.ip.fw.dyn_max sysctl's
anyway.
Maxim Dounin
From owner-freebsd-net@FreeBSD.ORG Fri May 13 13:32:44 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 D3EC3106566B;
Fri, 13 May 2011 13:32:44 +0000 (UTC) (envelope-from rj@cyclaero.com)
Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de
[IPv6:2a01:238:20a:202:53f0::1])
by mx1.freebsd.org (Postfix) with ESMTP id E43C18FC12;
Fri, 13 May 2011 13:32:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1305293562; l=9914;
s=domk; d=cyclaero.com;
h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:
Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH;
bh=RKltJEwxAboHF4di9HSyfgqL8zo=;
b=Y/XZtnvtIsfcaVM91sIznDFdSBU9SU+43etR03QiC4tV8XSTDxVNXnATfG+CA9T/1L6
+f+Ix8++W/Z44eHEMj6xsBwMyFXhb+5lJo9s8OEmkTzK8CQVgG4DpvbNiT8cmZePeh12S
CAXS/dcsO03qiWr5Ezg4MAzLe9C7KXpyxgw=
X-RZG-AUTH: :O2kGeEG7b/pS1E6gSHOyjPKyNsg/5l1He+DgCy9/8FSej6CwUyslcvR13AejfvgZQ88TEw==
X-RZG-CLASS-ID: mo00
Received: from rolf.projectworld.net
(189-54-106-151-nd.cpe.vivax.com.br [189.54.106.151])
by post.strato.de (jimi mo12) (RZmta 25.18)
with (AES128-SHA encrypted) ESMTPA id N00d48n4DCEchH ;
Fri, 13 May 2011 15:32:40 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Dr. Rolf Jansen <rj@cyclaero.com>
In-Reply-To: <20110512090221.GA647@zeninc.net>
Date: Fri, 13 May 2011 10:32:36 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4705CFB3-020C-4D70-B08B-6544FC727E0E@cyclaero.com>
References: <042051F4-D309-4317-BBE5-5DF9DEEB342C@cyclaero.com>
<20110512090221.GA647@zeninc.net>
To: VANHULLEBUS Yvan <vanhu@FreeBSD.org>
X-Mailer: Apple Mail (2.1084)
Cc: freebsd-net@freebsd.org
Subject: Re: multiple clients behind the same NAT connecting a L2TP/IPsec
VPN server behind another NAT
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 13:32:45 -0000
Hello Yvan!
Many thanks for your response.
Am 12.05.2011 um 06:02 schrieb VANHULLEBUS Yvan:
> On Wed, May 11, 2011 at 09:43:35PM -0300, Dr. Rolf Jansen wrote:
>=20
>> The only remaining problem is, that from behind the same NAT only
>> one client works well. As soon as a connection between a second
>> client and the server has been established, the communication of
>> both break down. The racoon log shows nothing noticeable here, and
>> according to the log both connections are established successfully,
>> anyhow, the communication is blocked.
>=20
> Sounds like something (racoon ? kernel ? both ?) handles ports in a
> bad way in transport mode....
>=20
> Could you send an example of such generated policies/SAs ?
Here is the output of /usr/local/sbin/setkey -DP, once 2 clients behind =
the same NAT are connected to the L2TP/IPsec-Server in the DMZ of =
70.71.72.73. The IP's are changed, and I re-grouped and tagged the =
output.
# DEFAULT POLICY
0.0.0.0/0[1701] 0.0.0.0/0[any] udp
out ipsec
esp/transport//require
spid=3D30 seq=3D2 pid=3D3271
refcnt=3D1
# FIRST CONNECTION
192.168.0.100[50300] 70.71.72.73[1701] udp
in ipsec
esp/transport//unique:1
created: May 12 19:37:20 2011 lastused: May 12 19:37:20 2011
lifetime: 3600(s) validtime: 0(s)
spid=3D31 seq=3D4 pid=3D3271
refcnt=3D1
70.71.72.73[1701] 192.168.0.100[50300] udp
out ipsec
esp/transport//unique:1
created: May 12 19:37:20 2011 lastused: May 12 19:37:20 2011
lifetime: 3600(s) validtime: 0(s)
spid=3D32 seq=3D1 pid=3D3271
refcnt=3D1
# SECOND CONNECTION
192.168.0.200[49196] 70.71.72.73[1701] udp
in ipsec
esp/transport//unique:2
created: May 12 19:37:56 2011 lastused: May 12 19:37:56 2011
lifetime: 3600(s) validtime: 0(s)
spid=3D33 seq=3D3 pid=3D3271
refcnt=3D1
70.71.72.73[1701] 192.168.0.200[49196] udp
out ipsec
esp/transport//unique:2
created: May 12 19:37:56 2011 lastused: May 12 19:37:56 2011
lifetime: 3600(s) validtime: 0(s)
spid=3D34 seq=3D0 pid=3D3271
refcnt=3D1
>> racoon is configured to generate unique policies.
>=20
> A bit more strange.... SAs should be really hard linked with SPDs, and
> even with a confusion with ports, they should be considered as NOT be
> for the same tunnel.....
Here comes the output of racoonctl show-sa esp. Again, I changed the =
IP's and re-grouped and tagged the output. As for the output of setkey =
above, according to the time stamps, the first block belongs to the =
first established connection, and the second block reflects the status =
of the second connection. 192.168.1.1 is the local IP of the VPN-Server =
in the DMZ. The address 80.81.82.83 is the public address of the NAT'ed =
firewall of from where the two clients 192.168.0.100 and 192.168.0.200 =
have established the connection.
#FIRST CONNECTION
192.168.1.1[4500] 80.81.82.83[4500]=20
esp-udp mode=3Dtransport spi=3D197527017(0x0bc605e9) =
reqid=3D1(0x00000001)
E: aes-cbc 596a7dcf 5b25433e 155a33d2 d27e9499
A: hmac-sha1 ca7e8320 a965c807 f7e73238 0c7e2102 3a59c587
seq=3D0x0000001e replay=3D4 flags=3D0x00000000 state=3Dmature=20
created: May 12 19:37:20 2011 current: May 12 19:41:53 2011
diff: 273(s) hard: 3600(s) soft: 2880(s)
last: May 12 19:37:29 2011 hard: 0(s) soft: 0(s)
current: 4976(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 30 hard: 0 soft: 0
sadb_seq=3D1 pid=3D3125 refcnt=3D1
80.81.82.83[4500] 192.168.1.1[4500]=20
esp-udp mode=3Dtransport spi=3D73066306(0x045ae742) =
reqid=3D1(0x00000001)
E: aes-cbc 91c6df1d 604a8eca 2c29b240 517b05c3
A: hmac-sha1 fe368cb6 d31e7b16 6cfb3410 7a8426fe 9246f9b3
seq=3D0x00000058 replay=3D4 flags=3D0x00000000 state=3Dmature=20
created: May 12 19:37:20 2011 current: May 12 19:41:53 2011
diff: 273(s) hard: 3600(s) soft: 2880(s)
last: May 12 19:41:43 2011 hard: 0(s) soft: 0(s)
current: 11567(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 88 hard: 0 soft: 0
sadb_seq=3D0 pid=3D3125 refcnt=3D1
#SECOND CONNECTION
192.168.1.1[4500] 80.81.82.83[57670]=20
esp-udp mode=3Dtransport spi=3D67190636(0x04013f6c) =
reqid=3D2(0x00000002)
E: aes-cbc 3ce5335e 94832280 d27f2459 9f4465bf
A: hmac-sha1 93b25d41 874432a2 87685009 a95bdf1f 003e8a49
seq=3D0x00000045 replay=3D4 flags=3D0x00000000 state=3Dmature=20
created: May 12 19:37:56 2011 current: May 12 19:41:53 2011
diff: 237(s) hard: 3600(s) soft: 2880(s)
last: May 12 19:41:39 2011 hard: 0(s) soft: 0(s)
current: 11368(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 69 hard: 0 soft: 0
sadb_seq=3D3 pid=3D3125 refcnt=3D2
80.81.82.83[57670] 192.168.1.1[4500]=20
esp-udp mode=3Dtransport spi=3D95933843(0x05b7d593) =
reqid=3D2(0x00000002)
E: aes-cbc 83b2e655 e8a416d3 de50f74a 1fbac49b
A: hmac-sha1 80481e75 933727f8 b1d21207 b0dd7113 45707403
seq=3D0x0000003a replay=3D4 flags=3D0x00000000 state=3Dmature=20
created: May 12 19:37:56 2011 current: May 12 19:41:53 2011
diff: 237(s) hard: 3600(s) soft: 2880(s)
last: May 12 19:41:39 2011 hard: 0(s) soft: 0(s)
current: 6497(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 58 hard: 0 soft: 0
sadb_seq=3D2 pid=3D3125 refcnt=3D1
I can see one special thing. The first connection is on both sides =
running on port 4500, while the second connection is using a different =
port at the peer side. As a matter of fact, during these tests, =
connection 2 was still working, but only connection 1 was blocked.
>> When a client disconnects from the server, racoon usually purges 2
>> IPsec-SA shortly after. The interesting thing in the case of 2
>> clients from the same NAT is, that it purges one IPsec-SA from the
>> client just disconnected, and 1 belonging to the client that is
>> still connected. So, it seems that the internal SA house holding of
>> racoon got confused.
>=20
> See in racoon's debug (-dd to have more verbose) if decision comes
> from racoon, from peer (I don't think so) or from the kernel (via a
> PFKey message).
Yesterday, it turned out to me that this effect shows up only with the =
following setkey.conf:
flush;
spdflush;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec =
esp/transport//require;
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec =
esp/transport//require;
With this setup, the second client (192.168.0.200) could not establish a =
connection, and only one half of it was dropped, together with another =
half of the first connection (192.168.0.100):
2011-05-12 19:33:11: [80.81.82.83] INFO: DPD: remote (ISAKMP-SA =
spi=3D2b64453a611ace30:dd38274322e05e06) seems to be dead.
2011-05-12 19:33:11: INFO: purging ISAKMP-SA =
spi=3D2b64453a611ace30:dd38274322e05e06.
2011-05-12 19:33:11: DEBUG2: getph1: start
2011-05-12 19:33:11: DEBUG2: local: 192.168.1.1[4500]
2011-05-12 19:33:11: DEBUG2: remote: 80.81.82.83[40699]
2011-05-12 19:33:11: DEBUG2: p->local: 192.168.1.1[4500]
2011-05-12 19:33:11: DEBUG2: p->remote: 80.81.82.83[4500]
2011-05-12 19:33:11: DEBUG2: remote identity does match hint
2011-05-12 19:33:11: DEBUG2: no match
2011-05-12 19:33:11: DEBUG: call pfkey_send_dump
2011-05-12 19:33:11: DEBUG: pk_recv: retry[0] recv()=20
2011-05-12 19:33:11: DEBUG: pk_recv: retry[0] recv()=20
2011-05-12 19:33:11: DEBUG: pk_recv: retry[0] recv()=20
2011-05-12 19:33:11: DEBUG: pk_recv: retry[0] recv()=20
#### DROPPING ONE HALF OF THE SECOND CONNECTION
2011-05-12 19:33:11: INFO: deleting a generated policy.
2011-05-12 19:33:11: DEBUG: get a src address from ID payload =
192.168.0.200[49189] prefixlen=3D32 ul_proto=3D17
2011-05-12 19:33:11: DEBUG: get dst address from ID payload =
70.71.72.73[1701] prefixlen=3D32 ul_proto=3D17
2011-05-12 19:33:11: DEBUG: call pfkey_send_spddelete
2011-05-12 19:33:11: DEBUG: pfkey spddelete(inbound) sent.
2011-05-12 19:33:11: DEBUG: call pfkey_send_spddelete
2011-05-12 19:33:11: DEBUG: pfkey spddelete(outbound) sent.
2011-05-12 19:33:11: DEBUG: IV freed
2011-05-12 19:33:11: INFO: purged IPsec-SA spi=3D243828999.
#### DROPPING ONE HALF OF THE FIRST CONNECTION
2011-05-12 19:33:11: INFO: deleting a generated policy.
2011-05-12 19:33:11: DEBUG: get a src address from ID payload =
192.168.0.100[50287] prefixlen=3D32 ul_proto=3D17
2011-05-12 19:33:11: DEBUG: get dst address from ID payload =
70.71.72.73[1701] prefixlen=3D32 ul_proto=3D17
2011-05-12 19:33:11: DEBUG: call pfkey_send_spddelete
2011-05-12 19:33:11: DEBUG: pfkey spddelete(inbound) sent.
2011-05-12 19:33:11: DEBUG: call pfkey_send_spddelete
2011-05-12 19:33:11: DEBUG: pfkey spddelete(outbound) sent.
2011-05-12 19:33:11: DEBUG: IV freed
2011-05-12 19:33:11: INFO: purged IPsec-SA spi=3D6251846.
2011-05-12 19:33:11: INFO: purged ISAKMP-SA =
spi=3D2b64453a611ace30:dd38274322e05e06.
This DOES NOT happen, with my current setkey.conf:
flush;
spdflush;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec =
esp/transport//require;
With this, a second client can successfully establish a connection. Only =
the communication over the first connection is blocked somehow after the =
second one has been established.
> There is "some chance", but this may involve userland and/or kernel
> patching...
I am pretty comfortable in programming in C (and others), so I don't =
fear patching anything.
>> BTW: Using only mpd5, I setup also a PPTP-VPN server running in
>> parallel to the L2TP/IPsec one. Multiple PPTP-VPN clients behind the
>> same NAT work perfectly well with my server - So, I tend to believe
>> that it is really an issue with the IPsec part and not with the L2TP
>> (mpd5) part of my setup.
>=20
> I don't know MPD so much, ...
Yeah, this is OK, since just recently Alexander Motin, who is one of the =
programmers of MPD5, wrote to me: "I am not an IPsec expert...".
:-)
Many thanks for taking your time for looking into my problems!
Best regards
Rolf
From owner-freebsd-net@FreeBSD.ORG Fri May 13 20:22:47 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 68AF91065675
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 20:22:47 +0000 (UTC)
(envelope-from freebsd-net@m.gmane.org)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
by mx1.freebsd.org (Postfix) with ESMTP id F349F8FC2A
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 20:22:46 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <freebsd-net@m.gmane.org>) id 1QKyeG-0005yt-6W
for freebsd-net@freebsd.org; Fri, 13 May 2011 22:07:44 +0200
Received: from 192.75.139.248 ([192.75.139.248])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 22:07:44 +0200
Received: from ivoras by 192.75.139.248 with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 22:07:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-net@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 13 May 2011 16:07:31 -0400
Lines: 79
Message-ID: <iqk323$f8e$1@dough.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 192.75.139.248
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
Subject: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 20:22:47 -0000
I'm seeing an an unusual problem at a remote machine; this machine is
the FreeBSD server, and the client is a probably Windows machine (but I
don't know the details yet). Something happens which causes FreeBSD to
send ACKs to the client, and the client to send ICMP unreachable
messages to the server. It is most likely a configuration error at the
remote site but I have no idea how to verify this.
A tcpdump sample is attached. Any ideas what to look into next?
18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191,
win 0, length 0
E..(J...@.W..(.d.(.D.P.|....}..gP...lR..
18:56:02.712009 IP server.http > client.elan: Flags [.], ack 2661379534,
win 0, length 0
E..(J...@.V..(.d.(.D.P.b.(....m.P.......
18:56:02.712025 IP server.http > client.2402: Flags [.], ack 2197439003,
win 0, length 0
E..(J...@.V..(.d.(.D.P b.m>5..B.P...@p..
18:56:02.712064 IP server.http > client.3427: Flags [.], ack 1373214750,
win 0, length 0
E..(K%..@.V..(.d.(.D.P^Mc_N..Q...P.......
18:56:02.712176 IP server.http > client.1893: Flags [.], ack 3549121877,
win 0, length 0
E..(K...@.V..(.d.(.D.P.ee..G..MUP...~_..
18:56:02.712304 IP server.http > client.atex_elmd: Flags [.], ack
2600295677, win 0, length 0
E..(Lq..@.UU.(.d.(.D.P.i.*.F..\.P...,...
18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win
65535, length 0
E..(L.@.@..2.(.d.(.D.P.|....}..gP.......
18:56:02.713193 IP server.http > client.elan: Flags [.], ack 1, win
65535, length 0
E..(L.@.@....(.d.(.D.P.b.(....m.P.......
18:56:02.713206 IP server.http > client.2402: Flags [.], ack 1, win
65535, length 0
E..(L.@.@....(.d.(.D.P b.m>6..B.P.......
18:56:02.713452 IP server.http > client.3427: Flags [.], ack 1, win
65535, length 0
E..(L.@.@....(.d.(.D.P^Mc_N..Q...P.......
18:56:02.713937 IP server.http > client.1893: Flags [.], ack 1, win
ovd65535, length 0
E..(M'@.@....(.d.(.D.P.ee..H..MUP.......
18:56:02.714436 IP server.http > client.atex_elmd: Flags [.], ack 1, win
65535, length 0
E..(M.@.@..P.(.d.(.D.P.i.*.G..\.P.......
18:56:05.723511 IP client > server: ICMP host client unreachable, length 48
E..D.8..?....(.D.(.d........E..(J...>.Y..(.d.(.D.P.|....}..gP...lR..
18:56:05.723527 IP client > server: ICMP host client unreachable, length 48
E..D.9..?....(.D.(.d........E..(L.@.>..2.(.d.(.D.P.|....}..gP...lQ..
18:56:07.712140 IP server.http > client.1859: Flags [.], ack 70891158,
win 0, length 0
E..(N0..@.S..(.d.(.D.P.C.>S..9..P.......
18:56:07.712161 IP server.http > client.dict: Flags [.], ack 878675698,
win 0, length 0
E..(NF..@.S..(.d.(.D.P
D...:4_..P...g...
18:56:07.713390 IP server.http > client.1859: Flags [.], ack 1, win
65535, length 0
E..(O.@.@....(.d.(.D.P.C.>S..9..P.......
18:56:07.713459 IP server.http > client.dict: Flags [.], ack 1, win
65535, length 0
E..(O.@.@....(.d.(.D.P
D...;4_..P.......
18:56:17.712207 IP server.http > client.3454: Flags [.], ack 119451926,
win 0, length 0
E..(R...@.O..(.d.(.D.P^M~@.i.....P...f7..
18:56:17.712354 IP server.http > client.2412: Flags [.], ack 4105579117,
win 0, length 0
E..(R...@.N..(.d.(.D.P l......*mP.......
18:56:17.712448 IP server.http > client.3438: Flags [.], ack 1002884906,
win 0, length 0
E..(SL..@.Nz.(.d.(.D.P^MnF.;.;..*P...;...
18:56:17.713764 IP server.http > client.3454: Flags [.], ack 1, win
65535, length 0
E..(S.@.@.^M..(.d.(.D.P^M~@.i.....P.......
18:56:17.714361 IP server.http > client.2412: Flags [.], ack 1, win
65535, length 0
E..(TY@.@.^M}.(.d.(.D.P l......*mP.......
From owner-freebsd-net@FreeBSD.ORG Fri May 13 21:39:05 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 13E021065673
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 21:39:05 +0000 (UTC)
(envelope-from cswiger@mac.com)
Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104])
by mx1.freebsd.org (Postfix) with ESMTP id F08B48FC16
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 21:39:04 +0000 (UTC)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from cswiger1.apple.com ([17.209.4.71])
by asmtp029.mac.com (Oracle Communications Messaging Exchange Server
7u4-20.01 64bit (built Nov 21 2010))
with ESMTPSA id <0LL500EYDLGAKY30@asmtp029.mac.com>; Fri,
13 May 2011 14:38:35 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.2.15,1.0.148,0.0.0000
definitions=2011-05-13_06:2011-05-13, 2011-05-13,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0
classifier=spam
adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105130171
From: Chuck Swiger <cswiger@mac.com>
In-reply-to: <iqk323$f8e$1@dough.gmane.org>
Date: Fri, 13 May 2011 14:38:34 -0700
Message-id: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
References: <iqk323$f8e$1@dough.gmane.org>
To: Ivan Voras <ivoras@freebsd.org>
X-Mailer: Apple Mail (2.1084)
Cc: freebsd-net@freebsd.org
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 21:39:05 -0000
On May 13, 2011, at 1:07 PM, Ivan Voras wrote:
> I'm seeing an an unusual problem at a remote machine; this machine is
> the FreeBSD server, and the client is a probably Windows machine (but I
> don't know the details yet). Something happens which causes FreeBSD to
> send ACKs to the client, and the client to send ICMP unreachable
> messages to the server. It is most likely a configuration error at the
> remote site but I have no idea how to verify this.
Let's look at just one connection:
18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191, win 0, length 0
18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win 65535, length 0
The packet is FreeBSD webserver sending ACKs with zero window size; that's a sign of congestion that the client should not be sending more data and instead doing periodic window probes until the local box opens the window again. The next packet on the same connection then ACK's something outside of the window with a 64K window size. That's wrong; the other side probably sends an RST and the ICMP error. If you have TSO enabled, try turning it off.
Otherwise, providing the hex data or the ICMP packet via -x or -X might help identify which connection the Windows box was objecting to. And it would also be helpful to see a data packet or two just to see normal data flow before whatever is going wrong.
Regards,
--
-Chuck
From owner-freebsd-net@FreeBSD.ORG Sat May 14 04:07:09 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 3411F106564A
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 04:07:09 +0000 (UTC)
(envelope-from ivoras@gmail.com)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com
[209.85.161.182])
by mx1.freebsd.org (Postfix) with ESMTP id E30348FC0C
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 04:07:08 +0000 (UTC)
Received: by gxk28 with SMTP id 28so1355645gxk.13
for <freebsd-net@freebsd.org>; Fri, 13 May 2011 21:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:in-reply-to:references:from
:date:x-google-sender-auth:message-id:subject:to:cc:content-type
:content-transfer-encoding;
bh=rxTRgx92K1Ct5UaJ1JvlkFpd7IbThtzcEAtTNwTk+jw=;
b=pIdorZlXPZmUn3ioS3GTvxodvnpK9T2BBegu+siu6u4ryQBxT8aFvzV/BYasx0gS8l
LpI+Af0k1PbRH0ZH9/A/k1B3HcNFUR2xY+9ls+sVxrHCHVL1B+3dy2DIPfzwcXmElS4k
B8OwOTAGAg3GafTU6UfSJOfSRkQeJzuFMntpo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:sender:in-reply-to:references:from:date
:x-google-sender-auth:message-id:subject:to:cc:content-type
:content-transfer-encoding;
b=ha/CqosK7ZI4iJCpaWfO0ujFYZ9qwRyzNN2fn/TOvPJTWc0pC8woSqLR21WSVov6R2
cV57Un4U38gLLKV+GFhc/bmFPL1SL4gZDCYnRSJcEffH3wyQU3VokGB+JS19dwrKZ7Od
9yyL9IJ5lLlo0NyCIiBuMYfvzFhwTFNC7NYQo=
Received: by 10.101.117.17 with SMTP id u17mr1338560anm.106.1305344429151;
Fri, 13 May 2011 20:40:29 -0700 (PDT)
MIME-Version: 1.0
Sender: ivoras@gmail.com
Received: by 10.100.248.5 with HTTP; Fri, 13 May 2011 20:39:49 -0700 (PDT)
In-Reply-To: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
References: <iqk323$f8e$1@dough.gmane.org>
<5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 13 May 2011 23:39:49 -0400
X-Google-Sender-Auth: 1M99IUXmo-O8p3SRh9zoiZnUmUs
Message-ID: <BANLkTikn_3EkHsqdkERpaqLxrGmCJXysGQ@mail.gmail.com>
To: Chuck Swiger <cswiger@mac.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: freebsd-net@freebsd.org
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 04:07:09 -0000
On 13 May 2011 17:38, Chuck Swiger <cswiger@mac.com> wrote:
> On May 13, 2011, at 1:07 PM, Ivan Voras wrote:
>> I'm seeing an an unusual problem at a remote machine; this machine is
>> the FreeBSD server, and the client is a probably Windows machine (but I
>> don't know the details yet). Something happens which causes FreeBSD to
>> send ACKs to the client, and the client to send ICMP unreachable
>> messages to the server. It is most likely a configuration error at the
>> remote site but I have no idea how to verify this.
>
>
> Let's look at just one connection:
>
> 18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191, =
win 0, length 0
> 18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win 65535=
, length 0
>
> The packet is FreeBSD webserver sending ACKs with zero window size; that'=
s a sign of congestion that the client should not be sending more data and =
instead doing periodic window probes until the local box opens the window a=
gain. =C2=A0The next packet on the same connection then ACK's something out=
side of the window with a 64K window size. =C2=A0That's wrong; the other si=
de probably sends an RST and the ICMP error. =C2=A0If you have TSO enabled,=
try turning it off.
Well the problem is that there is no traffic from the other side that
I can see; either it's blocked by ipfw on the server or by something
else - both options are not good.
Could it be that the ipfw dropped the (dynamic) state for the
connections but the TCP stack keeps retrying them and doesn't know
when to quit?
This is FreeBSD 8-stable under VMWare, without TSO on em.
> Otherwise, providing the hex data or the ICMP packet via -x or -X might h=
elp identify which connection the Windows box was objecting to. =C2=A0And i=
t would also be helpful to see a data packet or two just to see normal data=
flow before whatever is going wrong.
There is apparently no active traffic on these connections; netstat
shows them as in FIN_WAIT_2 state.
From owner-freebsd-net@FreeBSD.ORG Sat May 14 09:17:14 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 86D971065675
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 09:17:14 +0000 (UTC)
(envelope-from yilinjing2006@gmail.com)
Received: from sam.nabble.com (sam.nabble.com [216.139.236.26])
by mx1.freebsd.org (Postfix) with ESMTP id 61B938FC1F
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 09:17:14 +0000 (UTC)
Received: from [192.168.236.26] (helo=sam.nabble.com)
by sam.nabble.com with esmtp (Exim 4.69)
(envelope-from <yilinjing2006@gmail.com>) id 1QLAhE-0004eT-To
for freebsd-net@freebsd.org; Sat, 14 May 2011 01:59:36 -0700
Date: Sat, 14 May 2011 01:59:36 -0700 (PDT)
From: jyl_2006 <yilinjing2006@gmail.com>
To: freebsd-net@freebsd.org
Message-ID: <1305363576917-4395319.post@n5.nabble.com>
In-Reply-To: <44B0D157.8070503@cisco.com>
References: <44A552FA.2030302@cisco.com> <m2u061ogp3.wl%gnn@neville-neil.com>
<20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com>
<m2wtaril9n.wl%gnn@neville-neil.com> <44AE4814.2020706@cisco.com>
<20060708104718.GA1632@bashibuzuk.net> <44B0D157.8070503@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: SCTP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 09:17:14 -0000
I have download files from http://www.sctp.org/app.tar.bz2,and when I input
gmake,
It shows that:
cc:../user/FreeBSD/libsctpuser.a:No such file or directory.
I have tryed to search file named "libsctpuser.a",but nothing have found.
Anyone who can help me?
--
View this message in context: http://freebsd.1045724.n5.nabble.com/SCTP-tp4008109p4395319.html
Sent from the freebsd-net mailing list archive at Nabble.com.
From owner-freebsd-net@FreeBSD.ORG Sat May 14 12:01:15 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F36D11065672
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:01:14 +0000 (UTC)
(envelope-from jhellenthal@gmail.com)
Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com
[209.85.214.182])
by mx1.freebsd.org (Postfix) with ESMTP id A68E58FC12
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:01:14 +0000 (UTC)
Received: by iwn33 with SMTP id 33so3998148iwn.13
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 05:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:sender:date:from:to:cc:subject:message-id
:references:mime-version:content-type:content-disposition
:in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint
:x-openpgp-key-url;
bh=YqIfHLTPvkvwfmbvftrLlwzdYo0jdeleKVUQra2yblk=;
b=PuFDlvWii8zsdie56s4Rd/C0V64upqqTyfy4ICFFFZ+I2CKXIxQkcxPgU3P1vXeJDj
lObU01k/Gmos/fzZN1I+njnRufjJxeP0lGs7XAzOyeL/mDdveXeBnx8ZwImp189MRa+X
8MVfEIVmadg0O2IDHXkmYllEyBvW45PRh6lhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:x-openpgp-key-id
:x-openpgp-key-fingerprint:x-openpgp-key-url;
b=UwSQdmgonMfm2R4CVJRfT0ovcCIsAMQBbqcpxNygA5NASCxQ8jYOCB+xTZnN+Okz/5
uw/12v29sGd+/9jSjFd7ALi20cY+4lwHRjWLYgxARHG2BZ46NKokLzggjqJKdxhX4Lm4
he6hzigOc0FFo3VAYxyvbgT4VQCenHh+l89L4=
Received: by 10.231.51.17 with SMTP id b17mr1919213ibg.0.1305374472466;
Sat, 14 May 2011 05:01:12 -0700 (PDT)
Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net
[99.190.81.196])
by mx.google.com with ESMTPS id g16sm1333289ibb.54.2011.05.14.05.01.10
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 14 May 2011 05:01:11 -0700 (PDT)
Sender: "J. Hellenthal" <jhellenthal@gmail.com>
Received: from DataIX.net (localhost [127.0.0.1])
by DataIX.net (8.14.4/8.14.4) with ESMTP id p4EC17CN015540
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 14 May 2011 08:01:08 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Received: (from jhell@localhost)
by DataIX.net (8.14.4/8.14.4/Submit) id p4EC17fd015539;
Sat, 14 May 2011 08:01:07 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Date: Sat, 14 May 2011 08:01:07 -0400
From: Jason Hellenthal <jhell@DataIX.net>
To: jyl_2006 <yilinjing2006@gmail.com>
Message-ID: <20110514120107.GA13970@DataIX.net>
References: <44A552FA.2030302@cisco.com> <m2u061ogp3.wl%gnn@neville-neil.com>
<20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com>
<m2wtaril9n.wl%gnn@neville-neil.com> <44AE4814.2020706@cisco.com>
<20060708104718.GA1632@bashibuzuk.net> <44B0D157.8070503@cisco.com>
<1305363576917-4395319.post@n5.nabble.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline
In-Reply-To: <1305363576917-4395319.post@n5.nabble.com>
X-OpenPGP-Key-Id: 0x89D8547E
X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E
X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E
Cc: freebsd-net@freebsd.org
Subject: Re: SCTP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 12:01:15 -0000
--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
jyl_2006,
sctp.org has a mailing list. They might be able to help you further with
your app.
As for that tar ball. I could not find any reference for it on the
website where you got it from. Did you find the link to it somewhere
else ?
On Sat, May 14, 2011 at 01:59:36AM -0700, jyl_2006 wrote:
> I have download files from http://www.sctp.org/app.tar.bz2,and when I inp=
ut
> gmake,
> It shows that:
> cc:../user/FreeBSD/libsctpuser.a:No such file or directory.
> I have tryed to search file named "libsctpuser.a",but nothing have found.
> Anyone who can help me?
>=20
>=20
> --
> View this message in context: http://freebsd.1045724.n5.nabble.com/SCTP-t=
p4008109p4395319.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> _______________________________________________
> 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"
--=20
Regards, (jhell)
Jason Hellenthal
--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: http://bit.ly/0x89D8547E
iQEcBAEBAgAGBQJNzm8CAAoJEJBXh4mJ2FR+yqAH/2B9n0riUKnVvZI0MZNRiqQI
bganVbh1V6diaUTFdIADrP/8bpsMFn1Nl5eV1CwSR6mVjHKsGqp7THGtZAnXiGSm
wgT5sMK3572PVfSSoQG5ngWofJNtEH+feZVzFvlnGkSFaWodqx+eRg/LYCY07/sI
/NTHNvF3fLJm6GPm5goXORF/xN1cA+5ASPZKvlGCCC0qWr23qnoq3Ns3MMZ+hlAk
j77WeilhXrUHU6Z07Ywvz0S5BvwvY8HZAKZamwJqYcv6S3cN97KRngqCWdvc4+T8
yUTC+0d9641yp4/8nk+hY+cTy1WN1QAEv7XZ6qgzuST/5QDe+ycHzPBtPDD8IZQ=
=zBCL
-----END PGP SIGNATURE-----
--MGYHOYXEY6WxJCY8--
From owner-freebsd-net@FreeBSD.ORG Sat May 14 12:08:48 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 9C093106567B
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:08:48 +0000 (UTC)
(envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
by mx1.freebsd.org (Postfix) with ESMTP id 6E7FC8FC14
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:08:48 +0000 (UTC)
Received: from julian-mac.elischer.org ([24.114.252.243])
(authenticated bits=0)
by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p4EC8iJI077539
(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
Sat, 14 May 2011 05:08:47 -0700 (PDT)
(envelope-from julian@freebsd.org)
Message-ID: <4DCE70CA.3060408@freebsd.org>
Date: Sat, 14 May 2011 08:08:42 -0400
From: Julian Elischer <julian@freebsd.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US;
rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Ivan Voras <ivoras@freebsd.org>
References: <iqk323$f8e$1@dough.gmane.org> <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
<BANLkTikn_3EkHsqdkERpaqLxrGmCJXysGQ@mail.gmail.com>
In-Reply-To: <BANLkTikn_3EkHsqdkERpaqLxrGmCJXysGQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 12:08:48 -0000
On 5/13/11 11:39 PM, Ivan Voras wrote:
> On 13 May 2011 17:38, Chuck Swiger<cswiger@mac.com> wrote:
>> On May 13, 2011, at 1:07 PM, Ivan Voras wrote:
>>> I'm seeing an an unusual problem at a remote machine; this machine is
>>> the FreeBSD server, and the client is a probably Windows machine (but I
>>> don't know the details yet). Something happens which causes FreeBSD to
>>> send ACKs to the client, and the client to send ICMP unreachable
>>> messages to the server. It is most likely a configuration error at the
>>> remote site but I have no idea how to verify this.
>>
>> Let's look at just one connection:
>>
>> 18:56:02.711942 IP server.http> client.4732: Flags [.], ack 2110905191, win 0, length 0
>> 18:56:02.713155 IP server.http> client.4732: Flags [.], ack 1, win 65535, length 0
>>
>> The packet is FreeBSD webserver sending ACKs with zero window size; that's a sign of congestion that the client should not be sending more data and instead doing periodic window probes until the local box opens the window again. The next packet on the same connection then ACK's something outside of the window with a 64K window size. That's wrong; the other side probably sends an RST and the ICMP error. If you have TSO enabled, try turning it off.
> Well the problem is that there is no traffic from the other side that
> I can see; either it's blocked by ipfw on the server or by something
> else - both options are not good.
>
> Could it be that the ipfw dropped the (dynamic) state for the
> connections but the TCP stack keeps retrying them and doesn't know
> when to quit?
>
> This is FreeBSD 8-stable under VMWare, without TSO on em.
>
>> Otherwise, providing the hex data or the ICMP packet via -x or -X might help identify which connection the Windows box was objecting to. And it would also be helpful to see a data packet or two just to see normal data flow before whatever is going wrong.
are you sure the acks are not keepalives generated by ipfw in the middle?
> There is apparently no active traffic on these connections; netstat
> shows them as in FIN_WAIT_2 state.
> _______________________________________________
> 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 Sat May 14 12:45:57 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 C3D75106566B
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:45:57 +0000 (UTC)
(envelope-from jhellenthal@gmail.com)
Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com
[209.85.214.182])
by mx1.freebsd.org (Postfix) with ESMTP id 766FC8FC12
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:45:57 +0000 (UTC)
Received: by iwn33 with SMTP id 33so4019803iwn.13
for <multiple recipients>; Sat, 14 May 2011 05:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:sender:date:from:to:cc:subject:message-id
:references:mime-version:content-type:content-disposition
:in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint
:x-openpgp-key-url;
bh=tsKMX/cOREqhJdsOrLDWKEjqofpszNfoKGanvSa3PHA=;
b=uAd/QCfN7sSmW8Rc/62c4Kp+ACQp2VvticOS8roUscAIDkfoTTsN7/eEy71EF8Ldqk
i8GGgXRm/SdylZwGapSftDmlwzi+iSyxuf9rYH5owQDHCK0wRlvySGM+3OmG+x/ysPkc
rFj+SSk/zuKgZHVWEc7R+vJTDtyE65/tSTxZs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:x-openpgp-key-id
:x-openpgp-key-fingerprint:x-openpgp-key-url;
b=EfWbGuwo0m2wQPeOAMJaDQrHvJEOiwSd8anCM6mFIs6hdUyrZm6giswHDpkfXT3EcO
tCcOdT5F5NKibPgxvi83IkMk6hkzgsR5PHixOFnJX6D9bbaBmryeCNRPGoW7H8KN63bX
uY5wqi9oVmPL7/lcRiP2h2doMqs1lU9PKDZnw=
Received: by 10.42.141.136 with SMTP id o8mr3155809icu.512.1305377156793;
Sat, 14 May 2011 05:45:56 -0700 (PDT)
Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net
[99.190.81.196])
by mx.google.com with ESMTPS id i3sm1347240iby.40.2011.05.14.05.45.54
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 14 May 2011 05:45:55 -0700 (PDT)
Sender: "J. Hellenthal" <jhellenthal@gmail.com>
Received: from DataIX.net (localhost [127.0.0.1])
by DataIX.net (8.14.4/8.14.4) with ESMTP id p4ECjphw021210
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 14 May 2011 08:45:52 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Received: (from jhell@localhost)
by DataIX.net (8.14.4/8.14.4/Submit) id p4ECjpPW021209;
Sat, 14 May 2011 08:45:51 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Date: Sat, 14 May 2011 08:45:51 -0400
From: Jason Hellenthal <jhell@DataIX.net>
To: Ivan Voras <ivoras@freebsd.org>
Message-ID: <20110514124551.GB13970@DataIX.net>
References: <iqk323$f8e$1@dough.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ"
Content-Disposition: inline
In-Reply-To: <iqk323$f8e$1@dough.gmane.org>
X-OpenPGP-Key-Id: 0x89D8547E
X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E
X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E
Cc: freebsd-net@freebsd.org
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 12:45:57 -0000
--ZmUaFz6apKcXQszQ
Content-Type: multipart/mixed; boundary="hHWLQfXTYDoKhP50"
Content-Disposition: inline
--hHWLQfXTYDoKhP50
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Ivan,
On Fri, May 13, 2011 at 04:07:31PM -0400, Ivan Voras wrote:
> I'm seeing an an unusual problem at a remote machine; this machine is
> the FreeBSD server, and the client is a probably Windows machine (but I
> don't know the details yet). Something happens which causes FreeBSD to
> send ACKs to the client, and the client to send ICMP unreachable
> messages to the server. It is most likely a configuration error at the
> remote site but I have no idea how to verify this.
>=20
> A tcpdump sample is attached. Any ideas what to look into next?
>=20
>=20
> 18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191,
> win 0, length 0
> E..(J...@.W..(.d.(.D.P.|....}..gP...lR..
> 18:56:02.712009 IP server.http > client.elan: Flags [.], ack 2661379534,
> win 0, length 0
> E..(J...@.V..(.d.(.D.P.b.(....m.P.......
> 18:56:02.712025 IP server.http > client.2402: Flags [.], ack 2197439003,
> win 0, length 0
> E..(J...@.V..(.d.(.D.P b.m>5..B.P...@p..
> 18:56:02.712064 IP server.http > client.3427: Flags [.], ack 1373214750,
> win 0, length 0
> E..(K%..@.V..(.d.(.D.P^Mc_N..Q...P.......
> 18:56:02.712176 IP server.http > client.1893: Flags [.], ack 3549121877,
> win 0, length 0
> E..(K...@.V..(.d.(.D.P.ee..G..MUP...~_..
> 18:56:02.712304 IP server.http > client.atex_elmd: Flags [.], ack
> 2600295677, win 0, length 0
> E..(Lq..@.UU.(.d.(.D.P.i.*.F..\.P...,...
> 18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@..2.(.d.(.D.P.|....}..gP.......
> 18:56:02.713193 IP server.http > client.elan: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P.b.(....m.P.......
> 18:56:02.713206 IP server.http > client.2402: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P b.m>6..B.P.......
> 18:56:02.713452 IP server.http > client.3427: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P^Mc_N..Q...P.......
> 18:56:02.713937 IP server.http > client.1893: Flags [.], ack 1, win
> ovd65535, length 0
> E..(M'@.@....(.d.(.D.P.ee..H..MUP.......
> 18:56:02.714436 IP server.http > client.atex_elmd: Flags [.], ack 1, win
> 65535, length 0
> E..(M.@.@..P.(.d.(.D.P.i.*.G..\.P.......
> 18:56:05.723511 IP client > server: ICMP host client unreachable, length =
48
> E..D.8..?....(.D.(.d........E..(J...>.Y..(.d.(.D.P.|....}..gP...lR..
> 18:56:05.723527 IP client > server: ICMP host client unreachable, length =
48
> E..D.9..?....(.D.(.d........E..(L.@.>..2.(.d.(.D.P.|....}..gP...lQ..
> 18:56:07.712140 IP server.http > client.1859: Flags [.], ack 70891158,
> win 0, length 0
> E..(N0..@.S..(.d.(.D.P.C.>S..9..P.......
> 18:56:07.712161 IP server.http > client.dict: Flags [.], ack 878675698,
> win 0, length 0
> E..(NF..@.S..(.d.(.D.P
> D...:4_..P...g...
> 18:56:07.713390 IP server.http > client.1859: Flags [.], ack 1, win
> 65535, length 0
> E..(O.@.@....(.d.(.D.P.C.>S..9..P.......
> 18:56:07.713459 IP server.http > client.dict: Flags [.], ack 1, win
> 65535, length 0
> E..(O.@.@....(.d.(.D.P
> D...;4_..P.......
> 18:56:17.712207 IP server.http > client.3454: Flags [.], ack 119451926,
> win 0, length 0
> E..(R...@.O..(.d.(.D.P^M~@.i.....P...f7..
> 18:56:17.712354 IP server.http > client.2412: Flags [.], ack 4105579117,
> win 0, length 0
> E..(R...@.N..(.d.(.D.P l......*mP.......
> 18:56:17.712448 IP server.http > client.3438: Flags [.], ack 1002884906,
> win 0, length 0
> E..(SL..@.Nz.(.d.(.D.P^MnF.;.;..*P...;...
> 18:56:17.713764 IP server.http > client.3454: Flags [.], ack 1, win
> 65535, length 0
> E..(S.@.@.^M..(.d.(.D.P^M~@.i.....P.......
> 18:56:17.714361 IP server.http > client.2412: Flags [.], ack 1, win
> 65535, length 0
> E..(TY@.@.^M}.(.d.(.D.P l......*mP.......
>=20
This really looks like jhb@'s problem that he solved in revisions
r220679 which was a MFC of r220156.
Is the machine on the end your connecting to a 64-bit machine ? And is
it still unpatched as of that revision ?
I am unclear is this had made it to 7-STABLE as of yet.
------------------------------------------------------------------------
r220679 | jhb | 2011-04-15 16:42:27 -0400 (Fri, 15 Apr 2011) | 8 lines
MFC 220156:
Clamp the initial advertised receive window when responding to a SYN/ACK
to the maximum allowed window. Growing the window too large would cause
an underflow in the calculations in tcp_output() to decide if a window
update should be sent which would prevent the persist timer from being
started if data was pending and the other end of the connection
advertised an initial window size of 0.
--=20
Regards, (jhell)
Jason Hellenthal
--hHWLQfXTYDoKhP50
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="r220679.patch"
Index: /usr/src/sys/netinet/tcp_input.c
===================================================================
--- /usr/src/sys/netinet/tcp_input.c (revision 220678)
+++ /usr/src/sys/netinet/tcp_input.c (revision 220679)
@@ -1558,7 +1558,8 @@
(TF_RCVD_SCALE|TF_REQ_SCALE)) {
tp->rcv_scale = tp->request_r_scale;
}
- tp->rcv_adv += tp->rcv_wnd;
+ tp->rcv_adv += imin(tp->rcv_wnd,
+ TCP_MAXWIN << tp->rcv_scale);
tp->snd_una++; /* SYN is acked */
/*
* If there's data, delay ACK; if there's also a FIN
--hHWLQfXTYDoKhP50--
--ZmUaFz6apKcXQszQ
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: http://bit.ly/0x89D8547E
iQEcBAEBAgAGBQJNznl+AAoJEJBXh4mJ2FR+/uEIAJmFbixqlvQsfO9V7h6DvuRs
Fk6dducWnaJ/jGVObTAcjnZFSbSbgOEwoAK9C/KDMQal9aroitUEKtEQZKZ3RL2C
xPqSJFnQD/AoT+jpJKYl0QShjM07TvPJuDDkHUigQAiiez+sf2YrNrJn1IeOEXYv
xMq/7C0moLvbJLcCZ8tBbLpj0uvUyP/MJrTtIIUiSkh7FSNBx+wXQD1xljcVJenT
dJkeX2QzcIJbr19Ed9gF4qR1oVOqC1UYtRJvYuNljKqQR4an9sukuAV664gzm8ZD
wGFiNPBmlzDHXM5J9wI3IHCK/mkYQC+4lmMQ8Ihaenjgcrw51avBAhrFcPKxuyw=
=72mq
-----END PGP SIGNATURE-----
--ZmUaFz6apKcXQszQ--
From owner-freebsd-net@FreeBSD.ORG Sat May 14 12:53:10 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 4CD531065673
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:53:10 +0000 (UTC)
(envelope-from jhellenthal@gmail.com)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com
[209.85.210.182])
by mx1.freebsd.org (Postfix) with ESMTP id 03F8B8FC0A
for <freebsd-net@freebsd.org>; Sat, 14 May 2011 12:53:09 +0000 (UTC)
Received: by iyj12 with SMTP id 12so3795573iyj.13
for <multiple recipients>; Sat, 14 May 2011 05:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:sender:date:from:to:cc:subject:message-id
:references:mime-version:content-type:content-disposition
:in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint
:x-openpgp-key-url;
bh=ShieuAzRgrHXNzBphICJs6QAXolR1Xe4hPK57i6X/IQ=;
b=onn0uM6pcWJuMzMW1SFxVb7rsBFG7jxh7vcns9unUYEi7oArBmK9ijr1O4uSsYWGCX
lO8eQozlmgfFfcxp254ExSYNvAbpOkU6qjGORmOiomDG2cESg8kLkMEb+CDGo6wE6FFg
WT6yvwO9ETuhwp2ZJ2nSGbXQpJV/KTAYXozRQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:x-openpgp-key-id
:x-openpgp-key-fingerprint:x-openpgp-key-url;
b=J0wjZybqJvUOw90ykqnq9nxxWQb0luAR8CSYJu5tvSUN40MZtfyLM25AUhfCcZBRMF
RvUcVtkBrgxAJSlu4l3jGf5iZizHLvo9zMa9WMI+xxdQilAogYdYiYSLFDYGxnr1/JmS
Om2rdAQmXAa00Vz4mduD6hZsSbjnZjrOEtDRk=
Received: by 10.42.52.133 with SMTP id j5mr3127496icg.348.1305377589361;
Sat, 14 May 2011 05:53:09 -0700 (PDT)
Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net
[99.190.81.196])
by mx.google.com with ESMTPS id u17sm1351324ibm.28.2011.05.14.05.53.07
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 14 May 2011 05:53:08 -0700 (PDT)
Sender: "J. Hellenthal" <jhellenthal@gmail.com>
Received: from DataIX.net (localhost [127.0.0.1])
by DataIX.net (8.14.4/8.14.4) with ESMTP id p4ECr5B2021396
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 14 May 2011 08:53:05 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Received: (from jhell@localhost)
by DataIX.net (8.14.4/8.14.4/Submit) id p4ECr5Ij021395;
Sat, 14 May 2011 08:53:05 -0400 (EDT)
(envelope-from jhell@DataIX.net)
Date: Sat, 14 May 2011 08:53:05 -0400
From: Jason Hellenthal <jhell@DataIX.net>
To: Ivan Voras <ivoras@freebsd.org>
Message-ID: <20110514125305.GC13970@DataIX.net>
References: <iqk323$f8e$1@dough.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="5p8PegU4iirBW1oA"
Content-Disposition: inline
In-Reply-To: <iqk323$f8e$1@dough.gmane.org>
X-OpenPGP-Key-Id: 0x89D8547E
X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E
X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E
Cc: freebsd-net@freebsd.org
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 12:53:10 -0000
--5p8PegU4iirBW1oA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Ivan,
I was also going to mention these threads in the previous message to
this list.
This is the thread that ended up getting committed and MFC'd from the
previous mesage.
Feb 08 John Baldwin ( 73) TCP can advertise a really huge window
These is does not seem anything more has happened with them.
Feb 08 John Baldwin ( 88) A small TCP bug: excessive duplicate ACKs
Feb 08 John Baldwin ( 244) TCP connections stuck inpersist state
On Fri, May 13, 2011 at 04:07:31PM -0400, Ivan Voras wrote:
> I'm seeing an an unusual problem at a remote machine; this machine is
> the FreeBSD server, and the client is a probably Windows machine (but I
> don't know the details yet). Something happens which causes FreeBSD to
> send ACKs to the client, and the client to send ICMP unreachable
> messages to the server. It is most likely a configuration error at the
> remote site but I have no idea how to verify this.
>=20
> A tcpdump sample is attached. Any ideas what to look into next?
>=20
>=20
> 18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191,
> win 0, length 0
> E..(J...@.W..(.d.(.D.P.|....}..gP...lR..
> 18:56:02.712009 IP server.http > client.elan: Flags [.], ack 2661379534,
> win 0, length 0
> E..(J...@.V..(.d.(.D.P.b.(....m.P.......
> 18:56:02.712025 IP server.http > client.2402: Flags [.], ack 2197439003,
> win 0, length 0
> E..(J...@.V..(.d.(.D.P b.m>5..B.P...@p..
> 18:56:02.712064 IP server.http > client.3427: Flags [.], ack 1373214750,
> win 0, length 0
> E..(K%..@.V..(.d.(.D.P^Mc_N..Q...P.......
> 18:56:02.712176 IP server.http > client.1893: Flags [.], ack 3549121877,
> win 0, length 0
> E..(K...@.V..(.d.(.D.P.ee..G..MUP...~_..
> 18:56:02.712304 IP server.http > client.atex_elmd: Flags [.], ack
> 2600295677, win 0, length 0
> E..(Lq..@.UU.(.d.(.D.P.i.*.F..\.P...,...
> 18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@..2.(.d.(.D.P.|....}..gP.......
> 18:56:02.713193 IP server.http > client.elan: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P.b.(....m.P.......
> 18:56:02.713206 IP server.http > client.2402: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P b.m>6..B.P.......
> 18:56:02.713452 IP server.http > client.3427: Flags [.], ack 1, win
> 65535, length 0
> E..(L.@.@....(.d.(.D.P^Mc_N..Q...P.......
> 18:56:02.713937 IP server.http > client.1893: Flags [.], ack 1, win
> ovd65535, length 0
> E..(M'@.@....(.d.(.D.P.ee..H..MUP.......
> 18:56:02.714436 IP server.http > client.atex_elmd: Flags [.], ack 1, win
> 65535, length 0
> E..(M.@.@..P.(.d.(.D.P.i.*.G..\.P.......
> 18:56:05.723511 IP client > server: ICMP host client unreachable, length =
48
> E..D.8..?....(.D.(.d........E..(J...>.Y..(.d.(.D.P.|....}..gP...lR..
> 18:56:05.723527 IP client > server: ICMP host client unreachable, length =
48
> E..D.9..?....(.D.(.d........E..(L.@.>..2.(.d.(.D.P.|....}..gP...lQ..
> 18:56:07.712140 IP server.http > client.1859: Flags [.], ack 70891158,
> win 0, length 0
> E..(N0..@.S..(.d.(.D.P.C.>S..9..P.......
> 18:56:07.712161 IP server.http > client.dict: Flags [.], ack 878675698,
> win 0, length 0
> E..(NF..@.S..(.d.(.D.P
> D...:4_..P...g...
> 18:56:07.713390 IP server.http > client.1859: Flags [.], ack 1, win
> 65535, length 0
> E..(O.@.@....(.d.(.D.P.C.>S..9..P.......
> 18:56:07.713459 IP server.http > client.dict: Flags [.], ack 1, win
> 65535, length 0
> E..(O.@.@....(.d.(.D.P
> D...;4_..P.......
> 18:56:17.712207 IP server.http > client.3454: Flags [.], ack 119451926,
> win 0, length 0
> E..(R...@.O..(.d.(.D.P^M~@.i.....P...f7..
> 18:56:17.712354 IP server.http > client.2412: Flags [.], ack 4105579117,
> win 0, length 0
> E..(R...@.N..(.d.(.D.P l......*mP.......
> 18:56:17.712448 IP server.http > client.3438: Flags [.], ack 1002884906,
> win 0, length 0
> E..(SL..@.Nz.(.d.(.D.P^MnF.;.;..*P...;...
> 18:56:17.713764 IP server.http > client.3454: Flags [.], ack 1, win
> 65535, length 0
> E..(S.@.@.^M..(.d.(.D.P^M~@.i.....P.......
> 18:56:17.714361 IP server.http > client.2412: Flags [.], ack 1, win
> 65535, length 0
> E..(TY@.@.^M}.(.d.(.D.P l......*mP.......
>=20
> _______________________________________________
> 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"
--=20
Regards, (jhell)
Jason Hellenthal
--5p8PegU4iirBW1oA
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: http://bit.ly/0x89D8547E
iQEcBAEBAgAGBQJNznswAAoJEJBXh4mJ2FR+/yUH/3SRnws9yA+9nYgMEIzPouZC
fi+MdPDUiVxgqsxNB1ZHnLJcs3XmQyDLs+vQzH37l+N4QJ3gcHWnhfOajmZrqNwK
IDePaoQSZwmDoCMmSjNK+QpV0uC/oQEjos4ZCqxpxqGjDs0kO1Iy9cxCaeH04BRS
YwyiwlIB4176cvCFISgTMzFvAOXPaAgydYrYJ6qbAo1x9M/I0OcnoASM1OnzxAdm
SObOOsquU+5gZnbFsxK53HhMWCb0TpuY7q1cwXsI1KqML1KzacR7GxFDBzDnYyE0
mULsrsrxA/1mCJEIXGXfeWoDjBrduj1SFvbNKE5WMIbE/3C6XH1sytoHWrLKXaE=
=h5sY
-----END PGP SIGNATURE-----
--5p8PegU4iirBW1oA--
From owner-freebsd-net@FreeBSD.ORG Sat May 14 14:52:32 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2A1EC1065673;
Sat, 14 May 2011 14:52:32 +0000 (UTC)
(envelope-from to.my.trociny@gmail.com)
Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com
[209.85.214.54])
by mx1.freebsd.org (Postfix) with ESMTP id 781188FC19;
Sat, 14 May 2011 14:52:30 +0000 (UTC)
Received: by bwz12 with SMTP id 12so4057236bwz.13
for <multiple recipients>; Sat, 14 May 2011 07:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:to:cc:subject:references:x-comment-to
:sender:date:in-reply-to:message-id:user-agent:mime-version
:content-type; bh=6xrLNn5Bh+NIZZVtpY3+ByFrwxFdw9qWWOWnjeSmqrA=;
b=V7+dUom4DebxlJr97i1LcHVN8OUlGOeEvmUqd/5x6oop//cfjccA12RekGuekQx0a7
mZAQ7pZ7d8LdMQ/N64/1iHff7MEFChsKjhNpfCpr79yzBlubLuc2SVWIY2ekHchh9Ey+
bm/DHgIVXxIJf2SBfejmYbLim8i7A6lv0WI3w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to
:message-id:user-agent:mime-version:content-type;
b=Ci+SDcZECA+aM4lefOY3n7d9u1B9UeTFw7T/DrxD8mIP+y1TgUGh0zaGCqUem9+Eig
xSe3eIvJXAU/hVRhKIQf+muAKYkGGLpGCJ2aOF2vWeWoNamKsYJshPak4e6DpGABTP3m
OcxQZ7X9gCU/AhMUdCJAxFEd4TfrboCQnwuSQ=
Received: by 10.204.151.204 with SMTP id d12mr1868841bkw.127.1305384749258;
Sat, 14 May 2011 07:52:29 -0700 (PDT)
Received: from localhost ([95.69.172.154])
by mx.google.com with ESMTPS id d10sm1590806bkw.23.2011.05.14.07.52.27
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 14 May 2011 07:52:28 -0700 (PDT)
From: Mikolaj Golub <trociny@freebsd.org>
To: Chuck Swiger <cswiger@mac.com>
References: <iqk323$f8e$1@dough.gmane.org>
<5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com>
X-Comment-To: Chuck Swiger
Sender: Mikolaj Golub <to.my.trociny@gmail.com>
Date: Sat, 14 May 2011 17:52:25 +0300
In-Reply-To: <5BD73B66-9A84-4640-A43F-4970BDC584BA@mac.com> (Chuck Swiger's
message of "Fri, 13 May 2011 14:38:34 -0700")
Message-ID: <86zkmpl4gm.fsf@kopusha.home.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>,
John Baldwin <jhb@FreeBSD.org>
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 14:52:32 -0000
On Fri, 13 May 2011 14:38:34 -0700 Chuck Swiger wrote:
CS> On May 13, 2011, at 1:07 PM, Ivan Voras wrote:
>> I'm seeing an an unusual problem at a remote machine; this machine is
>> the FreeBSD server, and the client is a probably Windows machine (but I
>> don't know the details yet). Something happens which causes FreeBSD to
>> send ACKs to the client, and the client to send ICMP unreachable
>> messages to the server. It is most likely a configuration error at the
>> remote site but I have no idea how to verify this.
CS> Let's look at just one connection:
CS> 18:56:02.711942 IP server.http > client.4732: Flags [.], ack 2110905191, win 0, length 0
CS> 18:56:02.713155 IP server.http > client.4732: Flags [.], ack 1, win 65535, length 0
CS> The packet is FreeBSD webserver sending ACKs with zero window size;
CS> that's a sign of congestion that the client should not be sending more
CS> data and instead doing periodic window probes until the local box opens
CS> the window again. The next packet on the same connection then ACK's
CS> something outside of the window with a 64K window size. That's wrong;
CS> the other side probably sends an RST and the ICMP error. If you have TSO
CS> enabled, try turning it off.
Might be this the thing that jhb@ was fixing in r221346?
--
Mikolaj Golub
From owner-freebsd-net@FreeBSD.ORG Sat May 14 15:00:04 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 60EA0106564A;
Sat, 14 May 2011 15:00:04 +0000 (UTC) (envelope-from ache@vniz.net)
Received: from vniz.net (vniz.net [194.87.13.69])
by mx1.freebsd.org (Postfix) with ESMTP id C7E7D8FC08;
Sat, 14 May 2011 15:00:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by vniz.net (8.14.4/8.14.4) with ESMTP id p4EEmGha098148;
Sat, 14 May 2011 18:48:16 +0400 (MSD) (envelope-from ache@vniz.net)
Received: (from ache@localhost)
by localhost (8.14.4/8.14.4/Submit) id p4EEmGuC098147;
Sat, 14 May 2011 18:48:16 +0400 (MSD) (envelope-from ache)
Date: Sat, 14 May 2011 18:48:16 +0400
From: Andrey Chernov <ache@freebsd.org>
To: freebsd-net@freebsd.org
Message-ID: <20110514144815.GA98013@vniz.net>
Mail-Followup-To: Andrey Chernov <ache@freebsd.org>,
freebsd-net@freebsd.org, current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: current@freebsd.org
Subject: msk0: watchdog timeout (Yukon EC Ultra)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 15:00:04 -0000
Hi.
With recent -current I start to get
May 14 13:32:48 xxx kernel: msk0: watchdog timeout
May 14 13:32:48 xxx kernel: msk0: link state changed to DOWN
May 14 13:32:51 xxx kernel: msk0: link state changed to UP
with ~10 minutes interval usually at the starting of receiving essential
traffic. I run my on-board Gigabit Ethernet in the 100baseTX mode.
Below is detaled info.
Can anybody help?
mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci2
mskc0: MSI count : 1
mskc0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 258 to local APIC 0 vector 54
mskc0: using IRQ 258 for MSI
mskc0: RAM buffer size : 0KB
msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on mskc0
miibus0: <MII bus> on msk0
e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
e1000phy0: OUI 0x000ac2, model 0x000b, rev. 1
e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
mskc0@pci0:2:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00
vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)'
class = network
subclass = ethernet
cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 03[50] = VPD
cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet 100baseTX <full-duplex> (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
status: active
--
http://ache.vniz.net/
From owner-freebsd-net@FreeBSD.ORG Sat May 14 16:20:28 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 81A78106564A;
Sat, 14 May 2011 16:20:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
by mx1.freebsd.org (Postfix) with ESMTP id 5854B8FC16;
Sat, 14 May 2011 16:20:28 +0000 (UTC)
Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net
[66.111.2.69])
by cyrus.watson.org (Postfix) with ESMTPSA id 07CFF46B1A;
Sat, 14 May 2011 12:20:28 -0400 (EDT)
Received: from John-Baldwins-Macbook-Pro.local (unknown [192.75.139.253])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DE698A04F;
Sat, 14 May 2011 12:20:27 -0400 (EDT)
Message-ID: <4DCEABCB.9000501@FreeBSD.org>
Date: Sat, 14 May 2011 12:20:27 -0400
From: John Baldwin <jhb@FreeBSD.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jason Hellenthal <jhell@DataIX.net>
References: <iqk323$f8e$1@dough.gmane.org> <20110514125305.GC13970@DataIX.net>
In-Reply-To: <20110514125305.GC13970@DataIX.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
(bigwig.baldwin.cx); Sat, 14 May 2011 12:20:27 -0400 (EDT)
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject: Re: Spurious ACKs, ICMP unreachable?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 16:20:28 -0000
On 5/14/11 8:53 AM, Jason Hellenthal wrote:
>
> Ivan,
>
> I was also going to mention these threads in the previous message to
> this list.
>
> This is the thread that ended up getting committed and MFC'd from the
> previous mesage.
>
> Feb 08 John Baldwin ( 73) TCP can advertise a really huge window
>
>
> These is does not seem anything more has happened with them.
> Feb 08 John Baldwin ( 88) A small TCP bug: excessive duplicate ACKs
> Feb 08 John Baldwin ( 244) TCP connections stuck inpersist state
All three are committed and on track to be MFC'd in the not too distant
future. I have used them in production on 7 for many months.
--
John Baldwin
From owner-freebsd-net@FreeBSD.ORG Sat May 14 16:40:11 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 3EA931065678
for <freebsd-net@hub.freebsd.org>; Sat, 14 May 2011 16:40:11 +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 2DABA8FC18
for <freebsd-net@hub.freebsd.org>; Sat, 14 May 2011 16:40:11 +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 p4EGeAPF040879
for <freebsd-net@freefall.freebsd.org>; Sat, 14 May 2011 16:40:10 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4EGeArv040878;
Sat, 14 May 2011 16:40:10 GMT (envelope-from gnats)
Date: Sat, 14 May 2011 16:40:10 GMT
Message-Id: <201105141640.p4EGeArv040878@freefall.freebsd.org>
To: freebsd-net@FreeBSD.org
From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
Cc:
Subject: Re: kern/123463: [ipsec] [panic] repeatable crash related to
ipsec-tools
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Matthew Seaman <m.seaman@infracaninophile.co.uk>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2011 16:40:11 -0000
The following reply was made to PR kern/123463; it has been noted by GNATS.
From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
To: bug-followup@FreeBSD.org
Cc:
Subject: Re: kern/123463: [ipsec] [panic] repeatable crash related to ipsec-tools
Date: Sat, 14 May 2011 17:34:19 +0100
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig18EFA195310045D07DB24B02
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This PR was submitteted by me when at a former employer. Given the
elapsed time, and the fact I'm not there any more, it's unlikely to be
able to be progressed any further. Please close.
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enig18EFA195310045D07DB24B02
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3OrxEACgkQ8Mjk52CukIxVLwCcCcr5s0LjpQKppALm7aKTbWiq
2sQAn3pqVI/OkV1h43gS3nV4xIBvy10R
=6GEz
-----END PGP SIGNATURE-----
--------------enig18EFA195310045D07DB24B02--