From owner-freebsd-net@FreeBSD.ORG Sun Oct 13 08:45:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCE40E50 for ; Sun, 13 Oct 2013 08:45:20 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 687A9293C for ; Sun, 13 Oct 2013 08:45:20 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id c11so326024wgh.9 for ; Sun, 13 Oct 2013 01:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Fj3iRQJbUUbPCn8uFosmHJIjPT2kqgQSeH1dOQ4cBT0=; b=uJ2D1+Xl7kUATqiaNMsBVtuFZcx4ItDSIy2djpZShWa6Y3JbzmcHcm8CzT1hWEq1Gn dJfwBQkFypr14MR8IuA6JjETrkqPyV8uPcUKsqOpo+3bwHjaE04Tt6ozJ1Ty9rfNMmWD Vzta+umuOi4xzW1iGVECDuZKzpLjcy6i//bJAwqeZedVJmNNbwjjZ+lE5oKsOFXr19th vsbEymY2ByLmVGJ4UdTlH49Na8aBoKh78feycFO4VEEuZ+BFLvGAzjBs0vm2QECYabsg FikLsXUl9RCGSj/W4uFO4Ylbc0Z24kgz3hIlri2ectm/yV6vJPh6cV1FecV+TiQH9dbd xd0w== X-Received: by 10.194.122.99 with SMTP id lr3mr23755258wjb.21.1381653918805; Sun, 13 Oct 2013 01:45:18 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Sun, 13 Oct 2013 01:44:58 -0700 (PDT) In-Reply-To: References: <525817DE.2040006@gmail.com> From: h bagade Date: Sun, 13 Oct 2013 12:14:58 +0330 X-Google-Sender-Auth: 9YKssqAS9CcfdBy90JMQ0UGD0Kk Message-ID: Subject: Re: igb driver does not support altq To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Oct 2013 08:45:21 -0000 On Sat, Oct 12, 2013 at 8:28 AM, h bagade wrote: > On Fri, Oct 11, 2013 at 6:53 PM, Karim Fodil-Lemelin < > fodillemlinkarim@gmail.com> wrote: > >> On 10/10/2013 5:56 AM, h bagade wrote: >> >>> Hi all, >>> >>> I have problem with running altq on igb cards. When trying to run altq on >>> these cards, it outputs an error, driver does not support altq. >>> >>> I have FreeBSD 8.3-stable and tried to fix the problem, after searching >>> in >>> forums, by applying changes made to igb driver through following links: >>> >>> http://svnweb.freebsd.org/**base?view=revision&revision=**248906 >>> http://svnweb.freebsd.org/**base?view=revision&revision=**249339 >>> http://lists.freebsd.org/**pipermail/svn-src-stable/2013-** >>> July/019491.html >>> >>> But it doesn't help and I still have problem with running altq on igb! >>> >>> Does anybody know from which revision the problem is solved? >>> Any hints would be of great help. >>> ______________________________**_________________ >>> 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 >>> " >>> >> Hi, >> >> Those modifications require that you define IGB_LEGACY_TX in the driver >> code to get ALTQ running on igb. >> >> Regards, >> >> Karim. >> > > I did so but It was not successful! I may missed something but I don't > know what it may be! > Karim, you were right, thank you and sorry for misunderstanding. That time I didn't know the difference between adding IGB_LEGACY_TX in Makefile flags or adding to the driver code. Thereafter I found the thread http://lists.freebsd.org/pipermail/freebsd-net/2013-April/035137.html which discuss on this, and indicates adding IGB_LEGACY_TX to the Makefile doesn't work. From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 10:39:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C68915BC for ; Mon, 14 Oct 2013 10:39:14 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55AFC2A61 for ; Mon, 14 Oct 2013 10:39:13 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.7/8.14.5) with ESMTP id r9EAXWMB038350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 Oct 2013 21:33:33 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r9EAXRqK061778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Oct 2013 21:33:27 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r9EAXRtH061777 for freebsd-net@freebsd.org; Mon, 14 Oct 2013 21:33:27 +1100 (EST) (envelope-from peter) Date: Mon, 14 Oct 2013 21:33:27 +1100 From: Peter Jeremy To: freebsd-net@freebsd.org Subject: Unable to use pf(4) NAT with jail on 9.2-RELEASE Message-ID: <20131014103327.GC68355@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 10:39:14 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I am trying to configure a new firewall and want to run squid in a jail but have been unsuccessful in getting outgoing NAT to work. I have previously used jails on 8.x and 10.x with traffic going both into and out of jails but I admit this is the first time I've tried to use NAT on the outgoing traffic. I've tried attaching the jail to each of lo0, lo1 using a 127/8 address; lo1, the internal and the external interface using a dummy (RFC1918) address and the internal interface using a valid-for-my-internal-network RFC1918 address, using a NAT rule like: nat on $ext_if from $jail_subnet to any -> $ext_addr Monitoring the external interface on another host, either no packets are transmitted (for the 127/8 addresses) or the source address is the unchanged RFC1918 address unchanged. As a specific example: In rc.conf: jail_squid_ip=3D"198.168.120.4" # Dummy address jail_squid_interface=3D"em0" # Internal interface jail_squid_exec_start=3D"/usr/bin/fetch -o /tmp/zzz https://223.223.223.1/" Complete pf.conf: nat log on re0 from 192.168.120.4/32 to any -> 223.223.223.2 pass quick all (changing the /32 to /24 makes no difference). ifconfig whilst the jail is trying to start: em0: flags=3D8843 metric 0 mtu 1500 options=3D4019b inet 192.168.123.124 netmask 0xffffff00 broadcast 192.168.123.255 inet 198.168.120.4 netmask 0xffffffff broadcast 198.168.120.4 re0: flags=3D8843 metric 0 mtu 1500 options=3D8209b inet 223.223.223.2 netmask 0xfffffffc broadcast 223.223.223.3 And tcpdump on a system connected to re0 shows: 21:25:44.030983 IP 198.168.120.4.36205 > 223.223.223.1.443: Flags [S], seq = 1462646452, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 7128992= 26 ecr 0], length 0 (the source address should be 223.223.223.2). OTOH, if I use a more complete pf.conf and initiate the connection either on the host or on an "internal" box set to route through the firewall, everything works as expected. What am I doing wrong? --=20 Peter Jeremy --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iKYEARECAGYFAlJbyHdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIcbEACgvcDBUL216yo7ihYNkPFz3vC2 xmsAn3CHhcGBLqd1hb8bzHY6/sY75FH8 =/nWz -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 11:06:52 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E66C52E for ; Mon, 14 Oct 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8ABAF2C83 for ; Mon, 14 Oct 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9EB6qNS035277 for ; Mon, 14 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9EB6qbK035275 for freebsd-net@FreeBSD.org; Mon, 14 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Oct 2013 11:06:52 GMT Message-Id: <201310141106.r9EB6qbK035275@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181699 net [ipsec] [patch] IPsec does scale to large SPD / SADB o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 473 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 11:21:04 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B6B623D; Mon, 14 Oct 2013 11:21:04 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 517DE2F02; Mon, 14 Oct 2013 11:21:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9EBL4uJ042776; Mon, 14 Oct 2013 11:21:04 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9EBL2uK042775; Mon, 14 Oct 2013 11:21:02 GMT (envelope-from melifaro) Date: Mon, 14 Oct 2013 11:21:02 GMT Message-Id: <201310141121.r9EBL2uK042775@freefall.freebsd.org> To: xor@davydkovo.net, melifaro@FreeBSD.org, freebsd-net@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: kern/169664: [bgp] Wrongful replacement of interface connected net route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 11:21:04 -0000 Synopsis: [bgp] Wrongful replacement of interface connected net route State-Changed-From-To: open->feedback State-Changed-By: melifaro State-Changed-When: Mon Oct 14 11:19:17 UTC 2013 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=169664 From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 11:22:26 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 869AE2F6; Mon, 14 Oct 2013 11:22:26 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C7A52F26; Mon, 14 Oct 2013 11:22:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9EBMQ4P042846; Mon, 14 Oct 2013 11:22:26 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9EBMQ8m042845; Mon, 14 Oct 2013 11:22:26 GMT (envelope-from melifaro) Date: Mon, 14 Oct 2013 11:22:26 GMT Message-Id: <201310141122.r9EBMQ8m042845@freefall.freebsd.org> To: xor@davydkovo.net, melifaro@FreeBSD.org, freebsd-net@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: kern/169664: [bgp] Wrongful replacement of interface connected net route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 11:22:26 -0000 Synopsis: [bgp] Wrongful replacement of interface connected net route State-Changed-From-To: open->closed State-Changed-By: melifaro State-Changed-When: Mon Oct 14 11:21:16 UTC 2013 State-Changed-Why: Fixed in r248070 and merge to 9-STABLE in r248895. http://www.freebsd.org/cgi/query-pr.cgi?pr=169664 From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 20:39:32 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 11E4868E for ; Mon, 14 Oct 2013 20:39:32 +0000 (UTC) (envelope-from prox@prolixium.com) Received: from nox.prolixium.com (nox.prolixium.com [IPv6:2001:48c8:1:104::1e]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA76025E1 for ; Mon, 14 Oct 2013 20:39:31 +0000 (UTC) Received: from prox by nox.prolixium.com with local (Exim 4.80) (envelope-from ) id 1VVovJ-0000Rj-Ju for freebsd-net@FreeBSD.org; Mon, 14 Oct 2013 16:39:29 -0400 Date: Mon, 14 Oct 2013 16:39:29 -0400 From: Mark Kamichoff To: freebsd-net@FreeBSD.org Subject: IPv6 Source Address Selection in 9.x Message-ID: <20131014203929.GG25061@prolixium.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: prox@prolixium.com X-SA-Exim-Scanned: No (on nox.prolixium.com); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 20:39:32 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi -=20 A colleague of mine recently stumbled upon an IPv6-related quirk in FreeBSD that seems to have appeared in the 9.x series. It appears that more often than not, IPv6 is not chosen as the default address family when initiating outbound connections, even in cases where there's an IPv6 address on the outgoing interface and the DNS returns at least one AAAA for the destination host. For example: (dax:16:23)% host he.net. he.net has address 216.218.186.2 he.net has IPv6 address 2001:470:0:76::2 he.net mail is handled by 1 he.net. (dax:16:23)% telnet he.net. 80 Trying 216.218.186.2... Connected to he.net. Escape character is '^]'. ^]^D telnet> Connection closed. he.net. clearly has an AAAA, but FreeBSD connects using IPv4, instead of IPv6. Forcing the address family does still work, though: (dax:16:23)% telnet -6 he.net. 80 Trying 2001:470:0:76::2... Connected to he.net. Escape character is '^]'. ^]^D telnet> Connection closed. The above was taken on a FreeBSD-9.1-RELEASE-p4 host with a static default route to the Internet and static IPv6 addressing on the outgoing interface. Although there are tunnels on the machine, the default route does not exit through a tunnel interace. Here is some sanitized output from ifconfig and route: (dax:16:31)% ifconfig em0 em0: flags=3D8943 metric 0 = mtu 1500 options=3D4219b ether 00:24:8c:36:57:ad inet 10.9.189.182 netmask 0xfffffffc broadcast 10.9.189.183 inet6 fe80::224:8cff:fe26:57ad%em0 prefixlen 64 scopeid 0x1=20 inet6 2001:db8:1:2::2 prefixlen 64=20 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active (dax:16:35)% netstat -f inet6 -n -r|grep default default 2001:db8:1:2::1 UG1 em0 This behavior has been reproduced on 9.2, as well. It has not been seen on any prior version of FreeBSD that supports IPv6. I took a quick look through /etc/default/rc.conf to see if there were any new variables that might influence source address selection or name resolution, but did not see anything relevant. Has anyone else experienced a problem like this? - Mark --=20 Mark Kamichoff prox@prolixium.com http://www.prolixium.com/ --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJcVoEACgkQ0TYC9KtF8BN82gCgmKToWz7na0evOMVzWShc/LXd K/0AoJASDJtZPn1vciaDBszSnGpsRQm3 =2LL2 -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 20:45:48 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D20EA13 for ; Mon, 14 Oct 2013 20:45:48 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8331F269A for ; Mon, 14 Oct 2013 20:45:47 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r9EKjRAE029443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 05:45:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id r9EKjQBX020366; Tue, 15 Oct 2013 05:45:26 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 15 Oct 2013 05:45:15 +0900 (JST) Message-Id: <20131015.054515.997515800600548642.hrs@allbsd.org> To: prox@prolixium.com Subject: Re: IPv6 Source Address Selection in 9.x From: Hiroki Sato In-Reply-To: <20131014203929.GG25061@prolixium.com> References: <20131014203929.GG25061@prolixium.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct_15_05_45_15_2013_517)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 15 Oct 2013 05:45:39 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 20:45:48 -0000 ----Security_Multipart(Tue_Oct_15_05_45_15_2013_517)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Kamichoff wrote in <20131014203929.GG25061@prolixium.com>: pr> Hi - pr> pr> A colleague of mine recently stumbled upon an IPv6-related quirk in pr> FreeBSD that seems to have appeared in the 9.x series. ... pr> This behavior has been reproduced on 9.2, as well. It has not been seen pr> on any prior version of FreeBSD that supports IPv6. pr> pr> I took a quick look through /etc/default/rc.conf to see if there were pr> any new variables that might influence source address selection or name pr> resolution, but did not see anything relevant. Try ip6addrctl_policy="ipv6_prefer" in rc.conf. -- Hiroki ----Security_Multipart(Tue_Oct_15_05_45_15_2013_517)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlJcV9sACgkQTyzT2CeTzy3FOwCg3waeHZNdxNB/WKXYztBsc0XV WoAAoLnLQ/d9lepgkIcCyb1d60hrrRQ2 =Fg1o -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct_15_05_45_15_2013_517)---- From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 20:58:25 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 881794DF; Mon, 14 Oct 2013 20:58:25 +0000 (UTC) (envelope-from prox@prolixium.com) Received: from nox.prolixium.com (nox.prolixium.com [IPv6:2001:48c8:1:104::1e]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5700727B8; Mon, 14 Oct 2013 20:58:25 +0000 (UTC) Received: from prox by nox.prolixium.com with local (Exim 4.80) (envelope-from ) id 1VVpDc-0001Re-8J; Mon, 14 Oct 2013 16:58:24 -0400 Date: Mon, 14 Oct 2013 16:58:24 -0400 From: Mark Kamichoff To: Hiroki Sato Subject: Re: IPv6 Source Address Selection in 9.x Message-ID: <20131014205824.GI25061@prolixium.com> References: <20131014203929.GG25061@prolixium.com> <20131015.054515.997515800600548642.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <20131015.054515.997515800600548642.hrs@allbsd.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: prox@prolixium.com X-SA-Exim-Scanned: No (on nox.prolixium.com); SAEximRunCond expanded to false Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 20:58:25 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2013 at 05:45:15AM +0900, Hiroki Sato wrote: > Try ip6addrctl_policy=3D"ipv6_prefer" in rc.conf. Excellent. Thank you. I glanced right over that in /etc/default/rc.conf. I just added the above line to /etc/rc.conf and ran /etc/rc.d/ip6addrctl start prefer_ipv6. Now, it works as expected: (dax:16:47)% telnet he.net. 80 Trying 2001:470:0:76::2... Connected to he.net. Escape character is '^]'. ^]^D telnet> Connection closed. It's my understanding that by leaving ip6addrctl_policy as AUTO will only prefer IPv6 if ipv6_enable_all_interfaces is set to YES, which it is in my /etc/rc.conf. However, it appears that this never resulted in ip6addrctl_prefer_ipv6 being called from /etc/rc.d/ip6addrctl. Maybe I'm reading this wrong ...=20 - Mark --=20 Mark Kamichoff prox@prolixium.com http://www.prolixium.com/ --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJcWvAACgkQ0TYC9KtF8BNyoQCeMPQq12GTDu3SGvqX/STybLTU J84AnA3csDeq/gH5WvK3V1vsw2yRK3hi =VhWp -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 21:08:30 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 504DB9A8 for ; Mon, 14 Oct 2013 21:08:30 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C344A2862 for ; Mon, 14 Oct 2013 21:08:29 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r9EL8CP5031768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 06:08:22 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id r9EL8Cuu021045; Tue, 15 Oct 2013 06:08:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 15 Oct 2013 06:07:54 +0900 (JST) Message-Id: <20131015.060754.1615183637061250094.hrs@allbsd.org> To: prox@prolixium.com Subject: Re: IPv6 Source Address Selection in 9.x From: Hiroki Sato In-Reply-To: <20131014205824.GI25061@prolixium.com> References: <20131014203929.GG25061@prolixium.com> <20131015.054515.997515800600548642.hrs@allbsd.org> <20131014205824.GI25061@prolixium.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct_15_06_07_54_2013_493)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 15 Oct 2013 06:08:23 +0900 (JST) X-Spam-Status: No, score=-99.0 required=13.0 tests=CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,USER_IN_WHITELIST,X_CHINESE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 21:08:30 -0000 ----Security_Multipart(Tue_Oct_15_06_07_54_2013_493)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Kamichoff wrote in <20131014205824.GI25061@prolixium.com>: pr> On Tue, Oct 15, 2013 at 05:45:15AM +0900, Hiroki Sato wrote: pr> > Try ip6addrctl_policy="ipv6_prefer" in rc.conf. pr> pr> Excellent. Thank you. I glanced right over that in pr> /etc/default/rc.conf. I just added the above line to /etc/rc.conf and pr> ran /etc/rc.d/ip6addrctl start prefer_ipv6. Now, it works as expected: pr> pr> (dax:16:47)% telnet he.net. 80 pr> Trying 2001:470:0:76::2... pr> Connected to he.net. pr> Escape character is '^]'. pr> ^]^D pr> telnet> Connection closed. pr> pr> It's my understanding that by leaving ip6addrctl_policy as AUTO will pr> only prefer IPv6 if ipv6_enable_all_interfaces is set to YES, which it pr> is in my /etc/rc.conf. However, it appears that this never resulted in pr> ip6addrctl_prefer_ipv6 being called from /etc/rc.d/ip6addrctl. Maybe pr> I'm reading this wrong ... It is ipv6_activate_all_interfaces, not ipv6_enable_all_interfaces. If YES, AUTO (the default value) will set it as ipv6_prefer automatically. -- Hiroki ----Security_Multipart(Tue_Oct_15_06_07_54_2013_493)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlJcXSoACgkQTyzT2CeTzy1MAwCgnzjWXmSoHdmrvAXk+FZVeyUo 8/kAoLOJvpROPd17oRp0nUgz3AiVyjdu =g9n9 -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct_15_06_07_54_2013_493)---- From owner-freebsd-net@FreeBSD.ORG Mon Oct 14 21:12:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35D0DB49; Mon, 14 Oct 2013 21:12:47 +0000 (UTC) (envelope-from prox@prolixium.com) Received: from nox.prolixium.com (nox.prolixium.com [IPv6:2001:48c8:1:104::1e]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFC1128B2; Mon, 14 Oct 2013 21:12:46 +0000 (UTC) Received: from prox by nox.prolixium.com with local (Exim 4.80) (envelope-from ) id 1VVpRV-0002AI-P3; Mon, 14 Oct 2013 17:12:45 -0400 Date: Mon, 14 Oct 2013 17:12:45 -0400 From: Mark Kamichoff To: Hiroki Sato Subject: Re: IPv6 Source Address Selection in 9.x Message-ID: <20131014211245.GK25061@prolixium.com> References: <20131014203929.GG25061@prolixium.com> <20131015.054515.997515800600548642.hrs@allbsd.org> <20131014205824.GI25061@prolixium.com> <20131015.060754.1615183637061250094.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131015.060754.1615183637061250094.hrs@allbsd.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: prox@prolixium.com X-SA-Exim-Scanned: No (on nox.prolixium.com); SAEximRunCond expanded to false Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Oct 2013 21:12:47 -0000 On Tue, Oct 15, 2013 at 06:07:54AM +0900, Hiroki Sato wrote: > pr> It's my understanding that by leaving ip6addrctl_policy as AUTO will > pr> only prefer IPv6 if ipv6_enable_all_interfaces is set to YES, which it > pr> is in my /etc/rc.conf. However, it appears that this never resulted in > pr> ip6addrctl_prefer_ipv6 being called from /etc/rc.d/ip6addrctl. Maybe > pr> I'm reading this wrong ... > > It is ipv6_activate_all_interfaces, not ipv6_enable_all_interfaces. > If YES, AUTO (the default value) will set it as ipv6_prefer > automatically. Ah, indeed. I read the two variables as one. Thanks! - Mark -- Mark Kamichoff prox@prolixium.com http://www.prolixium.com/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 15 00:40:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AD722DA for ; Tue, 15 Oct 2013 00:40:36 +0000 (UTC) (envelope-from laurie_jennings_1977@yahoo.com) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB29A236E for ; Tue, 15 Oct 2013 00:40:35 +0000 (UTC) Received: from [66.196.81.171] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 00:40:28 -0000 Received: from [98.139.212.245] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 00:40:28 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 00:40:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 921048.35951.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 86745 invoked by uid 60001); 15 Oct 2013 00:40:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381797628; bh=0r467h4lPFN3ohkziKN4P89dl95yHQdX5ip/LYtFx3Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bQux1E+uCbjxdrIfCpygTFoLK5zsOV6LMPHON4zCG+pnf0ZGKtqrEhKqAPLoeDJ+/ClnaNvjeOALupz5rJ4bK4v/aMwxC9jHrqeDTrdaQPtn/zJikHYJb8LpNd6VvUkW1ouXNkzq+wKdSthFySQ7M0Dgla94efqQ4hou1kUqhZk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2BnDR8iISFafleznNIPMQMjGD2Rbhv3g0ySXWjNp4hL0R62CRmfMhUp744O+c1Lu+7RmJaOAUQSebgUlUGaZtnMBpRHPG/iLXRFybDhGzJxkc+AlCZnbwhTxEyou0+b2t/007VVTR/R/z7U7A4EiTe3J6kP+yBOfdQ/trDw2wc4=; X-YMail-OSG: mZqivQEVM1lJyLslkwgMPzAroFWYYkxSGK5pXAEHFd23Zfd 3_1WXMnxJRqRgYf25lHGlfHk2HLgpv3eLq34kcovUdKBHzMigu4lvrg38pPQ x0QSzziweuAMu1T14VZ3d6EPMPxbGetOnxhEReMLgylIvC.A7V0f9C3pw3Wz d3WXu7Xz4DMDXxwlxQspW6qPdV4w6dMDZmDQDvCb9dwiXN5iGhqVPFyDfM9N aklKbbCSefF1c4_cG7IN_QSn6y_zGAzQUWPWwlPe3JmboGFPWLQ4gLJGJZki X.13cWUhxf3piMyQuCnIzDEReyE3BOMBkGhjIKIKgFL8h6eRdpuPSQzhw4xO Cdpf7hSw8HpGjzk9bgmgv1EHcX4Hu85sDSGgJCjICC49J5WZPTpTcKbQ3dj4 UafZwChYeV8EF6n5uDs1lVnaczD0TlQRqA0feqGQIymzHfEgW5Q17S9zQqXl TIoXS3gPTYADSUDgXf0KA_J85GGiecsRzLOhvJA.ZROdlmUsDPcGTI7lqdq. nmjD43AkqpT0e90aj0xylzDcNDRqMkqR9.QeQXvR3Xhx.T6sDkVCkroukZyM - Received: from [98.203.118.124] by web125802.mail.ne1.yahoo.com via HTTP; Mon, 14 Oct 2013 17:40:28 PDT X-Rocket-MIMEInfo: 002.001, Sm9obiwgDQoNCkkgZ290IHRoaXMgd29ya2luZyB0aGFua3MgdG8geW91ciBoZWxwLiBJIGhhdmUgdG8gcnVuIG15IGFwcCBvbiBhbiBvbGQgc3lzdGVtIGFuZCBJIGNhbid0DQpnZXQgc2htX21hcCB0byB3b3JrIG9uIGEgMzItYml0IGJ1aWxkLiAgSSd2ZSB0cmFjZWQgaXQgdG8gdm1fZmF1bHRfd2lyZSgpIHJldHVybmluZyAyIChLRVJOX1BST1RFQ1RJT05fRkFJTFVSRSkuDQpUaGlzIHN0dWZmIGlzIGFib3ZlIG15IHBheSBncmFkZS4gSXMgdGhlcmUgc29tZSBvcHRpb24gdGhhdCBJJ20gbWlzc2luZz8gSSABMAEBAQE- X-Mailer: YahooMailClassic/352 YahooMailWebService/0.8.160.587 Message-ID: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> Date: Mon, 14 Oct 2013 17:40:28 -0700 (PDT) From: Laurie Jennings Subject: Re: shm_map questions To: freebsd-net@freebsd.org, John Baldwin In-Reply-To: <201304221143.54205.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Oct 2013 00:40:36 -0000 John,=20 I got this working thanks to your help. I have to run my app on an old syst= em and I can't get shm_map to work on a 32-bit build. I've traced it to vm_fault_wire() r= eturning 2 (KERN_PROTECTION_FAILURE). This stuff is above my pay grade. Is there some option that I'm missing? I = need to make this work and it's driving me crazy! Laurie -------------------------------------------- On Mon, 4/22/13, John Baldwin wrote: Subject: Re: shm_map questions To: freebsd-net@freebsd.org Cc: "Laurie Jennings" Date: Monday, April 22, 2013, 8:43 AM =20 On Saturday, April 20, 2013 9:18:24 pm Laurie Jennings wrote: > That does help. Is there a way for the kernel to access the memory map=20 directlyby segment name? =20 There is not, no.=A0 It wouldn't be hard to add, but the issue there is that the existing shm_map/unmap API assumes you have an open file descriptor and is tailored to having a userland process provide memory rather than having the kernel provide a SHM to userland, so even if you added a shm_open() that gave you a reference on the underlying shm object (struct shmfd *), you would need a slightly different shm_map/unmap that took that object directly rather than an fd. =20 > Laurie >=20 > --- On Thu, 4/18/13, John Baldwin wrote: >=20 > From: John Baldwin > Subject: Re: shm_map questions > To: freebsd-net@freebsd.org > Cc: "Laurie Jennings" > Date: Thursday, April 18, 2013, 6:50 AM >=20 > On Thursday, April 11, 2013 10:58:14 am Laurie Jennings wrote: > > Im working on a simple project that shares a memory segment between a user=20 > processand a kernel module. I'm having some problems with shm_map and there=20 > doesn't seem to be much info on it. > > Im not sure what happened to the memory when the user process that creates=20 > it terminates.=A0 I have some questions. > > 1) Does the kernel mapping keep the segment from being garbage collected=20 > when the use process that creates it terminated? I've experienced=20 shm_unmap()=20 > panic when tryingto unmap a segment > > scenario:=A0=20 > > User process Maps SegmentKernel maps it=A0 with shm_map()User Process=20 > TerminatesKernel tries to shm_unmap() and it panics. >=20 > The kernel mapping bumps the refcount on the underlying vm object, so it=20 will > not go away.=A0 OTOH, you should be keeping your own reference count on the > associated fd so that you can call shm_unmap().=A0 That is, the model should=20 be > something like: >=20 > struct mydata *foo; >=20 > foo->fp =3D fget(fd); > shm_map(fp, &foo->p); > /* Don't call fdrop */ >=20 > and then when unmapping: >=20 > struct mydata *foo; >=20 > shm_unmap(foo->fp, foo->p); > fdrop(foo->fp); >=20 > > 2) Is there a way for the kernel process to know when the user process has=20 > goneaway? A ref count? >=20 > You can install a process_exit EVENTHANDLER if you want to destroy this when=20 a > process goes away.=A0 I have used shm_map/unmap for other objects that already > had a reference count so I did my shm_unmap when that object was destroyed. >=20 > > 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or=20 > doesit get garbage collected when the creating user process terminates? >=20 > It goes away when the backing 'struct file' goes away.=A0 If you follow the=20 > model above of keeping a reference count on the associated struct file then > it won't go away until you fdrop() after the shm_unmap. >=20 > > 4) When using a named segment, can the kernel "reuse" a mapping for a new=20 > userprocess? > > Example: > > User process creates shm segment with path /fooKernel Maps shm segment=20 with=20 > shm_map()User process terminates.User process runs again, opening segment=20 /foo > > Does the kernel need to re-map, or is the original mapping valid? >=20 > The mapping is not per-process, so if you have mapped a shm for /foo and > mapped it, it will stay mapped until you call shm_unmap.=A0 Multiple processes > can shm_open /foo and mmap it and they will all share the same memory. >=20 > You could even share a SHM_ANON fd among multiple processes by passing it > across a UNIX domain socket. >=20 > Hope this helps. >=20 > --=20 > John Baldwin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 =20 --=20 John Baldwin _______________________________________________ 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 Tue Oct 15 06:56:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 600CDD3; Tue, 15 Oct 2013 06:56:03 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A61B26FC; Tue, 15 Oct 2013 06:56:02 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id w6so6422753lbh.19 for ; Mon, 14 Oct 2013 23:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Duy6WBBJwdxxeLB/5NMnPoh0Gdf1ATFHV44xONO1S0E=; b=uYV36ZAS1GYFac+P37TtbFqzxP3I1po/6Wf25mEKIYSXssGVEFHA/Rc2qVQIFXiLTZ 6MqhagaQDLQOrn86cd+kz7ax9tIBgfZZCBOvgwFX/txBHgxt3ElwPUlrI/eORAGLHiUq yu4mjNGIUROtoNwhZxd3HsYOLzFS5gxbVLwiyjrQDo337S0QtGbyOfO+tt2GVWi3kmBa N0zOZzSviXtVgZIFjcLBuBtENwJeD61PkMtRVk+ttMoNPXULCAHxsSg96Mlt046aok+e KnHTBPIi4yLS0uMxX+lL2gJ2DZNlQRSHgLQKlejlVBQuo/Q3RZNfQVev/K/GxYXTem75 k4mQ== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr10365176laa.28.1381820160232; Mon, 14 Oct 2013 23:56:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.139.132 with HTTP; Mon, 14 Oct 2013 23:56:00 -0700 (PDT) Date: Mon, 14 Oct 2013 23:56:00 -0700 X-Google-Sender-Auth: ZRlijJNEgYqrznQX5ZwRoSmgO3g Message-ID: Subject: VIMAGE: Freed UMA key was not empty From: Craig Rodrigues To: "freebsd-virtualization@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Adrian Chadd , "Bjoern A. Zeeb" , Marko Zec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Oct 2013 06:56:03 -0000 Bjoern, I was looking at this bug in FreeNAS: "Panic on new jail with vnet" https://bugs.freenas.org/issues/3102 It turns out that the root cause of the problem is the same as the one mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021280.html Using the testcase in that mail, I can reproduce these error messages: Freed UMA keg was not empty (10 items). Lost 1 pages of memory. and eventually get a kernel panic. In this message, you mentioned that you might have a patch which fixes the problem: http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021316.html By any chance, do you have a patch handy? I can quickly try it out and provide feedback. Thanks. -- Craig -- Craig From owner-freebsd-net@FreeBSD.ORG Tue Oct 15 19:48:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58D0F3FC for ; Tue, 15 Oct 2013 19:48:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 134AA2370 for ; Tue, 15 Oct 2013 19:48:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 22AD4B9A3; Tue, 15 Oct 2013 15:47:59 -0400 (EDT) From: John Baldwin To: Laurie Jennings Subject: Re: shm_map questions Date: Tue, 15 Oct 2013 15:21:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> In-Reply-To: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310151521.25231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Oct 2013 15:47:59 -0400 (EDT) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Oct 2013 19:48:00 -0000 On Monday, October 14, 2013 8:40:28 pm Laurie Jennings wrote: > John, > > I got this working thanks to your help. I have to run my app on an old system and I can't > get shm_map to work on a 32-bit build. I've traced it to vm_fault_wire() returning 2 (KERN_PROTECTION_FAILURE). > This stuff is above my pay grade. Is there some option that I'm missing? I need to make this work and it's > driving me crazy! The fd you pass into the kernel has to be the result of a shm_open() with O_RDWR or I think the mapping can end up being read-only which might cause this. > Laurie > > > -------------------------------------------- > On Mon, 4/22/13, John Baldwin wrote: > > Subject: Re: shm_map questions > To: freebsd-net@freebsd.org > Cc: "Laurie Jennings" > Date: Monday, April 22, 2013, 8:43 AM > > On Saturday, April 20, 2013 9:18:24 > pm Laurie Jennings wrote: > > That does help. Is there a way for the kernel to access > the memory map > directlyby segment name? > > There is not, no. It wouldn't be hard to add, but the > issue there is that > the existing shm_map/unmap API assumes you have an open file > descriptor and > is tailored to having a userland process provide memory > rather than having > the kernel provide a SHM to userland, so even if you added a > shm_open() that > gave you a reference on the underlying shm object (struct > shmfd *), you would > need a slightly different shm_map/unmap that took that > object directly > rather than an fd. > > > Laurie > > > > --- On Thu, 4/18/13, John Baldwin > wrote: > > > > From: John Baldwin > > Subject: Re: shm_map questions > > To: freebsd-net@freebsd.org > > Cc: "Laurie Jennings" > > Date: Thursday, April 18, 2013, 6:50 AM > > > > On Thursday, April 11, 2013 10:58:14 am Laurie Jennings > wrote: > > > Im working on a simple project that shares a > memory segment between a user > > processand a kernel module. I'm having some problems > with shm_map and there > > doesn't seem to be much info on it. > > > Im not sure what happened to the memory when the > user process that creates > > it terminates. I have some questions. > > > 1) Does the kernel mapping keep the segment from > being garbage collected > > when the use process that creates it terminated? I've > experienced > shm_unmap() > > panic when tryingto unmap a segment > > > scenario: > > > User process Maps SegmentKernel maps it with > shm_map()User Process > > TerminatesKernel tries to shm_unmap() and it panics. > > > > The kernel mapping bumps the refcount on the underlying > vm object, so it > will > > not go away. OTOH, you should be keeping your own > reference count on the > > associated fd so that you can call shm_unmap(). > That is, the model should > be > > something like: > > > > struct mydata *foo; > > > > foo->fp = fget(fd); > > shm_map(fp, &foo->p); > > /* Don't call fdrop */ > > > > and then when unmapping: > > > > struct mydata *foo; > > > > shm_unmap(foo->fp, foo->p); > > fdrop(foo->fp); > > > > > 2) Is there a way for the kernel process to know > when the user process has > > goneaway? A ref count? > > > > You can install a process_exit EVENTHANDLER if you want > to destroy this when > a > > process goes away. I have used shm_map/unmap for > other objects that already > > had a reference count so I did my shm_unmap when that > object was destroyed. > > > > > 3) Does a SHM_ANON segment persist as long as the > kernel has it mapped, or > > doesit get garbage collected when the creating user > process terminates? > > > > It goes away when the backing 'struct file' goes > away. If you follow the > > model above of keeping a reference count on the > associated struct file then > > it won't go away until you fdrop() after the > shm_unmap. > > > > > 4) When using a named segment, can the kernel > "reuse" a mapping for a new > > userprocess? > > > Example: > > > User process creates shm segment with path > /fooKernel Maps shm segment > with > > shm_map()User process terminates.User process runs > again, opening segment > /foo > > > Does the kernel need to re-map, or is the original > mapping valid? > > > > The mapping is not per-process, so if you have mapped a > shm for /foo and > > mapped it, it will stay mapped until you call > shm_unmap. Multiple processes > > can shm_open /foo and mmap it and they will all share > the same memory. > > > > You could even share a SHM_ANON fd among multiple > processes by passing it > > across a UNIX domain socket. > > > > Hope this helps. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-net@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-net@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > John Baldwin > _______________________________________________ > 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" > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Oct 15 20:25:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 236C470C for ; Tue, 15 Oct 2013 20:25:29 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA26F25CF for ; Tue, 15 Oct 2013 20:25:28 +0000 (UTC) Received: from [98.139.212.150] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:25:27 -0000 Received: from [98.139.212.206] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:25:27 -0000 Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 15 Oct 2013 20:25:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 192125.88217.bm@omp1015.mail.bf1.yahoo.com Received: (qmail 88591 invoked by uid 60001); 15 Oct 2013 20:25:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381868726; bh=27tau9COp2Ry6AvLDjrpYYPAm64ZiD4NcoUo26CHFW8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0F5vXFsXAvnkSwvQKNWmthrwIU/NITIopbMpaD47XRHHPpSNahT5wT9bybDI8TuZ3ng2drJEv02EmSagPOQaU7Oqt9bRO6jbzHAEL0JplgHr3RyDi626Jky44ghrmVNTyDG5vOsOdiHKEWHuC1XNMQH6jxS+icQmCj/By+F5J/A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yR+o5lmowApldI02YYrE+kbiDFuM/IjULQ+N/1nlYgEDSSDRBbEprkl+ugTv+GlYGDdZTuHN8qHpz5P+EsWCBEFDIACVNG6Vo9l9ohlLobIx838K5X/lqxwgwa/2e7TpbeamVex5xxiezk6Id6RJSKXdezj7kG/Sr6ETqVRgug0=; X-YMail-OSG: 3MulyV8VM1lC8f4VDG_tthP1lVPYdh9bmhaLG9Nlz.J7HRw Qxr1_hGuV2hhE5R6WhgkpQdxocXfC0tuF05WiYE1avRpO8P7DF71yM7KDLy1 HMcXrc4xI.8pU2l3YKnbD1doYgTGUn3qlC5pP.4.smWPLf4PBZB5ITqEBaf8 9IBPMeZa092QNgDTi3WW8bKd3FAImHmrnb0raz5N9SV0SEIKL7mBwlGYnYF1 4EaxgTKJ1UxFL.Gld3nJI7EP10op3Vhk6BexR17YNQQ8QCLJGIaTVrzHDPIx UbPUI8UIPivvgCzT8PAvpNChfYaKOhUi0fBjlSAaJSYzBgtDpDiqwMl5P5va oIzOFaydXELwD2p20curmtrIIRJ9duXtE6kMsSkL89MVjk3Ut11KWUeZODHn 718r99He0rjJR76WIm0YPeN15EuznV9tWlcv7THWEKyASMu0LiEKlDhORXAa WpZv6.5vAVTz8oHZMwWJG13oPOdVw3TKRHyA21.JTbszGxvigfwsYgrYK7P6 gMIF3RD9pfU_3Rm0DB_EoIrde9.hMF68n08L6oSqOGfb6mEkNlYGTjp.TA1T vJ_Qf07Be5MfhOmhB07ERPnzQAquARKbtdUyVgZDaITSV7nI- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Tue, 15 Oct 2013 13:25:26 PDT X-Rocket-MIMEInfo: 002.001, VGhlIEZEIGlzIFJEV1IuIEl0J3MgdGhlIHNhbWUgY29kZSB0aGF0IHdvcmtzIG9uIGEgNjRiaXQgYnVpbGQuIEl0IGZhaWxzIGhlcmU6CgppbnQKdm1fZmF1bHQodm1fbWFwX3QgbWFwLCB2bV9vZmZzZXRfdCB2YWRkciwgdm1fcHJvdF90IGZhdWx0X3R5cGUsIGludCBmYXVsdF9mbGFncykKewrCoCDCoCDCoCDCoCBzdHJ1Y3QgdGhyZWFkICp0ZDsKwqAgwqAgwqAgwqAgaW50IHJlc3VsdDsKwqAKwqAgwqAgwqAgwqAgdGQgPSBjdXJ0aHJlYWQ7CsKgIMKgIMKgIMKgIGlmICgodGQtPnRkX3BmbGFncyAmIFREUF8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1381797628.75337.YahooMailBasic@web125802.mail.ne1.yahoo.com> <201310151521.25231.jhb@freebsd.org> <1381868572.32631.YahooMailNeo@web121602.mail.ne1.yahoo.com> Message-ID: <1381868726.83793.YahooMailNeo@web121606.mail.ne1.yahoo.com> Date: Tue, 15 Oct 2013 13:25:26 -0700 (PDT) From: Barney Cordoba Subject: Re: shm_map questions To: John Baldwin In-Reply-To: <1381868572.32631.YahooMailNeo@web121602.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:25:29 -0000 The FD is RDWR. It's the same code that works on a 64bit build. It fails he= re:=0A=0Aint=0Avm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_ty= pe, int fault_flags)=0A{=0A=A0 =A0 =A0 =A0 struct thread *td;=0A=A0 =A0 =A0= =A0 int result;=0A=A0=0A=A0 =A0 =A0 =A0 td =3D curthread;=0A=A0 =A0 =A0 = =A0 if ((td->td_pflags & TDP_NOFAULTING) !=3D 0)=0A=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 return (KERN_PROTECTION_FAILURE);=0A....=0A=0A=0ALaurie=0A=0A=0A=0A= On Tuesday, October 15, 2013 4:22 PM, Barney Cordoba wrote:=0A =0AThe FD is RDWR. It's the same code that works on a 64bit = build. It fails here:=0A=0Aint=0Avm_fault(vm_map_t map, vm_offset_t vaddr, = vm_prot_t fault_type, int fault_flags)=0A{=0A=A0 =A0 =A0 =A0 struct thread = *td;=0A=A0 =A0 =A0 =A0 int result;=0A=A0=0A=A0 =A0 =A0 =A0 td =3D curthread= ;=0A=A0 =A0 =A0 =A0 if ((td->td_pflags & TDP_NOFAULTING) !=3D 0)=0A=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 return (KERN_PROTECTION_FAILURE);=0A....=0A=0A=0ALa= urie=0A=0A=0A=0AOn Tuesday, October 15, 2013 3:48 PM, John Baldwin wrote:=0A =0AOn Monday, October 14, 2013 8:40:28 pm Laurie Jennin= gs wrote:=0A> John, =0A> =0A> I got this working thanks to your help. I hav= e to run my app on an old =0Asystem and I can't=0A> get shm_map to work on = a 32-bit build.=A0 I've traced it to vm_fault_wire() =0Areturning 2 (KERN_P= ROTECTION_FAILURE).=0A> This stuff is above my pay grade. Is there some opt= ion that I'm missing? I =0Aneed to make this work and it's=0A> driving me c= razy!=0A=0AThe fd you pass into the kernel has to be the result of a shm_op= en() with =0AO_RDWR or I think the mapping can end up being read-only which= might cause =0Athis.=0A=0A> Laurie=0A> =0A> =0A>=0A ----------------------= ----------------------=0A> On Mon, 4/22/13, John Baldwin = wrote:=0A> =0A>=A0 Subject: Re: shm_map questions=0A>=A0 To: freebsd-net@fr= eebsd.org=0A>=A0 Cc: "Laurie Jennings" =0A>= =A0 Date: Monday, April 22, 2013, 8:43 AM=0A>=A0 =0A>=A0 On Saturday, April= 20, 2013 9:18:24=0A>=A0 pm Laurie Jennings wrote:=0A>=A0 > That does help.= Is there a way for the kernel to access=0A>=A0 the memory map =0A>=A0 dire= ctlyby segment name?=0A>=A0 =0A>=A0 There is not, no.=A0 It wouldn't be har= d to add, but the=0A>=A0 issue there is that=0A>=A0 the existing shm_map/un= map API assumes you have an open file=0A>=A0 descriptor and=0A>=A0 is tailo= red to having a userland process provide memory=0A>=A0 rather than having= =0A>=A0 the kernel provide a SHM to userland, so even if you added a=0A>=A0= shm_open() that=0A>=A0 gave you a reference on the underlying shm object (= struct=0A>=A0 shmfd *), you would=0A>=A0 need a slightly different shm_map/= unmap that took that=0A>=A0 object directly=0A>=A0 rather than an fd.=0A>= =A0 =0A>=A0 > Laurie=0A>=A0 > =0A>=A0 > --- On Thu, 4/18/13, John Baldwin <= jhb@freebsd.org>=0A>=A0 wrote:=0A>=A0 > =0A>=A0 > From: John Baldwin =0A>=A0 > Subject: Re: shm_map questions=0A>=A0 > To: freebsd-ne= t@freebsd.org=0A>=A0 > Cc: "Laurie Jennings" =0A>=A0 > Date:=0A Thursday, April 18, 2013, 6:50 AM=0A>=A0 > =0A>=A0 > O= n Thursday, April 11, 2013 10:58:14 am Laurie Jennings=0A>=A0 wrote:=0A>=A0= > > Im working on a simple project that shares a=0A>=A0 memory segment bet= ween a user =0A>=A0 > processand a kernel module. I'm having some problems= =0A>=A0 with shm_map and there =0A>=A0 > doesn't seem to be much info on it= .=0A>=A0 > > Im not sure what happened to the memory when the=0A>=A0 user p= rocess that creates =0A>=A0 > it terminates.=A0 I have some questions.=0A>= =A0 > > 1) Does the kernel mapping keep the segment from=0A>=A0 being garba= ge collected =0A>=A0 > when the use process that creates it terminated?=0A = I've=0A>=A0 experienced =0A>=A0 shm_unmap() =0A>=A0 > panic when tryingto u= nmap a segment=0A>=A0 > > scenario:=A0 =0A>=A0 > > User process Maps Segmen= tKernel maps it=A0 with=0A>=A0 shm_map()User Process =0A>=A0 > TerminatesKe= rnel tries to shm_unmap() and it panics.=0A>=A0 > =0A>=A0 > The kernel mapp= ing bumps the refcount on the underlying=0A>=A0 vm object, so it =0A>=A0 wi= ll=0A>=A0 > not go away.=A0 OTOH, you should be keeping your own=0A>=A0 ref= erence count on the=0A>=A0 > associated fd so that you can call shm_unmap()= . =0A>=A0 That is, the model should =0A>=A0 be=0A>=A0 >=0A something like:= =0A>=A0 > =0A>=A0 > struct mydata *foo;=0A>=A0 > =0A>=A0 > foo->fp =3D fget= (fd);=0A>=A0 > shm_map(fp, &foo->p);=0A>=A0 > /* Don't call fdrop */=0A>=A0= > =0A>=A0 > and then when unmapping:=0A>=A0 > =0A>=A0 > struct mydata *foo= ;=0A>=A0 > =0A>=A0 > shm_unmap(foo->fp, foo->p);=0A>=A0 > fdrop(foo->fp);= =0A>=A0 > =0A>=A0 > > 2) Is there a way for the kernel process to know=0A>= =A0 when the user process has =0A>=A0 > goneaway? A ref count?=0A>=A0 > =0A= >=A0 > You can install a process_exit EVENTHANDLER=0A if you want=0A>=A0 to= destroy this when =0A>=A0 a=0A>=A0 > process goes away.=A0 I have used shm= _map/unmap for=0A>=A0 other objects that already=0A>=A0 > had a reference c= ount so I did my shm_unmap when that=0A>=A0 object was destroyed.=0A>=A0 > = =0A>=A0 > > 3) Does a SHM_ANON segment persist as long as the=0A>=A0 kernel= has it mapped, or =0A>=A0 > doesit get garbage collected when the creating= user=0A>=A0 process terminates?=0A>=A0 > =0A>=A0 > It goes away when the b= acking 'struct file' goes=0A>=A0 away.=A0 If you follow the =0A>=A0 > model= above of keeping a reference count on the=0A>=A0 associated struct=0A file= then=0A>=A0 > it won't go away until you fdrop() after the=0A>=A0 shm_unma= p.=0A>=A0 > =0A>=A0 > > 4) When using a named segment, can the kernel=0A>= =A0 "reuse" a mapping for a new =0A>=A0 > userprocess?=0A>=A0 > > Example:= =0A>=A0 > > User process creates shm segment with path=0A>=A0 /fooKernel Ma= ps shm segment =0A>=A0 with =0A>=A0 > shm_map()User process terminates.User= process runs=0A>=A0 again, opening segment =0A>=A0 /foo=0A>=A0 > > Does th= e kernel need to re-map, or is the original=0A>=A0 mapping valid?=0A>=A0 > = =0A>=A0 > The mapping is not per-process, so if you have=0A mapped a=0A>=A0= shm for /foo and=0A>=A0 > mapped it, it will stay mapped until you call=0A= >=A0 shm_unmap.=A0 Multiple processes=0A>=A0 > can shm_open /foo and mmap i= t and they will all share=0A>=A0 the same memory.=0A>=A0 > =0A>=A0 > You co= uld even share a SHM_ANON fd among multiple=0A>=A0 processes by passing it= =0A>=A0 > across a UNIX domain socket.=0A>=A0 > =0A>=A0 > Hope this helps.= =0A>=A0 > =0A>=A0 > -- =0A>=A0 > John Baldwin=0A>=A0 > ____________________= ___________________________=0A>=A0 > freebsd-net@freebsd.org=0A>=A0 mailing= list=0A>=A0 > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A>=A0= > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= =0A>=A0 > _______________________________________________=0A>=A0 > freebsd-= net@freebsd.org=0A>=A0 mailing list=0A>=A0 > http://lists.freebsd.org/mailm= an/listinfo/freebsd-net=0A>=A0 > To unsubscribe, send any mail to "freebsd-= net-unsubscribe@freebsd.org"=0A=0A>=A0 > =0A>=A0 =0A>=A0 -- =0A>=A0 John Ba= ldwin=0A>=A0 _______________________________________________=0A>=A0 freebsd= -net@freebsd.org=0A>=A0 mailing list=0A>=A0 http://lists.freebsd.org/mailma= n/listinfo/freebsd-net=0A>=A0 To unsubscribe, send=0A any mail to "freebsd-= net-unsubscribe@freebsd.org"=0A>=A0 =0A> =0A=0A-- =0AJohn Baldwin=0A_______= ________________________________________=0Afreebsd-net@freebsd.org mailing = list=0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscri= be, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 02:58:21 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D40EDAF; Wed, 16 Oct 2013 02:58:21 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22B292987; Wed, 16 Oct 2013 02:58:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9G2wK3l042363; Wed, 16 Oct 2013 02:58:20 GMT (envelope-from kevlo@freefall.freebsd.org) Received: (from kevlo@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9G2wKku042362; Wed, 16 Oct 2013 02:58:20 GMT (envelope-from kevlo) Date: Wed, 16 Oct 2013 02:58:20 GMT Message-Id: <201310160258.r9G2wKku042362@freefall.freebsd.org> To: swildner@gmail.com, kevlo@FreeBSD.org, freebsd-net@FreeBSD.org From: kevlo@FreeBSD.org Subject: Re: bin/175974: ppp(8): logic issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Oct 2013 02:58:21 -0000 Synopsis: ppp(8): logic issue State-Changed-From-To: open->closed State-Changed-By: kevlo State-Changed-When: Wed Oct 16 02:55:50 UTC 2013 State-Changed-Why: Fixed. Your assumption is correct. Only protocol numbers 0x21 through 0xFA would be encrypted. http://www.freebsd.org/cgi/query-pr.cgi?pr=175974 From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 03:00:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B74B2E58 for ; Wed, 16 Oct 2013 03:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4CC1299E for ; Wed, 16 Oct 2013 03:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9G301px042533 for ; Wed, 16 Oct 2013 03:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9G301Uw042532; Wed, 16 Oct 2013 03:00:01 GMT (envelope-from gnats) Date: Wed, 16 Oct 2013 03:00:01 GMT Message-Id: <201310160300.r9G301Uw042532@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: bin/175974: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 03:00:01 -0000 The following reply was made to PR bin/175974; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/175974: commit references a PR Date: Wed, 16 Oct 2013 02:55:39 +0000 (UTC) Author: kevlo Date: Wed Oct 16 02:55:31 2013 New Revision: 256574 URL: http://svnweb.freebsd.org/changeset/base/256574 Log: Fix logic error. MPPE only accepts protocol numbers 0x21 through 0xFA. PR: bin/175974 Modified: head/usr.sbin/ppp/mppe.c Modified: head/usr.sbin/ppp/mppe.c ============================================================================== --- head/usr.sbin/ppp/mppe.c Wed Oct 16 02:46:00 2013 (r256573) +++ head/usr.sbin/ppp/mppe.c Wed Oct 16 02:55:31 2013 (r256574) @@ -168,7 +168,7 @@ MPPEOutput(void *v, struct ccp *ccp, str dictinit = 0; log_Printf(LogDEBUG, "MPPE: Output: Proto %02x (%d bytes)\n", *proto, ilen); - if (*proto < 0x21 && *proto > 0xFA) { + if (*proto < 0x21 || *proto > 0xFA) { log_Printf(LogDEBUG, "MPPE: Output: Not encrypting\n"); ccp->compout += ilen; ccp->uncompout += ilen; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 12:20:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90B9093F for ; Wed, 16 Oct 2013 12:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FD6828F7 for ; Wed, 16 Oct 2013 12:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9GCK27t085707 for ; Wed, 16 Oct 2013 12:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9GCK2rD085706; Wed, 16 Oct 2013 12:20:02 GMT (envelope-from gnats) Date: Wed, 16 Oct 2013 12:20:02 GMT Message-Id: <201310161220.r9GCK2rD085706@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/134531: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 12:20:02 -0000 The following reply was made to PR kern/134531; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134531: commit references a PR Date: Wed, 16 Oct 2013 12:18:58 +0000 (UTC) Author: melifaro Date: Wed Oct 16 12:18:44 2013 New Revision: 256624 URL: http://svnweb.freebsd.org/changeset/base/256624 Log: Fix long-standing issue with incorrect radix mask calculation. Usual symptoms are messages like rn_delete: inconsistent annotation rn_addmask: mask impossibly already in tree or inability to flush/delete particular prefix in ipfw table. Changes: * Assume 32 bytes as maximum radix key length * Remove rn_init() * Statically allocate rn_ones/rn_zeroes * Make separate mask tree for each "normal" tree instead of system global one * Remove "optimization" on masks reusage and key zeroying * Change rn_addmask() arguments to accept tree pointer (no users in base) PR: kern/182851, kern/169206, kern/135476, kern/134531 Found by: Slawa Olhovchenkov MFC after: 2 weeks Reviewed by: glebius Sponsored by: Yandex LLC Modified: head/sys/net/radix.c head/sys/net/radix.h head/sys/net/route.c Modified: head/sys/net/radix.c ============================================================================== --- head/sys/net/radix.c Wed Oct 16 12:15:33 2013 (r256623) +++ head/sys/net/radix.c Wed Oct 16 12:18:44 2013 (r256624) @@ -66,27 +66,19 @@ static struct radix_node *rn_search(void *, struct radix_node *), *rn_search_m(void *, struct radix_node *, void *); -static int max_keylen; -static struct radix_mask *rn_mkfreelist; -static struct radix_node_head *mask_rnhead; -/* - * Work area -- the following point to 3 buffers of size max_keylen, - * allocated in this order in a block of memory malloc'ed by rn_init. - * rn_zeros, rn_ones are set in rn_init and used in readonly afterwards. - * addmask_key is used in rn_addmask in rw mode and not thread-safe. - */ -static char *rn_zeros, *rn_ones, *addmask_key; +static void rn_detachhead_internal(void **head); +static int rn_inithead_internal(void **head, int off); + +#define RADIX_MAX_KEY_LEN 32 -#define MKGet(m) { \ - if (rn_mkfreelist) { \ - m = rn_mkfreelist; \ - rn_mkfreelist = (m)->rm_mklist; \ - } else \ - R_Malloc(m, struct radix_mask *, sizeof (struct radix_mask)); } - -#define MKFree(m) { (m)->rm_mklist = rn_mkfreelist; rn_mkfreelist = (m);} +static char rn_zeros[RADIX_MAX_KEY_LEN]; +static char rn_ones[RADIX_MAX_KEY_LEN] = { + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, +}; -#define rn_masktop (mask_rnhead->rnh_treetop) static int rn_lexobetter(void *m_arg, void *n_arg); static struct radix_mask * @@ -230,7 +222,8 @@ rn_lookup(v_arg, m_arg, head) caddr_t netmask = 0; if (m_arg) { - x = rn_addmask(m_arg, 1, head->rnh_treetop->rn_offset); + x = rn_addmask(m_arg, head->rnh_masks, 1, + head->rnh_treetop->rn_offset); if (x == 0) return (0); netmask = x->rn_key; @@ -489,53 +482,47 @@ on1: } struct radix_node * -rn_addmask(n_arg, search, skip) - int search, skip; - void *n_arg; +rn_addmask(void *n_arg, struct radix_node_head *maskhead, int search, int skip) { caddr_t netmask = (caddr_t)n_arg; register struct radix_node *x; register caddr_t cp, cplim; register int b = 0, mlen, j; - int maskduplicated, m0, isnormal; + int maskduplicated, isnormal; struct radix_node *saved_x; - static int last_zeroed = 0; + char addmask_key[RADIX_MAX_KEY_LEN]; - if ((mlen = LEN(netmask)) > max_keylen) - mlen = max_keylen; + if ((mlen = LEN(netmask)) > RADIX_MAX_KEY_LEN) + mlen = RADIX_MAX_KEY_LEN; if (skip == 0) skip = 1; if (mlen <= skip) - return (mask_rnhead->rnh_nodes); + return (maskhead->rnh_nodes); + + bzero(addmask_key, RADIX_MAX_KEY_LEN); if (skip > 1) bcopy(rn_ones + 1, addmask_key + 1, skip - 1); - if ((m0 = mlen) > skip) - bcopy(netmask + skip, addmask_key + skip, mlen - skip); + bcopy(netmask + skip, addmask_key + skip, mlen - skip); /* * Trim trailing zeroes. */ for (cp = addmask_key + mlen; (cp > addmask_key) && cp[-1] == 0;) cp--; mlen = cp - addmask_key; - if (mlen <= skip) { - if (m0 >= last_zeroed) - last_zeroed = mlen; - return (mask_rnhead->rnh_nodes); - } - if (m0 < last_zeroed) - bzero(addmask_key + m0, last_zeroed - m0); - *addmask_key = last_zeroed = mlen; - x = rn_search(addmask_key, rn_masktop); + if (mlen <= skip) + return (maskhead->rnh_nodes); + *addmask_key = mlen; + x = rn_search(addmask_key, maskhead->rnh_treetop); if (bcmp(addmask_key, x->rn_key, mlen) != 0) x = 0; if (x || search) return (x); - R_Zalloc(x, struct radix_node *, max_keylen + 2 * sizeof (*x)); + R_Zalloc(x, struct radix_node *, RADIX_MAX_KEY_LEN + 2 * sizeof (*x)); if ((saved_x = x) == 0) return (0); netmask = cp = (caddr_t)(x + 2); bcopy(addmask_key, cp, mlen); - x = rn_insert(cp, mask_rnhead, &maskduplicated, x); + x = rn_insert(cp, maskhead, &maskduplicated, x); if (maskduplicated) { log(LOG_ERR, "rn_addmask: mask impossibly already in tree"); Free(saved_x); @@ -590,12 +577,12 @@ rn_new_radix_mask(tt, next) { register struct radix_mask *m; - MKGet(m); + R_Malloc(m, struct radix_mask *, sizeof (struct radix_mask)); if (m == 0) { - log(LOG_ERR, "Mask for route not entered\n"); + log(LOG_ERR, "Failed to allocate route mask\n"); return (0); } - bzero(m, sizeof *m); + bzero(m, sizeof(*m)); m->rm_bit = tt->rn_bit; m->rm_flags = tt->rn_flags; if (tt->rn_flags & RNF_NORMAL) @@ -629,7 +616,8 @@ rn_addroute(v_arg, n_arg, head, treenode * nodes and possibly save time in calculating indices. */ if (netmask) { - if ((x = rn_addmask(netmask, 0, top->rn_offset)) == 0) + x = rn_addmask(netmask, head->rnh_masks, 0, top->rn_offset); + if (x == NULL) return (0); b_leaf = x->rn_bit; b = -1 - x->rn_bit; @@ -808,7 +796,8 @@ rn_delete(v_arg, netmask_arg, head) * Delete our route from mask lists. */ if (netmask) { - if ((x = rn_addmask(netmask, 1, head_off)) == 0) + x = rn_addmask(netmask, head->rnh_masks, 1, head_off); + if (x == NULL) return (0); netmask = x->rn_key; while (tt->rn_mask != netmask) @@ -841,7 +830,7 @@ rn_delete(v_arg, netmask_arg, head) for (mp = &x->rn_mklist; (m = *mp); mp = &m->rm_mklist) if (m == saved_m) { *mp = m->rm_mklist; - MKFree(m); + Free(m); break; } if (m == 0) { @@ -932,7 +921,7 @@ on1: struct radix_mask *mm = m->rm_mklist; x->rn_mklist = 0; if (--(m->rm_refs) < 0) - MKFree(m); + Free(m); m = mm; } if (m) @@ -1128,10 +1117,8 @@ rn_walktree(h, f, w) * bits starting at 'off'. * Return 1 on success, 0 on error. */ -int -rn_inithead(head, off) - void **head; - int off; +static int +rn_inithead_internal(void **head, int off) { register struct radix_node_head *rnh; register struct radix_node *t, *tt, *ttt; @@ -1163,8 +1150,8 @@ rn_inithead(head, off) return (1); } -int -rn_detachhead(void **head) +static void +rn_detachhead_internal(void **head) { struct radix_node_head *rnh; @@ -1176,28 +1163,41 @@ rn_detachhead(void **head) Free(rnh); *head = NULL; +} + +int +rn_inithead(void **head, int off) +{ + struct radix_node_head *rnh; + + if (*head != NULL) + return (1); + + if (rn_inithead_internal(head, off) == 0) + return (0); + + rnh = (struct radix_node_head *)(*head); + + if (rn_inithead_internal((void **)&rnh->rnh_masks, 0) == 0) { + rn_detachhead_internal(head); + return (0); + } + return (1); } -void -rn_init(int maxk) +int +rn_detachhead(void **head) { - char *cp, *cplim; + struct radix_node_head *rnh; - max_keylen = maxk; - if (max_keylen == 0) { - log(LOG_ERR, - "rn_init: radix functions require max_keylen be set\n"); - return; - } - R_Malloc(rn_zeros, char *, 3 * max_keylen); - if (rn_zeros == NULL) - panic("rn_init"); - bzero(rn_zeros, 3 * max_keylen); - rn_ones = cp = rn_zeros + max_keylen; - addmask_key = cplim = rn_ones + max_keylen; - while (cp < cplim) - *cp++ = -1; - if (rn_inithead((void **)(void *)&mask_rnhead, 0) == 0) - panic("rn_init 2"); + KASSERT((head != NULL && *head != NULL), + ("%s: head already freed", __func__)); + + rnh = *head; + + rn_detachhead_internal((void **)&rnh->rnh_masks); + rn_detachhead_internal(head); + return (1); } + Modified: head/sys/net/radix.h ============================================================================== --- head/sys/net/radix.h Wed Oct 16 12:15:33 2013 (r256623) +++ head/sys/net/radix.h Wed Oct 16 12:18:44 2013 (r256624) @@ -124,6 +124,7 @@ struct radix_node_head { void (*rnh_close) /* do something when the last ref drops */ (struct radix_node *rn, struct radix_node_head *head); struct radix_node rnh_nodes[3]; /* empty tree for common case */ + struct radix_node_head *rnh_masks; /* Storage for our masks */ #ifdef _KERNEL struct rwlock rnh_lock; /* locks entire radix tree */ #endif @@ -152,12 +153,11 @@ struct radix_node_head { #define RADIX_NODE_HEAD_WLOCK_ASSERT(rnh) rw_assert(&(rnh)->rnh_lock, RA_WLOCKED) #endif /* _KERNEL */ -void rn_init(int); int rn_inithead(void **, int); int rn_detachhead(void **); int rn_refines(void *, void *); struct radix_node - *rn_addmask(void *, int, int), + *rn_addmask(void *, struct radix_node_head *, int, int), *rn_addroute (void *, void *, struct radix_node_head *, struct radix_node [2]), *rn_delete(void *, void *, struct radix_node_head *), Modified: head/sys/net/route.c ============================================================================== --- head/sys/net/route.c Wed Oct 16 12:15:33 2013 (r256623) +++ head/sys/net/route.c Wed Oct 16 12:18:44 2013 (r256624) @@ -183,20 +183,12 @@ rt_tables_get_rnh(int table, int fam) static void route_init(void) { - struct domain *dom; - int max_keylen = 0; /* whack the tunable ints into line. */ if (rt_numfibs > RT_MAXFIBS) rt_numfibs = RT_MAXFIBS; if (rt_numfibs == 0) rt_numfibs = 1; - - for (dom = domains; dom; dom = dom->dom_next) - if (dom->dom_maxrtkey > max_keylen) - max_keylen = dom->dom_maxrtkey; - - rn_init(max_keylen); /* init all zeroes, all ones, mask table */ } SYSINIT(route_init, SI_SUB_PROTO_DOMAIN, SI_ORDER_THIRD, route_init, 0); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 18:17:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 14FCAF75 for ; Wed, 16 Oct 2013 18:17:45 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E57172170 for ; Wed, 16 Oct 2013 18:17:44 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kp14so1433338pab.20 for ; Wed, 16 Oct 2013 11:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4RtQbcRYLY69STSOTHRRyV6uC3KuANdLHoa3iSdH7tg=; b=x0w0JYOoRQstpwYI8CA9KCcIeFSVsN8tTSDTzIVQALC/OZqGXmYif0F3iGrXXTJk7x dxnSs9VWmBo6iU3oKw+s1aGPLfym9srvn8M7fdrpWO4J4rTFCiFKjYmXyYUHpY9d43Ez 0hMBY1KkUAOVnEto2WgKdSROYBus1bi6v2CWEJMZTD97MzmT9584dh4sQ6gy9HFrNKxU WOn0DMjwAGyanHWc8Seso1a7/uKv3i62dp0x0kEQ10ASJHzkUPGZlNp4JUxgftwIknrW V33aNtMgPW9JDdSI86VoE8WPx0iuWOq+EoIPpP/Tt5nDuDbH8naj2YQ2X8d6lK9Nvk3t tpzw== X-Received: by 10.66.170.168 with SMTP id an8mr5008876pac.58.1381947464080; Wed, 16 Oct 2013 11:17:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Wed, 16 Oct 2013 11:17:23 -0700 (PDT) From: Raimundo Santos Date: Wed, 16 Oct 2013 15:17:23 -0300 Message-ID: Subject: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Oct 2013 18:17:45 -0000 Hello list, I have a quad port Intel NIC and I am stucked on this problem: whenever I try to modify the address of one port of this NIC, I see from ifconfig ifconfig: ioctl (SIOCAIFADDR): File exists Here is the status of one port: # ifconfig igb1 igb1: flags=8843 metric 0 mtu 1500 options=401bb ether 00:1b:21:5a:93:31 inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active As you can see, no inet address. Try to put an address that was used before in the same port of this NIC, and.. # ifconfig igb1 XX.XX.XX.20/28 ifconfig: ioctl (SIOCAIFADDR): File exists I have routed running with this /etc/gateways: ripv2 if=tun0 no_rip if=tun1 no_rip if=et0 no_rip if=et1 no_rip if=igb2 no_rip if=igb3 no_rip rdisc_interval=45 no_ag no_super_ag subnet=X.Y.Z.56/30,1 subnet=X.Y.Z.0/29,1 subnet=X.Y.Z.8/29,1 subnet=X.Y.Z.16/29,1 subnet=X.Y.Z.24/29,1 subnet=X.Y.Z.32/29,1 subnet=X.Y.Z.40/29,1 subnet=X.Y.Z.48/29,1 subnet=X.Y.Z.64/29,1 subnet=X.Y.Z.72/29,1 subnet=X.Y.Z.80/29,1 subnet=X.Y.Z.88/29,1 subnet=X.Y.Z.96/29,1 subnet=X.Y.Z.104/29,1 subnet=X.Y.Z.112/29,1 subnet=X.Y.Z.120/29,1 The problem occurs when configuring the primary address or an alias in any port, after unconfigure some other address. Using # uname -a FreeBSD XXX 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #10: Thu Aug 1 19:04:09 BRT 2013 XXX:/usr/obj/usr/src/sys/XXX_KERNEL amd64 A custom system with 0 thru 15 FIBs, FWD in ipfw, and VNET/VIMAGE all enabled. Thank you! Raimundo Santos From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 18:54:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39A60BBC for ; Wed, 16 Oct 2013 18:54:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE96C23B4 for ; Wed, 16 Oct 2013 18:54:32 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id nc12so985208qeb.16 for ; Wed, 16 Oct 2013 11:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mxPaKapPFGWnqeL3Ln9M1rrUuohH4yszNleA+YCiHFY=; b=No5h7ccHaeymdW+WZS4U1niEaQ44KdhjFY61bYoIFMO9zwh1QbFSF4gDLzLiLSuH/Q rWaji0QqxoP0yMYY3drfisN2rOFmjxO+46IPw2D9pt/IqY2M0J1rJAayvashL9lptywU 8ulOisXouPS6kx9pH1U/v8X6L4LP2KgnEceq9DrBm2qQ0iFHZqXCddlB5/57gFrHMhf4 iU+DXI2QOLRWP2edkCIGDPj5V4ult95yZYcdQLMJgNGPEYoGjGtPGh8cNAeneP18cWvx mOG12j/OIfCmX+TtODlHE5fqWw+lFYQY4HpEclOoCDqtwrVhjHGWnriUSdsNWF8gsm/v kAhA== MIME-Version: 1.0 X-Received: by 10.224.11.133 with SMTP id t5mr7076031qat.34.1381949672053; Wed, 16 Oct 2013 11:54:32 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.39.97 with HTTP; Wed, 16 Oct 2013 11:54:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Oct 2013 12:54:31 -0600 X-Google-Sender-Auth: KQtSRfBwXoltpRRxu5_Xz55IxTs Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command From: Alan Somers To: Raimundo Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Oct 2013 18:54:33 -0000 On Wed, Oct 16, 2013 at 12:17 PM, Raimundo Santos wrote: > Hello list, > > I have a quad port Intel NIC and I am stucked on this problem: whenever I > try to modify the address of one port of this NIC, I see from ifconfig > > ifconfig: ioctl (SIOCAIFADDR): File exists > > Here is the status of one port: > > # ifconfig igb1 > igb1: flags=8843 metric 0 mtu 1500 > > options=401bb > ether 00:1b:21:5a:93:31 > inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > As you can see, no inet address. Try to put an address that was used before > in the same port of this NIC, and.. > > > # ifconfig igb1 XX.XX.XX.20/28 > ifconfig: ioctl (SIOCAIFADDR): File exists > > I have routed running with this /etc/gateways: > > ripv2 > if=tun0 no_rip > if=tun1 no_rip > if=et0 no_rip > if=et1 no_rip > if=igb2 no_rip > if=igb3 no_rip > rdisc_interval=45 > no_ag > no_super_ag > subnet=X.Y.Z.56/30,1 > subnet=X.Y.Z.0/29,1 > subnet=X.Y.Z.8/29,1 > subnet=X.Y.Z.16/29,1 > subnet=X.Y.Z.24/29,1 > subnet=X.Y.Z.32/29,1 > subnet=X.Y.Z.40/29,1 > subnet=X.Y.Z.48/29,1 > subnet=X.Y.Z.64/29,1 > subnet=X.Y.Z.72/29,1 > subnet=X.Y.Z.80/29,1 > subnet=X.Y.Z.88/29,1 > subnet=X.Y.Z.96/29,1 > subnet=X.Y.Z.104/29,1 > subnet=X.Y.Z.112/29,1 > subnet=X.Y.Z.120/29,1 > > The problem occurs when configuring the primary address or an alias in any > port, after unconfigure some other address. > > Using > > # uname -a > FreeBSD XXX 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #10: Thu Aug 1 19:04:09 > BRT 2013 XXX:/usr/obj/usr/src/sys/XXX_KERNEL amd64 > > A custom system with 0 thru 15 FIBs, FWD in ipfw, and VNET/VIMAGE all > enabled. > > Thank you! > Raimundo Santos > _______________________________________________ > 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" I ran into the same problem, on a system with LAGGs, multiple FIBs and multiple aliases per interface. I believe that the problem was due to a race condition in the kernel. Two process tried to SIOCAIFADDR with the same address simultaneously. The second one of them failed and printed the error message that you see. But due to the race, the first process reported success, yet the interface did not get the address. Unfortunately, I was unable to locate the race. My solution was to prevent two processes from trying to initialize the interface at the same time. The first process was our custom management software, which calls "service netif cloneup lagg0" and "service netif start lagg0" in rapid succession. The second process was devd, which was trying to initialize the newly attached lagg0 interface. I commented out the following lines in /etc/devd.conf and the problem went away. I don't know if this will solve your problem, but I recommend that you use dtrace or some other method to determine whether two processes are trying to SIOCAIFADDR at the same time. notify 0 { match "system" "IFNET"; match "type" "ATTACH"; action "/etc/pccard_ether $subsystem start"; }; -Alan From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 19:14:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39C28F32 for ; Wed, 16 Oct 2013 19:14:15 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13A1A24A8 for ; Wed, 16 Oct 2013 19:14:15 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fa1so1494987pad.9 for ; Wed, 16 Oct 2013 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=raEGGPgLLng9OuvKV/cnLB07WXabPM4D+ggHjxB139s=; b=VSTcwflgsBVlCMpniRhYvtpU+yX0Lk6xcW0roan9rHCZ5Wu6zDElrQLNOoQY7hNGRz 7ansrv+kMnnr4W1ZBiGL4c6ttUvviUjGR8h4d09O6qZYdPNI+ZJwmBRXSUpEsM1u0Frt rYE/MEQoI7rWPGj7BZIoh2Za0tJCw3tc7Lft/KP6tHjuNYv/P/hXx/i4W1RSE7rG4Rv5 OuSBnfbUnMTCoyPOSJcvO7vVjUYYh/HnGwqRAzH4grMvdiEULCkX7ZtqGToX5rzL2nax 1Hl8Wyi7uF5ocvvMCsmGqTdqwRaJ8edqdAM6D+F7KtEez78YyWymuRFOUh/0xVGb7zct 6Bug== X-Received: by 10.66.66.11 with SMTP id b11mr5207842pat.154.1381950854697; Wed, 16 Oct 2013 12:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Wed, 16 Oct 2013 12:13:54 -0700 (PDT) In-Reply-To: References: From: Raimundo Santos Date: Wed, 16 Oct 2013 16:13:54 -0300 Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Oct 2013 19:14:15 -0000 On 16 October 2013 15:54, Alan Somers wrote: > > > I ran into the same problem, on a system with LAGGs, multiple FIBs and > multiple aliases per interface. I believe that the problem was due to > a race condition in the kernel. Two process tried to SIOCAIFADDR with > the same address simultaneously. The second one of them failed and > printed the error message that you see. But due to the race, the > first process reported success, yet the interface did not get the > address. Unfortunately, I was unable to locate the race. My solution > was to prevent two processes from trying to initialize the interface > at the same time. The first process was our custom management > software, which calls "service netif cloneup lagg0" and "service netif > start lagg0" in rapid succession. The second process was devd, which > was trying to initialize the newly attached lagg0 interface. I > commented out the following lines in /etc/devd.conf and the problem > went away. I don't know if this will solve your problem, but I > recommend that you use dtrace or some other method to determine > whether two processes are trying to SIOCAIFADDR at the same time. > > notify 0 { > match "system" "IFNET"; > match "type" "ATTACH"; > action "/etc/pccard_ether $subsystem start"; > }; > > Hey Alan! Well, I don`t think it is the problem here. I just try to do a very simple ifconfig, nothing more, there are no private applications running (I have postgres siting around and munin gathering sysinfo to me). I was thinking about some problem in the interaction ifconfig/adresses + routed, but this is very strange. In a less destructive test (the first one took me to reboot the machine), I see a confusing behavior: . put a alias into an igb1 . remove this alias (-alias) . printing the main (#0) FIB, nothing is there related to the removed alias . put the same alias again . get the File exists result and no configuration of an alias over the igb1 . but now, listing the main routing table, there are info about that alias!, but in another port of the NIC, igb2 How is this possible? From owner-freebsd-net@FreeBSD.ORG Wed Oct 16 19:21:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 499A8189 for ; Wed, 16 Oct 2013 19:21:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3742511 for ; Wed, 16 Oct 2013 19:21:20 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id v2so1007454qcr.20 for ; Wed, 16 Oct 2013 12:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=y35y+J9iPg8UO4Ms51l8+xoyVI3o4XyCpRSMeYB8c2o=; b=BUMyB8J/bXy4v3iSv/jZJXoUEfkrZTSPNjFTMgawa8I7N46vj2u0Kzp7GlT4C+EwO6 5fCNDOE0n+3UUF6VcLwmpcN0VGFsUHa8UgmQCwzyzoL6ZZ9Zd2r2uYrfdOcQLQVOtrGH OcBmarYphvM8fAmg3uaBZUXnv8R1a/HbglzATF1ZZyLlT9n1GfyMGzLefyejyob/PZ37 bTGVz3R/DrU293IGaVWsqThzWNDng3ZbLD2QiYGuNiNHyJRbBSujdflJy9qst8PuAOrA d2PGekuR6UjE+tw/2zhmscXsDDDkjGoOJeODAiEWuIfXA3mPbc+6nKOno/k7IrPqsk0z fV3w== MIME-Version: 1.0 X-Received: by 10.224.14.79 with SMTP id f15mr4513869qaa.113.1381951280187; Wed, 16 Oct 2013 12:21:20 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.39.97 with HTTP; Wed, 16 Oct 2013 12:21:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Oct 2013 13:21:20 -0600 X-Google-Sender-Auth: ZqrRwq19NBHy_Jqpy-EdUvoDO1s Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command From: Alan Somers To: Raimundo Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Oct 2013 19:21:21 -0000 On Wed, Oct 16, 2013 at 1:13 PM, Raimundo Santos wrote: > On 16 October 2013 15:54, Alan Somers wrote: > >> >> >> I ran into the same problem, on a system with LAGGs, multiple FIBs and >> multiple aliases per interface. I believe that the problem was due to >> a race condition in the kernel. Two process tried to SIOCAIFADDR with >> the same address simultaneously. The second one of them failed and >> printed the error message that you see. But due to the race, the >> first process reported success, yet the interface did not get the >> address. Unfortunately, I was unable to locate the race. My solution >> was to prevent two processes from trying to initialize the interface >> at the same time. The first process was our custom management >> software, which calls "service netif cloneup lagg0" and "service netif >> start lagg0" in rapid succession. The second process was devd, which >> was trying to initialize the newly attached lagg0 interface. I >> commented out the following lines in /etc/devd.conf and the problem >> went away. I don't know if this will solve your problem, but I >> recommend that you use dtrace or some other method to determine >> whether two processes are trying to SIOCAIFADDR at the same time. >> >> notify 0 { >> match "system" "IFNET"; >> match "type" "ATTACH"; >> action "/etc/pccard_ether $subsystem start"; >> }; >> >> > Hey Alan! > > Well, I don`t think it is the problem here. I just try to do a very simple > ifconfig, nothing more, there are no private applications running (I have > postgres siting around and munin gathering sysinfo to me). I was thinking > about some problem in the interaction ifconfig/adresses + routed, but this > is very strange. > > In a less destructive test (the first one took me to reboot the machine), I > see a confusing behavior: > > . put a alias into an igb1 > . remove this alias (-alias) > . printing the main (#0) FIB, nothing is there related to the removed alias > . put the same alias again > . get the File exists result and no configuration of an alias over the igb1 > . but now, listing the main routing table, there are info about that > alias!, but in another port of the NIC, igb2 > > How is this possible? It's sad to say, but the fib code is pretty buggy. Without diving into the source, one thing that you could try is the net.add_addr_allfibs tunable. I think that it defaults to 1. If you set it to 0, then adding an interface address in one fib will not cause it to create routes in other fibs. Does that help? From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 05:59:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29A58E99 for ; Thu, 17 Oct 2013 05:59:48 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73456240A for ; Thu, 17 Oct 2013 05:59:47 +0000 (UTC) Received: from [10.0.0.10] ([10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id r9H5xf5V015667 for ; Thu, 17 Oct 2013 08:59:42 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <525F7CC9.4000800@ukr.net> Date: Thu, 17 Oct 2013 08:59:37 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [89.209.81.54]); Thu, 17 Oct 2013 08:59:42 +0300 (EEST) X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 05:59:48 -0000 16.04.2013 21:34, David Christensen wrote: >> | > Specifically, we've seen that newer (9 and higher) have issues with >> | > the doing initial setup and negotiation and that Dell did indeed >> | > release newer firmware to fix the issues. This requires a full >> | > reboot into Linux (probably centos6) to get the update to execute. >> | >> | I could be wrong but I *think* that the firmware is loaded on device >> | initialization, so there may be a chance that the driver can do it >> | when starting? Additionally, maybe one can leverage the kernel >> | firmware(9) framework so that the firmware can be more easily updated >> | by user? > > The 5706/5708/5709/5716 devices have a set of RISC processors. One is > loaded from NVRAM based firmware (MCP) while the others are loaded by > firmware embedded in the driver. The MCP firmware is loaded at device > power-on when the system is plugged into a socket in order to provide > pre-OS access to the system (think Dell DRAC). > I have a DELL PowerEdge 2950 server (3rd generation). There is a network card with chipset bce BCM5708. If a ready algorithm for getting rid of interface resetting / watchdog timeout? Thanks. > There's a chicken and egg problem with your suggestion for firmware(9) > support of the MCP firmware. Not only does MCP firmware provide pre-OS > services but it also provides FreeBSD driver services. There are shared > resources on the device which require synchronization between multiple > FreeBSD driver instances and the MCP acts as an arbitrator for them. > > Additionally, I have some security concerns about making NVRAM write > functionality easily accessible through the driver since it would be fairly > easy to take down a system and require a motherboard swap to fix the > problem. There's always a concern that a power-event could interrupt > an NVRAM upgrade and make the system unusable so I think it's > important to have the system administrator's blessings before making > any NVRAM changes to firmware. Not sure how to accomplish that > without making the driver load process interactive. > -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 07:06:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DDBE951 for ; Thu, 17 Oct 2013 07:06:06 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1F3727E0 for ; Thu, 17 Oct 2013 07:06:05 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VWdsJ-000Hd7-NW; Thu, 17 Oct 2013 07:03:47 +0400 Message-ID: <525F8C4F.5090303@FreeBSD.org> Date: Thu, 17 Oct 2013 11:05:51 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Raimundo Santos Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AOFMGQHXPBLALXGQLKIR" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 07:06:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AOFMGQHXPBLALXGQLKIR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16.10.2013 22:17, Raimundo Santos wrote: > Hello list, Hello! >=20 > I have a quad port Intel NIC and I am stucked on this problem: whenever= I > try to modify the address of one port of this NIC, I see from ifconfig >=20 > ifconfig: ioctl (SIOCAIFADDR): File exists >=20 > Here is the status of one port: >=20 > # ifconfig igb1 > igb1: flags=3D8843 metric 0 mtu= 1500 >=20 > options=3D401bb > ether 00:1b:21:5a:93:31 > inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > As you can see, no inet address. Try to put an address that was used be= fore > in the same port of this NIC, and.. >=20 >=20 > # ifconfig igb1 XX.XX.XX.20/28 > ifconfig: ioctl (SIOCAIFADDR): File exists This seems rather strange. I'm using multiple fibs in production, and it shouldn't behave that way. Can you do the following and send me output? 1) issue `route -n monitor` and log all messages 2) add first address to interface 3) do route -n get network_address (e.g. XX.XX.XX.16/28) for added prefix (in fib 0 and fib 1) 4) remove this address 5) repeat step 3 6) add this prefix to another port 7) repeat step 3 >=20 > I have routed running with this /etc/gateways: >=20 > ripv2 > if=3Dtun0 no_rip > if=3Dtun1 no_rip > if=3Det0 no_rip > if=3Det1 no_rip > if=3Digb2 no_rip > if=3Digb3 no_rip > rdisc_interval=3D45 > no_ag > no_super_ag > subnet=3DX.Y.Z.56/30,1 > subnet=3DX.Y.Z.0/29,1 > subnet=3DX.Y.Z.8/29,1 > subnet=3DX.Y.Z.16/29,1 > subnet=3DX.Y.Z.24/29,1 > subnet=3DX.Y.Z.32/29,1 > subnet=3DX.Y.Z.40/29,1 > subnet=3DX.Y.Z.48/29,1 > subnet=3DX.Y.Z.64/29,1 > subnet=3DX.Y.Z.72/29,1 > subnet=3DX.Y.Z.80/29,1 > subnet=3DX.Y.Z.88/29,1 > subnet=3DX.Y.Z.96/29,1 > subnet=3DX.Y.Z.104/29,1 > subnet=3DX.Y.Z.112/29,1 > subnet=3DX.Y.Z.120/29,1 >=20 > The problem occurs when configuring the primary address or an alias in = any > port, after unconfigure some other address. >=20 > Using >=20 > # uname -a > FreeBSD XXX 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #10: Thu Aug 1 19:04= :09 > BRT 2013 XXX:/usr/obj/usr/src/sys/XXX_KERNEL amd64 >=20 > A custom system with 0 thru 15 FIBs, FWD in ipfw, and VNET/VIMAGE all > enabled. >=20 > Thank you! > Raimundo Santos > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 ------enig2AOFMGQHXPBLALXGQLKIR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJfjFIACgkQwcJ4iSZ1q2k4WwCgou/pnKqoiYtrsfGO8u/iqAOf Mi0AoJcBXUYKj84OetTK6ZE3St4VjcMb =O2X/ -----END PGP SIGNATURE----- ------enig2AOFMGQHXPBLALXGQLKIR-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 15:16:47 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA56A258; Thu, 17 Oct 2013 15:16:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B019A292D; Thu, 17 Oct 2013 15:16:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9HFGlRP019684; Thu, 17 Oct 2013 15:16:47 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9HFGkv9019681; Thu, 17 Oct 2013 15:16:46 GMT (envelope-from ae) Date: Thu, 17 Oct 2013 15:16:46 GMT Message-Id: <201310171516.r9HFGkv9019681@freefall.freebsd.org> To: jp@tns.cz, ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/176097: [lagg] [patch] lagg/lacp broken when aggregated interfaces have same speed but different media type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 15:16:47 -0000 Synopsis: [lagg] [patch] lagg/lacp broken when aggregated interfaces have same speed but different media type State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Thu Oct 17 15:15:18 UTC 2013 State-Changed-Why: Committed in head/. Thanks! Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Thu Oct 17 15:15:18 UTC 2013 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=176097 From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 17:15:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E064CDD for ; Thu, 17 Oct 2013 17:15:30 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BEE2D22B5 for ; Thu, 17 Oct 2013 17:15:29 +0000 (UTC) Received: from [98.139.212.150] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 17:15:23 -0000 Received: from [68.142.230.75] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 17:15:23 -0000 Received: from [127.0.0.1] by smtp232.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 17:15:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382030123; bh=ySmOs+rl7m9CIwAHXWy/G/iyKi7nn4LigV9zbrwR+mw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=1QbfKDsXKvdzzZF1lBCujEs/BDvS1vDokDcff7YUhqiZJBZpeAGsC6p6iMefdMAfc6LMCdiigjlIARvwb3auwPz4YQl7pvAW3zuWXY95KlszIqnebEGuczRyQ/7fShigc2ZtFzCWaRDURhBQeZtkkq+E52Fl0/beHvlF0dtT6hY= X-Yahoo-Newman-Id: 306025.8621.bm@smtp232.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oECPDi4VM1lcsNBY8eT8BxhGqrA6rOfbDA0cqGM7e6A8VV5 CwmhfmER6.FXD69q0UJc5nsBAjfaotHkh.yGbQSs8d_tdLdQiTbSfPadvKfs nBnylofzh0TonmyMmbdXJkp_HcdaPI3htiZgrqlU3t_Xc0ukNEFh94uYJsSP fZYDiQCeRl9NOspfaWtpeRefQpEUgGCOTHaRPFnHab_EpgoHa.1NG.ZWIdeB yemlGRakuY3WoE5g78ZIHkQ1h_Ym0w_A.qCxEWH98wWFB6MYh8RM5KJbxJ2v jIUHrT9GsW7XbYfUWFD1ZcWyDX7BbYT1bUgExFXLx7vElJ8hc67iIqD.8pRb P.TdiYwn9Cj8ts7NNXjhHDSedQT9deuPDAhQOozEjFz5ZtenZ1UA4tyRQgq3 3ZQ317C9swNEn99GzE18EFS._jkfzrRn4hWyrdWfzhwJ8ATzDFsscBGiIELp ZmedGkG1379JudtZ_OVszazX08fyypUeswxV29PtoV84n8txBhLNTXFQFjtg 7m.nEwajNI.R97as_haaZ5105Ie5jXLtjbwRDgwDCR0qxs3SOMCCLkraoDpL Dxdmz9V5yoDl.MmmL3tcGXVZdqaMN6A28mej.B3Zglnw7DpzGndkv70RW X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp232.mail.bf1.yahoo.com with SMTP; 17 Oct 2013 17:15:23 +0000 UTC Subject: Re: bce(4) on the Dell PE 2950 From: Sean Bruno To: "Vladislav V. Prodan" In-Reply-To: <525F7CC9.4000800@ukr.net> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zh0SFT8p9UGoESxPncn0" Date: Thu, 17 Oct 2013 10:15:21 -0700 Message-ID: <1382030121.2570.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:15:30 -0000 --=-zh0SFT8p9UGoESxPncn0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2013-10-17 at 08:59 +0300, Vladislav V. Prodan wrote: > I have a DELL PowerEdge 2950 server (3rd generation). There is a > network > card with chipset bce BCM5708. >=20 > If a ready algorithm for getting rid of interface resetting / watchdog > timeout? >=20 > Thanks.=20 In the freebsd.org cluster we run several of these machines. We had to update the f/w on them (broadcom) to make the errors go away. sean --=-zh0SFT8p9UGoESxPncn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSYBsmAAoJEBkJRdwI6BaHWSEH/3DTKHFtvorvYJUiVas4s7iY I2Pkc5EvRZDAAhKIM2l1elUi8RE5Yss1yxQU7RinIs8QvefF4mXYYLcYpslSsGNU vBPEuXeluo9Q509xVVg0noYmiXI5jjfmuPZ6ePWM5CDMVwKpFOkN8OHPElzbVrJy dRmkBU3HQ2Peo0gjF8PXVmxNbVKLctLdRYnw6/jAmEWvfecKTIM6SY+/wKTRNXid vEbPqRfDvA04sQ07n0jUJIx6QuYKpM/zddzIGYOk/Jkclsh5fAWYBHpmfLAT7JYY Xic+j55BNrGCeJvTkNnEKCWCW3b9Pnjg0lisVlC4jdtQyt92D0TfAbw4XWe/7y0= =+9Kv -----END PGP SIGNATURE----- --=-zh0SFT8p9UGoESxPncn0-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 17:32:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9159A896; Thu, 17 Oct 2013 17:32:17 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63FBB23FF; Thu, 17 Oct 2013 17:32:17 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fa1so3063094pad.23 for ; Thu, 17 Oct 2013 10:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ATv5gPvPVg8LKNP1N5I7vojCgxwqmyJxG8vBC2Xj+rE=; b=Z1FnZgK2ODqQg6yD0UOdyyTbgupaJJgqyi22SNR8kVuECg6CcYgvs1mtYcgbvbWY82 ya6kliTs2VICiiIY3U1LMh/n9UZMwz9lKVeuS1nPZchqegEVpeP4M3tmu5ctyUMOcH7p EYtlxlwA0Y/0yBmIQn7/qgM0h19ERn71BNsyUmgfMZHumxTtpDmwRnL7eSbHAJfd0t7A 6UqYT7eEfZ4jW8pdjfjAb3KgPCaJ6VHkn0yWnv4+fXgfxhCh7XtPZJmIcrtUIrYT2XAT GEG5eEM7lWgbZ6sgHsq5QFdPukBfv1EKcm9QbzjtsiPlBa30HlS+24OouMKXkRnqvi6G Hhvg== X-Received: by 10.68.113.130 with SMTP id iy2mr9782335pbb.2.1382031136987; Thu, 17 Oct 2013 10:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Thu, 17 Oct 2013 10:31:56 -0700 (PDT) In-Reply-To: <5260147D.3000907@FreeBSD.org> References: <525F8C4F.5090303@FreeBSD.org> <5260147D.3000907@FreeBSD.org> From: Raimundo Santos Date: Thu, 17 Oct 2013 14:31:56 -0300 Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command To: "Alexander V. Chernikov" , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 17:32:17 -0000 Oh my... I forgot to reply to list... an here we go again! On 17 October 2013 13:46, Alexander V. Chernikov wrote: > On 17.10.2013 18:25, Raimundo Santos wrote: > > On 17 October 2013 04:05, Alexander V. Chernikov wrote: > >> This seems rather strange. I'm using multiple fibs in production, and it >> shouldn't behave that way. >> >> > It occurs even with aliases. > >> >> Can you do the following and send me output? >> >> 1) issue `route -n monitor` and log all messages >> 2) add first address to interface >> 3) do route -n get network_address (e.g. XX.XX.XX.16/28) for added >> prefix (in fib 0 and fib 1) >> 4) remove this address >> 5) repeat step 3 >> 6) add this prefix to another port >> 7) repeat step 3 >> >> > Hello, Alexander! > > The machine in question are under production, too. It hurts the results > if I do these steps without removing all the addresses from the interface? > > By the way, this machine is a "border" router (not using BGP by now, but > over the borders of my network and my providers network). All the addresses > over this Intel NIC are routable, except in one port, where we have some > equipment lying out the network (just don't ask why...) and all of them > have private addresses. I saw the issue when trying to comunicate to these > equipments adding and removing aliases in one of the ports. That said, > there is an intersting output, after removing ALL the aliases from the > refered NIC port: > > command issued: > > for i in `seq 0 14`; do \ > echo "fib $i" >> routing.fibs; \ > setfib $i netstat -rnfinet | grep '172\.31\.' >> routing.fibs; \ > echo "--------------------------------" >> routing.fibs; \ > done > > status of igb1 and 2: > > igb1: flags=8843 metric 0 mtu 1500 > > options=401bb > ether 00:1b:21:5a:93:31 > inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 > inet (routable addr) netmask 0xfffffff0 broadcast (routable addr > broadcast) > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > igb2: flags=8843 metric 0 mtu 1500 > > options=401bb > ether 00:1b:21:5a:93:34 > inet (routable addr) netmask 0xfffffff8 broadcast (routable > broadcast) > inet6 fe80::21b:21ff:fe5a:9334%igb2 prefixlen 64 scopeid 0x3 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > And the output of the commands: > > fib 0 > 172.31.19.0/24 172.31.19.190 U 0 0 igb1 > 172.31.20.0/24 172.31.20.190 U 0 0 igb2 > > ^^^^^^^^^^ > This is probably installed by some routing daemon (issuing RTM_CHANGE > message) > (can be easily checked with `route -n monitor`) > This is fixed in r248070 ( and merged to 9.2) > > -------------------------------- > fib 1 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 2 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 3 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 4 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 5 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 6 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 7 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 8 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 9 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 10 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 11 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 12 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 13 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > fib 14 > 172.31.19.0/24 link#2 U 0 0 igb1 > -------------------------------- > > I never set 172.31.whatever over igb2! Just over igb1. > > Just to remeber: > > kernel options > > options VIMAGE > > # routing options > options ROUTETABLES=15 > # IPFW options > options IPFIREWALL_FORWARD > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=300 > options IPFIREWALL_DEFAULT_TO_ACCEPT > > Under > > FreeBSD 9.1-RELEASE-p4 > > Thank you for your time! > > > Okey, Alexander, I found the culprit: routed, running in this machine as pid 99399. This is the result of 'route -n monitor' after doing a for loop over all fibs and manualy removing 172.31.19/24 and 172.31.20/24. First two, the deletes, last two, the adds. No RTM_CHANGE, so far, and the ADD only apply to fib 0. (Thank you for the route monitor advice!) got message of size 192 on Thu Oct 17 14:14:01 2013 RTM_DELETE: Delete Route: len 192, pid: 94802, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.31.19.0 172.31.19.190 (255) ffff ffff ff got message of size 192 on Thu Oct 17 14:14:07 2013 RTM_DELETE: Delete Route: len 192, pid: 94819, seq 1, errno 0, flags: locks: inits: sockaddrs: 172.31.20.0 172.31.20.190 (255) ffff ffff ff got message of size 191 on Thu Oct 17 14:14:29 2013 RTM_ADD: Add Route: len 191, pid: 99399, seq 1142, errno 0, flags: locks: inits: sockaddrs: 172.31.19.0 172.31.19.190 pmsg_addrs: truncated route message, only 7 bytes left got message of size 191 on Thu Oct 17 14:14:32 2013 RTM_ADD: Add Route: len 191, pid: 99399, seq 1143, errno 0, flags: locks: inits: sockaddrs: 172.31.20.0 172.31.20.190 pmsg_addrs: truncated route message, only 7 bytes left >From where routed take these addresses? When removing an fib entry, doesn't it means that routed will never announce/add our whatever with the non-existing entry? When came to changing, adding or removing an interface address, will it be good to restart routing and routed services? And by upgrading to 9.2-RELEASE, may the issue goes away! Best regards, Raimundo Santos From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 17:49:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36FE31A0 for ; Thu, 17 Oct 2013 17:49:23 +0000 (UTC) (envelope-from pz-freebsd-net@ziemba.us) Received: from ziemba.us (osmtp.ziemba.us [208.106.105.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FFB02507 for ; Thu, 17 Oct 2013 17:49:22 +0000 (UTC) Received: from hairball.ziemba.us (localhost.ziemba.us [127.0.0.1]) by hairball.ziemba.us (8.14.6/8.14.6) with ESMTP id r9HHQXx0076897 for ; Thu, 17 Oct 2013 10:26:33 -0700 (PDT) (envelope-from pz-freebsd-net@ziemba.us) Received: (from mailnull@localhost) by hairball.ziemba.us (8.14.6/8.14.6/Submit) id r9HHQX1d076896 for freebsd-net@freebsd.org; Thu, 17 Oct 2013 10:26:33 -0700 (PDT) (envelope-from pz-freebsd-net@ziemba.us) X-Authentication-Warning: hairball.ziemba.us: mailnull set sender to pz-freebsd-net@ziemba.us using -f Received: (from news@localhost) by usenet.ziemba.us (8.14.5/8.14.5/Submit) id r9HHQXOK087140 for treehouse-mail-freebsd-net@hairball.ziemba.us; Thu, 17 Oct 2013 10:26:33 -0700 (PDT) (envelope-from news) From: "G. Paul Ziemba" To: freebsd-net@freebsd.org Subject: Please consider committing FIB fixes 167947, 183065 Date: Thu, 17 Oct 2013 17:26:33 +0000 (UTC) Message-id: Errors-to: "G. Paul Ziemba" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: paul+usenet@w6yx.stanford.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:49:23 -0000 Hi, Could someone with privileges please consider committing the patches attached to PRs 167947 and 183065? I use them both in my home network and they work for me. The 167947 patch seems to be also confirmed by rpolzer (see PR). I submitted the 183065 patch today, so it might warrant some review/sanity check. They are both 1-line changes. thanks, ~!paul -- G. Paul Ziemba FreeBSD unix: 10:26AM up 7 days, 1:07, 14 users, load averages: 1.15, 1.09, 1.08 From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 17:53:00 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 305B245A; Thu, 17 Oct 2013 17:53:00 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04C4E2576; Thu, 17 Oct 2013 17:53:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9HHqxBC052805; Thu, 17 Oct 2013 17:52:59 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9HHqxE8052804; Thu, 17 Oct 2013 17:52:59 GMT (envelope-from melifaro) Date: Thu, 17 Oct 2013 17:52:59 GMT Message-Id: <201310171752.r9HHqxE8052804@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-net@FreeBSD.org, melifaro@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: kern/167947: [setfib] [patch] arpresolve checks only the default FIB for the interface route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 17:53:00 -0000 Synopsis: [setfib] [patch] arpresolve checks only the default FIB for the interface route Responsible-Changed-From-To: freebsd-net->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Oct 17 17:52:40 UTC 2013 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=167947 From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 22:04:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED3E3FA0 for ; Thu, 17 Oct 2013 22:04:56 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 9D2EA2656 for ; Thu, 17 Oct 2013 22:04:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:content-type:content-transfer-encoding; s=smtpapi; bh=mYF6fODW38ZBgOOsqOBRTrqKWfU=; b=BeynJHkf3/Rl1IffSH +432M7iufT/an1c5r6f+S1alQpt5stJ6MWhtcm5TL3UXlmROmAyXLP6JDYY5NqPJ XyWtt1Tyhmv1PromK+za3lh6N/qw+j2yC3O3zNOOt8rsopJdHgePV96CgNuH0faL LMtUcf+wGMuQuYurXJs/qOIPc= Received: by filter-135.sjc1.sendgrid.net with SMTP id filter-135.12838.52605F071 Thu, 17 Oct 2013 22:04:55 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi16 (SG) with ESMTP id 141c87332c5.63c8.87f9c7 for ; Thu, 17 Oct 2013 22:04:54 +0000 (UTC) Received: (qmail 40126 invoked from network); 17 Oct 2013 22:04:53 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 17 Oct 2013 22:04:53 -0000 Received: (qmail 23340 invoked from network); 17 Oct 2013 22:03:53 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 17 Oct 2013 22:03:53 -0000 Message-ID: <52605EC9.6090406@freebsd.org> Date: Thu, 17 Oct 2013 15:03:53 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: LRO causing stretch ACK violations interacts badly with delayed ACKing X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEvsV1hzqsglIY99Quqt84nrQERKmjdwWbqOTMhFTL5avN5LcQI9w5KDHvjrpnngvyesP8t3J6pda1eclzrIACA+fwGdpRaKeA5cLTckWl6JAwRMRa1X+FnXW9JVeUPJfo= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 22:04:57 -0000 Hi all, I know {TSO, LRO, ACKing policy} has been discussed here recently, and I don't want to rehash everything, but I'm seeing some very bad misbehaviour with LRO and delayed ACKing turned on. Running 'fetch -o /dev/null https://www.amazon.com/' on an EC2 instance running FreeBSD 10.0-BETA1: > 00:00:00.000000 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [S], seq 3375534763, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1606713 ecr 0], length 0 > 00:00:00.000754 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [S.], seq 3035209700, ack 3375534764, win 8190, options [mss 1460,nop,wscale 6], length 0 > 00:00:00.000788 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 > 00:00:00.002003 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [.], ack 1, win 127, length 0 > 00:00:00.028959 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [P.], seq 1:318, ack 1, win 1026, length 317 > 00:00:00.029884 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [.], ack 318, win 108, length 0 > 00:00:00.029925 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [.], seq 1:4097, ack 318, win 108, length 4096 Amazon's SSL certificate is too large to fit into their initial send window, and despite the fact that FreeBSD has received 4096 bytes (more than 2 MSS, and thus enough that it SHOULD send an ACK according to RFC 2581) we delay that ACK here. 100 ms later, our delayed-ACK timer fires, we send the ACK, Amazon's TCP stack finishes sending their SSL certificate, and everything starts moving again. > 00:00:00.129497 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [.], ack 4097, win 1026, length 0 > 00:00:00.130258 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [P.], seq 4097:4241, ack 318, win 108, length 144 > 00:00:00.131332 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [P.], seq 318:632, ack 4241, win 1026, length 314 > 00:00:00.136398 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [P.], seq 4241:4288, ack 632, win 128, length 47 > 00:00:00.136773 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [P.], seq 632:1011, ack 4288, win 1026, length 379 > 00:00:00.141006 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [F.], seq 4867, ack 1011, win 144, length 0 > 00:00:00.141022 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [.], ack 4288, win 1026, length 0 > 00:00:00.141033 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [P.], seq 4288:4867, ack 1011, win 144, length 579 > 00:00:00.141059 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [.], ack 4868, win 1017, length 0 > 00:00:00.141167 IP 10.142.128.54.13252 > 176.32.98.166.443: Flags [P.], seq 1011:1038, ack 4868, win 1026, length 27 > 00:00:00.142036 IP 176.32.98.166.443 > 10.142.128.54.13252: Flags [R], seq 3035214568, win 9700, length 0 Out of 142 ms that this TCP connection is alive, 100 ms was wasted. This seems like something which ought to be fixed... -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 22:56:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9AA1DEAD; Thu, 17 Oct 2013 22:56:48 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0611E2907; Thu, 17 Oct 2013 22:56:47 +0000 (UTC) Received: from [10.0.0.10] ([10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id r9HMufBQ018397; Fri, 18 Oct 2013 01:56:41 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <52606B26.5090809@ukr.net> Date: Fri, 18 Oct 2013 01:56:38 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> In-Reply-To: <1382030121.2570.1.camel@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [89.209.81.54]); Fri, 18 Oct 2013 01:56:41 +0300 (EEST) X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Oct 2013 22:56:48 -0000 17.10.2013 20:15, Sean Bruno wrote: > On Thu, 2013-10-17 at 08:59 +0300, Vladislav V. Prodan wrote: >> I have a DELL PowerEdge 2950 server (3rd generation). There is a >> network >> card with chipset bce BCM5708. >> >> If a ready algorithm for getting rid of interface resetting / watchdog >> timeout? >> >> Thanks. > > In the freebsd.org cluster we run several of these machines. We had to > update the f/w on them (broadcom) to make the errors go away. > Hello Share instructions for updating the network card firmware? Thank you. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 08:25:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7A5B881C for ; Fri, 18 Oct 2013 08:25:28 +0000 (UTC) (envelope-from anri@polynet.lviv.ua) Received: from postal.polynet.lviv.ua (postal.polynet.lviv.ua [195.22.112.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFBA2AA9 for ; Fri, 18 Oct 2013 08:25:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polynet.lviv.ua; s=dkimpolynet; h=Subject:Content-Transfer-Encoding:MIME-Version:Content-Type:In-Reply-To:References:Cc:To:From:Message-ID:Date; bh=suOV7R3R1ov1bxVqFut1s8KM8ixhURAZNzGr3DQmAPQ=; b=T/ydSU7AyVkRBsuLbTMhZyxFFhU6Ggd2aj6R/DoBYBcNjhQYo6lEzNk3wVph+qwROfz5VkTVvsZSVkv93ePS4utGDL/Djf6lTCxGJ19Wr/vE6NFIWu760eiyBiXkdWcqlfCssKTB5eB1X+T7oN2O9A1IUBDYx3bFkYG6PEfp+RY=; Received: from postoffice.lp.lviv.ua ([192.168.0.6] helo=postal.polynet.lviv.ua) by postal.polynet.lviv.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VX5N1-000GYH-JA; Fri, 18 Oct 2013 11:25:19 +0300 Received: from vega.polynet.lviv.ua (vega.polynet.lviv.ua [195.22.112.3]) by mail.polynet.lviv.ua (Horde Framework) with HTTP; Fri, 18 Oct 2013 11:25:19 +0300 Date: Fri, 18 Oct 2013 11:25:19 +0300 Message-ID: <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> From: Andriy Kopystyansky To: freebsd-net@freebsd.org References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.5-git) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.0.6 X-SA-Exim-Mail-From: anri@polynet.lviv.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on postal.polynet.lviv.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.8 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 Subject: Re: Intel 82580 lagg(4) problem X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on postal.polynet.lviv.ua) Cc: mybsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 08:25:28 -0000 =D0=A6=D0=B8=D1=82=D1=83=D1=8E=20mybsd=20: >=20Set=20net.link.lagg.0.use_flowid=3D0=20not=20solve=20the=20problem. > >=20My=20system=20is=20freebsd=208.4,=20use=20the=20e1000=20driver=20from= =20freebsd=208.3=20=20 >=20solves=20this=20problem=20. >=20Should=20confirm=20that=20the=20problem=20is=20driver > >=20I=20have=20already=20submitted=20the=20BUG. >=20http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182917 > I=20can=20confirm,=20e1000=20driver=20from=20freebsd=208.3=20works=20as=20e= xpected,=20i've=20=20 got=20almost=201.8=20Gb/s=20over=20lagg(4)=20interface,=20whereas=20using= =20default=20=20 driver=20from=209.1=20couldnt=20get=20more=20than=201.2Gb/s. Trying=20iperf=20test=20to=20two=20different=20dst: 1)=20[SUM]=20=200.0-54.5=20sec=20=205.50=20GBytes=20=20=20867=20Mbits/sec 2)=20[SUM]=20=200.0-90.1=20sec=20=209.25=20GBytes=20=20=20882=20Mbits/sec ifstat=20on=20lagg,igb=20using=208.3=20driver: anri@host:[11:01]~#ifstat=20-i=20lagg1,igb0,igb2 =20=20=20=20=20=20=20lagg1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20i= gb0=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20igb2 =20=20KB/s=20in=20=20KB/s=20out=20=20 KB/s in KB/s out KB/s in KB/s out 21748.67 221021.3 10419.36 122968.5 11442.13 150645.1 22010.81 222652.2 10954.49 125154.8 11161.90 150698.2 Test above was performed with net.link.lagg.1.use_flowid=3D1 Setting=20this=20to=20=3D0=20leads=20to=20slightly=20less=20throughput,=20a= nd=20noticable=20=20 cpu=20overhead.=20(I=20havent=20any=20non-ip=20traffic). -- From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 10:22:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5FD26648 for ; Fri, 18 Oct 2013 10:22:52 +0000 (UTC) (envelope-from ole.myhre@dataoppdrag.no) Received: from mail1.dataoppdrag.no (mail1.dataoppdrag.no [IPv6:2a02:f58:7:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D8CB62326 for ; Fri, 18 Oct 2013 10:22:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail1.dataoppdrag.no (Postfix) with ESMTP id 4DA102D0D3 for ; Fri, 18 Oct 2013 12:22:50 +0200 (CEST) Received: from mail1.dataoppdrag.no ([127.0.0.1]) by localhost (mail1.dataoppdrag.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCrmfnN4it2M for ; Fri, 18 Oct 2013 12:22:50 +0200 (CEST) Received: from EX-MBX02.cust-d1.dataoppdrag.no (ex-mbx02.cust-d1.dataoppdrag.no [IPv6:2a02:f58:0:313:b898:7b82:13e0:c3bd]) by mail1.dataoppdrag.no (Postfix) with ESMTPS id 3C6842D006 for ; Fri, 18 Oct 2013 12:22:50 +0200 (CEST) Received: from EX-MBX01.cust-d1.dataoppdrag.no ([fe80::6db0:e393:6a07:457]) by EX-MBX02.cust-d1.dataoppdrag.no ([fe80::b898:7b82:13e0:c3bd%11]) with mapi id 14.02.0342.003; Fri, 18 Oct 2013 12:22:50 +0200 From: Ole Myhre To: "freebsd-net@freebsd.org" Subject: Interface up/down, carp and loopback route Thread-Topic: Interface up/down, carp and loopback route Thread-Index: Ac7L5ZlsrA8IdnofT2qcoevAvXN/vQ== Date: Fri, 18 Oct 2013 10:22:50 +0000 Message-ID: Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:f58:0:314:91d:fe7d:557b:b606] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 10:22:52 -0000 Hi, I'm seeing some inconsistent behavior with how carp handles the loopback ro= ute when it transition from MASTER to BACKUP and how the loopback route is = handled when an interface is marked down. This is currently tested on 10.0-BETA1. (fw1 and fw2 has just been booted) [root@fw1 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: MASTER vhid 1 advbase 1 advskew 0 [root@fw1 ~]# netstat -rn | grep 192.168.0.1 192.168.0.1 link#3 UHS 0 0 lo0 [root@fw1 ~]#=20 [root@fw2 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: BACKUP vhid 1 advbase 1 advskew 0 [root@fw2 ~]# netstat -rn | grep 192.168.0.1 [root@fw2 ~]# [root@fw1 ~]# ifconfig em2 vhid 1 advskew 100 [root@fw1 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: BACKUP vhid 1 advbase 1 advskew 100 [root@fw1 ~]# netstat -rn | grep 192.168.0.1 [root@fw1 ~]# [root@fw2 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: MASTER vhid 1 advbase 1 advskew 0 [root@fw2 ~]# netstat -rn | grep 192.168.0.1 192.168.0.1 link#3 UHS 0 0 lo0 [root@fw2 ~]# [root@fw2 ~]# ifconfig em2 vhid 1 advskew 200 [root@fw2 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: BACKUP vhid 1 advbase 1 advskew 200 [root@fw2 ~]# netstat -rn | grep 192.168.0.1 [root@fw2 ~]# So far, so good. The loopback route is removed when the carp interface goes= back to BACKUP, and added when it goes to MASTER. However, if I mark an interface as down: [root@fw1 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: MASTER vhid 1 advbase 1 advskew 100 [root@fw1 ~]# netstat -rn | grep 192.168.0.1 192.168.0.1 link#3 UHS 0 0 lo0 [root@fw1 ~]# ifconfig em2 down [root@fw1 ~]# ifconfig em2 | grep 'carp\|inet ' inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1 carp: INIT vhid 1 advbase 1 advskew 100 [root@fw1 ~]# netstat -rn | grep 192.168.0.1 192.168.0.1 link#3 UHS 0 0 lo0 [root@fw1 ~]# The loopback route is not removed. The same things happen if I set any interface to down, not just interfaces = with carp enabled. Is this expected behavior, or is it a bug? Or maybe it is (or should be) a = sysctl setting? And is the loopback route really necessary at all? --=20 Ole Myhre From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 12:33:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D801E72 for ; Fri, 18 Oct 2013 12:33:02 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 614C92D00 for ; Fri, 18 Oct 2013 12:33:02 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0027020FED for ; Fri, 18 Oct 2013 08:33:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Fri, 18 Oct 2013 08:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=JLs/TE65E1fmyxYQ72BTHgiL8h4=; b=s8c wckDj3xxeGZ1maQISy8kY+WkUeE7cyfPOeeaVg8yWcYOyWn3kR5Ka4hxD3nngX02 oKZRtui+GEHlLGx2og3WCDDcvJrYNKWb8TVHoxZ+7t7LH8TVlSXVHlfYdqhT+g5v QosBwt+I07OMquna8aAhFXz4rOh9tLhIcWdNq3uQ= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id D72C5100CF2; Fri, 18 Oct 2013 08:33:00 -0400 (EDT) Message-Id: <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> X-Sasl-Enc: w3SHIsGgOtZhPW9teLb0dh9CSTaINSYN9Uda71sSM1Vh 1382099580 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-443dd2cc In-Reply-To: <52606B26.5090809@ukr.net> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> <52606B26.5090809@ukr.net> Subject: Re: bce(4) on the Dell PE 2950 Date: Fri, 18 Oct 2013 07:33:00 -0500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 12:33:02 -0000 On Thu, Oct 17, 2013, at 17:56, Vladislav V. Prodan wrote: > 17.10.2013 20:15, Sean Bruno wrote: > > On Thu, 2013-10-17 at 08:59 +0300, Vladislav V. Prodan wrote: > >> I have a DELL PowerEdge 2950 server (3rd generation). There is a > >> network > >> card with chipset bce BCM5708. > >> > >> If a ready algorithm for getting rid of interface resetting / watchdog > >> timeout? > >> > >> Thanks. > > > > In the freebsd.org cluster we run several of these machines. We had to > > update the f/w on them (broadcom) to make the errors go away. > > > > Hello > > Share instructions for updating the network card firmware? > Thank you. > I imagine you should either boot off a Dell OMSA live CD and apply the patches (they're Linux binaries) or build a firmware update disc that automatically applies all firmware updates. The latter requires a specific Dell application that runs on Windows I believe.. maybe OSX? There may be a third option -- if you have the Enterprise DRAC in your system you can boot into a firmware update mode that pulls the patches directly from ftp.dell.com and applies them. However, I can't recall if this mode exists in 2950 IIIs. From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 12:55:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39021C7D for ; Fri, 18 Oct 2013 12:55:50 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from ca2.route.mx (ca2.route.mx [72.55.175.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D27282E97 for ; Fri, 18 Oct 2013 12:55:49 +0000 (UTC) Received: (route-mx 43684 invoked from network); 18 Oct 2013 12:49:04 -0000 Received: from pickles.tp.telepac.pt (HELO nbari-z200.diz.la) (nbari@inbox.im@route.mx) (envelope-sender ) by ca2.route.mx (route-mx) with CAMELLIA256-SHA encrypted SMTP for ; 18 Oct 2013 12:49:04 -0000 Message-ID: <52612E3E.9060607@inbox.im> Date: Fri, 18 Oct 2013 13:49:02 +0100 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> <52606B26.5090809@ukr.net> <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> In-Reply-To: <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 12:55:50 -0000 What is the latest stable firmware and in what firmware version you get this issue ? regards On 10/18/2013 13:33, Mark Felder wrote: > On Thu, Oct 17, 2013, at 17:56, Vladislav V. Prodan wrote: >> 17.10.2013 20:15, Sean Bruno wrote: >>> On Thu, 2013-10-17 at 08:59 +0300, Vladislav V. Prodan wrote: >>>> I have a DELL PowerEdge 2950 server (3rd generation). There is a >>>> network >>>> card with chipset bce BCM5708. >>>> >>>> If a ready algorithm for getting rid of interface resetting / watchdog >>>> timeout? >>>> >>>> Thanks. >>> In the freebsd.org cluster we run several of these machines. We had to >>> update the f/w on them (broadcom) to make the errors go away. >>> >> Hello >> >> Share instructions for updating the network card firmware? >> Thank you. >> > I imagine you should either boot off a Dell OMSA live CD and apply the > patches (they're Linux binaries) or build a firmware update disc that > automatically applies all firmware updates. The latter requires a > specific Dell application that runs on Windows I believe.. maybe OSX? > > There may be a third option -- if you have the Enterprise DRAC in your > system you can boot into a firmware update mode that pulls the patches > directly from ftp.dell.com and applies them. However, I can't recall if > this mode exists in 2950 IIIs. > _______________________________________________ > 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 Fri Oct 18 17:48:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84FC3CDB for ; Fri, 18 Oct 2013 17:48:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43AB623EA for ; Fri, 18 Oct 2013 17:48:22 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id ii20so909850qab.18 for ; Fri, 18 Oct 2013 10:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NxeS06P9Pe3CBWdnEXaLoslKMKfdcvyGnMeqBKIy7UY=; b=kvPFeS4wywVEq6vpPKe/Kyj8iGXgU0yMCf+Cve8ceCEBneyw7e6azja6u0LFYJq31z b8beS34MJhkvPdGnyey9scxvRUn8kqCOWomHAHDKILx+jQGQRQtlvjB0z9q5Xs3xMRBq mxzAnDQxqXY0sB4iJmNAYArjlmUNzCFdaNJrWU72UHSwbdZzExOPpuVP1Jms/GG6PvZC MiisYpLq0JvFVz4XeP4M+gzvjchkwvkqJ32bm8L3Fel/x4zhj7l6S7mrKt478o87icrJ 1OBipqnsTn6vMl+Oh7BIBvySg/cAcMuNYKogMwvEJ9tQVmKZpMJYmGINHalLgU47OQcu o8oA== MIME-Version: 1.0 X-Received: by 10.49.12.14 with SMTP id u14mr5797398qeb.74.1382118501357; Fri, 18 Oct 2013 10:48:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 10:48:21 -0700 (PDT) In-Reply-To: <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> Date: Fri, 18 Oct 2013 10:48:21 -0700 X-Google-Sender-Auth: QpwVCbbmYXhanj_uvauWlHc1qzY Message-ID: Subject: Re: Intel 82580 lagg(4) problem From: Adrian Chadd To: Andriy Kopystyansky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , mybsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 17:48:22 -0000 Oh wait a sec - you mean that you're running freebsd-8.4 but with the freebsd-8.3 driver (and freebsd-8.4 lagg?) -adrian On 18 October 2013 01:25, Andriy Kopystyansky wrote: > > =D0=A6=D0=B8=D1=82=D1=83=D1=8E mybsd : > > > Set net.link.lagg.0.use_flowid=3D0 not solve the problem. >> >> My system is freebsd 8.4, use the e1000 driver from freebsd 8.3 solves >> this problem . >> Should confirm that the problem is driver >> >> I have already submitted the BUG. >> http://www.freebsd.org/cgi/**query-pr.cgi?pr=3D182917 >> >> > I can confirm, e1000 driver from freebsd 8.3 works as expected, i've got > almost 1.8 Gb/s over lagg(4) interface, whereas using default driver from > 9.1 couldnt get more than 1.2Gb/s. > Trying iperf test to two different dst: > 1) [SUM] 0.0-54.5 sec 5.50 GBytes 867 Mbits/sec > 2) [SUM] 0.0-90.1 sec 9.25 GBytes 882 Mbits/sec > > ifstat on lagg,igb using 8.3 driver: > anri@host:[11:01]~#ifstat -i lagg1,igb0,igb2 > lagg1 igb0 igb2 > > KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out > 21748.67 221021.3 10419.36 122968.5 11442.13 150645.1 > 22010.81 222652.2 10954.49 125154.8 11161.90 150698.2 > > Test above was performed with net.link.lagg.1.use_flowid=3D1 > Setting this to =3D0 leads to slightly less throughput, and noticable cpu > overhead. (I havent any non-ip traffic). > > -- > > > > > > ______________________________**_________________ > 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 Fri Oct 18 18:29:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F9945BA for ; Fri, 18 Oct 2013 18:29:37 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A005D2640 for ; Fri, 18 Oct 2013 18:29:36 +0000 (UTC) Received: from [98.139.212.144] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 18 Oct 2013 18:29:29 -0000 Received: from [98.139.211.200] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 18 Oct 2013 18:29:29 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 18 Oct 2013 18:29:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382120969; bh=MJbv9KYPFApr7lS5DGc3R6Luf0akV5wlSBsOSa6RQm0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=IzBNmQlTJctYQfMIINlcK0zJxjvLeVQXGKibf8JMHWfdfbmfAK/Oe27rD4PBssUjIEFwRFGp7+UoFte8OvLyZJl+t1QQZJt7Qx3qSYyvIL9+K4iaI0bagR8HcPoQNGGhn0MrIodN8nXJbgji2xaZWA4zkECDn+gFsQ8C+tmcMqk= X-Yahoo-Newman-Id: 368094.66063.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: av8mlG0VM1ms8F8pHZjOXyjE8iKLunkPpw8gaPdnPtzEscV kzVLB6aLVhb6CPP4QRs.BUnPDeFt2jxHQhJBBMtmZE0MWuBf.TqCG9fLIMGO LDL4SJKfsqkEQOI.O4l_wGHXAzyF08Js5vloIQmf745SReT4xYTDrROdYYXm wOY7.qRLtakLxCz35cILD9D7s1jTjdJVCIQol7FmQ.fyMA72SsWlI6joJYMg 6MI_8.IKT165tV1Ze4yqLO6IYRL0SP2eo_wPSVAV0mQEx2f81lKmxIWniA6g jL7GSXu.6o0P8FuKHaUMFBbLjHkDBie8PDee.R1jpwx9aCcl2mr7GPFyLAMx msdVy8Z_LMq0v_YOvrZpp5t0s_0WKtVHRkONILGxHlaH4NsZwbIWz1Jor.q_ cAZ6gxlRrrc.EVMCVldWQVWQqx9WYnJIJoYnZ8gIEsv4rDTHX5IMYgcu6ZCR wHSXaVr_74kZ3P0m_QloiATs37Dad9jV5Zj8bgTaaBm39xs37gWrOadrt8PZ KWUVjxVve5Ofx7I.t_ibFzSPnc7PDJK6c3jZYdCtCp6TY.g9waDL7Je3aF4O MnAy9s.DEG1YBmEqpMk2RPS7ZLpujsrWuH_w8RRrwl6XqIGw9.FUonmdUSaL 2B4wrA4d.524QxAz8D2ODi6tYM3jyEX1gjoYMYZ3U8RO9ledcX6xPktPmQ0_ 3PXHuGHtZe936EpO6EtzMtcCIGmKM9OkP8TQqcckYKKVlVEXXFqHflpW.myv C_wAQJVzcz5b9QaHKo8v7Dkb9ugAP9_kMUlYmJx.mxL_cnh6VQTpATdf6 X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp209.mail.bf1.yahoo.com with SMTP; 18 Oct 2013 11:29:29 -0700 PDT Subject: Re: bce(4) on the Dell PE 2950 From: Sean Bruno To: Nicolas de Bari Embriz Garcia Rojas In-Reply-To: <52612E3E.9060607@inbox.im> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> <52606B26.5090809@ukr.net> <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> <52612E3E.9060607@inbox.im> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FQXckx7PnerF9N9M4fak" Date: Fri, 18 Oct 2013 11:29:27 -0700 Message-ID: <1382120967.1386.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:29:37 -0000 --=-FQXckx7PnerF9N9M4fak Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Fri, 2013-10-18 at 13:49 +0100, Nicolas de Bari Embriz Garcia Rojas wrote: > What is the latest stable firmware and in what firmware version you get > this issue ? >=20 > regards This ridiculous web link *should* take you there to get new firmware: http://www.dell.com/support/drivers/us/en/555/DriverDetails/Product/powered= ge-2950?driverId=3DP32M4&osCode=3DRH60&fileId=3D3230162487&languageCode=3DE= N&categoryId=3DNI Known "good" firmware output from bce(4) on bootup: bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 miibus0: on bce0 bce0: Ethernet address: 00:18:8b:52:0e:42 bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 miibus1: on bce1 bce1: Ethernet address: 00:18:8b:52:0e:40 bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) --=-FQXckx7PnerF9N9M4fak Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAABAgAGBQJSYX4HAAoJEBkJRdwI6BaH17EH/2zqbqm78FAgFOGfX+l6Z2SZ K4f01MnawHFGJ15tS3mn3L+fu+WjgWNen39XQObUisXHbOCuHYFHidLBQi81XeWa qdC8knolYec6zmixUb7sNj4GZKKgOFsG6MP/WqpQ9Vd9EVCmOcBQVKOLiK6KXBjg BvQq6g+YVqks8MpTEh0NQqp+VLPlKfrfpcZh+Bno5ksfCgfbyei5iSEuZ0Z9HMFE FxMhAI6LCk19n7WEFU9FOk3oTkxNdnqbzVOrbeYQyvyo4MwkRd8F/Nrr9n13t9WI gQPECGPpV7px+vqsaDqMq1+1CQ6sS5zUlL6cak5S57OW/QnmOhzX1y7sIpb4oB0= =WXfV -----END PGP SIGNATURE----- --=-FQXckx7PnerF9N9M4fak-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 19:54:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63CFB9B2; Fri, 18 Oct 2013 19:54:08 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35B312A83; Fri, 18 Oct 2013 19:54:08 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id wz7so185495pbc.38 for ; Fri, 18 Oct 2013 12:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jbF268gh6LaxI9BH/+QlwUzc2TJFcc8TJyaan0TnjUw=; b=s18+xdA4lKMvfhli1yd36PVILFFdt7RAJkRRoF1c/Q06Y0GsbB8+vZUwXaBkkPR6jH Pgn+SQA8FrXumpW3VS/X8SWYFSdsI8Kae94OYSfP4dw17SpPwyc3buOVHg4JtmqxToEg rvVClxmeO6iH7WdIFgR2MSN9+hpLT8N1XpkjEhZTnzBNbRkJZ14WXZ4lB+VIvqa1UvEX daH2SDeXlDRi/4bxK7/ybAiqr4O4a5Lz3HFcBejA3cCJ/u2U6DMnI/5WIWxai53kvUX9 Ocx3lu9QFPn1vGHSmxphk4UkRlfAJfEJtVTDRA003ALxTGLEJe0BdcD0WCH5QZkrxzUc kBhQ== X-Received: by 10.68.194.130 with SMTP id hw2mr4723587pbc.114.1382126047847; Fri, 18 Oct 2013 12:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Fri, 18 Oct 2013 12:53:46 -0700 (PDT) In-Reply-To: References: <525F8C4F.5090303@FreeBSD.org> <5260147D.3000907@FreeBSD.org> From: Raimundo Santos Date: Fri, 18 Oct 2013 16:53:46 -0300 Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command To: "Alexander V. Chernikov" , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 19:54:08 -0000 Upgraded from 9.1 to 9.2-RELEASE, problem solved. Thank you all! Raimundo Santos On 17 October 2013 14:31, Raimundo Santos wrote: > > Oh my... I forgot to reply to list... an here we go again! > > > > On 17 October 2013 13:46, Alexander V. Chernikov wrote: > >> On 17.10.2013 18:25, Raimundo Santos wrote: >> >> On 17 October 2013 04:05, Alexander V. Chernikov wrote: >> >>> This seems rather strange. I'm using multiple fibs in production, and it >>> shouldn't behave that way. >>> >>> >> It occurs even with aliases. >> >>> >>> Can you do the following and send me output? >>> >>> 1) issue `route -n monitor` and log all messages >>> 2) add first address to interface >>> 3) do route -n get network_address (e.g. XX.XX.XX.16/28) for added >>> prefix (in fib 0 and fib 1) >>> 4) remove this address >>> 5) repeat step 3 >>> 6) add this prefix to another port >>> 7) repeat step 3 >>> >>> >> Hello, Alexander! >> >> The machine in question are under production, too. It hurts the results >> if I do these steps without removing all the addresses from the interface? >> >> By the way, this machine is a "border" router (not using BGP by now, >> but over the borders of my network and my providers network). All the >> addresses over this Intel NIC are routable, except in one port, where we >> have some equipment lying out the network (just don't ask why...) and all >> of them have private addresses. I saw the issue when trying to comunicate >> to these equipments adding and removing aliases in one of the ports. That >> said, there is an intersting output, after removing ALL the aliases from >> the refered NIC port: >> >> command issued: >> >> for i in `seq 0 14`; do \ >> echo "fib $i" >> routing.fibs; \ >> setfib $i netstat -rnfinet | grep '172\.31\.' >> routing.fibs; \ >> echo "--------------------------------" >> routing.fibs; \ >> done >> >> status of igb1 and 2: >> >> igb1: flags=8843 metric 0 mtu 1500 >> >> options=401bb >> ether 00:1b:21:5a:93:31 >> inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 >> inet (routable addr) netmask 0xfffffff0 broadcast (routable addr >> broadcast) >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> igb2: flags=8843 metric 0 mtu 1500 >> >> options=401bb >> ether 00:1b:21:5a:93:34 >> inet (routable addr) netmask 0xfffffff8 broadcast (routable >> broadcast) >> inet6 fe80::21b:21ff:fe5a:9334%igb2 prefixlen 64 scopeid 0x3 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> And the output of the commands: >> >> fib 0 >> 172.31.19.0/24 172.31.19.190 U 0 0 igb1 >> 172.31.20.0/24 172.31.20.190 U 0 0 igb2 >> >> ^^^^^^^^^^ >> This is probably installed by some routing daemon (issuing RTM_CHANGE >> message) >> (can be easily checked with `route -n monitor`) >> This is fixed in r248070 ( and merged to 9.2) >> >> -------------------------------- >> fib 1 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 2 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 3 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 4 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 5 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 6 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 7 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 8 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 9 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 10 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 11 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 12 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 13 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 14 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> >> I never set 172.31.whatever over igb2! Just over igb1. >> >> Just to remeber: >> >> kernel options >> >> options VIMAGE >> >> # routing options >> options ROUTETABLES=15 >> # IPFW options >> options IPFIREWALL_FORWARD >> options IPFIREWALL_VERBOSE >> options IPFIREWALL_VERBOSE_LIMIT=300 >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> >> Under >> >> FreeBSD 9.1-RELEASE-p4 >> >> Thank you for your time! >> >> >> > Okey, Alexander, I found the culprit: routed, running in this machine as > pid 99399. This is the result of 'route -n monitor' after doing a for loop > over all fibs and manualy removing 172.31.19/24 and 172.31.20/24. First > two, the deletes, last two, the adds. No RTM_CHANGE, so far, and the ADD > only apply to fib 0. (Thank you for the route monitor advice!) > > got message of size 192 on Thu Oct 17 14:14:01 2013 > RTM_DELETE: Delete Route: len 192, pid: 94802, seq 1, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.19.0 172.31.19.190 (255) ffff ffff ff > > got message of size 192 on Thu Oct 17 14:14:07 2013 > RTM_DELETE: Delete Route: len 192, pid: 94819, seq 1, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.20.0 172.31.20.190 (255) ffff ffff ff > > got message of size 191 on Thu Oct 17 14:14:29 2013 > RTM_ADD: Add Route: len 191, pid: 99399, seq 1142, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.19.0 172.31.19.190 > pmsg_addrs: truncated route message, only 7 bytes left > > > got message of size 191 on Thu Oct 17 14:14:32 2013 > RTM_ADD: Add Route: len 191, pid: 99399, seq 1143, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.20.0 172.31.20.190 > pmsg_addrs: truncated route message, only 7 bytes left > > From where routed take these addresses? When removing an fib entry, > doesn't it means that routed will never announce/add our whatever with the > non-existing entry? > > When came to changing, adding or removing an interface address, will it be > good to restart routing and routed services? > > And by upgrading to 9.2-RELEASE, may the issue goes away! > > Best regards, > Raimundo Santos > From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 20:00:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6FA55AAD; Fri, 18 Oct 2013 20:00:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CDF72AE4; Fri, 18 Oct 2013 20:00:59 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id q19so2216706qeb.38 for ; Fri, 18 Oct 2013 13:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8uA+GPcwFPk0039BmBJiX3sAYUlQZH+XHU+82FNmLBE=; b=hWKg6OHSESIK33qXH2a4EUAKixG/Pyk5huGTIPvV8CyunGDZYzJggLSJmjQq7dQ+i/ jUrbGyl+SdLmzA8cy1RLtO6iFlbD39lOpuqXlthJFOoBdhV/PsIf9to7j8oGuVYJKDRD i/cZYG1KLCHZRt6x383JgwjsU/NFfiXCLkrJA3qvE7UFl/D+h+FrPeOquudGEjX6qDgr uZDG3xTJk64gOmXBchjfrEYkovDcB0IzWxvtUj7I910LhTur3B9GXc+6DzjKa/P4OrrX j6YagcXT0GZVY+i1eHZObIZIycqwBUBzD/B60/bd6Re76pyTQ9w9bvTrNNpQkwqtoB4Y 1W+Q== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr7025121qad.76.1382126458246; Fri, 18 Oct 2013 13:00:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 13:00:58 -0700 (PDT) In-Reply-To: <1382120967.1386.1.camel@localhost> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> <52606B26.5090809@ukr.net> <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> <52612E3E.9060607@inbox.im> <1382120967.1386.1.camel@localhost> Date: Fri, 18 Oct 2013 13:00:58 -0700 X-Google-Sender-Auth: 2kLL-1Nseo-vSOBV0LbySINN8qM Message-ID: Subject: Re: bce(4) on the Dell PE 2950 From: Adrian Chadd To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Nicolas de Bari Embriz Garcia Rojas X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 20:00:59 -0000 Hi, can you create a wiki page for this (eg https://wiki.freebsd.org/dev/bce(4)) and put this information in it? I'm sure this won't be the first time someone asks this question. Also is it worth modifying the driver to check that this firmware is the minimum 'good' version installed? -adrian On 18 October 2013 11:29, Sean Bruno wrote: > On Fri, 2013-10-18 at 13:49 +0100, Nicolas de Bari Embriz Garcia Rojas > wrote: > > What is the latest stable firmware and in what firmware version you get > > this issue ? > > > > regards > > > This ridiculous web link *should* take you there to get new firmware: > > http://www.dell.com/support/drivers/us/en/555/DriverDetails/Product/poweredge-2950?driverId=P32M4&osCode=RH60&fileId=3230162487&languageCode=EN&categoryId=NI > > Known "good" firmware output from bce(4) on bootup: > > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > miibus0: on bce0 > bce0: Ethernet address: 00:18:8b:52:0e:42 > bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > miibus1: on bce1 > bce1: Ethernet address: 00:18:8b:52:0e:40 > bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 23:23:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB840571; Fri, 18 Oct 2013 23:23:17 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9BBEA25CD; Fri, 18 Oct 2013 23:23:17 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id ma3so4417951pbc.7 for ; Fri, 18 Oct 2013 16:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hHwnLYVyQq7aMN2CmoTPQkF/9ANM1inpVS4cColK8WM=; b=ARGnkjuGk61ZfH5n2l6nkDSzng2QZJt+B6pooTbmkp7A6WAyxS/f1yGk5/dqRF4VTG PpeO0aMfdSFvaHvtInMw9prizu1c4MIZFb5dCFY4ORwTFMnsMgUoyA2vFI/IZHdGipW4 ck9+fzHQgWbb5va2sMj+s+DlpcD1ofh2b8V9cuw1quMlk8dwtmAe9R3AQb/asehc3e37 raP+mMYl2y/w2taZaDNuRuS4G2jLfKn/CitgLeBnoyjoj5nYeVaDVXuTZROcIMW6Zb2g AlRZRoChcMgYyXGogfvgEy7DT4UcaldMncNHzDj5lgleGobYLaljkVGh70A0sZ089Z0E 9h6w== MIME-Version: 1.0 X-Received: by 10.68.130.234 with SMTP id oh10mr5507792pbb.0.1382138596169; Fri, 18 Oct 2013 16:23:16 -0700 (PDT) Received: by 10.70.30.98 with HTTP; Fri, 18 Oct 2013 16:23:16 -0700 (PDT) Received: by 10.70.30.98 with HTTP; Fri, 18 Oct 2013 16:23:16 -0700 (PDT) In-Reply-To: References: <5146121B.5080608@FreeBSD.org> Date: Sat, 19 Oct 2013 02:23:16 +0300 Message-ID: Subject: Re: MPLS From: Sami Halabi To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Oct 2013 23:23:17 -0000 Hi, I would love to see progress and even help... Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 14 =D7=91=D7=99=D7=95=D7=A0 2013 10:40= , "Sami Halabi" =D7=9B=D7=AA=D7=91: > Hi Alex, > Got any progress? I'm excited to test mpls in fbsd :) > > Sami > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 15 =D7=91=D7=9E=D7=90=D7=99 2013 17:= 43, =D7=9E=D7=90=D7=AA "Sami Halabi" : > >> Hi Alex, >> Any progress on mpls fbsd? >> >> Thanks in advance, >> Sami >> On Mar 17, 2013 8:57 PM, "Alexander V. Chernikov" >> wrote: >> >>> On 17.03.2013 13:20, Sami Halabi wrote: >>> >>>> any one? :) >>>> >>>> >>>> On Fri, Mar 15, 2013 at 6:28 PM, Sami Halabi >>>> wrote: >>>> >>>> Hi, >>>>> Are there ongoing job of mpls in freebsd? >>>>> I saw thd site http://freebsd.mpls.in for aboug a year now and I don'= t >>>>> see much progress. >>>>> >>>> Yep. It was frozen for a while. >>> Currently I'm working on it again. >>> >>> control plane code was heavily redesigned, see >>> http://bird.mpls.in/projects/**mpls-bird/repository/show?rev=3D**bird_m= pls >>> >>> I have some working MPLS code on 8-S and I hope to create freebsd svn >>> branch with base MPLS support in 2-3 weeks. >>> >>> ITOH OpenBSD has a complete implementation of MPLS out of the box, may= be >>>>> >>>> Their control plane code is mostly useless due to design approach >>> (routing daemons talk via kernel). >>> Their data plane code, well.. Yes, we can use some defines from their >>> headers, but that's all :) >>> >>>> porting it would be short and more straight forward than porting linux >>>>> LDP >>>>> implementation of BIRD. >>>>> >>>> It is not 'linux' implementation. LDP itself is cross-platform. >>> The most tricky place here is control plane. >>> However, making _fast_ MPLS switching is tricky too, since it requires >>> chages in our netisr/ethernet handling code. >>> >>>> >>>>> Thanks in advance, >>>>> Sami >>>>> >>>>> >>>> >>>> >>>> >>> From owner-freebsd-net@FreeBSD.ORG Sat Oct 19 09:01:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 651324E7 for ; Sat, 19 Oct 2013 09:01:02 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E79A52F34 for ; Sat, 19 Oct 2013 09:01:01 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ev20so1574650lab.11 for ; Sat, 19 Oct 2013 02:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=/G7iOXEUofFfsEOjI3ddVT/Fnsj0tz31/VwUC2nh+2s=; b=X2h6JGfYOmvtfopw5Cm5OuEWutB2beftKOZbHnOWTVP7th7SkX2FGxataO19XuRwFP wakbDPNnlAAMe6EKaTNxnM2fdt52xV7dmwBGgXv6Y79Etz9ps7+WYCpCIRclhR5PavPj kS0L0o7KAKojBJSyFNYRls8usxqEXOrRnP4Oiw9aBE/laIWTUqPlqIn8z6ptogiAPd5f OSO4Zxnf839ty/h/BtM8jsNd5ELMOtt3ivHwytf34ZGu5hAQRFil6QZjSxGXYveG/YAM ZcqI1xUeVX/lJTuCbcQx5gmEFyzio7NfvToCvOzUsjO4E/gWPg3p0/DdpLK/MC2JmA66 k0pA== X-Received: by 10.152.5.162 with SMTP id t2mr5454019lat.1.1382173259880; Sat, 19 Oct 2013 02:00:59 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.114.161.109 with HTTP; Sat, 19 Oct 2013 02:00:39 -0700 (PDT) From: h bagade Date: Sat, 19 Oct 2013 12:30:39 +0330 X-Google-Sender-Auth: EncgL3g7KHB8N4wHMSf_ldwF_K4 Message-ID: Subject: Netmap and in-kernel IPFW interactions! To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Oct 2013 09:01:02 -0000 Hi Everybody, I have compiled my kernel with support of netmap without any changes on ipfw. Afterwards, I defined ipfw rules and surprisingly they worked!! Before my experiment on ipfw, I'd thought because packets are reached to userspace directly by means of netmap, so in-kernel ipfw won't be able to check them in between?! Could anyone clarify me how in-kernel tools are able to work even after netmap is used? From owner-freebsd-net@FreeBSD.ORG Sat Oct 19 15:28:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E985A199 for ; Sat, 19 Oct 2013 15:28:55 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C41AA2FBD for ; Sat, 19 Oct 2013 15:28:55 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id z10so6230634pdj.2 for ; Sat, 19 Oct 2013 08:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=roUb9nEI5mTaDHAzzXntLDToyZzyVEkG/uYC6owSDcA=; b=A7gjFhMqXgRstxpQJRY8l2wVya8rQRIumF4S2DV2aPouVo8aTh02bg0OcIQE1sGJHv dmSZyZM3zJyymEidSJHIhwOy25ToODic+fp7taUweE0bQasbV7AssWm7yUWjg5wLDW2E o5BEjBgywXUBHy1XHJpI4nK+HQA3gtf1Cis6Jk1yXy3P4e/MuPJwAqDG348Ow7jlNGAK y4r7FLInay+hnwVHCXbtBWzOJDt4P6wHPW29orzBoT1p71v/VPuHm6+dDVDDuJbC0Dhf 7dp3ltEUPjxG6jNHHnbMf05kIS76QVjDN5ogiqoRg6N6vUotdgkUTPv0+2w7eR7l3mXO Memw== X-Received: by 10.66.170.168 with SMTP id an8mr9194021pac.58.1382196535256; Sat, 19 Oct 2013 08:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Sat, 19 Oct 2013 08:28:35 -0700 (PDT) In-Reply-To: References: From: Raimundo Santos Date: Sat, 19 Oct 2013 12:28:35 -0300 Message-ID: Subject: Re: Netmap and in-kernel IPFW interactions! To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Oct 2013 15:28:56 -0000 On 19 October 2013 06:00, h bagade wrote: > Hi Everybody, > > Hello! > I have compiled my kernel with support of netmap without any changes on > ipfw. Afterwards, I defined ipfw rules and surprisingly they worked!! > > Being netmap-ed your kernel doesn't mean you are really using it. If your data continue to take normal paths, ie, do not touch netmap, it will be there to the in kernel classifier take care. > Before my experiment on ipfw, I'd thought because packets are reached to > userspace directly by means of netmap, so in-kernel ipfw won't be able to > check them in between?! > > You must open the netmap device and interact with it, no more, no less. As the OPERATION section of netmap(4) states: netmap clients must first open the open("/dev/netmap") If your NIC driver doesn't support netmap, you end up with the normal path to frames and packets. > Could anyone clarify me how in-kernel tools are able to work even after > netmap is used? > So, to clarify you, you must clarify us: how are you *using* it, actually? Best Regards, Raimundo Santos From owner-freebsd-net@FreeBSD.ORG Sat Oct 19 16:33:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D4345AF for ; Sat, 19 Oct 2013 16:33:13 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD60E2334 for ; Sat, 19 Oct 2013 16:33:12 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id y10so5065412wgg.32 for ; Sat, 19 Oct 2013 09:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0hKpaKsKv2vrZNDdGvifFKCoheOJ/mpW7WRqNMOtLCA=; b=pxfQu7QqEDyKReC/x//69DinBuLiQmqiNb9uIJy8woBWxeIa1NGJclZF9w0tE2GgHs INZdAZW8rL0TsRw9qG94sCOTXXXshLq7CaGtuwtZsA4YlfIygCEFKQd2SI5NyU++TbZP bl9ihUPgsiW9L7JNJ744QZfC2AVaYtRx2XGW+WyfXRDnszfvV8HRjUCrqNpwBowp+YUH VszX//npMQ9uJzmqUQukqM1Kd0tcfg7VCmTBWrN82ciBnieC6RGIJ7aXJWrZaJAZBEV0 FDiBaay5xNzV8Vl9L9GZzvTtolqTXePh1MFD3P+S8gKSwLiLrjhowrzG2CuTjiUpLRan v9+A== X-Received: by 10.180.101.197 with SMTP id fi5mr3620348wib.46.1382200391262; Sat, 19 Oct 2013 09:33:11 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Sat, 19 Oct 2013 09:32:51 -0700 (PDT) In-Reply-To: References: From: h bagade Date: Sat, 19 Oct 2013 20:02:51 +0330 X-Google-Sender-Auth: 7bFytptYdtHlr6JCI9HF0HXBovA Message-ID: Subject: Re: Netmap and in-kernel IPFW interactions! To: Raimundo Santos Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Oct 2013 16:33:13 -0000 On Sat, Oct 19, 2013 at 6:58 PM, Raimundo Santos wrote: > On 19 October 2013 06:00, h bagade wrote: > > > Hi Everybody, > > > > > Hello! > > > > I have compiled my kernel with support of netmap without any changes on > > ipfw. Afterwards, I defined ipfw rules and surprisingly they worked!! > > > > > Being netmap-ed your kernel doesn't mean you are really using it. If your > data continue to take normal paths, ie, do not touch netmap, it will be > there to the in kernel classifier take care. > > > > Before my experiment on ipfw, I'd thought because packets are reached to > > userspace directly by means of netmap, so in-kernel ipfw won't be able to > > check them in between?! > > > > > You must open the netmap device and interact with it, no more, no less. As > the OPERATION section of netmap(4) states: > > netmap clients must first open the open("/dev/netmap") > > If your NIC driver doesn't support netmap, you end up with the normal path > to frames and packets. > > > > Could anyone clarify me how in-kernel tools are able to work even after > > netmap is used? > > > > So, to clarify you, you must clarify us: how are you *using* it, actually? > > Best Regards, > Raimundo Santos > _______________________________________________ > 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" > I've changed em and igb drivers too. In this situation, I think that they are using netmap and grow-up performance is a sign of the change. I've used pkt-gen for performance checking. From owner-freebsd-net@FreeBSD.ORG Sat Oct 19 16:44:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36021C9D for ; Sat, 19 Oct 2013 16:44:02 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2A2B23DC for ; Sat, 19 Oct 2013 16:44:01 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id u14so1325776lbd.15 for ; Sat, 19 Oct 2013 09:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ou+T9nCejm5M1od2PnF1T3d/H7aGyYAWmBNq7+OTjv0=; b=hetaFKcvWeU7U5TuX1EqyRY0fB+aNx5VsHeAHWC8jecRmBnYoRxz3D9De+c2kT3a9S oRgfn44fkzJssRIcaQEHgWirjIgysCtypItd5l8KgseeDzTmHiufDMs3rRl/aIzpcz1/ gwm35N4M4qsCzj3Hf4lws99XEzq56v/aBDs+xbjk1RLy7+H7YxHtfaF1jycwJWaJTn0k ob01SfjQRTZedm2oCMQ0HvWkeOE9OMeUiL7pibpKFPPEJ2V7eLwAiBaZrBf/j3Ebs/ZJ EFI534VHUPIVrvZQChFnjgY09ihF2jO7uI//Qz+2y7+IMtTuwOMQAChNB9mx0nJg9Xm3 ISSQ== MIME-Version: 1.0 X-Received: by 10.152.23.5 with SMTP id i5mr6674830laf.8.1382201039650; Sat, 19 Oct 2013 09:43:59 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.172.105 with HTTP; Sat, 19 Oct 2013 09:43:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Oct 2013 09:43:59 -0700 X-Google-Sender-Auth: J1ZDs_9OlBFEwZKg-kwfO4x2iew Message-ID: Subject: Re: Netmap and in-kernel IPFW interactions! From: Luigi Rizzo To: h bagade Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Oct 2013 16:44:02 -0000 On Sat, Oct 19, 2013 at 9:32 AM, h bagade wrote: > On Sat, Oct 19, 2013 at 6:58 PM, Raimundo Santos > wrote: > > > On 19 October 2013 06:00, h bagade wrote: > > > > > I've changed em and igb drivers too. In this situation, I think that they > are using netmap and grow-up performance is a sign of the change. I've > used pkt-gen for performance checking. > you use netmap only when you use a netmap-aware tool, such as pkt-gen. The normal stack still uses the regular drivers. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Oct 19 18:10:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99C06C17 for ; Sat, 19 Oct 2013 18:10:35 +0000 (UTC) (envelope-from sh1970@163.com) Received: from mproxyjp5.163.com (mproxyjp5.163.com [176.34.24.136]) by mx1.freebsd.org (Postfix) with ESMTP id BF8A5291D for ; Sat, 19 Oct 2013 18:10:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:In-Reply-To: References:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=ruUXFyvTGJaxqXiwbIAQRdyfQrcV2NjVQP UKImXymm0=; b=MfqCrMUZndPZ5I5xuOT1wdD5quniH85sGnUEI96W/E8lCNCdds gu/YPf0yznyrlEDpFz0YY6X0+vsau94dhGutaMJRQ4rcd/l2t/EDaRWAxFRYPZME Wfu/0vRR1SOgoB+3MXpny5o9lrFVrEwhIMnTRXFqCGTcDlA2voEvTaCEs= Received: from [192.168.1.100] (unknown [60.255.0.18]) by smtp11 (Coremail) with SMTP id D8CowEDZGUZtx2JS4ATPAg--.1369S2; Sun, 20 Oct 2013 01:54:54 +0800 (CST) X-Coremail-DSSMTP: 60.255.0.18 Date: Sun, 20 Oct 2013 01:54:41 +0800 From: sh1970 To: freebsd-net@freebsd.org Subject: Re: Intel 82580 lagg(4) problem In-Reply-To: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> Message-Id: <20131020015440.3617.A3C13D1F@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [en] X-CM-TRANSID: D8CowEDZGUZtx2JS4ATPAg--.1369S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvj4RtBMNDUUUU X-CM-SenderInfo: 1vkrmlqq6rljoofrz/1tbiMg67JlD-oBBX0wAAs6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Oct 2013 18:10:35 -0000 yes. http://www.freebsd.org/cgi/query-pr.cgi?pr=182917 -- sh1970