From owner-freebsd-net@FreeBSD.ORG Sun Sep 9 14:39:16 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A4F16A418; Sun, 9 Sep 2007 14:39:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx03.syd.optusnet.com.au (fallbackmx03.syd.optusnet.com.au [211.29.133.136]) by mx1.freebsd.org (Postfix) with ESMTP id F31C213C46E; Sun, 9 Sep 2007 14:39:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx03.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l88DgCbA014906; Sat, 8 Sep 2007 23:42:17 +1000 Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l88DfvtP004027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2007 23:42:04 +1000 Date: Sat, 8 Sep 2007 23:41:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bakul Shah In-Reply-To: <20070907235622.C410D5B58@mail.bitblocks.com> Message-ID: <20070908220703.Y32678@besplex.bde.org> References: <20070907235622.C410D5B58@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Kirc Gover , Andre Oppermann Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 14:39:17 -0000 On Fri, 7 Sep 2007, Bakul Shah wrote: >> This is not the case. Flood ping doesn't reach the limit in any >> way. Have a look at the ping man page and flood ping description. > > Ah yes, I was forgetting about the strict synchrony. Flood ping neither floods nor is synchronous. As documented, it outputs packets as fast as they come back or 100 times per second, whichever is more. The magic 100 was a good approximation to infinity at 1Mbps, but it scales poorly. I see the following behaviour on a 1Gbps network that has a ping latency of ~100 usec: - initially the throughput is ~10 kpps, due to strict synchrony (sp?). The 100 Hz timeout is almost irrelevant because 100 is much less than 10k. - the throughput gradually (after about 1 minute) ramps up to ~120 kpps (equals only about 1/5 of ttcp max transmit-only throughput which saturates the transmitter). My explanation for this is that one side gets behind due to random delays and/or accidental sync with the 100 Hz timeout. Then the synchrony is not per-packet, but per burst of packets, where the burst size is some combination of the random delays, the magic 100, and the software and/or hardware queue lengths. The magic 100 is hard to increase much, since it is implemented as a timeout and timeouts have limited resolution. Utilities like ttcp have similar problems from this -- they tend to leave the network idle while they are waiting for a timeout, or are reduced to busy-waiting. On the same systems that have the highly variable ping throughput of 10-120 kpps due to the ramp-up: Modifying flood ping to actually flood gives a throughput of ~170 kpps at a cost of approximately doubling the latency. Modifying flood ping to be synchronous gives a constant throughput of ~8kpps. Apparently my ping throughput was never initially 10 kpps -- 10 is after some ramp-up, while 8 is consistent with the latency. The average latency at the time of measurement was 122 uS but I misremembered it as 95 uS. Bruce From owner-freebsd-net@FreeBSD.ORG Sun Sep 9 20:23:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C433416A41A; Sun, 9 Sep 2007 20:23:55 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from XSMTP0.ethz.ch (xsmtp0.ethz.ch [82.130.70.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4020D13C494; Sun, 9 Sep 2007 20:23:55 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from xfe2.d.ethz.ch ([82.130.124.42]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:18:36 +0200 Received: from bike-planet.inf.ethz.ch ([80.218.230.225]) by xfe2.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:18:35 +0200 Received: by bike-planet.inf.ethz.ch (Postfix, from userid 1001) id A99A11D212B; Sun, 9 Sep 2007 22:18:38 +0200 (CEST) Date: Sun, 9 Sep 2007 22:18:37 +0200 From: Matus Harvan To: freebsd-net@freebsd.org Message-ID: <20070909201837.GA18107@inf.ethz.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-OriginalArrivalTime: 09 Sep 2007 20:18:36.0208 (UTC) FILETIME=[9A073300:01C7F31E] Cc: Max Laier , Brooks Davis , mharvan@inf.ethz.ch Subject: UDP catchall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:23:56 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I am a Google Summer of Code student working on mtund, aka Magic Tunnel Daemon aka Super Tunnel Daemon, http://wiki.freebsd.org/SuperTunnelDaemon. For mtund it would be useful to listen on all unused UDP ports, allowing a client behind firewall to use any possible hole it could find. To achieve this, the easiest way seems to be to allow a raw IP/UDP socket to receive UDP traffic that no regular UDP socket wants. In the kernel this means passing the mbuf from udp_input to rip_input(). Upon receiving a packet, the user space program would inspect the UDP header and create a UDP socket bound to the correct local port and connected to the right remote port and address. The user space usage would then look as follows: fd =3D socket(AF_INET, SOCK_RAW, IPPROTO_UDP); recvfrom(fd, ...); /* parse the UDP header for the source and destination addresses */ new_fd =3D socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); bind(new_fd, ...); connect(new_fd, ...); This catchall feature could be enabled/disabled via a sysctl variable, net.inet.raw.udp_catchall. Furthermore, a rate limit could be used to mitigate possible DoS misuse. A simple testing program can be found under http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/soc2007/mharvan-mtun= d/sys.patches/test_catchall/&c=3Dxpc@//depot/projects/soc2007/mharvan-mtund= /sys.patches/test_catchall/ucatchalld.c?ac=3D22 and a more complex example is the udp catchall plugin for mtund http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/soc2007/mharvan-mtun= d/mtund.src/&c=3DSM3@//depot/projects/soc2007/mharvan-mtund/mtund.src/plugi= n_udp_catchall.c?ac=3D22 Matus patch: Index: udp_usrreq.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 RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.216 diff -d -u -r1.216 udp_usrreq.c --- udp_usrreq.c 10 Jul 2007 09:30:46 -0000 1.216 +++ udp_usrreq.c 6 Sep 2007 21:59:31 -0000 @@ -125,6 +125,15 @@ SYSCTL_ULONG(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW, &udp_recvspace, 0, "Maximum space for incoming UDP datagrams"); =20 +static int udp_catchall =3D 0; +SYSCTL_INT(_net_inet_raw, OID_AUTO, udp_catchall, CTLFLAG_RW | CTLFLAG_SEC= URE, + &udp_catchall, 0, "Raw IP UDP sockets receive unclaimed UDP datagrams"); + +static int catchalllim =3D 5; +SYSCTL_INT(_net_inet_udp, OID_AUTO, catchalllim, CTLFLAG_RW | CTLFLAG_SECU= RE, + &catchalllim, 0, + "Rate limit on received UDP datagrams due to udp_catchall"); + struct inpcbhead udb; /* from udp_var.h */ struct inpcbinfo udbinfo; =20 @@ -136,6 +145,11 @@ SYSCTL_STRUCT(_net_inet_udp, UDPCTL_STATS, stats, CTLFLAG_RW, &udpstat, udpstat, "UDP statistics (struct udpstat, netinet/udp_var.h)"); =20 +static struct rate { + struct timeval lasttime; + int curpps; +} catchallr; + static void udp_detach(struct socket *so); static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, struct mbuf *, struct thread *); @@ -515,6 +529,35 @@ */ inp =3D in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, ip->ip_dst, uh->uh_dport, 1, ifp); + + /* catchall socket */ + if (inp =3D=3D NULL && udp_catchall !=3D 0) { +#ifdef DIAGNOSTIC + printf("IP UDP catchall active\n"); + char dbuf[INET_ADDRSTRLEN], sbuf[INET_ADDRSTRLEN]; + strcpy(dbuf, inet_ntoa(ip->ip_dst)); + strcpy(sbuf, inet_ntoa(ip->ip_src)); + printf("\tip_src: %s, sport: %hu\n\tip_dst: %s, dport: %hu\n", + sbuf, ntohs(uh->uh_sport), dbuf, ntohs(uh->uh_dport)); +#endif + + /* rate limiting */ + if (catchalllim > 0)=20 + if (ppsratecheck(&catchallr.lasttime, + &catchallr.curpps, catchalllim)) { + rip_input(m, off); + INP_INFO_RUNLOCK(&udbinfo); + return; + } +#ifdef DIAGNOSTIC + else + printf("ppsratecheck limited " + "udp_catchall\n"); + else + printf("ppsratecheck limited udp_catchall\n"); +#endif + } + if (inp =3D=3D NULL) { if (udp_log_in_vain) { char buf[4*sizeof "123"]; --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5FUd43LQWDWf0QIRAtWyAJ94JyjXtEY5Dl+9u/QN3KfOTsrQuACgirmD aHyP2ELbRkFzvCpev/9d1Zk= =4L3p -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 9 20:23:56 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF18416A417 for ; Sun, 9 Sep 2007 20:23:56 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from XSMTP0.ethz.ch (xsmtp0.ethz.ch [82.130.70.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6BC13C4A6 for ; Sun, 9 Sep 2007 20:23:56 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from xfe2.d.ethz.ch ([82.130.124.42]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:11:50 +0200 Received: from bike-planet.inf.ethz.ch ([80.218.230.225]) by xfe2.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:11:50 +0200 Received: by bike-planet.inf.ethz.ch (Postfix, from userid 1001) id 5C8981D212B; Sun, 9 Sep 2007 22:11:53 +0200 (CEST) Date: Sun, 9 Sep 2007 22:11:52 +0200 From: Matus Harvan To: freebsd-net@freebsd.org Message-ID: <20070909201152.GA18039@inf.ethz.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-OriginalArrivalTime: 09 Sep 2007 20:11:50.0169 (UTC) FILETIME=[A8029090:01C7F31D] Cc: Max Laier , Brooks Davis , mharvan@inf.ethz.ch Subject: icmp echo_user X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:23:56 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I am a Google Summer of Code student working on mtund, aka Magic Tunnel Daemon aka Super Tunnel Daemon, http://wiki.freebsd.org/SuperTunnelDaemon. For mtund it would be useful to tunnel in ICMP echo request/reply pairs. For this being able to receive ICMP echo requests in the user space would be helpful. Currently, ICMP echo requests are processed in the kernel where an ICMP echo reply is generated, but they are not passed to the user space. I would suggest the patch below, adding a sysctl variable net.inet.icmp.echo_user, allowing to recevie the ICMP echo requests in the user space on a raw IP/ICMP socket rather than having the kernel generate a reply to them. Matus patch: Index: ip_icmp.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 RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.117 diff -d -u -r1.117 ip_icmp.c --- ip_icmp.c 19 Jul 2007 22:34:25 -0000 1.117 +++ ip_icmp.c 6 Sep 2007 21:26:08 -0000 @@ -124,6 +124,10 @@ SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, &icmpbmcastecho, 0, ""); =20 +static int icmpechouser =3D 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, echo_user, CTLFLAG_RW | CTLFLAG_SECUR= E, + &icmpechouser, 0, "Pass ICMP echo requests to userspace rather tha= n" + "replying to them in the kernel"); =20 #ifdef ICMPPRINTFS int icmpprintfs =3D 0; @@ -454,6 +458,9 @@ break; =20 case ICMP_ECHO: + if (icmpechouser) + goto raw; + if (!icmpbmcastecho && (m->m_flags & (M_MCAST | M_BCAST)) !=3D 0) { icmpstat.icps_bmcastecho++; --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5FOI43LQWDWf0QIRAiQyAJ9PvtTv2OxaBPpZRum6M2PSC0KkkwCbBt48 YHpjkNJzXpS541oC/r58pCw= =WGkU -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 9 20:41:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D11716A41B; Sun, 9 Sep 2007 20:41:48 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from xsmtp1.ethz.ch (xsmtp1.ethz.ch [82.130.70.13]) by mx1.freebsd.org (Postfix) with ESMTP id B61F813C465; Sun, 9 Sep 2007 20:41:47 +0000 (UTC) (envelope-from matus.harvan@inf.ethz.ch) Received: from xfe2.d.ethz.ch ([82.130.124.42]) by xsmtp1.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:41:46 +0200 Received: from bike-planet.inf.ethz.ch ([80.218.230.225]) by xfe2.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Sep 2007 22:41:45 +0200 Received: by bike-planet.inf.ethz.ch (Postfix, from userid 1001) id EF4171D212B; Sun, 9 Sep 2007 22:41:48 +0200 (CEST) Date: Sun, 9 Sep 2007 22:41:48 +0200 From: Matus Harvan To: freebsd-net@freebsd.org Message-ID: <20070909204148.GB18107@inf.ethz.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-OriginalArrivalTime: 09 Sep 2007 20:41:46.0032 (UTC) FILETIME=[D66D8300:01C7F321] Cc: Max Laier , Brooks Davis , mharvan@inf.ethz.ch Subject: TCP listenall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:41:48 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I am a Google Summer of Code student working on mtund, aka Magic Tunnel Daemon aka Super Tunnel Daemon, http://wiki.freebsd.org/SuperTunnelDaemon. For mtund it would be useful to listen on all unused TCP ports, allowing a client behind firewall to use any possible hole it could find. To achieve this I would suggest the patch below. It would add a socket option TCP_LISTENALL. This clearly could only be set on one socket. When activated, the global variable inp_tlistenall would be used to assign traffic to unused TCP ports to that socket. In particular, the changed code in tcp_input() would be used twice - once for the SYN packet (1st packet) and once for the ACK packet (3rd packet). inp_tlistenall is protected by the INP_INFO lock on tcbinfo in all places. The patch also includes rate limiting to mitigate possible DoS misuse. With listenall enabled, a portscan becomes a syn flood. However, as there are already mechanisms to protect against a syn flood attack, such as syncache and syncookies, the rate limit might be left out. The disadvanatage of the rate limit is that a portscan becomes a DoS against the listenall socket. A testing program is available in perforce: http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/soc2007/mharvan-mtun= d/sys.patches/test_catchall/&c=3Dxpc@//depot/projects/soc2007/mharvan-mtund= /sys.patches/test_catchall/tcatchalld.c?ac=3D22 Note that the tcp listenall feature would be usefull to other programs beyond mtund, i.e., a modified ssh daemon for people who won't be able to run mtund, but will be able to run ssh. Matus patch: Index: netinet/tcp.h =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 RCS file: /home/ncvs/src/sys/netinet/tcp.h,v retrieving revision 1.40 diff -d -u -r1.40 tcp.h --- netinet/tcp.h 25 May 2007 21:28:49 -0000 1.40 +++ netinet/tcp.h 8 Sep 2007 10:35:57 -0000 @@ -147,6 +147,7 @@ #define TCP_NOOPT 0x08 /* don't use TCP options */ #define TCP_MD5SIG 0x10 /* use MD5 digests (RFC2385) */ #define TCP_INFO 0x20 /* retrieve tcp_info structure */ +#define TCP_LISTENALL 0x40 /* listen on all unused TCP ports */ =20 #define TCPI_OPT_TIMESTAMPS 0x01 #define TCPI_OPT_SACK 0x02 Index: netinet/tcp_input.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 RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.367 diff -d -u -r1.367 tcp_input.c --- netinet/tcp_input.c 30 Jul 2007 11:06:41 -0000 1.367 +++ netinet/tcp_input.c 8 Sep 2007 10:35:57 -0000 @@ -144,9 +144,15 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, recvbuf_max, CTLFLAG_RW, &tcp_autorcvbuf_max, 0, "Max size of automatic receive buffer"); =20 +static int listenalllim =3D 5; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, listenalllim, CTLFLAG_RW | CTLFLAG_SEC= URE, + &listenalllim, 0, + "Rate limit on sockets created by the TCP_LISTENALL socket"); + struct inpcbhead tcb; #define tcb6 tcb /* for KAME src sync over BSD*'s */ struct inpcbinfo tcbinfo; +struct inpcb *inp_tlistenall; /* listening on all unused TCP ports */ =20 static void tcp_dooptions(struct tcpopt *, u_char *, int, int); static void tcp_do_segment(struct mbuf *, struct tcphdr *, @@ -258,6 +264,11 @@ struct tcphdr tcp_savetcp; short ostate =3D 0; #endif + static struct rate { + struct timeval lasttime; + int curpps; + } listenallr; + =20 #ifdef INET6 isipv6 =3D (mtod(m, struct ip *)->ip_v =3D=3D 6) ? 1 : 0; @@ -460,6 +471,36 @@ goto dropunlock; } #endif /* IPSEC */ + + /* listenall socket */ + if ((inp =3D=3D NULL) && (inp_tlistenall !=3D NULL)) { +#ifdef DIAGNOSTIC + printf("listenall socket used (0x%x)\n", + (unsigned int)inp_tlistenall); + char dbuf[INET_ADDRSTRLEN], sbuf[INET_ADDRSTRLEN]; + strcpy(dbuf, inet_ntoa(ip->ip_dst)); + strcpy(sbuf, inet_ntoa(ip->ip_src)); + printf("\tip_src: %s, sport: %hu\n\tip_dst: %s, dport: %hu\n", + sbuf, ntohs(th->th_sport), dbuf, ntohs(th->th_dport)); +#endif + /* do rate limiting for SYN packets */ + if (thflags & TH_SYN) { + if (listenalllim > 0)=20 + if (ppsratecheck(&listenallr.lasttime, + &listenallr.curpps, listenalllim)) + inp =3D inp_tlistenall; +#ifdef DIAGNOSTIC + else + printf("ppsratecheck limited " + "tcp_listenall\n"); +#endif +#ifdef DIAGNOSTIC + else + printf("ppsratecheck limited tcp_listenall\n"); +#endif + } else + inp =3D inp_tlistenall; + } =20 /* * If the INPCB does not exist then all data in the incoming Index: netinet/tcp_subr.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 RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.296 diff -d -u -r1.296 tcp_subr.c --- netinet/tcp_subr.c 16 Aug 2007 01:35:55 -0000 1.296 +++ netinet/tcp_subr.c 8 Sep 2007 10:35:57 -0000 @@ -264,6 +264,7 @@ tcp_rexmit_slop =3D TCPTV_CPU_VAR; tcp_inflight_rttthresh =3D TCPTV_INFLIGHT_RTTTHRESH; tcp_finwait2_timeout =3D TCPTV_FINWAIT2_TIMEOUT; + inp_tlistenall =3D NULL; =20 INP_INFO_LOCK_INIT(&tcbinfo, "tcp"); LIST_INIT(&tcb); Index: netinet/tcp_usrreq.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 RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.160 diff -d -u -r1.160 tcp_usrreq.c --- netinet/tcp_usrreq.c 30 Jul 2007 11:06:41 -0000 1.160 +++ netinet/tcp_usrreq.c 8 Sep 2007 10:35:57 -0000 @@ -48,6 +48,7 @@ #endif /* INET6 */ #include #include +#include #include #include #include @@ -162,6 +163,13 @@ KASSERT(so->so_pcb =3D=3D inp, ("tcp_detach: so_pcb !=3D inp")); KASSERT(inp->inp_socket =3D=3D so, ("tcp_detach: inp_socket !=3D so")); =20 + if (inp =3D=3D inp_tlistenall) { +#ifdef DIAGNOSTIC + printf("deactivating TCP_LISTENALL - socket closed\n"); +#endif + inp_tlistenall =3D NULL; + } + tp =3D intotcpcb(inp); =20 if (inp->inp_vflag & INP_TIMEWAIT) { @@ -1338,6 +1346,29 @@ error =3D EINVAL; break; =20 + case TCP_LISTENALL: + error =3D sooptcopyin(sopt, &optval, sizeof optval, + sizeof optval); + if (error) + break; + + priv_check(curthread, + PRIV_NETINET_TCP_LISTENALL); + if (error !=3D 0) + break; + + if (optval > 0) /* enable LISTENALL */ + if (inp_tlistenall =3D=3D NULL) + inp_tlistenall =3D inp; + else + error =3D EBUSY; + + else /* disable LISTENALL */ + if (inp_tlistenall =3D=3D inp) + inp_tlistenall =3D NULL; + + break; + default: error =3D ENOPROTOOPT; break; @@ -1371,6 +1402,13 @@ case TCP_INFO: tcp_fill_info(tp, &ti); error =3D sooptcopyout(sopt, &ti, sizeof ti); + break; + case TCP_LISTENALL: + if (inp =3D=3D inp_tlistenall) =20 + optval =3D 1; + else + optval =3D 0; + error =3D sooptcopyout(sopt, &optval, sizeof optval); break; default: error =3D ENOPROTOOPT; Index: netinet/tcp_var.h =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 RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.155 diff -d -u -r1.155 tcp_var.h --- netinet/tcp_var.h 28 Jul 2007 12:20:39 -0000 1.155 +++ netinet/tcp_var.h 8 Sep 2007 10:35:57 -0000 @@ -493,6 +493,7 @@ =20 extern struct inpcbhead tcb; /* head of queue of active tcpcb's */ extern struct inpcbinfo tcbinfo; +extern struct inpcb *inp_tlistenall; /* listening on all unused TCP ports= */ extern struct tcpstat tcpstat; /* tcp statistics */ extern int tcp_log_in_vain; extern int tcp_mssdflt; /* XXX */ Index: sys/priv.h =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 RCS file: /home/ncvs/src/sys/sys/priv.h,v retrieving revision 1.15 diff -d -u -r1.15 priv.h --- sys/priv.h 18 Jun 2007 07:54:27 -0000 1.15 +++ sys/priv.h 8 Sep 2007 10:35:58 -0000 @@ -374,6 +374,7 @@ #define PRIV_NETINET_ALIFETIME6 502 /* Administer IPv6 address lifetimes. = */ #define PRIV_NETINET_IPSEC 503 /* Administer IPSEC. */ #define PRIV_NETINET_REUSEPORT 504 /* Allow [rapid] port/address reuse. */ +#define PRIV_NETINET_TCP_LISTENALL 505 /* Allow setting TCP_LISTENALL */ =20 /* * IPX/SPX privileges. --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5FqM43LQWDWf0QIRAla4AKCq3dmIZPPzHawK1cnkMNxkr59kxQCgly75 6VElx/PTljiFYwbH4b9S2bs= =M4FW -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 9 20:46:45 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B548D16A420 for ; Sun, 9 Sep 2007 20:46:45 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2771313C4DB for ; Sun, 9 Sep 2007 20:46:44 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so1265462fka for ; Sun, 09 Sep 2007 13:46:43 -0700 (PDT) Received: by 10.82.175.17 with SMTP id x17mr4250086bue.1189370803113; Sun, 09 Sep 2007 13:46:43 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Sun, 9 Sep 2007 13:46:43 -0700 (PDT) Message-ID: Date: Sun, 9 Sep 2007 23:46:43 +0300 From: "Vlad GALU" To: "Fabien THOMAS" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:46:45 -0000 On 9/6/07, Fabien THOMAS wrote: > Hi, > > After many years of good services we will stop using FreeBSD 4.x :) > During my performance regression tests under FreeBSD 6.2 i've found > that polling has lower performance than interrupt. > To solve that issue i've rewritten the core of polling to be more SMP > ready. > > You can find a summary of all my tests and the source code at the > following address: > http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz > > Feel free to ask more detailed information if necessary and report > any bugs / comments. > Fabien, since you have the necesary hardware to stimulate the FreeBSD box, would it be too much to ask you to run some packet capture tests with your polling implementation and the capturing interface set to IFF_MONITOR? The userland program should use pcap and simply increment a counter and spit out capture average once every N seconds. It would be very interesting to see how polling affects packet capture, with varying BPF buffer sizes. > Fabien > > > _______________________________________________ > 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" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 01:30:02 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E4916A417 for ; Mon, 10 Sep 2007 01:30:02 +0000 (UTC) (envelope-from nuno.antunes@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2C38A13C483 for ; Mon, 10 Sep 2007 01:30:01 +0000 (UTC) (envelope-from nuno.antunes@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so700549nfd for ; Sun, 09 Sep 2007 18:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=P99c++HHAoUlOTaaz9LHoDm4zzihtcYuq9Xi4WKrEhA=; b=qZ3RMNkTw9qH7l/11g+W8UblCcmw0uZ7xPQF28fIwM/j4g3jhhd1oYp62M7KG+W0o/5srC9zLI2sIWAPk6qHNnEUb3A3DhYN4q2YZbuFkfAuzXGs2tIf1+xNDNk4dcKttQZ+9w+dsG9Z70HJ5K8ZLj1NodYgc7LJkalaFNNpOdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cDbYCiOvNAdTA5I6bSOg8Zvc/nHpJ7GlJRQcanGhK8cbsNYzEO/6WTR5jk0m6A9Vi+pqMWvmc6G/t41VJ1nUiKeQChCXfaHaltIirm+ZhowhRVsWKXrSKVXXjKEShbLgZNsXcUBA9YgE9xAyHplc3ospFLFNghTgIa5FuJf2fUI= Received: by 10.86.60.7 with SMTP id i7mr3295007fga.1189386210314; Sun, 09 Sep 2007 18:03:30 -0700 (PDT) Received: by 10.86.3.15 with HTTP; Sun, 9 Sep 2007 18:03:25 -0700 (PDT) Message-ID: <262949390709091803s507265e6mf3929c4dd26ecc56@mail.gmail.com> Date: Mon, 10 Sep 2007 02:03:25 +0100 From: "Nuno Antunes" To: "Tom Judge" In-Reply-To: <20070907185757.GA25624@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E11515.8090007@tomjudge.com> <46E174DB.8070004@FreeBSD.org> <20070907185757.GA25624@kobe.laptop> Cc: Giorgos Keramidas , freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 01:30:02 -0000 > > Tom Judge wrote: > >> Hi, > >> While making some changes to the routing table on one of our routers > >> today I noticed that "route add" was showing some strange > >> behaviour. When adding a route for 128/8 to the table rather than > >> adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works > >> correctly. > >> > >> Is this a bug in route or the routing table? > > Hi, Can you take a look at this patch, please? http://leaf.dragonflybsd.org/mailarchive/submit/2007-09/msg00000.html Thanks, Nuno From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 02:48:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71BC016A419 for ; Mon, 10 Sep 2007 02:48:09 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.68.41]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1F913C478 for ; Mon, 10 Sep 2007 02:48:09 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l8A1nhTb018270 for ; Sun, 9 Sep 2007 20:49:43 -0500 (CDT) Date: Sun, 9 Sep 2007 20:49:43 -0500 (CDT) From: Scott Bennett Message-Id: <200709100149.l8A1nhLv018269@mp.cs.niu.edu> To: freebsd-net@freebsd.org Subject: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 02:48:09 -0000 My Dell Inspiron XPS has just one built-in Ethernet port, and I need to have at least one other. Armed with a printed copy of Section 3.2 of the FreeBSD 6.2 Harware Notes, I went to the several electronics stores, looking to find a device on the list of supported devices. Eventually, I found and bought two Linksys USB200M Compact USB 2.0 Network Adapters, which are listed in the Hardware Notes as being supported by the axe(4) driver. Comments in if_axe.c specifically refer to the USB200M as a supported model. So, thinking I had found what I needed, I hooked one up to a USB port and booted my FreeBSD 6.2-STABLE system. The kernel did recognize that there was something attached to the USB port, but the device type was not identified, and no driver was associated with it, and therefore no axe0 network interface was created in the kernel. I've also tried connecting the card while the system was already up and running. Here's the resulting message in /var/log/messages: Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 Disconnecting the device yielded the following messages: Sep 9 20:36:15 hellas kernel: ugen0: at uhub4 port 6 (addr 3) disconnected Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.3 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.2 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.1 Sep 9 20:36:15 hellas kernel: All threads purged from ugen0 Sep 9 20:36:15 hellas kernel: ugen0: detached Is the Linksys USB200M supported or not? What am I missing here? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 08:36:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF11916A419 for ; Mon, 10 Sep 2007 08:36:28 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id 393A413C458 for ; Mon, 10 Sep 2007 08:36:27 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([213.206.147.173]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Mon, 10 Sep 2007 08:36:15 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 012A5181427; Mon, 10 Sep 2007 09:36:14 +0100 (BST) Message-ID: <46E501FE.7050809@tomjudge.com> Date: Mon, 10 Sep 2007 09:36:14 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Scott Bennett References: <200709100149.l8A1nhLv018269@mp.cs.niu.edu> In-Reply-To: <200709100149.l8A1nhLv018269@mp.cs.niu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 08:36:29 -0000 Scott Bennett wrote: > My Dell Inspiron XPS has just one built-in Ethernet port, and I need to > have at least one other. Armed with a printed copy of Section 3.2 of the > FreeBSD 6.2 Harware Notes, I went to the several electronics stores, looking > to find a device on the list of supported devices. Eventually, I found and > bought two Linksys USB200M Compact USB 2.0 Network Adapters, which are listed > in the Hardware Notes as being supported by the axe(4) driver. Comments in > if_axe.c specifically refer to the USB200M as a supported model. > So, thinking I had found what I needed, I hooked one up to a USB port > and booted my FreeBSD 6.2-STABLE system. The kernel did recognize that there > was something attached to the USB port, but the device type was not identified, > and no driver was associated with it, and therefore no axe0 network interface > was created in the kernel. I've also tried connecting the card while the > system was already up and running. Here's the resulting message in > /var/log/messages: > > Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 > > Disconnecting the device yielded the following messages: > > Sep 9 20:36:15 hellas kernel: ugen0: at uhub4 port 6 (addr 3) disconnected > Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.3 > Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.2 > Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.1 > Sep 9 20:36:15 hellas kernel: All threads purged from ugen0 > Sep 9 20:36:15 hellas kernel: ugen0: detached > > Is the Linksys USB200M supported or not? What am I missing here? > Hi, Try removing the device from the system then running "kldload if_axe" and then plugging the device back in. It should then be detected correctly. Tom From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 11:08:14 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 885D916A4C9 for ; Mon, 10 Sep 2007 11:08:14 +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 2FCC013C46C for ; Mon, 10 Sep 2007 11:08:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8AB8ExK017328 for ; Mon, 10 Sep 2007 11:08:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8AB8DHS017324 for freebsd-net@FreeBSD.org; Mon, 10 Sep 2007 11:08:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Sep 2007 11:08:13 GMT Message-Id: <200709101108.l8AB8DHS017324@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:08:14 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge o kern/116172 net Network / ipv6 recursive mutex panic 2 problems total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116185 net if_iwi driver leads system to reboot o kern/116186 net can not set wi channel on current 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 11:24:36 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AE616A418; Mon, 10 Sep 2007 11:24:36 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7C61113C459; Mon, 10 Sep 2007 11:24:35 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8AB5jLY019880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Sep 2007 14:05:54 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8AB5Tsf002713; Mon, 10 Sep 2007 14:05:44 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8AB5SIV002712; Mon, 10 Sep 2007 14:05:28 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 10 Sep 2007 14:05:28 +0300 From: Giorgos Keramidas To: Nuno Antunes Message-ID: <20070910110528.GB2476@kobe.laptop> References: <46E11515.8090007@tomjudge.com> <46E174DB.8070004@FreeBSD.org> <20070907185757.GA25624@kobe.laptop> <262949390709091803s507265e6mf3929c4dd26ecc56@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <262949390709091803s507265e6mf3929c4dd26ecc56@mail.gmail.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.073, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.33, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Tom Judge , freebsd-net@FreeBSD.org, "Bruce M. Simpson" Subject: Re: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:24:36 -0000 On 2007-09-10 02:03, Nuno Antunes wrote: >>> Tom Judge wrote: >>>> Hi, >>>> While making some changes to the routing table on one of our routers >>>> today I noticed that "route add" was showing some strange >>>> behaviour. When adding a route for 128/8 to the table rather than >>>> adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works >>>> correctly. >>>> >>>> Is this a bug in route or the routing table? > > Hi, > Can you take a look at this patch, please? > > http://leaf.dragonflybsd.org/mailarchive/submit/2007-09/msg00000.html Fantastic, thanks for the pointer! :-) Skimming fast through the diff it seems to be ok. It doesn't apply cleanly over HEAD so some merging was required to get this version instead: %%% diff -r 3624c4072e63 sbin/route/route.c --- a/sbin/route/route.c Fri Sep 07 09:19:22 2007 +0000 +++ b/sbin/route/route.c Mon Sep 10 14:02:01 2007 +0300 @@ -799,18 +799,19 @@ inet_makenetandmask(net, sin, bits) rtm_addrs |= RTA_NETMASK; if (net == 0) mask = addr = 0; - else if (net < 128) { - addr = net << IN_CLASSA_NSHIFT; - mask = IN_CLASSA_NET; - } else if (net < 65536) { - addr = net << IN_CLASSB_NSHIFT; - mask = IN_CLASSB_NET; - } else if (net < 16777216L) { - addr = net << IN_CLASSC_NSHIFT; - mask = IN_CLASSC_NET; - } else { - addr = net; - if ((addr & IN_CLASSA_HOST) == 0) + else { + if (net <= 0xff) + addr = net << IN_CLASSA_NSHIFT; + else if (net < 0xffff) + addr = net << IN_CLASSB_NSHIFT; + else if (net < 0xffffff) + addr = net << IN_CLASSC_NSHIFT; + else + addr = net; + + if (bits) + mask = 0xffffffff << (32 - bits); + else if ((addr & IN_CLASSA_HOST) == 0) mask = IN_CLASSA_NET; else if ((addr & IN_CLASSB_HOST) == 0) mask = IN_CLASSB_NET; @@ -819,8 +820,6 @@ inet_makenetandmask(net, sin, bits) else mask = -1; } - if (bits) - mask = 0xffffffff << (32 - bits); sin->sin_addr.s_addr = htonl(addr); sin = &so_mask.sin; sin->sin_addr.s_addr = htonl(mask); %%% With this version, I can successfully add *and* delete a route for 128/8 on my laptop and route -nv monitor reports: # got message of size 132 on Mon Sep 10 14:03:56 2007 # RTM_ADD: Add Route: len 132, pid: 2698, seq 1, errno 0, # flags: # locks: inits: # sockaddrs: # 128.0.0.0 127.0.0.1 (0) 0 ff # # got message of size 132 on Mon Sep 10 14:03:57 2007 # RTM_DELETE: Delete Route: len 132, pid: 2702, seq 1, errno 0, # flags: # locks: inits: # sockaddrs: # 128.0.0.0 127.0.0.1 (255) ffff ff From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 11:57:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAD716A417; Mon, 10 Sep 2007 11:57:07 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1347D13C45A; Mon, 10 Sep 2007 11:57:06 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8ABusVc022447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Sep 2007 14:57:00 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8ABucJs009390; Mon, 10 Sep 2007 14:56:53 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8ABubw9009389; Mon, 10 Sep 2007 14:56:37 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 10 Sep 2007 14:56:36 +0300 From: Giorgos Keramidas To: Nuno Antunes Message-ID: <20070910115636.GA8326@kobe.laptop> References: <46E11515.8090007@tomjudge.com> <46E174DB.8070004@FreeBSD.org> <20070907185757.GA25624@kobe.laptop> <262949390709091803s507265e6mf3929c4dd26ecc56@mail.gmail.com> <20070910110528.GB2476@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910110528.GB2476@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.071, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.33, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Tom Judge , freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:57:07 -0000 On 2007-09-10 14:05, Giorgos Keramidas wrote: > On 2007-09-10 02:03, Nuno Antunes wrote: > >>> Tom Judge wrote: > >>>> Hi, > >>>> While making some changes to the routing table on one of our routers > >>>> today I noticed that "route add" was showing some strange > >>>> behaviour. When adding a route for 128/8 to the table rather than > >>>> adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works > >>>> correctly. > >>>> > >>>> Is this a bug in route or the routing table? > > > > Hi, > > Can you take a look at this patch, please? > > > > http://leaf.dragonflybsd.org/mailarchive/submit/2007-09/msg00000.html > > Fantastic, thanks for the pointer! :-) > > Skimming fast through the diff it seems to be ok. It doesn't apply > cleanly over HEAD so some merging was required to get this version > instead: > > %%% > diff -r 3624c4072e63 sbin/route/route.c > --- a/sbin/route/route.c Fri Sep 07 09:19:22 2007 +0000 > +++ b/sbin/route/route.c Mon Sep 10 14:02:01 2007 +0300 > @@ -799,18 +799,19 @@ inet_makenetandmask(net, sin, bits) > rtm_addrs |= RTA_NETMASK; > if (net == 0) > mask = addr = 0; > [snip] > + else { > + if (net <= 0xff) > + addr = net << IN_CLASSA_NSHIFT; > + else if (net < 0xffff) > + addr = net << IN_CLASSB_NSHIFT; > + else if (net < 0xffffff) > + addr = net << IN_CLASSC_NSHIFT; ... which will fail for 0xffff and 0xffffff comparisons. I apologize for not testing all the possible address lengths before emailing the first patch. I should have used <= here, so an updated patch is: %%% diff -r 3624c4072e63 sbin/route/route.c --- a/sbin/route/route.c Fri Sep 07 09:19:22 2007 +0000 +++ b/sbin/route/route.c Mon Sep 10 14:55:16 2007 +0300 @@ -799,18 +799,19 @@ inet_makenetandmask(net, sin, bits) rtm_addrs |= RTA_NETMASK; if (net == 0) mask = addr = 0; - else if (net < 128) { - addr = net << IN_CLASSA_NSHIFT; - mask = IN_CLASSA_NET; - } else if (net < 65536) { - addr = net << IN_CLASSB_NSHIFT; - mask = IN_CLASSB_NET; - } else if (net < 16777216L) { - addr = net << IN_CLASSC_NSHIFT; - mask = IN_CLASSC_NET; - } else { - addr = net; - if ((addr & IN_CLASSA_HOST) == 0) + else { + if (net <= 0xff) + addr = net << IN_CLASSA_NSHIFT; + else if (net <= 0xffff) + addr = net << IN_CLASSB_NSHIFT; + else if (net <= 0xffffff) + addr = net << IN_CLASSC_NSHIFT; + else + addr = net; + + if (bits) + mask = 0xffffffff << (32 - bits); + else if ((addr & IN_CLASSA_HOST) == 0) mask = IN_CLASSA_NET; else if ((addr & IN_CLASSB_HOST) == 0) mask = IN_CLASSB_NET; @@ -819,8 +820,6 @@ inet_makenetandmask(net, sin, bits) else mask = -1; } - if (bits) - mask = 0xffffffff << (32 - bits); sin->sin_addr.s_addr = htonl(addr); sin = &so_mask.sin; sin->sin_addr.s_addr = htonl(mask); %%% From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 12:11:45 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92A5216A418 for ; Mon, 10 Sep 2007 12:11:45 +0000 (UTC) (envelope-from fabient@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 37B2F13C467 for ; Mon, 10 Sep 2007 12:11:45 +0000 (UTC) (envelope-from fabient@netasq.com) Received: from intranet.netasq.com (jabber.netasq.com [10.0.0.6]) by netasq.netasq.com (Postfix) with ESMTP id BBE2B1B5CF; Mon, 10 Sep 2007 13:41:09 +0200 (CEST) Received: from 10.0.0.126 (SquirrelMail authenticated user fabient); by intranet.netasq.com with HTTP; Mon, 10 Sep 2007 13:41:09 +0200 (CEST) Message-ID: <13076.10.0.0.126.1189424469.squirrel@10.0.0.126> In-Reply-To: References: Date: Mon, 10 Sep 2007 13:41:09 +0200 (CEST) From: fabient@netasq.com To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Vlad GALU Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 12:11:45 -0000 > > Fabien, since you have the necesary hardware to stimulate the > FreeBSD box, would it be too much to ask you to run some packet > capture tests with your polling implementation and the capturing > interface set to IFF_MONITOR? The userland program should use pcap and > simply increment a counter and spit out capture average once every N > seconds. It would be very interesting to see how polling affects > packet capture, with varying BPF buffer sizes. > > If you have the bench application src i will try to do the test during my next session. Fabien From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 13:21:54 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C3D16A419 for ; Mon, 10 Sep 2007 13:21:54 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1A01313C4D5 for ; Mon, 10 Sep 2007 13:21:53 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (F72aa.f.ppp-pool.de [195.4.114.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id D084312883F; Mon, 10 Sep 2007 14:48:55 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) (Authenticated sender: vwerth@bellona.sz.vwsoft.com) by mail.vtec.ipme.de (Postfix) with ESMTP id CF3783F43E; Mon, 10 Sep 2007 14:46:48 +0200 (CEST) Message-ID: <46E53D37.6000308@vwsoft.com> Date: Mon, 10 Sep 2007 14:48:55 +0200 From: Volker User-Agent: Thunderbird 2.0.0.6 (X11/20070807) MIME-Version: 1.0 To: Scott Bennett References: <200709100149.l8A1nhLv018269@mp.cs.niu.edu> In-Reply-To: <200709100149.l8A1nhLv018269@mp.cs.niu.edu> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-net@freebsd.org Subject: Re: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 13:21:54 -0000 On 12/23/-58 20:59, Scott Bennett wrote: ... > Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 Scott, you didn't buy a USB200M (AX88172) but a USB200M V2. That thing has a slightly different chip (AX88772) and is currently not supported by axe(4) (at least not in STABLE, quite unsure for CURRENT). OpenBSD has support for the AX88772 chipset. Volker From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 17:24:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE10616A419 for ; Mon, 10 Sep 2007 17:24:46 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from imx3.ngs.ru (imx3.ngs.ru [81.176.214.138]) by mx1.freebsd.org (Postfix) with ESMTP id 6D71813C465 for ; Mon, 10 Sep 2007 17:24:46 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from mx1.intranet.ru (mx1.intranet.ru [172.16.1.1]) by smtp.ngs.ru (smtp) with ESMTP id 92A4B2DB00B2 for ; Tue, 11 Sep 2007 00:09:05 +0700 (NOVST) Received: from [80.242.64.3] (account ivsan@ngs.ru) by mx1.intranet.ru (CommuniGate Pro WebUser 4.3.12) with HTTP id 95343829 for freebsd-net@freebsd.org; Tue, 11 Sep 2007 00:09:05 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.3.12 Date: Tue, 11 Sep 2007 00:09:05 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20070910 #411896, check: 20070910 clean Subject: nested vlans and ethernet frame size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 17:24:47 -0000 Hi I'd like to ask for advice - what is the right place for setting maximum ethernet frame size in freebsd? It needs 1526 bytes to allow two vlan tags per packet. Those tags must be processed by ng_vlan code so it seems that vlanmtu interface flag will be of no use here. We're running freebsd6.2-stable and use some Intel pro 100 card for testing purposes along with QinQ-capable switch. Currently frames of 1526 length are sent without problems but incoming packets of such a size are lost. Since fxp driver complains about 'discarding oversize frame' it can be supposed that the problem in this case is not in nic hardware but in driver. As far as I can see in kernel sources (it's a pity I'm not a programmer :) many ethernet drivers use ETHERNET_MAX_FRAME macro to define size checks. Possibly I could replace "1518" by "1526" in sys/net/ethernet.h but it must be considered brutal, isn't it ? :) Thanks in advance, Ivan From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 17:52:58 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC8816A421 for ; Mon, 10 Sep 2007 17:52:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 27C5313C469 for ; Mon, 10 Sep 2007 17:52:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 10 Sep 2007 10:52:57 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 0009612631F; Mon, 10 Sep 2007 10:52:56 -0700 (PDT) Message-ID: <46E58478.3070009@elischer.org> Date: Mon, 10 Sep 2007 10:52:56 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Alexandrovich References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nested vlans and ethernet frame size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 17:52:58 -0000 Ivan Alexandrovich wrote: > Hi > > I'd like to ask for advice - what is the right place for > setting maximum ethernet frame size in freebsd? > It needs 1526 bytes to allow two vlan tags per packet. > Those tags must be processed by ng_vlan code so > it seems that vlanmtu interface flag will be of no use here. > We're running freebsd6.2-stable and use some Intel pro 100 > card for testing purposes along with QinQ-capable switch. > > Currently frames of 1526 length are sent without problems but > incoming packets of such a size are lost. Since fxp driver > complains about 'discarding oversize frame' it can be supposed that > the problem in this case is not in nic hardware but in > driver. > > As far as I can see in kernel sources (it's a pity I'm not a > programmer :) many ethernet drivers use ETHERNET_MAX_FRAME macro > to define size checks. > Possibly I could replace "1518" by "1526" in sys/net/ethernet.h > but it must be considered brutal, isn't it ? :) basically you need go add smaller and smaller MTUs on your vlann interfaces as they get more and more nested. You can't really go in the other direction of increasing them in a lot of scenarios. > > > Thanks in advance, > Ivan > _______________________________________________ > 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 Mon Sep 10 17:59:38 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F69816A41B for ; Mon, 10 Sep 2007 17:59:38 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp810.mail.ird.yahoo.com (smtp810.mail.ird.yahoo.com [217.146.188.70]) by mx1.freebsd.org (Postfix) with SMTP id 6C01113C458 for ; Mon, 10 Sep 2007 17:59:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 88504 invoked from network); 10 Sep 2007 17:59:36 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@217.44.142.35 with plain) by smtp810.mail.ird.yahoo.com with SMTP; 10 Sep 2007 17:59:35 -0000 X-YMail-OSG: 9b5jC9IVM1kTpRfLQcfMKsIz7Luo8G4x9dpZxjI1lcKwXV_8 Message-ID: <46E59494.7040507@tomjudge.com> Date: Mon, 10 Sep 2007 20:01:40 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Ivan Alexandrovich References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nested vlans and ethernet frame size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 17:59:38 -0000 Ivan Alexandrovich wrote: > Hi > > I'd like to ask for advice - what is the right place for > setting maximum ethernet frame size in freebsd? > It needs 1526 bytes to allow two vlan tags per packet. > Those tags must be processed by ng_vlan code so > it seems that vlanmtu interface flag will be of no use here. > We're running freebsd6.2-stable and use some Intel pro 100 > card for testing purposes along with QinQ-capable switch. > > Currently frames of 1526 length are sent without problems but > incoming packets of such a size are lost. Since fxp driver > complains about 'discarding oversize frame' it can be supposed that > the problem in this case is not in nic hardware but in > driver. > > As far as I can see in kernel sources (it's a pity I'm not a > programmer :) many ethernet drivers use ETHERNET_MAX_FRAME macro > to define size checks. > Possibly I could replace "1518" by "1526" in sys/net/ethernet.h > but it must be considered brutal, isn't it ? :) > > > Thanks in advance, > Ivan This fix does not support N depth nesting, also if you are exceeding 1518 does that not imply at you require hardware that supports jumbo frames to do VLAN tag nesting? Tom From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 18:58:03 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA93F16A418 for ; Mon, 10 Sep 2007 18:58:03 +0000 (UTC) (envelope-from SRS0=01d1934a68e0056a2dddf323e301c4de2385aa5e=454=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4BB13C458 for ; Mon, 10 Sep 2007 18:58:03 +0000 (UTC) (envelope-from SRS0=01d1934a68e0056a2dddf323e301c4de2385aa5e=454=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id PBQ84300; Mon, 10 Sep 2007 11:58:00 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3CD624500C; Mon, 10 Sep 2007 11:58:00 -0700 (PDT) To: Tom Judge In-Reply-To: Your message of "Mon, 10 Sep 2007 20:01:40 BST." <46E59494.7040507@tomjudge.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189450680_83091P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 10 Sep 2007 11:58:00 -0700 From: "Kevin Oberman" Message-Id: <20070910185800.3CD624500C@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;;; X-Sender: X-To_Name: Tom Judge X-To_Domain: tomjudge.com X-To: Tom Judge X-To_Email: tom@tomjudge.com X-To_Alias: tom Cc: freebsd-net@freebsd.org, Ivan Alexandrovich Subject: Re: nested vlans and ethernet frame size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 18:58:03 -0000 --==_Exmh_1189450680_83091P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 10 Sep 2007 20:01:40 +0100 > From: Tom Judge > Sender: owner-freebsd-net@freebsd.org > > Ivan Alexandrovich wrote: > > Hi > > > > I'd like to ask for advice - what is the right place for > > setting maximum ethernet frame size in freebsd? > > It needs 1526 bytes to allow two vlan tags per packet. > > Those tags must be processed by ng_vlan code so > > it seems that vlanmtu interface flag will be of no use here. > > We're running freebsd6.2-stable and use some Intel pro 100 > > card for testing purposes along with QinQ-capable switch. > > > > Currently frames of 1526 length are sent without problems but > > incoming packets of such a size are lost. Since fxp driver > > complains about 'discarding oversize frame' it can be supposed that > > the problem in this case is not in nic hardware but in > > driver. > > > > As far as I can see in kernel sources (it's a pity I'm not a > > programmer :) many ethernet drivers use ETHERNET_MAX_FRAME macro > > to define size checks. > > Possibly I could replace "1518" by "1526" in sys/net/ethernet.h > > but it must be considered brutal, isn't it ? :) > > > > > > Thanks in advance, > > Ivan > > This fix does not support N depth nesting, also if you are exceeding > 1518 does that not imply at you require hardware that supports jumbo > frames to do VLAN tag nesting? 802.3 was updated to require support a minimum frame size of 1522 several years ago, so one VLAN tag should be OK on any but ancient hardware. Of course, software is a different matter. In either case, you really should decrease the IP MTU below 1500 if you are going to stack tags. The recommended IP MTU for jumbo frames is 9000. This is a US government recommendation and not a standard, but is used by almost all major governmental and educational nets to allow lots of room for VLAN and MPLS tags with a typical max frame size of at least 9100 octets. -- 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 --==_Exmh_1189450680_83091P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG5ZO3kn3rs5h7N1ERAnfNAJ9mMcK7YEWeFnzJ2CiuyH57+fDlcgCaA3fP NiWWymhhnq2E4pELhobrsq8= =EWga -----END PGP SIGNATURE----- --==_Exmh_1189450680_83091P-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 10 21:17:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FDE616A417 for ; Mon, 10 Sep 2007 21:17:09 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.68.41]) by mx1.freebsd.org (Postfix) with ESMTP id E681913C45D for ; Mon, 10 Sep 2007 21:17:08 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l8ALGe4u016063; Mon, 10 Sep 2007 16:16:40 -0500 (CDT) Date: Mon, 10 Sep 2007 16:16:40 -0500 (CDT) From: Scott Bennett Message-Id: <200709102116.l8ALGe8f016062@mp.cs.niu.edu> To: Tom Judge , Volker Cc: freebsd-net@freebsd.org Subject: Re: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 21:17:09 -0000 On Mon, 10 Sep 2007 09:36:14 +0100 Tom Judge wrote: >Scott Bennett wrote: >> >> My Dell Inspiron XPS has just one built-in Ethernet port, and I need to >> have at least one other. Armed with a printed copy of Section 3.2 of the >> FreeBSD 6.2 Harware Notes, I went to the several electronics stores, looking >> to find a device on the list of supported devices. Eventually, I found and >> bought two Linksys USB200M Compact USB 2.0 Network Adapters, which are listed >> in the Hardware Notes as being supported by the axe(4) driver. Comments in >> if_axe.c specifically refer to the USB200M as a supported model. >> So, thinking I had found what I needed, I hooked one up to a USB port >> and booted my FreeBSD 6.2-STABLE system. The kernel did recognize that there >> was something attached to the USB port, but the device type was not identified, >> and no driver was associated with it, and therefore no axe0 network interface >> was created in the kernel. I've also tried connecting the card while the >> system was already up and running. Here's the resulting message in >> /var/log/messages: >> >> Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 >> >> Disconnecting the device yielded the following messages: >> >> Sep 9 20:36:15 hellas kernel: ugen0: at uhub4 port 6 (addr 3) disconnected >> Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.3 >> Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.2 >> Sep 9 20:36:15 hellas kernel: All threads purged from ugen0.1 >> Sep 9 20:36:15 hellas kernel: All threads purged from ugen0 >> Sep 9 20:36:15 hellas kernel: ugen0: detached >> >> Is the Linksys USB200M supported or not? What am I missing here? > > >Try removing the device from the system then running "kldload if_axe" >and then plugging the device back in. It should then be detected correctly. I hadn't done that because "device axe" is in the kernel configuration already. Trying to kldload something that is already compiled into the kernel usually results in an error message to that effect. Then on Mon, 10 Sep 2007 14:48:55 +0200 Volker wrote: >On 12/23/-58 20:59, Scott Bennett wrote: >... > >> Sep 9 20:35:07 hellas kernel: ugen0: vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3 > >Scott, > >you didn't buy a USB200M (AX88172) but a USB200M V2. That thing has a >slightly different chip (AX88772) and is currently not supported by >axe(4) (at least not in STABLE, quite unsure for CURRENT). OpenBSD has >support for the AX88772 chipset. > Oh. So now I have another couple of white elephants. Damn. And I still don't have anything that will work as a second interface. Sigh. Thanks for the information. Do you know whether the AX88772 will be supported at some point? I.e., should I hang onto these gadgets or get rid of them? Also, do you have any suggestions for alternatives? The problem I was running into was that a lot of the equipment listed in Section 3.2 of the Hardware Notes seems to be "obsolete" in the sense that it has been discontinued by the manufacturers and is no longer readily available, which was why I bought two of the Linksys USB200M devices when I finally came across them. The store had already removed even those from the shelves, but hadn't yet shipped them back. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Tue Sep 11 13:47:06 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FAA16A419 for ; Tue, 11 Sep 2007 13:47:06 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6C313C461 for ; Tue, 11 Sep 2007 13:47:03 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (F72d9.f.ppp-pool.de [195.4.114.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 7E46C12883F; Tue, 11 Sep 2007 15:46:56 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) (Authenticated sender: vwerth@bellona.sz.vwsoft.com) by mail.vtec.ipme.de (Postfix) with ESMTP id 9A2823F43E; Tue, 11 Sep 2007 15:44:41 +0200 (CEST) Message-ID: <46E69C50.5080004@vwsoft.com> Date: Tue, 11 Sep 2007 15:46:56 +0200 From: Volker User-Agent: Thunderbird 2.0.0.6 (X11/20070807) MIME-Version: 1.0 To: Scott Bennett References: <200709102116.l8ALGe8f016062@mp.cs.niu.edu> In-Reply-To: <200709102116.l8ALGe8f016062@mp.cs.niu.edu> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Tom Judge , freebsd-net@freebsd.org Subject: Re: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 13:47:06 -0000 Scott, On 09/10/07 23:16, Scott Bennett wrote: > Oh. So now I have another couple of white elephants. Damn. And I still > don't have anything that will work as a second interface. Sigh. Do not trash them. Please test the patches available at: http://opal.com/jr/freebsd/sys/dev/usb/ > Also, do you have any suggestions for alternatives? I know your problem well. I do have a bunch of not supported USB NICs but also I've got a bunch of supported ones (mostly aue(4) based ones). These are cheap, and are sold a lot. There's (AFAIK) just one newer aue chipset which is currently not supported by aue(4) and is giving some errors. I haven't been able to figure out what's wrong with them. When grabbing aue based USB NICs from an online source, the chances are 3 out of 4 you're getting a supported one. But you should test your USB200Mv2 using the patches first. Volker From owner-freebsd-net@FreeBSD.ORG Tue Sep 11 19:29:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8ED316A41A for ; Tue, 11 Sep 2007 19:29:00 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id 77C9D13C467 for ; Tue, 11 Sep 2007 19:29:00 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 48FC5414C; Tue, 11 Sep 2007 15:02:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7F4A6.2434ACF6" Date: Tue, 11 Sep 2007 15:01:53 -0400 Message-ID: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FreeBSD nfe driver and IPMI cards Thread-Index: Acf0pjb2qHAkEjsqRA64vCJVVjX+eQ== From: "Robert Wojciechowski" To: X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Josh Mouch Subject: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 19:29:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F4A6.2434ACF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I'm the FreeBSD nfe driver from =20 http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html with FreeBSD 6-stable with good results for the most part. The only issue I've experienced is that during a detach/shutdown of if_nfe, the IPMI IP address I have set on my servers ceases to respond as well as the ability to manage the servers. =20 I traced the problem down to nfe_stop() and the fact that it completely disables the Rx and Tx on the NIC. I have patched the driver to not disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 down', 'shutdown -p now', etc. =20 Does anyone have any comments on this change I've made and any possible side effects? Can this be included in the mainstream distribution of the nfe drivers (and updated in 7-CURRENT) without causing any adverse problems? =20 Thanks, =20 Robert S Wojciechowski / ExpressYard 810.953.3799 x200 / cell 248.872.4509 ------_=_NextPart_001_01C7F4A6.2434ACF6 Content-Type: application/octet-stream; name="nfe-ipmi.patch" Content-Transfer-Encoding: base64 Content-Description: nfe-ipmi.patch Content-Disposition: attachment; filename="nfe-ipmi.patch" ZGlmZiAtdXdyIG5mZS0yMDA3MDgxNi9pZl9uZmUuYyBuZmUtMjAwNzA4MTYtc3NnaS9pZl9uZmUu YwotLS0gbmZlLTIwMDcwODE2L2lmX25mZS5jCVdlZCBBdWcgMTUgMjI6MDg6MTggMjAwNworKysg bmZlLTIwMDcwODE2LXNzZ2kvaWZfbmZlLmMJVHVlIFNlcCAxMSAxMTo1OTowMyAyMDA3CkBAIC0y NCw3ICsyNCw3IEBACiBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L25mZS9pZl9uZmUu Yyx2IDEuMTkgMjAwNy8wNy8yNCAwMToxMTowMCB5b25nYXJpIEV4cCAkIik7CiAKIC8qIFVuY29t bWVudCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gZW5hYmxlIHBvbGxpbmcuICovCi0vKiAjZGVmaW5l CURFVklDRV9QT0xMSU5HICovCisjZGVmaW5lCURFVklDRV9QT0xMSU5HCiAKICNpZmRlZiBIQVZF X0tFUk5FTF9PUFRJT05fSEVBREVSUwogI2luY2x1ZGUgIm9wdF9kZXZpY2VfcG9sbGluZy5oIgpA QCAtMzAwNCwxMCArMzAwNCwxMiBAQAogCWNhbGxvdXRfc3RvcCgmc2MtPm5mZV9zdGF0X2NoKTsK IAogCS8qIGFib3J0IFR4ICovCi0JTkZFX1dSSVRFKHNjLCBORkVfVFhfQ1RMLCAwKTsKKyAgLyog a2VlcCBUeCBhbGl2ZSBmb3IgSU1QSSBhbmQgcGVyaGFwcyBXT0wgKi8KKwkvKiBORkVfV1JJVEUo c2MsIE5GRV9UWF9DVEwsIDApOyAqLwogCiAJLyogZGlzYWJsZSBSeCAqLwotCU5GRV9XUklURShz YywgTkZFX1JYX0NUTCwgMCk7CisgIC8qIGtlZXAgUnggYWxpdmUgZm9yIElNUEkgYW5kIHBlcmhh cHMgV09MICovCisJLyogTkZFX1dSSVRFKHNjLCBORkVfUlhfQ1RMLCAwKTsgKi8KIAogCS8qIGRp c2FibGUgaW50ZXJydXB0cyAqLwogCW5mZV9kaXNhYmxlX2ludHIoc2MpOwo= ------_=_NextPart_001_01C7F4A6.2434ACF6-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 11 23:41:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2883416A417 for ; Tue, 11 Sep 2007 23:41:43 +0000 (UTC) (envelope-from nataraja@cis.udel.edu) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by mx1.freebsd.org (Postfix) with ESMTP id F16A913C49D for ; Tue, 11 Sep 2007 23:41:42 +0000 (UTC) (envelope-from nataraja@cis.udel.edu) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 038B12E1E; Tue, 11 Sep 2007 19:12:57 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on louie.udel.edu X-Spam-Level: X-Spam-Status: No, score=-22.1 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00, LOCAL_AUTH_RCVD autolearn=unavailable version=3.1.8 Received: from [192.168.1.102] (c-68-37-2-210.hsd1.de.comcast.net [68.37.2.210]) (Authenticated sender: nataraja@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id B647429E6; Tue, 11 Sep 2007 19:12:10 -0400 (EDT) Message-ID: <46E720C4.5090409@cis.udel.edu> Date: Tue, 11 Sep 2007 19:12:04 -0400 From: Preethi Natarajan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) To: freebsd-net@freebsd.org X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul D. Amer" Subject: TCP rcv_wnd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 23:41:43 -0000 Hello, I am trying to track TCP's receive window evolution in my experiments. Specifically, I want to know a connection's rwnd before processing every incoming packet. So, I put in my tracking code right after tp->rcv_wnd update in tcp_do_segment() in tcp_input.c I have packet drops in my experiment, and was hoping to see the rcv_wnd go down atleast a little bit. But rcv_wnd remains the same (net.inet.tcp.recvspace value). Was wondering if I am looking at the correct function. Any help is appreciated. Thanks -- Preethi From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 00:49:19 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC15C16A417 for ; Wed, 12 Sep 2007 00:49:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 62BA413C45E for ; Wed, 12 Sep 2007 00:49:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so27225nzf for ; Tue, 11 Sep 2007 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=0stGnmxcLJ5gywdpTpULBsl4KKzONB76YUEAYyLkUp8=; b=XNpN2EM3jF8zzRnRcAdtySyqitdOhmAEhu9mjHxV5C8Qohbtt8WXpVjkr/XpXDbihQ+uvpkYM6b77kLa2ofFVod/HQXQMIn4OUag9loWsruY1fDSsMWnXK5r0rCkGPqSxqa1Qq6nPWrjuTSpCG9X2X4QDptcJuelOCAuvONi9gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GXRriUF5Wu5FZuAalOfwIzu9tTOrAsDAioJTIMZ6oOKDbU5O220cpe/5zvqvu29CLxwb4kB69/hmqU3utor7pwl6tihVahCu5ggWBGadJBizWs/acxyd386QVJFNXvf8+UspYSRAwReHoQGsbX/XFXJIIYAeFQqAuEIeFQmP4V4= Received: by 10.65.139.9 with SMTP id r9mr13323500qbn.1189558126040; Tue, 11 Sep 2007 17:48:46 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 10sm660018nzo.2007.09.11.17.48.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2007 17:48:44 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l8C0jwII009205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 09:45:58 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l8C0jseS009204; Wed, 12 Sep 2007 09:45:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 12 Sep 2007 09:45:54 +0900 From: Pyun YongHyeon To: Robert Wojciechowski Message-ID: <20070912004554.GA8992@cdnetworks.co.kr> References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> User-Agent: Mutt/1.4.2.1i Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch Subject: Re: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 00:49:19 -0000 On Tue, Sep 11, 2007 at 03:01:53PM -0400, Robert Wojciechowski wrote: > Hello, > > > > I'm the FreeBSD nfe driver from > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > with FreeBSD 6-stable with good results for the most part. The only > issue I've experienced is that during a detach/shutdown of if_nfe, the > IPMI IP address I have set on my servers ceases to respond as well as > the ability to manage the servers. > > > > I traced the problem down to nfe_stop() and the fact that it completely > disables the Rx and Tx on the NIC. I have patched the driver to not > disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > down', 'shutdown -p now', etc. > > > > Does anyone have any comments on this change I've made and any possible > side effects? Can this be included in the mainstream distribution of the Because MAC is still alive if's possible to recieve a packet. All DMA maps are unloaded and buffers are already freed in nfe_stop so it would cause panic I guess. But I'm not familiar with IPMI so I'm not sure. > nfe drivers (and updated in 7-CURRENT) without causing any adverse > problems? > I have no experience on IPMI but the change you've made would not completely solve the issue. I guess supporting IPMI needs lots of more work including: o Autodetect IPMI capability. o Autodetect active IPMI session in device attach and don't blindly reset MAC/PHY. o Don't blindly stop Tx/Rx on device detach. Given that lack of publicly available datasheet for the hardware supporing IPMI would be severly limited. Fortunately Linux seems to have basic IPMI support in their forcedeth driver. Their code doesn't easy to read but you may see what should be done in driver. However I have no idea what we can do when active IPMI session is present in driver attach phase. Normally PHY driver would reset PHY hardware itself in driver attach which in turn would result in losing the IPMI connection. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 02:31:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADBEF16A421 for ; Wed, 12 Sep 2007 02:31:46 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from imx3.ngs.ru (imx3.ngs.ru [81.176.214.138]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCEF13C461 for ; Wed, 12 Sep 2007 02:31:46 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from mx1.intranet.ru (mx1.intranet.ru [172.16.1.1]) by smtp.ngs.ru (smtp) with ESMTP id C6BC42DB0148 for ; Wed, 12 Sep 2007 09:31:43 +0700 (NOVST) Received: from [80.242.64.3] (account ivsan@ngs.ru) by mx1.intranet.ru (CommuniGate Pro WebUser 4.3.12) with HTTP id 95372950 for freebsd-net@freebsd.org; Wed, 12 Sep 2007 09:31:43 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.3.12 Date: Wed, 12 Sep 2007 09:31:43 +0700 Message-ID: In-Reply-To: <46E58478.3070009@elischer.org> References: <46E58478.3070009@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20070912 #412467, check: 20070912 clean Subject: Re: nested vlans and ethernet frame size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 02:31:46 -0000 Thanks for all your replies and explanations. Sure lowering mtu below 1500 bytes for all hosts or using jumbo frames would be the right solution especially for corporate network. But we probably have to stick to 1500 bytes for one reason: that FreeBSD-based router configuration I mentioned is for segments where we use seperate vlan for each client connection (we're an ISP): it seems that using anything else instead of 1500 for clients will require too much tech support efforts. Since double-tagged frames will be transmitted only by one ethernet link per segment (the link between upper level switch with QinQ and FreeBSD router) then maybe it's acceptable to allow a little deviation from the standard as long as we remember the implications. Thanks for the help Ivan From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 12:25:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C246A16A419 for ; Wed, 12 Sep 2007 12:25:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA4D13C4B4 for ; Wed, 12 Sep 2007 12:25:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so150882rvb for ; Wed, 12 Sep 2007 05:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=bb20mw4Ex4Sq4cucETcbtRoO1kg2XBf04eM8UX7iF3I=; b=RVeCcSWnE+bdgILAk1etNscWcc6zs73Cbi6zJRuIqV9+09NCtIHNpaBGayfC4/fBkfBkDxHGCttErdS+l6xBUIZaY/xm5TKoxW2yZFm/d/rtM7X7tapTYdo7OZfL/zdsPq1EgIr8opMk2KJ04NgU5Q3/OxNfwAmomfGDNBeffXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=pE5LAw0nSVinqvhn857f2DyF4xkCCGHhoq071aCrfoQb/F7GnAsDPuUR9S2+PExa/M2Yyr3IkRazoKamxlAOY1CWcybMfgWhOzdwCjjxntzSiUOBwebqsHmNbFkgk0lWw0CfWXkbjTU0lZcLtopH2zaSR+S/g1GBGkTTphXTb7s= Received: by 10.141.159.13 with SMTP id l13mr176700rvo.1189599938265; Wed, 12 Sep 2007 05:25:38 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b34sm12120512rvf.2007.09.12.05.25.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2007 05:25:37 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l8CCMrlW011165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 21:22:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l8CCMqZT011164; Wed, 12 Sep 2007 21:22:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 12 Sep 2007 21:22:52 +0900 From: Pyun YongHyeon To: Stephen Clark Message-ID: <20070912122252.GD8992@cdnetworks.co.kr> References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> <46E7D9A2.2090106@seclark.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E7D9A2.2090106@seclark.us> User-Agent: Mutt/1.4.2.1i Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Robert Wojciechowski , Josh Mouch Subject: Re: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 12:25:39 -0000 On Wed, Sep 12, 2007 at 08:20:50AM -0400, Stephen Clark wrote: > Pyun YongHyeon wrote: > > >On Tue, Sep 11, 2007 at 03:01:53PM -0400, Robert Wojciechowski wrote: > >> Hello, > >> > >> > >> > >> I'm the FreeBSD nfe driver from > >> http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > >> with FreeBSD 6-stable with good results for the most part. The only > >> issue I've experienced is that during a detach/shutdown of if_nfe, the > >> IPMI IP address I have set on my servers ceases to respond as well as > >> the ability to manage the servers. > >> > >> > >> > >> I traced the problem down to nfe_stop() and the fact that it completely > >> disables the Rx and Tx on the NIC. I have patched the driver to not > >> disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > >> down', 'shutdown -p now', etc. > >> > >> > >> > >> Does anyone have any comments on this change I've made and any possible > >> side effects? Can this be included in the mainstream distribution of the > > > >Because MAC is still alive if's possible to recieve a packet. All DMA > >maps are unloaded and buffers are already freed in nfe_stop so it > >would cause panic I guess. But I'm not familiar with IPMI so I'm not > >sure. > > > >> nfe drivers (and updated in 7-CURRENT) without causing any adverse > >> problems? > >> > > > >I have no experience on IPMI but the change you've made would not > >completely solve the issue. I guess supporting IPMI needs lots of > >more work including: > >o Autodetect IPMI capability. > >o Autodetect active IPMI session in device attach and don't blindly > > reset MAC/PHY. > >o Don't blindly stop Tx/Rx on device detach. > >Given that lack of publicly available datasheet for the hardware > >supporing IPMI would be severly limited. Fortunately Linux seems to > >have basic IPMI support in their forcedeth driver. Their code doesn't > >easy to read but you may see what should be done in driver. However > >I have no idea what we can do when active IPMI session is present in > >driver attach phase. Normally PHY driver would reset PHY hardware > >itself in driver attach which in turn would result in losing the IPMI > >connection. > > > > > > > www.intel.com/design/servers/ipmi > What we need is documentation for NVIDIA NICs. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 12:47:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0FF516A417 for ; Wed, 12 Sep 2007 12:47:32 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by mx1.freebsd.org (Postfix) with SMTP id 5D3D013C46A for ; Wed, 12 Sep 2007 12:47:32 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 14643 invoked from network); 12 Sep 2007 12:20:51 -0000 Received: from unknown (24.144.77.243) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 12 Sep 2007 12:20:49 -0000 Message-ID: <46E7D9A2.2090106@seclark.us> Date: Wed, 12 Sep 2007 08:20:50 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pyunyh@gmail.com References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> In-Reply-To: <20070912004554.GA8992@cdnetworks.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Robert Wojciechowski , Josh Mouch Subject: Re: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 12:47:32 -0000 Pyun YongHyeon wrote: >On Tue, Sep 11, 2007 at 03:01:53PM -0400, Robert Wojciechowski wrote: > > Hello, > > > > > > > > I'm the FreeBSD nfe driver from > > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > with FreeBSD 6-stable with good results for the most part. The only > > issue I've experienced is that during a detach/shutdown of if_nfe, the > > IPMI IP address I have set on my servers ceases to respond as well as > > the ability to manage the servers. > > > > > > > > I traced the problem down to nfe_stop() and the fact that it completely > > disables the Rx and Tx on the NIC. I have patched the driver to not > > disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > > down', 'shutdown -p now', etc. > > > > > > > > Does anyone have any comments on this change I've made and any possible > > side effects? Can this be included in the mainstream distribution of the > >Because MAC is still alive if's possible to recieve a packet. All DMA >maps are unloaded and buffers are already freed in nfe_stop so it >would cause panic I guess. But I'm not familiar with IPMI so I'm not >sure. > > > nfe drivers (and updated in 7-CURRENT) without causing any adverse > > problems? > > > >I have no experience on IPMI but the change you've made would not >completely solve the issue. I guess supporting IPMI needs lots of >more work including: > o Autodetect IPMI capability. > o Autodetect active IPMI session in device attach and don't blindly > reset MAC/PHY. > o Don't blindly stop Tx/Rx on device detach. >Given that lack of publicly available datasheet for the hardware >supporing IPMI would be severly limited. Fortunately Linux seems to >have basic IPMI support in their forcedeth driver. Their code doesn't >easy to read but you may see what should be done in driver. However >I have no idea what we can do when active IPMI session is present in >driver attach phase. Normally PHY driver would reset PHY hardware >itself in driver attach which in turn would result in losing the IPMI >connection. > > > www.intel.com/design/servers/ipmi -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 14:12:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D339316A417 for ; Wed, 12 Sep 2007 14:12:51 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (unknown [IPv6:2001:ba8:0:1f0::5]) by mx1.freebsd.org (Postfix) with ESMTP id 60CB613C428 for ; Wed, 12 Sep 2007 14:12:51 +0000 (UTC) (envelope-from peter@alastria.net) Received: from [10.10.4.10] (dragon.lancs.uk.alastria.net [88.96.139.34]) (authenticated bits=0) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id l8CECgjx039495 for ; Wed, 12 Sep 2007 14:12:45 GMT (envelope-from peter@alastria.net) Message-ID: <46E7F3CF.3090909@alastria.net> Date: Wed, 12 Sep 2007 15:12:31 +0100 From: Peter Wood Organization: Alastria Networks Limited User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.137 () RCVD_IN_SORBS_DUL X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: Re: Intel 82572GI PCIe question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 14:12:51 -0000 Heya, > Has anyone had experience playing with the 82572GI PCIe cards under FreeBSD? Yes I have a couple of servers with PRO/1000 PF Server adapters which use the 82572GI controller. Granted mine are 1000Base-SX, but I've never seen an issue on 6.2-STABLE. You appear to be talking about copper switches (I guess), it wouldn't suprise me if it's something to do with tollerances/timing in the NICs vs switches. We've just had an interesting issue with HP ProCurve switches and an Agilent N2X packet generator. One some switches you'll get full 1000mbs accross two gig ports, on other you'll get about 100mbs (constant). We put two cheap Dell bge NIC driven laptops accross the same ports on a switch that was limited with the Agilent and we got near 1000mbs. It looked like the N2X was being to accurate with it's timing. Meh... anacdotal evidence at best, but I can say that on 6.2 I've had no issues. Pete. -- Peter Wood From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 18:17:44 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D47216A417 for ; Wed, 12 Sep 2007 18:17:44 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1914A13C45B for ; Wed, 12 Sep 2007 18:17:44 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IVWUA-0003Gs-El for freebsd-net@freebsd.org; Wed, 12 Sep 2007 10:58:46 -0700 Message-ID: <12641033.post@talk.nabble.com> Date: Wed, 12 Sep 2007 10:58:46 -0700 (PDT) From: tekkie140 To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: administrator@ksd140.org Subject: ftp daemon fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 18:17:44 -0000 no response in the freebsd-questions forum...maybe here? hi - all of a sudden (it used to work) i can't start the ftpd daemon. # /usr/libexec/ftpd -l -R -p ftpd-id Sept 10 09:02:22 myhostname ftpd[1234]: getpeername (/usr/libexec/ftpd): Socket operation on non-socket # anyone know where i should look? /etc/hosts looks okay. -- View this message in context: http://www.nabble.com/ftp-daemon-fails-tf4431115.html#a12641033 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 21:20:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424C916A419 for ; Wed, 12 Sep 2007 21:20:39 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id EE2E713C474 for ; Wed, 12 Sep 2007 21:20:38 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 8E0A84098; Wed, 12 Sep 2007 17:24:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7F582.C3A05A33" Date: Wed, 12 Sep 2007 17:21:13 -0400 Message-ID: <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> In-Reply-To: <20070912004554.GA8992@cdnetworks.co.kr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FreeBSD nfe driver and IPMI cards Thread-Index: Acf01t1/LUjgJMTCRtWYMKPiGkN7wAAp1VvA References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> From: "Robert Wojciechowski" To: Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch Subject: RE: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 21:20:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F582.C3A05A33 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > I'm the FreeBSD nfe driver from > > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > with FreeBSD 6-stable with good results for the most part. The only > > issue I've experienced is that during a detach/shutdown of if_nfe, > the > > IPMI IP address I have set on my servers ceases to respond as well > as > > the ability to manage the servers. > > > > > > > > I traced the problem down to nfe_stop() and the fact that it > completely > > disables the Rx and Tx on the NIC. I have patched the driver to not > > disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > > down', 'shutdown -p now', etc. > > > > > > > > Does anyone have any comments on this change I've made and any > possible > > side effects? Can this be included in the mainstream distribution of > the >=20 > Because MAC is still alive if's possible to recieve a packet. All DMA > maps are unloaded and buffers are already freed in nfe_stop so it > would cause panic I guess. But I'm not familiar with IPMI so I'm not > sure. Interesting, that is an issue that was also resolved by the forcedeth driver in Linux by resetting in nv_close to prevent DMA into freed memory. >=20 > > nfe drivers (and updated in 7-CURRENT) without causing any adverse > > problems? > > >=20 > I have no experience on IPMI but the change you've made would not > completely solve the issue. I guess supporting IPMI needs lots of > more work including: > o Autodetect IPMI capability. > o Autodetect active IPMI session in device attach and don't blindly > reset MAC/PHY. > o Don't blindly stop Tx/Rx on device detach. > Given that lack of publicly available datasheet for the hardware > supporing IPMI would be severly limited. Fortunately Linux seems to > have basic IPMI support in their forcedeth driver. Their code doesn't > easy to read but you may see what should be done in driver. However > I have no idea what we can do when active IPMI session is present in > driver attach phase. Normally PHY driver would reset PHY hardware > itself in driver attach which in turn would result in losing the IPMI > connection. >=20 Since we have no idea how to auto-detect IPMI, I added a device sysctl (enable_ipmi) to control the behavior I'm testing in-house right now. If the enable_ipmi sysctl is enabled, it'll: * resets after disabling the Rx/Tx and before disabling interrupts * re-enables the Rx/Tx after the ring buffers are freed, just like forcedeth but also enabling the Tx for IPMI (Linux just enabled the Rx for WOL) I have attached my new patch to this email that does the above, guarded by the sysctl. I have no idea how to handle the second case you mentioned, during attach. It does indeed cause a disruption in IPMI, but only for a few seconds. Where is the MAC and PHY reset and if it wasn't reset when using IPMI, what problems could it cause? -- Robert ------_=_NextPart_001_01C7F582.C3A05A33 Content-Type: application/octet-stream; name="nfe-ipmi-2.patch" Content-Transfer-Encoding: base64 Content-Description: nfe-ipmi-2.patch Content-Disposition: attachment; filename="nfe-ipmi-2.patch" ZGlmZiAtdXIgbmZlLTIwMDcwODE2L2lmX25mZS5jIG5mZS0yMDA3MDgxNi1zc2dpL2lmX25mZS5j Ci0tLSBuZmUtMjAwNzA4MTYvaWZfbmZlLmMJVHVlIFNlcCAxMSAwNzozNjoyNCAyMDA3CisrKyBu ZmUtMjAwNzA4MTYtc3NnaS9pZl9uZmUuYwlXZWQgU2VwIDEyIDEzOjAyOjM3IDIwMDcKQEAgLTI0 LDcgKzI0LDcgQEAKIF9fRkJTRElEKCIkRnJlZUJTRDogc3JjL3N5cy9kZXYvbmZlL2lmX25mZS5j LHYgMS4xOSAyMDA3LzA3LzI0IDAxOjExOjAwIHlvbmdhcmkgRXhwICQiKTsKIAogLyogVW5jb21t ZW50IHRoZSBmb2xsb3dpbmcgbGluZSB0byBlbmFibGUgcG9sbGluZy4gKi8KLSNkZWZpbmUJREVW SUNFX1BPTExJTkcKKy8qICNkZWZpbmUJREVWSUNFX1BPTExJTkcgKi8KIAogI2lmZGVmIEhBVkVf S0VSTkVMX09QVElPTl9IRUFERVJTCiAjaW5jbHVkZSAib3B0X2RldmljZV9wb2xsaW5nLmgiCkBA IC04MSw2ICs4MSw3IEBACiBzdGF0aWMgaW50ICBuZmVfcmVzdW1lKGRldmljZV90KTsKIHN0YXRp YyB2b2lkIG5mZV9zaHV0ZG93bihkZXZpY2VfdCk7CiBzdGF0aWMgdm9pZCBuZmVfcG93ZXIoc3Ry dWN0IG5mZV9zb2Z0YyAqKTsKK3N0YXRpYyB2b2lkIG5mZV9yZXNldChzdHJ1Y3QgbmZlX3NvZnRj ICopOwogc3RhdGljIGludCAgbmZlX21paWJ1c19yZWFkcmVnKGRldmljZV90LCBpbnQsIGludCk7 CiBzdGF0aWMgaW50ICBuZmVfbWlpYnVzX3dyaXRlcmVnKGRldmljZV90LCBpbnQsIGludCwgaW50 KTsKIHN0YXRpYyB2b2lkIG5mZV9taWlidXNfc3RhdGNoZyhkZXZpY2VfdCk7CkBAIC0xMjcsNiAr MTI4LDcgQEAKIHN0YXRpYyB2b2lkIG5mZV9kbWFfbWFwX3NlZ3Modm9pZCAqLCBidXNfZG1hX3Nl Z21lbnRfdCAqLCBpbnQsIGludCk7CiAKIHN0YXRpYyBpbnQgc3lzY3RsX2ludF9yYW5nZShTWVND VExfSEFORExFUl9BUkdTLCBpbnQsIGludCk7CitzdGF0aWMgaW50IHN5c2N0bF9od19uZmVfZW5h YmxlX2lwbWkoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMgaW50IHN5c2N0bF9od19uZmVf cHJvY19saW1pdChTWVNDVExfSEFORExFUl9BUkdTKTsKIAogI2lmZGVmIE5GRV9ERUJVRwpAQCAt NTM0LDYgKzUzNiwyMyBAQAogCiAJU1lTQ1RMX0FERF9QUk9DKGRldmljZV9nZXRfc3lzY3RsX2N0 eChkZXYpLAogCSAgICBTWVNDVExfQ0hJTERSRU4oZGV2aWNlX2dldF9zeXNjdGxfdHJlZShkZXYp KSwKKwkgICAgT0lEX0FVVE8sICJlbmFibGVfaXBtaSIsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19S VywKKwkgICAgJnNjLT5uZmVfZW5hYmxlX2lwbWksIDAsIHN5c2N0bF9od19uZmVfZW5hYmxlX2lw bWksICJJIiwKKwkgICAgImVuYWJsZSBJUE1JIik7CisKKwlzYy0+bmZlX2VuYWJsZV9pcG1pID0g TkZFX0VOQUJMRV9JUE1JX0RFRkFVTFQ7CisJZXJyb3IgPSByZXNvdXJjZV9pbnRfdmFsdWUoZGV2 aWNlX2dldF9uYW1lKGRldiksIGRldmljZV9nZXRfdW5pdChkZXYpLAorCSAgICAiZW5hYmxlX2lw bWkiLCAmc2MtPm5mZV9lbmFibGVfaXBtaSk7CisJaWYgKGVycm9yID09IDApIHsKKwkJaWYgKHNj LT5uZmVfcHJvY2Vzc19saW1pdCA8IDAgfHwgc2MtPm5mZV9wcm9jZXNzX2xpbWl0ID4gMSkgewor CQkJZGV2aWNlX3ByaW50ZihkZXYsICJlbmFibGVfaXBtaSB2YWx1ZSBvdXQgb2YgcmFuZ2U7ICIK KwkJCSAgICAidXNpbmcgZGVmYXVsdDogJWRcbiIsIE5GRV9FTkFCTEVfSVBNSV9ERUZBVUxUKTsK KwkJCXNjLT5uZmVfZW5hYmxlX2lwbWkgPSBORkVfRU5BQkxFX0lQTUlfREVGQVVMVDsKKwkJfQor CX0KKworCVNZU0NUTF9BRERfUFJPQyhkZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2KSwKKwkgICAg U1lTQ1RMX0NISUxEUkVOKGRldmljZV9nZXRfc3lzY3RsX3RyZWUoZGV2KSksCiAJICAgIE9JRF9B VVRPLCAicHJvY2Vzc19saW1pdCIsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywKIAkgICAgJnNj LT5uZmVfcHJvY2Vzc19saW1pdCwgMCwgc3lzY3RsX2h3X25mZV9wcm9jX2xpbWl0LCAiSSIsCiAJ ICAgICJtYXggbnVtYmVyIG9mIFJ4IGV2ZW50cyB0byBwcm9jZXNzIik7CkBAIC03NzksMTIgKzc5 OCw3IEBACiAKIAlpZiAoKHNjLT5uZmVfZmxhZ3MgJiBORkVfUFdSX01HTVQpID09IDApCiAJCXJl dHVybjsKLQlORkVfV1JJVEUoc2MsIE5GRV9SWFRYX0NUTCwgTkZFX1JYVFhfUkVTRVQgfCBORkVf UlhUWF9CSVQyKTsKLQlORkVfV1JJVEUoc2MsIE5GRV9NQUNfUkVTRVQsIE5GRV9NQUNfUkVTRVRf TUFHSUMpOwotCURFTEFZKDEwMCk7Ci0JTkZFX1dSSVRFKHNjLCBORkVfTUFDX1JFU0VULCAwKTsK LQlERUxBWSgxMDApOwotCU5GRV9XUklURShzYywgTkZFX1JYVFhfQ1RMLCBORkVfUlhUWF9CSVQy KTsKKwluZmVfcmVzZXQoc2MpOwogCXB3ciA9IE5GRV9SRUFEKHNjLCBORkVfUFdSMl9DVEwpOwog CXB3ciAmPSB+TkZFX1BXUjJfV0FLRVVQX01BU0s7CiAJaWYgKHNjLT5uZmVfcmV2aWQgPj0gMHhh MyAmJgpAQCAtNzk0LDYgKzgwOCwxNSBAQAogCU5GRV9XUklURShzYywgTkZFX1BXUjJfQ1RMLCBw d3IpOwogfQogCitzdGF0aWMgdm9pZAorbmZlX3Jlc2V0KHN0cnVjdCBuZmVfc29mdGMgKnNjKQor eworCU5GRV9XUklURShzYywgTkZFX1JYVFhfQ1RMLCBORkVfUlhUWF9SRVNFVCB8IE5GRV9SWFRY X0JJVDIpOworCU5GRV9XUklURShzYywgTkZFX01BQ19SRVNFVCwgTkZFX01BQ19SRVNFVF9NQUdJ Qyk7CisJREVMQVkoMTAwKTsKKwlORkVfV1JJVEUoc2MsIE5GRV9NQUNfUkVTRVQsIDApOworCURF TEFZKDEwMCk7Cit9CiAKIHN0YXRpYyB2b2lkCiBuZmVfbWlpYnVzX3N0YXRjaGcoZGV2aWNlX3Qg ZGV2KQpAQCAtMzAwOSw2ICszMDMyLDExIEBACiAJLyogZGlzYWJsZSBSeCAqLwogCU5GRV9XUklU RShzYywgTkZFX1JYX0NUTCwgMCk7CiAKKwkvKiByZXNldCB0aGUgVHgvUnggc28gdGhlIE5JQyBk b2VzIG5vdCBETUEgaW50byBmcmVlZCBtZW1vcnkgKi8KKwlpZiAoJnNjLT5uZmVfZW5hYmxlX2lw bWkpIHsKKwkJbmZlX3Jlc2V0KHNjKTsKKwl9CisKIAkvKiBkaXNhYmxlIGludGVycnVwdHMgKi8K IAluZmVfZGlzYWJsZV9pbnRyKHNjKTsKIApAQCAtMzA1NSw2ICszMDgzLDEyIEBACiAJCQl0ZGF0 YS0+bSA9IE5VTEw7CiAJCX0KIAl9CisKKwkvKiBlbmFibGUgdGhlIFR4L1J4IGZvciBJUE1JIHN1 cHBvcnQgKi8KKwlpZiAoJnNjLT5uZmVfZW5hYmxlX2lwbWkpIHsKKwkJTkZFX1dSSVRFKHNjLCBO RkVfVFhfQ1RMLCBORkVfVFhfU1RBUlQpOworCQlORkVfV1JJVEUoc2MsIE5GRV9SWF9DVEwsIE5G RV9SWF9TVEFSVCk7CisJfQogfQogCiAKQEAgLTMyMTAsNCArMzI0NCwxMSBAQAogCiAJcmV0dXJu IChzeXNjdGxfaW50X3JhbmdlKG9pZHAsIGFyZzEsIGFyZzIsIHJlcSwgTkZFX1BST0NfTUlOLAog CSAgICBORkVfUFJPQ19NQVgpKTsKK30KKworCitzdGF0aWMgaW50CitzeXNjdGxfaHdfbmZlX2Vu YWJsZV9pcG1pKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJcmV0dXJuIChzeXNjdGxfaW50X3Jh bmdlKG9pZHAsIGFyZzEsIGFyZzIsIHJlcSwgMCwgMSkpOwogfQpPbmx5IGluIG5mZS0yMDA3MDgx Ni1zc2dpOiBpZl9uZmUuYy5vcmlnCk9ubHkgaW4gbmZlLTIwMDcwODE2LXNzZ2k6IGlmX25mZS5j LnJlagpCaW5hcnkgZmlsZXMgbmZlLTIwMDcwODE2L2lmX25mZS5rbyBhbmQgbmZlLTIwMDcwODE2 LXNzZ2kvaWZfbmZlLmtvIGRpZmZlcgpCaW5hcnkgZmlsZXMgbmZlLTIwMDcwODE2L2lmX25mZS5v IGFuZCBuZmUtMjAwNzA4MTYtc3NnaS9pZl9uZmUubyBkaWZmZXIKZGlmZiAtdXIgbmZlLTIwMDcw ODE2L2lmX25mZXJlZy5oIG5mZS0yMDA3MDgxNi1zc2dpL2lmX25mZXJlZy5oCi0tLSBuZmUtMjAw NzA4MTYvaWZfbmZlcmVnLmgJV2VkIEF1ZyAxNSAyMDo1MToxOCAyMDA3CisrKyBuZmUtMjAwNzA4 MTYtc3NnaS9pZl9uZmVyZWcuaAlXZWQgU2VwIDEyIDEyOjQ1OjM3IDIwMDcKQEAgLTIyLDYgKzIy LDcgQEAKICNkZWZpbmUJTkZFX0pVTUJPX1JYX1JJTkdfQ09VTlQJTkZFX1JYX1JJTkdfQ09VTlQK ICNkZWZpbmUJTkZFX1RYX1JJTkdfQ09VTlQJMjU2CiAKKyNkZWZpbmUJTkZFX0VOQUJMRV9JUE1J X0RFRkFVTFQJMAogI2RlZmluZQlORkVfUFJPQ19ERUZBVUxUCSgoTkZFX1JYX1JJTkdfQ09VTlQg KiAzKSAvIDQpCiAjZGVmaW5lCU5GRV9QUk9DX01JTgkJNTAKICNkZWZpbmUJTkZFX1BST0NfTUFY CQkoTkZFX1JYX1JJTkdfQ09VTlQgLSAxKQpkaWZmIC11ciBuZmUtMjAwNzA4MTYvaWZfbmZldmFy LmggbmZlLTIwMDcwODE2LXNzZ2kvaWZfbmZldmFyLmgKLS0tIG5mZS0yMDA3MDgxNi9pZl9uZmV2 YXIuaAlXZWQgQXVnIDE1IDIwOjUxOjE4IDIwMDcKKysrIG5mZS0yMDA3MDgxNi1zc2dpL2lmX25m ZXZhci5oCVdlZCBTZXAgMTIgMTI6MzU6NDcgMjAwNwpAQCAtMTE1LDYgKzExNSw3IEBACiAJaW50 CQkJbmZlX3N1c3BlbmRlZDsKIAlpbnQJCQluZmVfZnJhbWVzaXplOwogCWludAkJCW5mZV9wcm9j ZXNzX2xpbWl0OworCWludAkJCW5mZV9lbmFibGVfaXBtaTsKIAlpbnQJCQluZmVfZm9yY2VfdHg7 CiAJdWludDMyX3QJCW5mZV9pcnFfc3RhdHVzOwogCXVpbnQzMl90CQluZmVfaXJxX21hc2s7Cg== ------_=_NextPart_001_01C7F582.C3A05A33-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 12 21:40:33 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C21C16A420 for ; Wed, 12 Sep 2007 21:40:33 +0000 (UTC) (envelope-from nataraja@cis.udel.edu) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6122113C46C for ; Wed, 12 Sep 2007 21:40:33 +0000 (UTC) (envelope-from nataraja@cis.udel.edu) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id C1D1E1038; Wed, 12 Sep 2007 17:40:28 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on louie.udel.edu X-Spam-Level: X-Spam-Status: No, score=-22.3 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00, LOCAL_AUTH_RCVD autolearn=ham version=3.1.8 Received: from [128.175.192.76] (roaming-192-76.nss.udel.edu [128.175.192.76]) (Authenticated sender: nataraja@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 42E2B1018 for ; Wed, 12 Sep 2007 17:40:27 -0400 (EDT) Message-ID: <46E85CCA.4050500@cis.udel.edu> Date: Wed, 12 Sep 2007 17:40:26 -0400 From: Preethi Natarajan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) To: freebsd-net@freebsd.org X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Tcp reassembly buffer size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 21:40:33 -0000 Is there an easy way to figure out the total size of all mbufs used in TCP reassembly queue (i.e. the mbufs handling out of order segments)? The sysctl vm.zone gives me info on tcpreass zone, but I want to know the actual amount of memory used by out of order segments. Thanks, -- Preethi From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 00:19:57 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B6616A41B for ; Thu, 13 Sep 2007 00:19:57 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 60FF913C459 for ; Thu, 13 Sep 2007 00:19:56 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup243.ach.sch.gr [81.186.70.243]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8D0JWmD002820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2007 03:19:41 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8D0JShM005798; Thu, 13 Sep 2007 03:19:30 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8D0JKf1005796; Thu, 13 Sep 2007 03:19:20 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 13 Sep 2007 03:19:20 +0300 From: Giorgos Keramidas To: tekkie140 Message-ID: <20070913001920.GA5712@kobe.laptop> References: <12641033.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12641033.post@talk.nabble.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.882, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.52, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-net@FreeBSD.org Subject: Re: ftp daemon fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 00:19:57 -0000 On 2007-09-12 10:58, tekkie140 wrote: > > no response in the freebsd-questions forum...maybe here? > > hi - all of a sudden (it used to work) i can't start the ftpd daemon. > > # /usr/libexec/ftpd -l -R -p ftpd-id > Sept 10 09:02:22 myhostname ftpd[1234]: getpeername (/usr/libexec/ftpd): > Socket operation on non-socket > # > > anyone know where i should look? /etc/hosts looks okay. /usr/libexec/ftpd is not something you are expected to run directly from the command-line. It should work MUCH better if you use inetd(8) to launch it. Try reading up on inetd(8) and inetd.conf(5) a bit: man inetd man inetd.conf Then edit /etc/inetd.conf to match your preferred ftpd setup, and start inetd (or restart it, if it's already running). - Giorgos From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 00:58:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A3C16A41B for ; Thu, 13 Sep 2007 00:58:17 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7314C13C45B for ; Thu, 13 Sep 2007 00:58:17 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1IVcFM-0003dT-G3 for freebsd-net@freebsd.org; Thu, 13 Sep 2007 00:07:52 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1IVcFM-0002Cg-Bh for freebsd-net@freebsd.org; Thu, 13 Sep 2007 00:07:52 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id BC2A88E296; Wed, 12 Sep 2007 19:07:46 -0500 (CDT) Date: Wed, 12 Sep 2007 19:07:46 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20070913000746.GB22926@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <12641033.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <12641033.post@talk.nabble.com> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: ftp daemon fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 00:58:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 tekkie140 wrote: > > hi - all of a sudden (it used to work) i can't start the ftpd daemon. > > # /usr/libexec/ftpd -l -R -p ftpd-id > Sept 10 09:02:22 myhostname ftpd[1234]: getpeername (/usr/libexec/ftpd): > Socket operation on non-socket Your ftpd is thinking it was launched from inetd, and expected to get a socket on standard input. I think you need to add the -D flag to get a stand-alone daemon. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFG6H9SFSrKRjX5eCoRAnJMAJ0dtBamvO8mivrj1uiCARVWzjiSlwCggl5+ pXKFcwiLpiJN8X78/Gv3hbk= =+IVP -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 01:07:38 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E4A016A421 for ; Thu, 13 Sep 2007 01:07:38 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ironmail.infoweapons.com (ironmail.infoweapons.com [58.71.34.140]) by mx1.freebsd.org (Postfix) with ESMTP id C231B13C478 for ; Thu, 13 Sep 2007 01:07:37 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: (qmail 53246 invoked by uid 98); 13 Sep 2007 00:40:54 -0000 Received: from 10.3.1.41 by ironmail.cebu.infoweapons.com (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.86.1/959. spamassassin: 3.0.4. Clear:RC:1(10.3.1.41):. Processed in 0.072635 secs); 13 Sep 2007 00:40:54 -0000 X-Qmail-Scanner-Mail-From: rmaglasang@infoweapons.com via ironmail.cebu.infoweapons.com X-Qmail-Scanner: 1.25 (Clear:RC:1(10.3.1.41):. Processed in 0.072635 secs) Received: from unknown (HELO ?10.3.1.41?) (10.3.1.41) by ironmail.infoweapons.com with AES256-SHA encrypted SMTP; 13 Sep 2007 00:40:53 -0000 Message-ID: <46E88380.3070505@infoweapons.com> Date: Thu, 13 Sep 2007 08:25:36 +0800 From: "Ronnel P. Maglasang" User-Agent: Thunderbird 1.5 (X11/20060613) MIME-Version: 1.0 To: tekkie140 References: <12641033.post@talk.nabble.com> In-Reply-To: <12641033.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ftp daemon fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 01:07:38 -0000 tekkie140 wrote: > no response in the freebsd-questions forum...maybe here? > > hi - all of a sudden (it used to work) i can't start the ftpd daemon. > > # /usr/libexec/ftpd -l -R -p ftpd-id > Sept 10 09:02:22 myhostname ftpd[1234]: getpeername (/usr/libexec/ftpd): > Socket operation on non-socket > # > > anyone know where i should look? /etc/hosts looks okay. > daemonize the process... e.g. /usr/libexec/ftpd -D -l -R -p ftpd-id From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 03:15:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3535E16A417 for ; Thu, 13 Sep 2007 03:15:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id F07A413C442 for ; Thu, 13 Sep 2007 03:15:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id B610CEB6083; Thu, 13 Sep 2007 11:15:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id pDOq69YpoOuC; Thu, 13 Sep 2007 11:15:19 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id C1F4AEB6060; Thu, 13 Sep 2007 11:15:18 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=H+9CQW5heGTmOtxXRz59O6hO5ppxmYm/wAnjLKYZywI0ezTL3fR8q6lRQPWxkEI6r 805tqLDTXTLCxWG/av8BQ== Message-ID: <46E8AB2E.7020602@delphij.net> Date: Thu, 13 Sep 2007 11:14:54 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig919655627E1CC87DEA2FC942" Subject: [nsdispatch] hosts(5) does not override DNS lookup? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 03:15:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig919655627E1CC87DEA2FC942 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Recently one of our local user has found that he was unable to use hosts(5) to override "localhost" lookup that happens in DNS, while doing rpc_clnt_create. A preliminary investigate of this seems to be related to nsdispatch, by replacing: hosts: files dns With: hosts: files in /etc/nsswitch.conf, it does not query DNS. Before diving into NSSWITCH code, I'd like to know if this is expected behavior? Say, when we have a match in hosts(5), should we even bother to query DNS if configured hosts: files dns? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig919655627E1CC87DEA2FC942 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFG6KsuOfuToMruuMARCmgtAJUXcplUBthkyBHhBgYs9rxb3GJOAJ4s/Bh4 G9j2DGzBo4YermJ8cQTJbw== =67mU -----END PGP SIGNATURE----- --------------enig919655627E1CC87DEA2FC942-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 03:33:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6856716A419 for ; Thu, 13 Sep 2007 03:33:55 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate1.pacific.net.sg (smtpgate1.pacific.net.sg [203.120.90.31]) by mx1.freebsd.org (Postfix) with SMTP id A106F13C458 for ; Thu, 13 Sep 2007 03:33:54 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 26448 invoked from network); 13 Sep 2007 03:33:52 -0000 Received: from bb121-7-106-120.singnet.com.sg (HELO P2120.somewherefaraway.com) (oceanare@121.7.106.120) by smtpgate1.pacific.net.sg with ESMTPA; 13 Sep 2007 03:33:52 -0000 Message-ID: <46E8AF9C.3060107@pacific.net.sg> Date: Thu, 13 Sep 2007 11:33:48 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: d@delphij.net References: <46E8AB2E.7020602@delphij.net> In-Reply-To: <46E8AB2E.7020602@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: [nsdispatch] hosts(5) does not override DNS lookup? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 03:33:55 -0000 Hi, I have had the same behaviour. LI Xin wrote: > > Recently one of our local user has found that he was unable to use > hosts(5) to override "localhost" lookup that happens in DNS, while doing > rpc_clnt_create. A preliminary investigate of this seems to be related > to nsdispatch, by replacing: > > hosts: files dns > > With: > > hosts: files > > in /etc/nsswitch.conf, it does not query DNS. > > Before diving into NSSWITCH code, I'd like to know if this is expected > behavior? Say, when we have a match in hosts(5), should we even bother > to query DNS if configured hosts: files dns? > After getting a hint on the list, I found out that some strange characters in hosts made the file useless. After retyping hosts, hosts was accepted again. I was not able to find out what character it was. I expected CR, but it was not the case. Just retype or copy it from a working system. Erich From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 03:43:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B42AF16A417 for ; Thu, 13 Sep 2007 03:43:51 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 781D913C459 for ; Thu, 13 Sep 2007 03:43:51 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 2372EEB60B5; Thu, 13 Sep 2007 11:43:50 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id b1qsg7QViyks; Thu, 13 Sep 2007 11:43:42 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 605DEEB60E0; Thu, 13 Sep 2007 11:43:40 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=ENpTZJ6PBjsco4vgbHE+DTjgXmyazvAVPw9L5MB4whErAiZ0/6FopYIkCIfihC0X8 rY3MFAD6drtlo9yUq7A3w== Message-ID: <46E8B1D5.5040707@delphij.net> Date: Thu, 13 Sep 2007 11:43:17 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Erich Dollansky References: <46E8AB2E.7020602@delphij.net> <46E8AF9C.3060107@pacific.net.sg> In-Reply-To: <46E8AF9C.3060107@pacific.net.sg> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE7ACF6882E65B510FE624596" Cc: freebsd-net , d@delphij.net Subject: Re: [nsdispatch] hosts(5) does not override DNS lookup? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 03:43:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7ACF6882E65B510FE624596 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Erich Dollansky wrote: [...] > After getting a hint on the list, I found out that some strange > characters in hosts made the file useless. After retyping hosts, hosts > was accepted again. >=20 > I was not able to find out what character it was. I expected CR, but it= > was not the case. >=20 > Just retype or copy it from a working system. I think this is unrelated issue. My copy is the original copy from /usr/src/etc/hosts :-) Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigE7ACF6882E65B510FE624596 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6LHVOfuToMruuMARCt1NAJ4mo4rPRoYHfXZpQzmeUEbGd9UeqQCfVPGD LMQwP4EkPu82hmxbKDD5b+U= =HSXd -----END PGP SIGNATURE----- --------------enigE7ACF6882E65B510FE624596-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 04:28:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B032E16A419 for ; Thu, 13 Sep 2007 04:28:39 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 972FB13C46E for ; Thu, 13 Sep 2007 04:28:39 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so488133waf for ; Wed, 12 Sep 2007 21:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=X9MAqCUdKCxFqaXTFyHAisYjajHh8/MeQr6kCoCNivk=; b=G6VkHNE0+QNDNzfcmWpk0+FBACO83rYgDsY1UeLr977FFlngy2geAkYqQIsiruq1tUa/rwKQ5rX6WE0t09aufDVzmGdyWfS45YZViPcC/WKHGU3Edc6F1z9JPl7BDSOCT/15SwDpok7o6r/Rv9BqNTR/JrvU59o2HSFWl/sU5YA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ie55HMK4RazfG1W4k2itbOqR41Tc7U3IAaFzQksXr4MfHW+JzZ148oGKhn3H2rjiGT0eMmpM9moqdfFQqIG8fkwRNMSW+k8SuUdFgMaorzp1ujaZ+R9Fma92frLbM8OHEppfsfdj414taZ8AAnG/46KpR2ferVX8CknMo6JyV28= Received: by 10.114.149.2 with SMTP id w2mr10949wad.1189657714665; Wed, 12 Sep 2007 21:28:34 -0700 (PDT) Received: by 10.115.79.2 with HTTP; Wed, 12 Sep 2007 21:28:34 -0700 (PDT) Message-ID: <82bdb5ec0709122128r2d789050j7926109a84ec2033@mail.gmail.com> Date: Wed, 12 Sep 2007 23:28:34 -0500 From: "sazzadur rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query regarding dynamic address configuration in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 04:28:39 -0000 Hello, I am trying to test a dynamic address configuration scenario between a sctp server and a sctp client. The scenario is like: sctp_server(129.15.78.125) sctp_client(129.15.78.114) 1. <------------------------------------------------------------------------ connect accept -----------------------------------------------------------------------> 2. <--------------------------------------------------------------------- data sack -----------------------------------------------------------------------> sctp_server creates an ipalias of 129.15.78.126 3. addip(129.15.78.126 )--------------------------------------------------------> <-------------------------------------------------------------------------asconf_ack 4. setpeerprimary(129.15.78.126)-------------------------------------------> <-------------------------------------------------------------------------asconf_ack 5. <------------------------------------------------------------------------ data (still it sends data to peers 129.15.78.125 instead of 129.15.78.126) I was expecting that in step 5, sctp_client would send data to sctp_server in 129.15.78.126 IP address which has been set primary by peer. But it still sends data to the old ip address 129.15.78.125. I found add ip and setpeerprimary operations were successful as sctp_server gets successful asconf_ack after each operations. I also found that sctp_client gets SCTP_PEER_ADDR_CHANGE event with states SCTP_ADDR_ADDED and SCTP_ADDR_CONFIRMED after addip operation by sctp_server and SCTP_ADDR_MADE_PRIM state after set_peer_primary_address operation by sctp_server. Hence, I guess every operations worked perfect. So, is my expectation wrong in this scenario? What else should I do to make sctp_client send data to 129.15.78.126 ip address instead of 129.15.78.125ip address? I would appriciate any help in this regard. Best Regards, Sazzadur Rahman, Graduate Student, School of computer science, University of Oklahoma, Norman, USA From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 05:29:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4023B16A419 for ; Thu, 13 Sep 2007 05:29:18 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCA213C45A for ; Thu, 13 Sep 2007 05:29:17 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.1/8.14.1) with ESMTP id l8D5TCQ2005285; Thu, 13 Sep 2007 00:29:12 -0500 (CDT) Date: Thu, 13 Sep 2007 00:29:12 -0500 (CDT) From: Scott Bennett Message-Id: <200709130529.l8D5TCDO005284@mp.cs.niu.edu> To: volker@vwsoft.com Cc: tom@tomjudge.com, freebsd-net@freebsd.org Subject: Re: axe(4) and Linksys USB200M question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 05:29:18 -0000 On Tue, 11 Sep 2007 15:46:56 +0200 Volker wrote >On 09/10/07 23:16, Scott Bennett wrote: >> Oh. So now I have another couple of white elephants. Damn. And I still >> don't have anything that will work as a second interface. Sigh. > >Do not trash them. Please test the patches available at: >http://opal.com/jr/freebsd/sys/dev/usb/ Thank you. I've already heard from someone else off-list who has been working on a patch for axe(4) modules. That person says that the patch is working on a different USB NIC that uses the same chipset, but that performance is still poor. The performance that the author is thus far getting is plenty adequate for my current needs, and I plan to test that patch in the next day or two. If it fails to work or produces errors, I will next try the patch you mention above. If it works, however, I understand that the patch may be committed to -HEAD soon, though the author would like to test it on some other devices using the older chipset as well first. > >> Also, do you have any suggestions for alternatives? > >I know your problem well. I do have a bunch of not supported USB NICs >but also I've got a bunch of supported ones (mostly aue(4) based >ones). These are cheap, and are sold a lot. There's (AFAIK) just one >newer aue chipset which is currently not supported by aue(4) and is >giving some errors. I haven't been able to figure out what's wrong >with them. > >When grabbing aue based USB NICs from an online source, the chances >are 3 out of 4 you're getting a supported one. But you should test That's great to know, and I will keep your message at hand in case the USB200Ms don't work soon. Thank you for that. >your USB200Mv2 using the patches first. > Right on. Thanks again for the help! Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 11:08:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3383216A421 for ; Thu, 13 Sep 2007 11:08:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2C84413C458 for ; Thu, 13 Sep 2007 11:08:49 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IVmYy-0002bb-5R for freebsd-net@freebsd.org; Thu, 13 Sep 2007 04:08:48 -0700 Message-ID: <12652777.post@talk.nabble.com> Date: Thu, 13 Sep 2007 04:08:48 -0700 (PDT) From: tekkie140 To: freebsd-net@freebsd.org In-Reply-To: <20070913000746.GB22926@verio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: administrator@ksd140.org References: <12641033.post@talk.nabble.com> <20070913000746.GB22926@verio.net> Subject: Re: ftp daemon fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 11:08:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 tekkie140 wrote: > > hi - all of a sudden (it used to work) i can't start the ftpd daemon. > > # /usr/libexec/ftpd -l -R -p ftpd-id > Sept 10 09:02:22 myhostname ftpd[1234]: getpeername (/usr/libexec/ftpd): > Socket operation on non-socket > Your ftpd is thinking it was launched from inetd, and expected to get a > socket on standard input. > I think you need to add the -D flag to get a stand-alone daemon. Yes, good call. Silly of me to think that ftpd (ftp daemon) would automatically launch as a daemon. The -D flag did the trick. Thanks! Thanks to the others who responded as well. I'll RTFM on inet as well. -- View this message in context: http://www.nabble.com/ftp-daemon-fails-tf4431115.html#a12652777 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 11:29:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B5A16A417 for ; Thu, 13 Sep 2007 11:29:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7F65513C46E for ; Thu, 13 Sep 2007 11:29:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so596558waf for ; Thu, 13 Sep 2007 04:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=V+tPQ5tm0aOCzayh/8HDc//XXrAMVaeEndTeegxAOoQ=; b=Z4I4+SZJUgJOR281QgzXZUaTiTr+5+s+yNEdMOllGbeqP5VFFureAqYmZy7fQqfNBTfi23monT81rLAbzFR9O8eUgnP0EarOdzmaVxALHkCct8Z2sJGDr9s79WW+Hjfni6pZyO/C6lvhT3wQl0d2EmiqyXUziNqmb0hCt9VYeKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Jb/sI1G6xMwnmuTqxcW38Z9QnVXTnrXlg2G9yCTOJYi58UG4Ps/EG6r6CYSf43dHIAP2TFWuIbUqvr0cUsWDuOsGLC7XVepmxvj1S423th6KnIZz97KaFhrTLMiliSekkKAsZLWpf5iydhFE9+xXM6IYm4XuSH5ViFlzzlYJIuI= Received: by 10.115.106.7 with SMTP id i7mr489137wam.1189682948884; Thu, 13 Sep 2007 04:29:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k9sm10609889wah.2007.09.13.04.29.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2007 04:29:07 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l8DBQPva014907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 20:26:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l8DBQOGK014906; Thu, 13 Sep 2007 20:26:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 13 Sep 2007 20:26:24 +0900 From: Pyun YongHyeon To: Robert Wojciechowski Message-ID: <20070913112624.GC13071@cdnetworks.co.kr> References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> User-Agent: Mutt/1.4.2.1i Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch Subject: Re: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 11:29:10 -0000 On Wed, Sep 12, 2007 at 05:21:13PM -0400, Robert Wojciechowski wrote: > > > I'm the FreeBSD nfe driver from > > > > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > > with FreeBSD 6-stable with good results for the most part. The only > > > issue I've experienced is that during a detach/shutdown of if_nfe, > > the > > > IPMI IP address I have set on my servers ceases to respond as well > > as > > > the ability to manage the servers. > > > > > > > > > > > > I traced the problem down to nfe_stop() and the fact that it > > completely > > > disables the Rx and Tx on the NIC. I have patched the driver to not > > > disable the Rx/Tx and IPMI continues to work after a 'ifconfig nfe0 > > > down', 'shutdown -p now', etc. > > > > > > > > > > > > Does anyone have any comments on this change I've made and any > > possible > > > side effects? Can this be included in the mainstream distribution > of > > the > > > > Because MAC is still alive if's possible to recieve a packet. All DMA > > maps are unloaded and buffers are already freed in nfe_stop so it > > would cause panic I guess. But I'm not familiar with IPMI so I'm not > > sure. > > Interesting, that is an issue that was also resolved by the forcedeth > driver in Linux by resetting in nv_close to prevent DMA into freed > memory. > > > > > > nfe drivers (and updated in 7-CURRENT) without causing any adverse > > > problems? > > > > > > > I have no experience on IPMI but the change you've made would not > > completely solve the issue. I guess supporting IPMI needs lots of > > more work including: > > o Autodetect IPMI capability. > > o Autodetect active IPMI session in device attach and don't blindly > > reset MAC/PHY. > > o Don't blindly stop Tx/Rx on device detach. > > Given that lack of publicly available datasheet for the hardware > > supporing IPMI would be severly limited. Fortunately Linux seems to > > have basic IPMI support in their forcedeth driver. Their code doesn't > > easy to read but you may see what should be done in driver. However > > I have no idea what we can do when active IPMI session is present in > > driver attach phase. Normally PHY driver would reset PHY hardware > > itself in driver attach which in turn would result in losing the IPMI > > connection. > > > > Since we have no idea how to auto-detect IPMI, I added a device sysctl > (enable_ipmi) to control the behavior I'm testing in-house right now. > > If the enable_ipmi sysctl is enabled, it'll: > > * resets after disabling the Rx/Tx and before disabling interrupts It also need to enable Tx/Rx bits related with IPMI. > * re-enables the Rx/Tx after the ring buffers are freed, just like > forcedeth but also enabling the Tx for IPMI (Linux just enabled the Rx > for WOL) You may only want to enable IPMI Tx/Rx. Blindly enabling entire MAC generates more problems. forcedeth uses different bits for IPMI Rx/Tx. > > I have attached my new patch to this email that does the above, guarded > by the sysctl. > Btw, it seems there is typo in the patch. You used sc->nfe_process_limit instead of sc->nfe_enable_ipmi in enable_ipmi value range check. In order to check IPMI capability you don't need '&' operator. > I have no idea how to handle the second case you mentioned, during > attach. It does indeed cause a disruption in IPMI, but only for a few > seconds. Where is the MAC and PHY reset and if it wasn't reset when > using IPMI, what problems could it cause? > It's somewhat complex. MAC reset is done by nfe(4) whereas all PHY related handling is done by its PHY driver(ciphy(4), e1000phy(4), rgephy(4), rlphy(4) etc) and link state change event can also enable/disable MAC. See nfe_link_task(). Witout proper reset operation of PHY, some functions like automatic MDI/MDI-X detection, wakeup from powerdown mode, special page register settings wouldn't be activated which in turn result in operating at legacy mode. In worst case the PHY wouldn't work at all and you may see no link, i.e. "no career" message. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 13:50:23 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604D316A41B for ; Thu, 13 Sep 2007 13:50:23 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 26EF113C442 for ; Thu, 13 Sep 2007 13:50:23 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.20,250,1186383600"; d="scan'208";a="523552061" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2007 06:50:23 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DDoMep002100; Thu, 13 Sep 2007 06:50:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8DDoIoV016902; Thu, 13 Sep 2007 13:50:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 06:49:13 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 06:49:13 -0700 Message-ID: <46E93FC6.4080003@cisco.com> Date: Thu, 13 Sep 2007 09:48:54 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0709122128r2d789050j7926109a84ec2033@mail.gmail.com> In-Reply-To: <82bdb5ec0709122128r2d789050j7926109a84ec2033@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 13:49:13.0645 (UTC) FILETIME=[DE81FDD0:01C7F60C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3089; t=1189691422; x=1190555422; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20dynamic=20address=20configura tion=20in=20SCTP |Sender:=20; bh=+qkZ0tv/i2zvm7dyfv94IMyZNniEmNp8iTpOVAudKbg=; b=u/vbEOaa2fH0Ls1MnwgWMsO1tkWwAotis3kdDXYbfvIAkgWfOyIL2PNaLMcFcoP1kyW4LQVB eTceBJhpmf7u7siGpfFAh7CmFwG8a2LuWc+FmO/m+ELCRiSZJuKze4fe; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding dynamic address configuration in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 13:50:23 -0000 Sazzadur: No I don't think your expectation is wrong.. this may be a bug in the code. Not sure whats up but I will test this scenario and see if I can recreate it. Once you get the addr made primary .. this should be the primary address.. Let me try this here in my lab and see if I get the same results. By the way. What version of the code are you on.. is it the Current 7.0 code.. or is it a patch from sctp.org on 6.x? If a patch, what is the name (date) of the patch.. Thanks R sazzadur rahman wrote: > Hello, > > I am trying to test a dynamic address configuration scenario between a sctp > server and a sctp client. > The scenario is like: > > > sctp_server(129.15.78.125) > sctp_client(129.15.78.114) > > 1. > <------------------------------------------------------------------------ > connect > accept > -----------------------------------------------------------------------> > > 2. > <--------------------------------------------------------------------- data > > sack > -----------------------------------------------------------------------> > > sctp_server > creates an ipalias > of 129.15.78.126 > > 3. addip(129.15.78.126 > )--------------------------------------------------------> > > <-------------------------------------------------------------------------asconf_ack > > > 4. setpeerprimary(129.15.78.126)-------------------------------------------> > > <-------------------------------------------------------------------------asconf_ack > > > 5. > <------------------------------------------------------------------------ > data (still it sends data to peers > > 129.15.78.125 instead of 129.15.78.126) > > I was expecting that in step 5, sctp_client would send data to sctp_server > in 129.15.78.126 IP address > which has been set primary by peer. But it still sends data to the old ip > address 129.15.78.125. > > I found add ip and setpeerprimary operations were successful as sctp_server > gets successful asconf_ack after each > operations. I also found that sctp_client gets SCTP_PEER_ADDR_CHANGE event > with states SCTP_ADDR_ADDED and SCTP_ADDR_CONFIRMED after addip operation > by sctp_server and SCTP_ADDR_MADE_PRIM state after set_peer_primary_address > operation by sctp_server. Hence, I guess every operations worked perfect. > > > So, is my expectation wrong in this scenario? What else should I do to make > sctp_client send data to 129.15.78.126 ip address instead of > 129.15.78.125ip address? > > I would appriciate any help in this regard. > > Best Regards, > Sazzadur Rahman, > Graduate Student, > School of computer science, > University of Oklahoma, > Norman, USA > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 14:10:56 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23C0216A417 for ; Thu, 13 Sep 2007 14:10:56 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id D84AE13C465 for ; Thu, 13 Sep 2007 14:10:55 +0000 (UTC) (envelope-from robertw@expressyard.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 0FB994128; Thu, 13 Sep 2007 10:15:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Sep 2007 10:11:22 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326866236A2@server1.ssgi.local> In-Reply-To: <20070913112624.GC13071@cdnetworks.co.kr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD nfe driver and IPMI cards Thread-Index: Acf1+W+yEidDPnlmTLW9yXLdvOpmJgAEgNEQ References: <85D4F2C294E8434CA0AF775741532686623679@server1.ssgi.local> <20070912004554.GA8992@cdnetworks.co.kr> <85D4F2C294E8434CA0AF775741532686623694@server1.ssgi.local> <20070913112624.GC13071@cdnetworks.co.kr> From: "Robert Wojciechowski" To: Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, Josh Mouch Subject: RE: FreeBSD nfe driver and IPMI cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 14:10:56 -0000 > You may only want to enable IPMI Tx/Rx. Blindly enabling entire MAC > generates more problems. forcedeth uses different bits for IPMI Rx/Tx. >=20 Oh, hmm. I didn't see anything in forcedeth 0.60 that only enabled the IPMI Rx/Tx. It does turn out that I was looking at an older version, though, and that they now set the packet filter to non-promisc mode just in case before starting the Rx. I updated the patch to include that. > > > > I have attached my new patch to this email that does the above, > > guarded by the sysctl. > > >=20 > Btw, it seems there is typo in the patch. You used sc- > >nfe_process_limit > instead of sc->nfe_enable_ipmi in enable_ipmi value range check. In > order to check IPMI capability you don't need '&' operator. >=20 Oops, yes. The typo and dereferencing were mistakes, thanks for catching that. Updated in the patch. > > I have no idea how to handle the second case you mentioned, during > > attach. It does indeed cause a disruption in IPMI, but only for a few > > seconds. Where is the MAC and PHY reset and if it wasn't reset when > > using IPMI, what problems could it cause? > > >=20 > It's somewhat complex. MAC reset is done by nfe(4) whereas all PHY > related handling is done by its PHY driver(ciphy(4), e1000phy(4), > rgephy(4), rlphy(4) etc) and link state change event can also > enable/disable MAC. See nfe_link_task(). > Witout proper reset operation of PHY, some functions like automatic > MDI/MDI-X detection, wakeup from powerdown mode, special page register > settings wouldn't be activated which in turn result in operating at > legacy mode. In worst case the PHY wouldn't work at all and you may > see no link, i.e. "no career" message. >=20 This is probably also a problem for many other NICs I'm assuming? Not many drivers seem to handle detection of ASF/IPMI and initialize carefully to avoid causing problems. That being said, with the changes in this current patch at least a machine is manageable if you reboot/shutdown/unload the module. Perhaps handling the attach perfectly will have to wait until Nvidia opens up the specs. -- Robert From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 14:17:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11BE16A41A for ; Thu, 13 Sep 2007 14:17:36 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id 28D2013C457 for ; Thu, 13 Sep 2007 14:17:35 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so546015fka for ; Thu, 13 Sep 2007 07:17:35 -0700 (PDT) Received: by 10.82.156.12 with SMTP id d12mr979868bue.1189693054469; Thu, 13 Sep 2007 07:17:34 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Thu, 13 Sep 2007 07:17:34 -0700 (PDT) Message-ID: Date: Thu, 13 Sep 2007 17:17:34 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: nfe(4) and RELENG_6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 14:17:36 -0000 Hi, I'm sorry if I ask something that's been asked before. Is there any reason not to include nfe(4) in STABLE? It's been working flawlessly ever since I installed the OS at work, and it's quite annoying to have to recompile it everytime I recompile the kernel. Thanks! -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Sep 13 14:50:45 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 840C716A417 for ; Thu, 13 Sep 2007 14:50:45 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3717413C4B0 for ; Thu, 13 Sep 2007 14:50:44 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.20,250,1186383600"; d="scan'208";a="523574830" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2007 07:50:43 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEohWV028921; Thu, 13 Sep 2007 07:50:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEofFK008473; Thu, 13 Sep 2007 14:50:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 07:50:41 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 07:50:40 -0700 Message-ID: <46E94E2D.2090204@cisco.com> Date: Thu, 13 Sep 2007 10:50:21 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0709122128r2d789050j7926109a84ec2033@mail.gmail.com> In-Reply-To: <82bdb5ec0709122128r2d789050j7926109a84ec2033@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 14:50:41.0138 (UTC) FILETIME=[746CC520:01C7F615] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2822; t=1189695043; x=1190559043; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20dynamic=20address=20configura tion=20in=20SCTP |Sender:=20; bh=ZbZJ9r19csD7Ptxhj3LBeSX6RN3t+/8OkYER15ftMig=; b=VLNweQP3p0Rj8ZcHtRcDLFb/bfwRqBWbKxC7r9Ft9iOQyDMo+JoHmxKTFDOEu6E6im5mkJa5 s14HZJSDCy7WKoo/IEHotl2covoFnS4OjuObRocxIOEfrGup27W0qVgh; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding dynamic address configuration in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 14:50:45 -0000 Sazzadur: I cannot recreate this... I will contact you offlist and share with you my results (and pcap file). I see things work as you expect below.. different addresses of course. This is of course with the latest code in Current. R sazzadur rahman wrote: > Hello, > > I am trying to test a dynamic address configuration scenario between a sctp > server and a sctp client. > The scenario is like: > > > sctp_server(129.15.78.125) > sctp_client(129.15.78.114) > > 1. > <------------------------------------------------------------------------ > connect > accept > -----------------------------------------------------------------------> > > 2. > <--------------------------------------------------------------------- data > > sack > -----------------------------------------------------------------------> > > sctp_server > creates an ipalias > of 129.15.78.126 > > 3. addip(129.15.78.126 > )--------------------------------------------------------> > > <-------------------------------------------------------------------------asconf_ack > > > 4. setpeerprimary(129.15.78.126)-------------------------------------------> > > <-------------------------------------------------------------------------asconf_ack > > > 5. > <------------------------------------------------------------------------ > data (still it sends data to peers > > 129.15.78.125 instead of 129.15.78.126) > > I was expecting that in step 5, sctp_client would send data to sctp_server > in 129.15.78.126 IP address > which has been set primary by peer. But it still sends data to the old ip > address 129.15.78.125. > > I found add ip and setpeerprimary operations were successful as sctp_server > gets successful asconf_ack after each > operations. I also found that sctp_client gets SCTP_PEER_ADDR_CHANGE event > with states SCTP_ADDR_ADDED and SCTP_ADDR_CONFIRMED after addip operation > by sctp_server and SCTP_ADDR_MADE_PRIM state after set_peer_primary_address > operation by sctp_server. Hence, I guess every operations worked perfect. > > > So, is my expectation wrong in this scenario? What else should I do to make > sctp_client send data to 129.15.78.126 ip address instead of > 129.15.78.125ip address? > > I would appriciate any help in this regard. > > Best Regards, > Sazzadur Rahman, > Graduate Student, > School of computer science, > University of Oklahoma, > Norman, USA > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Sep 14 00:53:43 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC40F16A417; Fri, 14 Sep 2007 00:53:43 +0000 (UTC) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BEF5713C442; Fri, 14 Sep 2007 00:53:43 +0000 (UTC) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (rodrigc@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8E0rhv9039968; Fri, 14 Sep 2007 00:53:43 GMT (envelope-from rodrigc@freefall.freebsd.org) Received: (from rodrigc@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8E0rhN6039964; Fri, 14 Sep 2007 00:53:43 GMT (envelope-from rodrigc) Date: Fri, 14 Sep 2007 00:53:43 GMT Message-Id: <200709140053.l8E0rhN6039964@freefall.freebsd.org> To: rodrigc@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: rodrigc@FreeBSD.org Cc: Subject: Re: kern/116335: Excessive TCP window updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 00:53:44 -0000 Synopsis: Excessive TCP window updates Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: rodrigc Responsible-Changed-When: Fri Sep 14 00:53:26 UTC 2007 Responsible-Changed-Why: Send to freebsd-net@ http://www.freebsd.org/cgi/query-pr.cgi?pr=116335 From owner-freebsd-net@FreeBSD.ORG Fri Sep 14 10:11:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D69BE16A418 for ; Fri, 14 Sep 2007 10:11:30 +0000 (UTC) (envelope-from myronn@seed.net.tw) Received: from seed.net.tw (sn16.seed.net.tw [139.175.54.16]) by mx1.freebsd.org (Postfix) with ESMTP id B3AE713C442 for ; Fri, 14 Sep 2007 10:11:30 +0000 (UTC) (envelope-from myronn@seed.net.tw) Received: from [139.175.54.128] (port=51721 helo=wm8.seed.net.tw) by seed.net.tw with esmtp (Seednet 4.23:1) id 1IW7fp-000Dji-BC for freebsd-net@freebsd.org; Fri, 14 Sep 2007 17:41:17 +0800 Message-ID: <18389100.19191189762877349.JavaMail.root@wm8.seed.net.tw> Date: Fri, 14 Sep 2007 17:41:17 +0800 (CST) From: myronn@seed.net.tw To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain;charset=Big5 Content-Transfer-Encoding: 7bit Subject: ICMP issue while multiple interface in the same subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 10:11:30 -0000 Hi, For a special test reason, I must use two hosts and it has two interfaces to connect each other without any switch or hub. Host1 Host2 |-----| |-----| | 1 0-----------------0 1 | | | | | | 2 0-----------------0 2 | |-----| |-----| Host platform OS is BSD. I assigned Host1 NIC1 ping Host NIC2. Command is correct but I found as follows: 1. Host1 arp broadcast to Host2 and Host2 would be return info to Host1. 2. Then, Host1 sent ICMP request packet to Host2. 3. Host2 received packet and always "USE" NIC2 replaying the ICMP reply. 4. If Host1 use NIC2 ping Host2 NIC2, Host1 NIC2 could get the ICMP reply packet from Host2 NIC2. Question: 1. This behavior is a normal network behavior? 2. If it's a normal network behavior, it followed which standard? 3. I know that there were other softwares could change this behavior but why many platforms(BSD,Linux,.....) used this behavior was its default network behavior? 4. Why default behavior is incoming interface different from outgoing interface? 5. If I set all interfaces are in the same subnet and the incoming interface is the same with outgoing interface, what weakness would be happened? Thanks and Regards, Myron From owner-freebsd-net@FreeBSD.ORG Fri Sep 14 10:57:03 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928FE16A418 for ; Fri, 14 Sep 2007 10:57:03 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 16CA913C458 for ; Fri, 14 Sep 2007 10:57:03 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id AFC6750871; Fri, 14 Sep 2007 13:57:01 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTU3VBUMkagZ; Fri, 14 Sep 2007 13:56:58 +0300 (EEST) Received: from [193.226.5.46] (hades.utcluj.ro [193.226.5.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 989A95087B; Fri, 14 Sep 2007 13:56:58 +0300 (EEST) Message-ID: <46EA68FB.8010108@net.utcluj.ro> Date: Fri, 14 Sep 2007 13:56:59 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: myronn@seed.net.tw References: <18389100.19191189762877349.JavaMail.root@wm8.seed.net.tw> In-Reply-To: <18389100.19191189762877349.JavaMail.root@wm8.seed.net.tw> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ICMP issue while multiple interface in the same subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 10:57:03 -0000 myronn@seed.net.tw wrote: > Hi, > For a special test reason, I must use two hosts and it has two interfaces to connect each other without any switch or hub. > Host1 Host2 > |-----| |-----| > | 1 0-----------------0 1 | > | | | | > | 2 0-----------------0 2 | > |-----| |-----| > > Host platform OS is BSD. I assigned Host1 NIC1 ping Host NIC2. Command is correct but I found as follows: > 1. Host1 arp broadcast to Host2 and Host2 would be return info to Host1. > 2. Then, Host1 sent ICMP request packet to Host2. > 3. Host2 received packet and always "USE" NIC2 replaying the ICMP reply. > 4. If Host1 use NIC2 ping Host2 NIC2, Host1 NIC2 could get the ICMP reply packet from Host2 NIC2. > > Question: > 1. This behavior is a normal network behavior? > 2. If it's a normal network behavior, it followed which standard? > 3. I know that there were other softwares could change this behavior but why many platforms(BSD,Linux,.....) used this behavior was its default network behavior? > 4. Why default behavior is incoming interface different from outgoing interface? > 5. If I set all interfaces are in the same subnet and the incoming interface is the same with outgoing interface, what weakness would be happened? Hi, This is the expected behaviour. ICMP reply packets are sent to the destination based on routing table, and not on the same interface as the incoming ICMP request packet. Depending on what you would like to accomplish, your solution could be as easy as adding a route, or as complicated as using policy routing. From owner-freebsd-net@FreeBSD.ORG Fri Sep 14 19:57:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A5A216A41A for ; Fri, 14 Sep 2007 19:57:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 06E4B13C45D for ; Fri, 14 Sep 2007 19:57:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 14 Sep 2007 12:57:03 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 5C1191263AD; Fri, 14 Sep 2007 12:57:03 -0700 (PDT) Message-ID: <46EAE78D.8060108@elischer.org> Date: Fri, 14 Sep 2007 12:57:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Christensen , FreeBSD Net , Jack Vogel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 19:57:05 -0000 more on this issue: 802.3-2000 expanded the maximum frame size for standard ethernet to 1522 bytes (including vlan header, ethernet header and CRC). however this has produced quite a bit of confusion with HP telling their custommers to set their MTUs on equipment to 1522, which in turn has packets of 1522+vlan_header+CRC+etherhedr (i.e. too big) floating around some networks. When we try to connect our FreeBSD based products on these networks thigns go badly. Sure they've misconfigured their networks but telling a bank to reconfigure their network with all the change-control they have, is a sure fire way to lose a $100,000 deal. Our action has been to relax the discard limit on various drivers, but it'd be nice if we didn't have to keep separate diffs for this. I discussed it a while back on net but the discussion was mostly about the code in if_ethersubr.c (since deleted) that did the same. I'd like to just ask around as to whether relaxing the limit on drivers makes sense, and if so, how much to relax it. While we're about it, what size is the actual maximal sized jumbo packet we will ever see? (including likely misconfigurations). It is possible we should just allow any packet that fits into the allocated memory, though one might suggest we just allow say 32 bytes of leeway or something. Julian From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 01:29:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F6DF16A41B for ; Sat, 15 Sep 2007 01:29:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE0D13C45A for ; Sat, 15 Sep 2007 01:29:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IWMTn-0004aJ-8d for freebsd-net@freebsd.org; Fri, 14 Sep 2007 18:29:51 -0700 Message-ID: <12686199.post@talk.nabble.com> Date: Fri, 14 Sep 2007 18:29:51 -0700 (PDT) From: Ingo Flaschberger To: freebsd-net@freebsd.org In-Reply-To: <200707061348.17399.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: if@xip.at References: <468D9E86.3020605@nepal.is> <200707061348.17399.max@love2party.net> Subject: Re: carp carpdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 01:29:51 -0000 Max Laier wrote: >=20 > On Friday 06 July 2007, =C3=93lafur Helgi Haraldsson wrote: >> Im wondering if someone is working on porting carpdev option for >> ifconfig on FreeBSD 6? Are some patches for it out there? >=20 > I'm working on it (for CURRENT). Nothing to show yet, however. >=20 I have written a patch for FreeBSD 6.2-STABLE. http://www.nabble.com/file/p12686199/carpdev.diff carpdev.diff=20 Not 100% failsave. See fixme. Kind regards, Ingo --=20 View this message in context: http://www.nabble.com/carp-carpdev-tf4033279.= html#a12686199 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 04:29:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B7416A417 for ; Sat, 15 Sep 2007 04:29:40 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 73BCB13C461 for ; Sat, 15 Sep 2007 04:29:40 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IWPHV-0007gP-BL for freebsd-net@freebsd.org; Fri, 14 Sep 2007 21:29:21 -0700 Message-ID: <12687218.post@talk.nabble.com> Date: Fri, 14 Sep 2007 21:29:21 -0700 (PDT) From: Ingo Flaschberger To: freebsd-net@freebsd.org In-Reply-To: <12686199.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: if@xip.at References: <468D9E86.3020605@nepal.is> <200707061348.17399.max@love2party.net> <12686199.post@talk.nabble.com> Subject: Re: carp carpdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 04:29:40 -0000 Ingo Flaschberger wrote: > > I have written a patch for FreeBSD 6.2-STABLE. > http://www.nabble.com/file/p12686199/carpdev.diff carpdev.diff > Not 100% failsave. > See fixme. > argl.. need some more tweaks. carp adds only a hostroute, and no network. fixed that it add a network, but now kernels cries to receive the arp at the parent interface and not at the carp interface... bye, Ingo -- View this message in context: http://www.nabble.com/carp-carpdev-tf4033279.html#a12687218 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 05:22:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A704716A41A for ; Sat, 15 Sep 2007 05:22:53 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ironmail.infoweapons.com (ironmail.infoweapons.com [58.71.34.140]) by mx1.freebsd.org (Postfix) with ESMTP id B8C2513C45D for ; Sat, 15 Sep 2007 05:22:52 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: (qmail 25354 invoked by uid 98); 15 Sep 2007 05:22:38 -0000 Received: from 10.3.1.41 by ironmail.cebu.infoweapons.com (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.86.1/959. spamassassin: 3.0.4. Clear:RC:1(10.3.1.41):. Processed in 0.053316 secs); 15 Sep 2007 05:22:38 -0000 X-Qmail-Scanner-Mail-From: rmaglasang@infoweapons.com via ironmail.cebu.infoweapons.com X-Qmail-Scanner: 1.25 (Clear:RC:1(10.3.1.41):. Processed in 0.053316 secs) Received: from unknown (HELO ?10.3.1.41?) (10.3.1.41) by ironmail.infoweapons.com with AES256-SHA encrypted SMTP; 15 Sep 2007 05:22:38 -0000 Message-ID: <46EB6888.2030407@infoweapons.com> Date: Sat, 15 Sep 2007 13:07:20 +0800 From: "Ronnel P. Maglasang" User-Agent: Thunderbird 1.5 (X11/20060613) MIME-Version: 1.0 To: myronn@seed.net.tw References: <18389100.19191189762877349.JavaMail.root@wm8.seed.net.tw> In-Reply-To: <18389100.19191189762877349.JavaMail.root@wm8.seed.net.tw> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ICMP issue while multiple interface in the same subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 05:22:53 -0000 what are the IP addresses of your nics in Host1 and Host2? they should be in different networks (e.g. 10/8 and 172.16/16) for this to work. myronn@seed.net.tw wrote: > Hi, > For a special test reason, I must use two hosts and it has two interfaces to connect each other without any switch or hub. > Host1 Host2 > |-----| |-----| > | 1 0-----------------0 1 | > | | | | > | 2 0-----------------0 2 | > |-----| |-----| > > Host platform OS is BSD. I assigned Host1 NIC1 ping Host NIC2. Command is correct but I found as follows: > 1. Host1 arp broadcast to Host2 and Host2 would be return info to Host1. > 2. Then, Host1 sent ICMP request packet to Host2. > 3. Host2 received packet and always "USE" NIC2 replaying the ICMP reply. > 4. If Host1 use NIC2 ping Host2 NIC2, Host1 NIC2 could get the ICMP reply packet from Host2 NIC2. > > Question: > 1. This behavior is a normal network behavior? > 2. If it's a normal network behavior, it followed which standard? > 3. I know that there were other softwares could change this behavior but why many platforms(BSD,Linux,.....) used this behavior was its default network behavior? > 4. Why default behavior is incoming interface different from outgoing interface? > 5. If I set all interfaces are in the same subnet and the incoming interface is the same with outgoing interface, what weakness would be happened? > > Thanks and Regards, > Myron > _______________________________________________ > 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 Sep 15 08:45:32 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABC516A418; Sat, 15 Sep 2007 08:45:32 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C476413C457; Sat, 15 Sep 2007 08:45:32 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8F8jW6h062995; Sat, 15 Sep 2007 08:45:32 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8F8jWOf062991; Sat, 15 Sep 2007 08:45:32 GMT (envelope-from andre) Date: Sat, 15 Sep 2007 08:45:32 GMT Message-Id: <200709150845.l8F8jWOf062991@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/116335: Excessive TCP window updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 08:45:33 -0000 Synopsis: Excessive TCP window updates Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Sat Sep 15 08:45:13 UTC 2007 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=116335 From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 15:26:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95EE916A417 for ; Sat, 15 Sep 2007 15:26:37 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5215D13C4B6 for ; Sat, 15 Sep 2007 15:26:37 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l8FEqHwV041276; Sat, 15 Sep 2007 09:52:19 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200709151452.l8FEqHwV041276@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Fri, 14 Sep 2007 12:57:01 -0700. <46EAE78D.8060108@elischer.org> Date: Sat, 15 Sep 2007 09:52:17 -0500 Sender: karels@karels.net Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 15:26:37 -0000 > I'd like to just ask around as to whether relaxing the limit on drivers > makes sense, and if so, how much to relax it. While we're about it, > what size is the actual maximal sized jumbo packet we will ever see? (including > likely misconfigurations). > It is possible we should just allow any packet that fits into the allocated memory, > though one might suggest we just allow say 32 bytes of leeway or something. My personal opinion is that drivers should accept anything that is convenient to accept, at least up to the size that standards would dictate. The HP situation is unfortunate, but I don't see any good reason to reject those frames. If the above means up to MCLBYTES (2K), that doesn't bother me. Jumbo is another story. The maximum size is hardware-dependent. It seeems that most NICs will handle an MTU of 9000, but the actual limit varies a lot. If I recall correctly, some em cards will do about 16K, but newer cards have a lower limit. Secure Computing (my employer) has a modification that seems reasonable to me (well, I guess I wouldn't have done it otherwise). We adopted the existing but unused JUMBO_MTU capability flag, and, if enabled, instructs the driver to receive jumbo frames according to the hardware limits. With that flag, the MTU may be 1500, but the driver is still instructed to receive jumbo frames even without sending them. The reason for this is the lack of a way to negotiate the use of jumbo frames per host (as far as I know; such a thing would certainly be useful, though). Mostly, I'd still go with "be conservative in what you send, liberal in what you accept." Mike From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 16:55:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 130A216A419 for ; Sat, 15 Sep 2007 16:55:46 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id F191B13C461 for ; Sat, 15 Sep 2007 16:55:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.102]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IWavo-000K7V-PO; Sat, 15 Sep 2007 16:55:44 +0000 Message-ID: <46EC0E75.5070307@psg.com> Date: Sat, 15 Sep 2007 06:55:17 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Elischer References: <46EAE78D.8060108@elischer.org> In-Reply-To: <46EAE78D.8060108@elischer.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 16:55:46 -0000 > what size is the actual maximal sized jumbo packet we will ever see? some transpac science community folk, who care more about speed trials with big data sets than they do about over-stretching the ethernet crc, use 9k jumbo frames. randy From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 17:25:11 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA3D16A418 for ; Sat, 15 Sep 2007 17:25:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 83BB613C49D for ; Sat, 15 Sep 2007 17:25:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 15 Sep 2007 10:25:10 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 276261263C7; Sat, 15 Sep 2007 10:25:10 -0700 (PDT) Message-ID: <46EC1575.4070401@elischer.org> Date: Sat, 15 Sep 2007 10:25:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Randy Bush References: <46EAE78D.8060108@elischer.org> <46EC0E75.5070307@psg.com> In-Reply-To: <46EC0E75.5070307@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 17:25:11 -0000 Randy Bush wrote: >> what size is the actual maximal sized jumbo packet we will ever see? > > some transpac science community folk, who care more about speed trials > with big data sets than they do about over-stretching the ethernet crc, > use 9k jumbo frames. well that's the standard but the highest I've seen mentioned as a normal size is I think 9220 bytes. From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 17:31:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA32516A419 for ; Sat, 15 Sep 2007 17:31:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9058C13C478 for ; Sat, 15 Sep 2007 17:31:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.102]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IWbUV-000K9n-Qe; Sat, 15 Sep 2007 17:31:35 +0000 Message-ID: <46EC16DC.2010104@psg.com> Date: Sat, 15 Sep 2007 07:31:08 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Elischer References: <46EAE78D.8060108@elischer.org> <46EC0E75.5070307@psg.com> <46EC1575.4070401@elischer.org> In-Reply-To: <46EC1575.4070401@elischer.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 17:31:36 -0000 >>> what size is the actual maximal sized jumbo packet we will ever see? >> some transpac science community folk, who care more about speed trials >> with big data sets than they do about over-stretching the ethernet crc, >> use 9k jumbo frames. > well that's the standard but the highest I've seen mentioned as a normal > size is I think 9220 bytes. i suggest being careful with the word "standard." ieee, which controls the ethernet spec, has refused to standardize anything above 1500 on the grounds that it would over-stretch the crc. randy From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 17:41:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCACB16A418 for ; Sat, 15 Sep 2007 17:41:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA8A13C468 for ; Sat, 15 Sep 2007 17:41:01 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 15 Sep 2007 10:40:58 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id ADF3E1263C8; Sat, 15 Sep 2007 10:40:57 -0700 (PDT) Message-ID: <46EC1929.5020706@elischer.org> Date: Sat, 15 Sep 2007 10:40:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: karels@karels.net References: <200709151452.l8FEqHwV041276@redrock.karels.net> In-Reply-To: <200709151452.l8FEqHwV041276@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 17:41:01 -0000 Mike Karels wrote: >> I'd like to just ask around as to whether relaxing the limit on drivers >> makes sense, and if so, how much to relax it. While we're about it, >> what size is the actual maximal sized jumbo packet we will ever see? (including >> likely misconfigurations). > >> It is possible we should just allow any packet that fits into the allocated memory, >> though one might suggest we just allow say 32 bytes of leeway or something. > > My personal opinion is that drivers should accept anything that is > convenient to accept, at least up to the size that standards would > dictate. The HP situation is unfortunate, but I don't see any good > reason to reject those frames. If the above means up to MCLBYTES (2K), > that doesn't bother me. Normal packet storage is MCLBYTES (2k) so I think that under normal situations we should receive any packet up to that (plus or minus any mailbox info that a driver also wants to put in there (e.g. the bce driver)). Generally when the MTU is greater than some number the driver will allocate jumbo buffers. I'm not quite sure what exact size that is but I see we do 9K and 16k variants. Some documents I've seen mention 9216 (9 x 1024) and others talk about 9000. I've also seen 9100, 9160 and 9200 mentioned and one mention I think of 9220 which seems a bit of an odd man out. > > Jumbo is another story. The maximum size is hardware-dependent. It > seeems that most NICs will handle an MTU of 9000, but the actual limit > varies a lot. If I recall correctly, some em cards will do about 16K, > but newer cards have a lower limit. there seems to be a lot of confusion about this limit. > > Secure Computing (my employer) has a modification that seems reasonable > to me (well, I guess I wouldn't have done it otherwise). We adopted the > existing but unused JUMBO_MTU capability flag, and, if enabled, instructs > the driver to receive jumbo frames according to the hardware limits. With > that flag, the MTU may be 1500, but the driver is still instructed to > receive jumbo frames even without sending them. The reason for this > is the lack of a way to negotiate the use of jumbo frames per host > (as far as I know; such a thing would certainly be useful, though). certainly the adoption of that flag is reasonable. is it settable from ifconfig? it's probably better than saying "enable jumbo reception if mtu is greater than 1600 bytes" or whatever.. > > Mostly, I'd still go with "be conservative in what you send, liberal > in what you accept." > > Mike From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 18:12:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91BEE16A418 for ; Sat, 15 Sep 2007 18:12:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6371B13C45A for ; Sat, 15 Sep 2007 18:12:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 15 Sep 2007 11:12:41 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E68151263BE; Sat, 15 Sep 2007 11:12:40 -0700 (PDT) Message-ID: <46EC2098.2000908@elischer.org> Date: Sat, 15 Sep 2007 11:12:40 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Randy Bush References: <46EAE78D.8060108@elischer.org> <46EC0E75.5070307@psg.com> <46EC1575.4070401@elischer.org> <46EC16DC.2010104@psg.com> In-Reply-To: <46EC16DC.2010104@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 18:12:42 -0000 Randy Bush wrote: >>>> what size is the actual maximal sized jumbo packet we will ever see? >>> some transpac science community folk, who care more about speed trials >>> with big data sets than they do about over-stretching the ethernet crc, >>> use 9k jumbo frames. >> well that's the standard but the highest I've seen mentioned as a normal >> size is I think 9220 bytes. > > i suggest being careful with the word "standard." ieee, which controls > the ethernet spec, has refused to standardize anything above 1500 on the > grounds that it would over-stretch the crc. > true, (I was surprised to not see 9k packets in the standard (though old) that I have. (I guess now I'm in Cisco I could get to a newer one). but practicality suggests that we spport what the customer is doing. > randy From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 18:53:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD98716A41B for ; Sat, 15 Sep 2007 18:53:17 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 383B713C45E for ; Sat, 15 Sep 2007 18:53:16 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l8FIo0na042120; Sat, 15 Sep 2007 13:50:00 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200709151850.l8FIo0na042120@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Sat, 15 Sep 2007 10:40:57 -0700. <46EC1929.5020706@elischer.org> Date: Sat, 15 Sep 2007 13:50:00 -0500 Sender: karels@karels.net Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 18:53:17 -0000 > > Secure Computing (my employer) has a modification that seems reasonable > > to me (well, I guess I wouldn't have done it otherwise). We adopted the > > existing but unused JUMBO_MTU capability flag, and, if enabled, instructs > > the driver to receive jumbo frames according to the hardware limits. With > > that flag, the MTU may be 1500, but the driver is still instructed to > > receive jumbo frames even without sending them. The reason for this > > is the lack of a way to negotiate the use of jumbo frames per host > > (as far as I know; such a thing would certainly be useful, though). > certainly the adoption of that flag is reasonable. > is it settable from ifconfig? > it's probably better than saying "enable jumbo reception > if mtu is greater than 1600 bytes" or whatever.. Yes, the flag is settable with ifconfig. It expands the "accept what is convenient" to "and also accept whatever is reasonable for jumbo" (for this NIC). Mike From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 19:30:24 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6B6B16A419 for ; Sat, 15 Sep 2007 19:30:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 8153313C46C for ; Sat, 15 Sep 2007 19:30:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 15 Sep 2007 12:30:20 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 940A51263C4; Sat, 15 Sep 2007 12:30:19 -0700 (PDT) Message-ID: <46EC32CB.2030202@elischer.org> Date: Sat, 15 Sep 2007 12:30:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: karels@karels.net References: <200709151850.l8FIo0na042120@redrock.karels.net> In-Reply-To: <200709151850.l8FIo0na042120@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 19:30:24 -0000 Mike Karels wrote: >>> Secure Computing (my employer) has a modification that seems reasonable >>> to me (well, I guess I wouldn't have done it otherwise). We adopted the >>> existing but unused JUMBO_MTU capability flag, and, if enabled, instructs >>> the driver to receive jumbo frames according to the hardware limits. With >>> that flag, the MTU may be 1500, but the driver is still instructed to >>> receive jumbo frames even without sending them. The reason for this >>> is the lack of a way to negotiate the use of jumbo frames per host >>> (as far as I know; such a thing would certainly be useful, though). > >> certainly the adoption of that flag is reasonable. >> is it settable from ifconfig? >> it's probably better than saying "enable jumbo reception >> if mtu is greater than 1600 bytes" or whatever.. > > Yes, the flag is settable with ifconfig. It expands the "accept > what is convenient" to "and also accept whatever is reasonable > for jumbo" (for this NIC). > > Mike It would be interesting to get patches to look at.... Does it require changing all the drivers? I assume that if so, you'd only patch those you are interested in. From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 21:03:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E6216A417 for ; Sat, 15 Sep 2007 21:03:00 +0000 (UTC) (envelope-from SRS0=c40166501bd0870be4ada925990340ae3ca4aa35=459=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 444E213C458 for ; Sat, 15 Sep 2007 21:03:00 +0000 (UTC) (envelope-from SRS0=c40166501bd0870be4ada925990340ae3ca4aa35=459=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id UER66255; Sat, 15 Sep 2007 14:02:55 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1730A4500C; Sat, 15 Sep 2007 14:02:55 -0700 (PDT) To: Randy Bush In-Reply-To: Your message of "Sat, 15 Sep 2007 06:55:17 -1000." <46EC0E75.5070307@psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189890175_21733P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 15 Sep 2007 14:02:55 -0700 From: "Kevin Oberman" Message-Id: <20070915210255.1730A4500C@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;;; X-Sender: X-To_Name: Randy Bush X-To_Domain: psg.com X-To: Randy Bush X-To_Email: randy@psg.com X-To_Alias: randy Cc: FreeBSD Net , Julian Elischer Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 21:03:00 -0000 --==_Exmh_1189890175_21733P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 15 Sep 2007 06:55:17 -1000 > From: Randy Bush > Sender: owner-freebsd-net@freebsd.org > > > what size is the actual maximal sized jumbo packet we will ever see? > > some transpac science community folk, who care more about speed trials > with big data sets than they do about over-stretching the ethernet crc, > use 9k jumbo frames. Almost the entire global R&E community uses 9K frames. This includes Internet2 (USA), Geant (Europe), Red Clara (S. America), CA*net (Canada), CUDI (Mexico), AMPATH (S. America), Transpac, Kreonet (Korea), NASA (USA), and ESnet (USA). 9000 (just to clarify the meaning of 'K') is the MTU recommended by the Joint Engineering Taskforce, a group which is a consortium of US and Canadian R&E networks and adopted almost universally in the global community. This will allow for multiple stacked VLAN and/or MPLS tags on an 8K byte data packet. Note that most systems use an 8192 byte IP MTU as that usually affords better performance as the data portion of the packet will fit in a single page of memory on most systems. -- 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 --==_Exmh_1189890175_21733P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG7Eh/kn3rs5h7N1ERAk7CAKCpS/JWn89B7s5yUrv3BReOLYXE4wCeJhZp TC34AHRxwiNbHMhsY7RmGCI= =oR1U -----END PGP SIGNATURE----- --==_Exmh_1189890175_21733P-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 21:55:56 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E18D16A418 for ; Sat, 15 Sep 2007 21:55:56 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id ABEAC13C468 for ; Sat, 15 Sep 2007 21:55:55 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l8FLq1lq042729; Sat, 15 Sep 2007 16:52:01 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200709152152.l8FLq1lq042729@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Sat, 15 Sep 2007 12:30:19 -0700. <46EC32CB.2030202@elischer.org> Date: Sat, 15 Sep 2007 16:52:01 -0500 Sender: karels@karels.net Cc: FreeBSD Net , David Christensen , Jack Vogel Subject: Re: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 21:55:56 -0000 > Mike Karels wrote: > >>> Secure Computing (my employer) has a modification that seems reasonable > >>> to me (well, I guess I wouldn't have done it otherwise). We adopted the > >>> existing but unused JUMBO_MTU capability flag, and, if enabled, instructs > >>> the driver to receive jumbo frames according to the hardware limits. With > >>> that flag, the MTU may be 1500, but the driver is still instructed to > >>> receive jumbo frames even without sending them. The reason for this > >>> is the lack of a way to negotiate the use of jumbo frames per host > >>> (as far as I know; such a thing would certainly be useful, though). > > > >> certainly the adoption of that flag is reasonable. > >> is it settable from ifconfig? > >> it's probably better than saying "enable jumbo reception > >> if mtu is greater than 1600 bytes" or whatever.. > > > > Yes, the flag is settable with ifconfig. It expands the "accept > > what is convenient" to "and also accept whatever is reasonable > > for jumbo" (for this NIC). > > > > Mike > It would be interesting to get patches to look at.... > Does it require changing all the drivers? > I assume that if so, you'd only patch those you are interested in. I can provide diffs if they are of interest. As you say, this is driver-by-driver. We have done only em at this point, as we don't support 9K clusters. (Long story, has to do with resource management.) Mike From owner-freebsd-net@FreeBSD.ORG Sat Sep 15 22:40:06 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3827016A418 for ; Sat, 15 Sep 2007 22:40:06 +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 E243113C442 for ; Sat, 15 Sep 2007 22:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8FMe5OE009640 for ; Sat, 15 Sep 2007 22:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8FMe5rN009639; Sat, 15 Sep 2007 22:40:05 GMT (envelope-from gnats) Date: Sat, 15 Sep 2007 22:40:05 GMT Message-Id: <200709152240.l8FMe5rN009639@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Death Kitten" Cc: Subject: Re: kern/112528: [nfs] NFS over TCP under load hangs with "impossible packet length" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Death Kitten List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 22:40:06 -0000 The following reply was made to PR kern/112528; it has been noted by GNATS. From: "Death Kitten" To: bug-followup@FreeBSD.org, seraphi.lord@gmail.com Cc: Subject: Re: kern/112528: [nfs] NFS over TCP under load hangs with "impossible packet length" Date: Sat, 15 Sep 2007 18:07:12 -0400 ------=_Part_9076_1125785.1189894032915 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I get this error as well. impossible packet length (365132517) from nfs server 10.10.129.4:/tank/sites/images.domain.org impossible packet length (1642561917) from nfs server 10.10.129.4:/tank/sites/images.domain.org impossible packet length (45280) from nfs server 10.10.129.4:/tank/sites/images.domain.org impossible packet length (2937967) from nfs server 10.10.129.4:/tank/sites/images.domain.org %uname -a FreeBSD www0.domain.org 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Apr 28 20:12:34 CDT 2007 ender@domain.org:/usr/obj/usr/src/sys/DOMAINWWW i386 ------=_Part_9076_1125785.1189894032915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I get this error as well.
 
impossible packet length (365132517) from nfs server 10.10.129.4:/tank/sites/images.domain.org
impossible packet length (1642561917) from nfs server 10.10.129.4:/tank/sites/images.domain.org
impossible packet length (45280) from nfs server 10.10.129.4:/tank/sites/images.domain.org
impossible packet length (2937967) from nfs server 10.10.129.4:/tank/sites/images.domain.org
%uname -a
FreeBSD www0.domain.org 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Apr 28 20:12:34 CDT 2007     ender@domain.org:/usr/obj/usr/src/sys/DOMAINWWW  i386


------=_Part_9076_1125785.1189894032915--