From owner-freebsd-net@FreeBSD.ORG Mon Jan 2 08:11:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6EA106566B; Mon, 2 Jan 2012 08:11:21 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76BE38FC14; Mon, 2 Jan 2012 08:11:20 +0000 (UTC) Received: by eaaf13 with SMTP id f13so19897284eaa.13 for ; Mon, 02 Jan 2012 00:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zG8rP9nluB/a/fnZpRT4FDgySrXW54/nsD4iJJzoRB4=; b=NH0+90sD+tdO/urlqrLlSA1UObkX/U4DfWSYREjS3d2PjtWkR8GODH8c4a9ePaw+MK 8j1TO0X8ImRpZwUIN7D3c7fSpl+h5o+X7Q6i8OREqAURg2P6jgA3Ms/b4kMLYrNbwXpH FbR8UQj4PeFxIMextNnoTRQcoDabIa7yBodyo= Received: by 10.204.48.148 with SMTP id r20mr6551719bkf.116.1325491879429; Mon, 02 Jan 2012 00:11:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.123.17 with HTTP; Mon, 2 Jan 2012 00:10:37 -0800 (PST) In-Reply-To: References: <4EF038B9.5050203@gmx.com> <4EF18D7D.1050609@gmx.com> <4EF61535.4030507@gmx.com> <4EF8394F.8050108@gmx.com> <4EFAE551.8040101@gmx.com> From: saeedeh motlagh Date: Mon, 2 Jan 2012 11:40:37 +0330 Message-ID: To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Alexander Lunev , Nikos Vassiliadis , Alireza Torabi Subject: Re: vlan without ip address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 08:11:21 -0000 [image: untitled.bmp] thank you guys, the above picture is my network topology. as you see, i have four end point systems in the same range ip. three of them (c1, c3, c4) are the member of vlan1 and the other one (c2) is the member of vlan2. these three systems should ping each other and should not ping c2. there are three important points for me: 1- all of the vlans configurations should be done on the middle freebsd box which acts as switch and no vlan is defined on the end points. 2- the middle freebsd box should not have any ip addresses. 2- we can ping c4 from the other members of vlan1. in the other words, the middle freebsd box should be able to communicate with the remaining devices of the network (which can includes cisco switches). any suggestion for the configuration of the middle freebsd box to do this scenario, would be appreciated. yours On Sun, Jan 1, 2012 at 2:00 AM, Juli Mallett wrote: > On Sat, Dec 31, 2011 at 03:26, saeedeh motlagh > wrote: > > thank you guys for your answers but my problem is not solved yet:(( > > > > the thing is, i wanna have something like this: > > a freebsd box which acts like switch (for example cisco 2960). i want to > > define vlanX on one interface (without any ip address) and it tags any > > passing packets through that interface as vlanX (any passing packet will > > have vlanX ID). > > Did you see my previous message about VLAN interfaces in FreeBSD not > being like the VLANs one can define in a switch? You do not need the > interface to add any tag to incoming packets, if that is what you are > saying. Have you tried just bridging the interfaces without VLANs to > see if that does what you want? > > You may also be adding the VLAN in the wrong place. If you create an > interface em0.4, which is tagged VLAN 4 on em0, then any incoming > packet on em0 which has a VLAN tag of 4 will appear on em0.4. If you > send any packets on em0.4, then they will be sent out em0 with a VLAN > tag of for VLAN 4 added. Is that what you want? > > It may be helpful for you to draw us a diagram. Use specific > examples. Show an incoming packet. Does it have a VLAN tag? If so, > what is the VLAN number? What is the name of the physical interface > on which it arrives? Do you want that VLAN tag to be removed? Do you > want another VLAN tag to be added? Do you want it bridged to another > interface? If so, which interface? When it comes out that other > interface, should it have a VLAN tag? If so, with what VLAN number? > > You've mentioned that you're using bridging, then you say you want > switching, then you give a specific example of a switch you want > FreeBSD to act like. FreeBSD will not act like that switch. You may > be able to accomplish the same thing, but the performance, > configuration and operation will be different. If you want FreeBSD to > act exactly like a Cisco switch with a few lines in rc.conf, then you > should probably stop now, FreeBSD is the wrong tool for the job. > > If, however, you can be very specific about what it is you want to do, > instead of just repeating the same things about switches and VLANs, > then we might be able to help you do it with FreeBSD. We'd all very > much like to, but what you're trying to do is not clear. Forget all > about what the VLAN interfaces are named, forget all about IP > addresses, and tell us what you want to do. > > Thanks, > Juli. > From owner-freebsd-net@FreeBSD.ORG Mon Jan 2 11:07:07 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24FB1065711 for ; Mon, 2 Jan 2012 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1268FC16 for ; Mon, 2 Jan 2012 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q02B77FK005188 for ; Mon, 2 Jan 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q02B76MF005185 for freebsd-net@FreeBSD.org; Mon, 2 Jan 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Jan 2012 11:07:06 GMT Message-Id: <201201021107.q02B76MF005185@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 11:07:07 -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/163482 net IP address is not round robined if DNS name has many 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/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h 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/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net [re] RTL8169SC - re0: PHY write failed 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/160420 net [msk] phy write timeout on HP 5310m 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/159795 net [tcp] excessive duplicate ACKs and TCP session freezes 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/157429 net [re] Realtek RTL8169 doesn't work with re(4) 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/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin 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/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr 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/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/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/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. 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 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 o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 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 bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o 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/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow 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/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption 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 kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/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] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o 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/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/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 s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/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 o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c 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 383 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 2 13:20:48 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31AEA1065677; Mon, 2 Jan 2012 13:20:48 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id EBD9F8FC1B; Mon, 2 Jan 2012 13:20:47 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3B939117BE6; Mon, 2 Jan 2012 13:20:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Stefan Bethke In-Reply-To: <20111210140540.6301dfa9.ray@freebsd.org> Date: Mon, 2 Jan 2012 14:20:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <865DC2D7-F7EF-4314-8745-19466D2DA83C@lassitu.de> References: <20111210140540.6301dfa9.ray@freebsd.org> To: Aleksandr Rybalko , FreeBSD Net X-Mailer: Apple Mail (2.1084) Cc: Subject: Re: "float PHYs", communication between indirect attached devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 13:20:48 -0000 Am 10.12.2011 um 13:05 schrieb Aleksandr Rybalko: > Hi net@ subscribers, >=20 > Simple explanation of problem:=20 > real situation, device with two NICs (arge0 and arge1) > arge0 attached to PHY w/o direct access to it. > arge1 attached to switch MII port (and have access to MDIO bus). >=20 > switch have child MDIO bus for all Physical ports. > One of this ports (or his PHY) must be controlled by arge0. >=20 > I will do pseudo PHY driver that must communicate with real one on > switch MDIO bus. >=20 > Question: how to communicate, since newbus can't handle two parents: > 1) sysctl > 2) events > 3) kenv > 4) something better > globals is not a solution, because it is possible that we will have > some device with more than one "float PHYs" >=20 > please, help me to find best way! >=20 > Wait for your suggestions, comments, hints, etc. I'll trx to explain with a bit more detail what the situation is, and = what variations we're encountering with the various embedded systems = that have a switch connected to one or more ethernet ports of the SoC. Right now Adrian, Aleksadr and I are trying to add configuration support = for the switch controllers in small WLAN routers based on the various = Atheros SoC and a variety of switch controllers. As different as they = might be, they are usually attached in one of these ways: - the ethernet interface is connected via MII, RGMII or GMII to one of = the MACs on the switch (back to back, no PHY). The switch might have = PHYs attached to its other ports, but as far as the SoC ethernet = interfaces are concerned, there's nothing to be configured. - the interface is connected to a PHY via MII, but the PHYs MDIO slave = is not connected to the ethernet interface's MDIO master. Both can exist at the same time; e.g in many wlan routers, arge0 is = connected to a PHY in the switch chip, while arge1 is connected to one = of the switch port MACs. The switch controller can be connected to the SoC via I2C (e.g. RTL83XX = series), or through an MDIO interface (AR8x16, RTL830x). The switch controller has its own MDIO master, controlled through the = switch register set, to communicate with the built-in PHYs. To further confuse things: the PHY that arge0 is connected to can only = be controlled by talking to the switch that is connected to arge1's MDIO = master, in turn talking to the switch's MDIO master to talk to the PHY. This poses a number of challenges: - ethernet switches that are attached via MDIO may not look like PHYs, = in particular, they might not have a BMSR or ID1 and ID2. This is the = case with the Atheros AR8x16 series. The miibus code assumes that all = possible children of an miibus are PHYs, and will not easily accept = non-PHY children. - attach hierarchy and sequence, e.g. for the PHY in the switch chip, = where the switch chip is attached to arge1, but the PHY needs to be at = arge0. - creating miibus'ses that are not associated with an interface. The = miibus code assumes that any PHY is attached to an MII connected to an = ethernet interfaces MAC. The switch ports are not part of the ethernet = interfaces, and their MAC configuration doesn't change when one of the = switch ports negotiate a different media setting. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Mon Jan 2 21:32:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680DD106564A; Mon, 2 Jan 2012 21:32:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0956C8FC15; Mon, 2 Jan 2012 21:32:43 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so21131283vcb.13 for ; Mon, 02 Jan 2012 13:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rT3UYcYOQztEPx08BX5Hl8OKCO17hXUKr6ztGOpycaQ=; b=HEUO76nFsSBXEhPZ5xFzXzUVNamT8mrkf4HqcqwawT8Ah4dMnLmXTE5/u0w3RIALWX vpVKy4HCyXOy8ARVJlfXJukeM7sm5BkB5BMeOqnFwfgBAIV5DX1InuQnRu9vJvAefBwP 0/b8yVPkStyxqCxPhOV9Plt/Tiuy7UOE4PFOw= MIME-Version: 1.0 Received: by 10.220.148.201 with SMTP id q9mr8694731vcv.33.1325539963267; Mon, 02 Jan 2012 13:32:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Mon, 2 Jan 2012 13:32:43 -0800 (PST) In-Reply-To: <865DC2D7-F7EF-4314-8745-19466D2DA83C@lassitu.de> References: <20111210140540.6301dfa9.ray@freebsd.org> <865DC2D7-F7EF-4314-8745-19466D2DA83C@lassitu.de> Date: Mon, 2 Jan 2012 13:32:43 -0800 X-Google-Sender-Auth: p0SmhPn51pHLnnOLqYvbhBFyR8g Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Aleksandr Rybalko Subject: Re: "float PHYs", communication between indirect attached devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 21:32:44 -0000 Hi, How about ray (or stefan, or someone :) does up a bit of a summary as to how zrouter uses the floatphy and other stuff in the configuration hints to represent all of this? Would we be better off changing the miibus code to work with the notion of non-phy devices? Would that help a bit? Adrian From owner-freebsd-net@FreeBSD.ORG Mon Jan 2 21:33:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74FF1065675; Mon, 2 Jan 2012 21:33:45 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 76E8E8FC16; Mon, 2 Jan 2012 21:33:45 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3AD6746ACB; Mon, 2 Jan 2012 21:33:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Stefan Bethke In-Reply-To: Date: Mon, 2 Jan 2012 22:33:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13EBA7E5-4CB1-477A-B0DB-EC89734189AC@lassitu.de> References: <20111210140540.6301dfa9.ray@freebsd.org> <865DC2D7-F7EF-4314-8745-19466D2DA83C@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko Subject: Re: "float PHYs", communication between indirect attached devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 21:33:45 -0000 Am 02.01.2012 um 22:32 schrieb Adrian Chadd: > Hi, >=20 > How about ray (or stefan, or someone :) does up a bit of a summary as > to how zrouter uses the floatphy and other stuff in the configuration > hints to represent all of this? >=20 > Would we be better off changing the miibus code to work with the > notion of non-phy devices? Would that help a bit? If you wouldn't mind waiting a day or two, I'm working on a suggestion. = First draft RSN=85 Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 03:21:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA9F106564A; Tue, 3 Jan 2012 03:21:28 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E7BF08FC0C; Tue, 3 Jan 2012 03:21:27 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so21370515vbb.13 for ; Mon, 02 Jan 2012 19:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2fEVaeTULYDT0uxBjBC2cvBv4/aKfATi9vdnhVokiZs=; b=blJn0ffL7I9/zTTTvRiBTQhti6FTgw18zMosDn4vRAF3R5ojmrE9C3zD7M0MkLrqzd 441QO+pppakWPc6/h+zrF6+iM7z1OB0mhoB8t2pOzJ7xV9bFOBAUupmvDzTlgG1pssJE KyOG4J2gCZgk/ph0tKhk9BiWJNhoaMYmdXoT8= MIME-Version: 1.0 Received: by 10.52.71.106 with SMTP id t10mr7957505vdu.103.1325559008680; Mon, 02 Jan 2012 18:50:08 -0800 (PST) Received: by 10.52.26.1 with HTTP; Mon, 2 Jan 2012 18:50:08 -0800 (PST) Date: Tue, 3 Jan 2012 10:50:08 +0800 Message-ID: From: suken woo To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, mobile@freebsd.org, net@freebsd.org Subject: DLink DWL-G132 USB wifi Adapter failed under 9.0 RC3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 03:21:28 -0000 hi lists DWL-G132 failed to load on 9.0RC3 uath0: on usbus3 uath0: timeout waiting for reply to cmd 0x4 (4) uath0: could not read capability 3 uath0: could not get device capabilities device_attach: uath0 attach returned 35 and uathload lp# uathload -v -d /dev/ugen3.2 Load firmware ar5523.bin (builtin) to /dev/ugen3.2 send block 0: 151368 bytes remaining : data... : wait for ack... uathload: error reading msg (/dev/usb/3.2.1): No error: 0 usbconfig -u 3 -a 2 dump_device_desc ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x2001 idProduct = 0x3a02 bcdDevice = 0x0001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001 From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 03:53:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 94EF61065670 for ; Tue, 3 Jan 2012 03:53:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5D8FB152385; Tue, 3 Jan 2012 03:53:37 +0000 (UTC) Message-ID: <4F027BC0.1080101@FreeBSD.org> Date: Mon, 02 Jan 2012 19:53:36 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> In-Reply-To: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 03:53:38 -0000 We have a pair of physical FreeBSD systems configured as routers designed to operate in an active/standby CARP configuration. Everything used to work fine, but since an upgrade to 8.2-STABLE on December 29th the two routers don't speak BGP to each other anymore. They both function fine individually, and failover works. It is only the openbgpd communication between them that's not flowing. They have OpenBGPd (openbgpd-4.9.20110612_1 from ports) installed. The active router takes BGP full route feeds from our peers and *should* feed it to the standby router via a direct connection (crossover cable between physical em2 ports). The relative "bgpctl show" reports: 10.0.0.2 12345 0 0 0 Never Active or 10.0.0.2 12345 0 0 0 Never Connect The bgp daemon for the active server periodically reports: bgpd[6773]: neighbor 10.0.0.2: socket error: Operation timed out There is not a connectivity problem between the two hosts; ssh for example works fine. Telnet'ing to the bgp port times out, even from the same machine. There is no firewall configured on that interface. TCP-MD5 is *not* configured on the bgpd side. We did try enabling it (properly) between the two machines via /etc/ipsec.conf to see if it would make a difference, but that also had no effect on this problem. We've tried tcpdump, and both machines can clearly see the TCP SYN and SYN-ACK setup packets flowing in both directions, but the ACK packet never happens. In netstat -an, the opening side gets: tcp4 0 0 10.0.0.2.16797 10.0.0.1.179 SYN_SENT and the receiving side gets: tcp4 0 0 10.0.0.1.179 10.0.0.2.16797 SYN_RCVD Just to make sure pf can't possibly be affecting this, right at the top of pf.conf on both machines: ## Pass inter-router traffic pass quick on em2 from 10.0.0.2 to 10.0.0.1 pass quick on em2 from 10.0.0.1 to 10.0.0.2 This is sufficient because we can connect to bgpd with nc: $ nc -S 10.0.0.2 179 ????????????????-??Z?^w?A?? Produces: $ netstat -an | fgrep 10.0.0.2 tcp4 0 0 10.0.0.1.25711 10.0.0.2.179 ESTABLISHED and $ netstat -an | fgrep 10.0.0.1 tcp4 0 0 10.0.0.2.179 10.0.0.1.25711 ESTABLISHED So this appears to be some sort of weird problem specific to openbgpd and the updated kernel. At this point I'm at a loss as to how to proceed, so any suggestions on how to fix, or even debug this will be greatly appreciated. Doug From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 04:35:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CA09106566C for ; Tue, 3 Jan 2012 04:35:32 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D81EB8FC08 for ; Tue, 3 Jan 2012 04:35:31 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so21400000vbb.13 for ; Mon, 02 Jan 2012 20:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=BqXFeI4hWFgFQoAPCEnectpJaORdjdGwPwe9wAQ4wW8=; b=g5ndIqQCP0FnwJYP34YR1vtD03cTNc98rcalh2wqeJOV4X/TuLxDdvPWXIjVqj5EXN WNYoqvSdKpafDPki8/4WQeQ1O8bqUr2y6DqUFIFYOiVOVxnVwL6Kxv/t1np8litzpSkl WZ162Ashs8m9mnq2vHNnUJWjlPufqvDRC9tRk= MIME-Version: 1.0 Received: by 10.52.72.46 with SMTP id a14mr13269439vdv.125.1325565331043; Mon, 02 Jan 2012 20:35:31 -0800 (PST) Received: by 10.220.108.144 with HTTP; Mon, 2 Jan 2012 20:35:31 -0800 (PST) Date: Mon, 2 Jan 2012 20:35:31 -0800 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Use of spinlocks for TCP callouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 04:35:32 -0000 I have see the following call sequence in profiles: called/total parents index %time self descendents called+self name index called/total children 0.02 1.14 3822699/7559737 tcp_do_segment [154] 0.5 0.03 2.26 7559737 callout_reset_on 2.19 0.02 7573352/94883048 spinlock_exit 0.01 0.04 7573352/11975031 callout_lock It is my perception that spinlocks are expensive. Since general TCP locks are sleep mutexes, would there be any merit in building a TCP callout facility using sleep mutexes? I can hack something up and share here but wanted to check if people know of an existing facility that might be used here? -vijay From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 06:40:12 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D28FF106564A for ; Tue, 3 Jan 2012 06:40:12 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id B454C8FC0A for ; Tue, 3 Jan 2012 06:40:12 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rhy2e-0003Kz-Bm for freebsd-net@FreeBSD.org; Tue, 03 Jan 2012 06:40:12 +0000 Date: Tue, 03 Jan 2012 15:40:11 +0900 Message-ID: From: Randy Bush To: freebsd-net User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: how to debug non-working hole in nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 06:40:12 -0000 FreeBSD gate0.psg.com 8.2-STABLE FreeBSD 8.2-STABLE #8: Sat Dec 24 13:39:45 GMT 2011 root@gate0.psg.com:/usr/obj/usr/src/sys/GATE0 i386 i have a working natd setup and am trying to punch a hole in it for ssh to an internal host. .------------------------------. | | | b --wlan0| | r | 192.168.0.0/24 WAN IIJ | i --- vr1| LAN hosts, PPP/NAT ---|vr0[PPPoE][ppp]tun0--d | DHCP Clients | g --- vr2| ... | e | | 0 --- vr3| | | `------------------------------' i am trying to do it all in /etc/rc.conf, though i am not wedded to doing so. i will append the tasty bits. when tring to ssh in from outside, i get % ssh -p 60022 gate0 < long pause > ssh: connect to host gate0.psg.com port 60022: No route to host i have no problem sshing to the target host from within the LAN % ssh 192.168.0.34 Last login: Tue Jan 3 06:16:07 2012 from 192.168.0.1 tcpdump of bridge0 of the gateway shows nothing except the target host polling dropbox.com occasionally. /etc/ipfw.rules is quite bland, and the rest of the 15 machines on the LAN have no complaints. flush add deny log all from any to any ipoptions ssrr,lsrr,rr add pass all from any to any via lo0 add deny log all from 127.0.0.0/8 to any add deny log all from any to 127.0.0.0/8 add divert natd all from any to any via bridge0 add deny tcp from any to me smtp add 65530 pass all from any to any any clues on how i debug? randy --- hostname=gate0.psg.com firewall_enable=YES firewall_type=/etc/ipfw.rules firewall_quiet=YES firewall_logging=YES ppp_enable=YES ppp_mode=dedicated ppp_profile=iij wlans_ath0="wlan0 wlan1" create_args_wlan0="wlanmode ap mode 11g channel 11 up" cloned_interfaces=bridge0 ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up" ifconfig_vr1=up ifconfig_vr2=up ifconfig_vr3=up hostapd_enable=YES natd_enable=YES natd_interface=bridge0 natd_flags="-redirect_port tcp 192.168.0.34:22 60022" gateway_enable=YES -30- From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 07:07:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D24A106564A for ; Tue, 3 Jan 2012 07:07:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A6E4A8FC0C for ; Tue, 3 Jan 2012 07:07:51 +0000 (UTC) Received: by eekc50 with SMTP id c50so18671853eek.13 for ; Mon, 02 Jan 2012 23:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8oKJPVGfgDAexnq5dgNySBvl3WhS/LnuroLyfcvXGwI=; b=YC/R3Eva6m6Zjo1PW9HWmlDXcAbjVjiLD9SBl22tSp7ajQabCTs/P2W3K00tD7hUGw UcoXmpxTgbKIQpQjld+CYLhV8yru/I/F4Y54qMKdmEvWWH3nU/4RxwywzH1bbgMQhdOg y0HrEQOz9JdTVC93gFlmjr8FPtXi2bymgNL8Q= Received: by 10.213.28.193 with SMTP id n1mr10653377ebc.33.1325574470345; Mon, 02 Jan 2012 23:07:50 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id a60sm201960847eeb.4.2012.01.02.23.07.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 23:07:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: <4F027BC0.1080101@FreeBSD.org> Date: Tue, 3 Jan 2012 09:07:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 07:07:52 -0000 On Jan 3, 2012, at 5:53 AM, Doug Barton wrote: > We have a pair of physical FreeBSD systems configured as routers > designed to operate in an active/standby CARP configuration. = Everything > used to work fine, but since an upgrade to 8.2-STABLE on December 29th > the two routers don't speak BGP to each other anymore. They both > function fine individually, and failover works. It is only the = openbgpd > communication between them that's not flowing. >=20 > They have OpenBGPd (openbgpd-4.9.20110612_1 from ports) installed. = The > active router takes BGP full route feeds from our peers and *should* > feed it to the standby router via a direct connection (crossover cable > between physical em2 ports). >=20 > The relative "bgpctl show" reports: >=20 > 10.0.0.2 12345 0 0 0 Never Active >=20 > or >=20 > 10.0.0.2 12345 0 0 0 Never Connect >=20 > The bgp daemon for the active server periodically reports: >=20 > bgpd[6773]: neighbor 10.0.0.2: socket error: Operation timed out >=20 > There is not a connectivity problem between the two hosts; ssh for > example works fine. Telnet'ing to the bgp port times out, even from = the > same machine. >=20 > There is no firewall configured on that interface. >=20 > TCP-MD5 is *not* configured on the bgpd side. We did try enabling it > (properly) between the two machines via /etc/ipsec.conf to see if it > would make a difference, but that also had no effect on this problem. >=20 > We've tried tcpdump, and both machines can clearly see the TCP SYN and > SYN-ACK setup packets flowing in both directions, but the ACK packet > never happens. In netstat -an, the opening side gets: >=20 > tcp4 0 0 10.0.0.2.16797 10.0.0.1.179 SYN_SENT >=20 > and the receiving side gets: >=20 > tcp4 0 0 10.0.0.1.179 10.0.0.2.16797 SYN_RCVD >=20 > Just to make sure pf can't possibly be affecting this, right at the = top > of pf.conf on both machines: >=20 > ## Pass inter-router traffic > pass quick on em2 from 10.0.0.2 to 10.0.0.1 > pass quick on em2 from 10.0.0.1 to 10.0.0.2 >=20 > This is sufficient because we can connect to bgpd with nc: >=20 > $ nc -S 10.0.0.2 179 > ????????????????-??Z?^w?A?? >=20 > Produces: >=20 > $ netstat -an | fgrep 10.0.0.2 > tcp4 0 0 10.0.0.1.25711 10.0.0.2.179 ESTABLISHED >=20 > and >=20 > $ netstat -an | fgrep 10.0.0.1 > tcp4 0 0 10.0.0.2.179 10.0.0.1.25711 ESTABLISHED >=20 > So this appears to be some sort of weird problem specific to openbgpd > and the updated kernel. >=20 > At this point I'm at a loss as to how to proceed, so any suggestions = on > how to fix, or even debug this will be greatly appreciated. >=20 >=20 > Doug >=20 Since I've had similar problem with Quagga after updating to 8.2-STABLE = I'd suggest you to try setting "net.inet.tcp.signature_verify_input=3D0" and see if = that would help. Here is another thread about the similar (if not the same) problem :=20 = http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/e= a347a919dbc165d/eeaa2965fc4f64c9?show_docid=3Deeaa2965fc4f64c9&pli=3D1 Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 08:00:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FDB6106566B; Tue, 3 Jan 2012 08:00:30 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id D0C4A8FC15; Tue, 3 Jan 2012 08:00:29 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id C099A9DC55A; Tue, 3 Jan 2012 08:43:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> Date: Tue, 3 Jan 2012 08:43:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <225368A1-5BB9-4B20-8D3D-B3F09EBA3602@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> To: Nikolay Denev X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:00:30 -0000 On Jan 3, 2012, at 8:07 AM, Nikolay Denev wrote: >=20 > On Jan 3, 2012, at 5:53 AM, Doug Barton wrote: >=20 >> We have a pair of physical FreeBSD systems configured as routers >> designed to operate in an active/standby CARP configuration. = Everything >> used to work fine, but since an upgrade to 8.2-STABLE on December = 29th >> the two routers don't speak BGP to each other anymore. They both >> function fine individually, and failover works. It is only the = openbgpd >> communication between them that's not flowing. Try compiling a kernel *without* TCP_MD5 and maybe without IPSEC = support. I found out OpenBGPd has a problem. However, Quagga has been = working for me flawlessly. Borja. From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 08:52:54 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B873C106566C for ; Tue, 3 Jan 2012 08:52:54 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A1E1A8FC13 for ; Tue, 3 Jan 2012 08:52:54 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ri074-0003Zn-2o for freebsd-net@FreeBSD.org; Tue, 03 Jan 2012 08:52:54 +0000 Date: Tue, 03 Jan 2012 17:52:53 +0900 Message-ID: From: Randy Bush To: freebsd-net In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: how to debug non-working hole in nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:52:54 -0000 ignore. i sorted it. randy From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 08:53:01 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5595106568D for ; Tue, 3 Jan 2012 08:53:01 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7B78FC1C for ; Tue, 3 Jan 2012 08:53:01 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 3 Jan 2012 03:42:10 -0500 Date: Tue, 3 Jan 2012 02:42:30 -0600 From: "Paul A. Procacci" To: Randy Bush Message-ID: <20120103084230.GC35878@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: how to debug non-working hole in nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:53:02 -0000 > add divert natd all from any to any via bridge0 This nat's all internal traffic on your lan. You probably don't want this.= I'd place the nat on the tun0 interface. Which leads me to.... If you machine receives a syn from the tun0 interface, what firewall rule i= s in place to redirect the packet to the nat instance? I do not see any. ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for= further information on confidentiality and the risks of non-secure electro= nic communication. If you cannot access these links, please notify us by re= ply message and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 09:16:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8661065672; Tue, 3 Jan 2012 09:16:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 53B408FC08; Tue, 3 Jan 2012 09:16:04 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E7D6C46B06; Tue, 3 Jan 2012 04:16:03 -0500 (EST) Date: Tue, 3 Jan 2012 09:16:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <4EFE5E12.7080103@FreeBSD.org> Message-ID: References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> <4ECEE6F0.4010301@FreeBSD.org> <4EFE158C.2040705@FreeBSD.org> <4EFE5B70.9050807@FreeBSD.org> <4EFE5E12.7080103@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:16:04 -0000 On Fri, 30 Dec 2011, Maxim Sobolev wrote: > On 12/30/2011 4:46 PM, Maxim Sobolev wrote: >> I see. Would you guys mind if I put that NULL pointer check into the code >> for the time being and turn it into some kind of big nasty warning in >> 8-stable branch only? > > I could also open a ticket, put all debug information collected to date in > there. And encourage people to report to it once they see this warning on > their system. Then it would provide more information about the exposure. It > is definitely looks like locking issue somewhere, not just bad luck or flaky > hardware, as we see it happening consistently on top 4 most UDP-loaded > systems here, and it correlates well with the load. With my small NULL catch > the machines have been running happily for a month now, so there is no > visible side-effects. Please do file the PR so that all the information is in one place -- this is a network stack hacking week for me, so I should be able to take a closer look. Could you characterise the traffic load on these boxes a bit more? Also, is there regular monitoring using netstat/bsnmp/etc going on? I'd like to try and identify ways in which this workload differs from other common high-UDP workloads being used on 8.x that aren't seeing this problem... Robert From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 15:39:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32FE106564A for ; Tue, 3 Jan 2012 15:39:59 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id A073F8FC12 for ; Tue, 3 Jan 2012 15:39:59 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Tue, 3 Jan 2012 10:29:10 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 4E3FC33C02; Tue, 3 Jan 2012 10:29:10 -0500 (EST) Date: Tue, 3 Jan 2012 10:29:10 -0500 From: Ed Maste To: Nikolay Denev Message-ID: <20120103152909.GA83706@sandvine.com> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, borjam@sarenet.es Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 15:40:00 -0000 On Tue, Jan 03, 2012 at 09:07:56AM +0200, Nikolay Denev wrote: > Since I've had similar problem with Quagga after updating to 8.2-STABLE I'd suggest > you to try setting "net.inet.tcp.signature_verify_input=0" and see if that would help. > > Here is another thread about the similar (if not the same) problem : > http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1 Thanks for the link Nikolay. Borja, I assume it's the PR submission form that gave you trouble - sorry for that. Based on your report it sounds to me like the bug is in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option though I'd assume it's due to a difference in our (FreeBSD's) implementation of the option. Did you look at the OpenBSD/FreeBSD differences in your investigation? -Ed Another related query, where adding the TCP_SIGNATURE option reportedly fixed it: http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234503.html From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 15:42:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C8691065676 for ; Tue, 3 Jan 2012 15:42:07 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id CEDCC8FC12 for ; Tue, 3 Jan 2012 15:42:06 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 4899A9DC53A; Tue, 3 Jan 2012 16:42:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120103152909.GA83706@sandvine.com> Date: Tue, 3 Jan 2012 16:42:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A630554-160A-4A20-B791-6E110D5B9FF4@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 15:42:07 -0000 On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: > On Tue, Jan 03, 2012 at 09:07:56AM +0200, Nikolay Denev wrote: >=20 >> Since I've had similar problem with Quagga after updating to = 8.2-STABLE I'd suggest >> you to try setting "net.inet.tcp.signature_verify_input=3D0" and see = if that would help. >>=20 >> Here is another thread about the similar (if not the same) problem :=20= >> = http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/e= a347a919dbc165d/eeaa2965fc4f64c9?show_docid=3Deeaa2965fc4f64c9&pli=3D1 >=20 > Thanks for the link Nikolay. >=20 > Borja, I assume it's the PR submission form that gave you trouble - > sorry for that. Based on your report it sounds to me like the bug is Yes, I was filling a very detailed report and it was lost. Quite = annoying... > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option > though I'd assume it's due to a difference in our (FreeBSD's) > implementation of the option. Did you look at the OpenBSD/FreeBSD > differences in your investigation? What I saw is that OpenBGPd *sets* the TCP_MD5SIG for the socket just to = test if TCP_MD5 is available. Maybe in OpenBSD the behavior is different = and unless you set the key TCP_MD5 won't be really enabled. In FreeBSD, = the keys are set outside of your program using setkey(8). The second link you mention is simply a configuration problem. Unless = you include TCP_SIGNATURE in the kernel config file, TCP_MD5 support = will not be available. What I observed is this: if you have TCP_MD5 correctly available in the = system, I mean, TCP_SIGNATURE and the rest of the IPSEC support = correctly configured into the kernel, OpenBGPd is unable to work = *without* TCP_MD5. Quagga works, I can use TCP_MD5 or not, my choice.=20 Borja. From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 16:23:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF51106564A for ; Tue, 3 Jan 2012 16:23:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 774138FC08 for ; Tue, 3 Jan 2012 16:23:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2F81A46B0D; Tue, 3 Jan 2012 11:23:50 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 69FA2B960; Tue, 3 Jan 2012 11:23:49 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 3 Jan 2012 10:01:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031001.09004.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 11:23:49 -0500 (EST) Cc: Vijay Singh Subject: Re: Use of spinlocks for TCP callouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:23:50 -0000 On Monday, January 02, 2012 11:35:31 pm Vijay Singh wrote: > I have see the following call sequence in profiles: > > > called/total parents > index %time self descendents called+self name index > called/total children > > 0.02 1.14 3822699/7559737 tcp_do_segment > [154] 0.5 0.03 2.26 7559737 callout_reset_on > 2.19 0.02 7573352/94883048 spinlock_exit > 0.01 0.04 7573352/11975031 callout_lock > > It is my perception that spinlocks are expensive. Since general TCP > locks are sleep mutexes, would there be any merit in building a TCP > callout facility using sleep mutexes? I can hack something up and > share here but wanted to check if people know of an existing facility > that might be used here? The spinlock in question is probably the callout_mtx itself. The problem is that you have to be able to acquire some sort of lock in the timer interrupt to check the timer state to see if a timer thread should be scheduled. That has to be a spin lock. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 16:23:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B9E10656AE; Tue, 3 Jan 2012 16:23:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF84B8FC1E; Tue, 3 Jan 2012 16:23:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5C5B746B0A; Tue, 3 Jan 2012 11:23:53 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C4489B960; Tue, 3 Jan 2012 11:23:52 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Tue, 3 Jan 2012 11:23:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <20111229225539.GD12721@FreeBSD.org> In-Reply-To: <20111229225539.GD12721@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201031123.46973.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 11:23:52 -0500 (EST) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:23:54 -0000 On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote: > On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote: > J> - if_addr_uses.patch This changes callers of the existing macros to use > J> either read or write locks. This is the patch that > J> could use the most review. > > Reviewing your patch I've found several problems not introduced by it, > but already existing, and somewhat related to your patch: > > 1) Unneeded use of _SAFE version of TAILQ: > > igmp.c:3338 > in6.c:1339 > mld6.c:2993 I'll fix these. > 2) Potential race when dropping a lock inside FOREACH loop: > > igmp.c:2058 > mld6.c:1419 > mld6.c:1704 (this one isn't even a SAFE, so would crash earlier) These are not easy to fix. :( Dropping the lock is of course the wrong thing to do. However, there are a few layering violations that make this hard to fix properly. Actually, we might be able to use an approach similar to that used in mld_ifdetach() and igmp_ifdetach() to fix the cancel timers cases. Patch below > 3) I've found that in6_ifawithifp() doesn't do what it is supposed > to, as well as uses incorrect locking during this. As last resort > it should run through global list of addresses, not run throgh the > ifp one again. Patch attached. This looks good to me. Maybe you can get bz@ to review it? Index: netinet/igmp.c =================================================================== --- netinet/igmp.c (revision 229389) +++ netinet/igmp.c (working copy) @@ -2004,7 +2003,7 @@ { struct ifmultiaddr *ifma; struct ifnet *ifp; - struct in_multi *inm; + struct in_multi *inm, *tinm; CTR3(KTR_IGMPV3, "%s: cancel v3 timers on ifp %p(%s)", __func__, igi->igi_ifp, igi->igi_ifp->if_xname); @@ -2050,14 +2049,8 @@ * transition to REPORTING to ensure the host leave * message is sent upstream to the old querier -- * transition to NOT would lose the leave and race. - * - * SMPNG: Must drop and re-acquire IF_ADDR_LOCK - * around inm_release_locked(), as it is not - * a recursive mutex. */ - IF_ADDR_UNLOCK(ifp); - inm_release_locked(inm); - IF_ADDR_LOCK(ifp); + SLIST_INSERT_HEAD(&igi->igi_relinmhead, inm, inm_nrele); /* FALLTHROUGH */ case IGMP_G_QUERY_PENDING_MEMBER: case IGMP_SG_QUERY_PENDING_MEMBER: @@ -2076,6 +2069,10 @@ _IF_DRAIN(&inm->inm_scq); } IF_ADDR_UNLOCK(ifp); + SLIST_FOREACH_SAFE(inm, &igi->igi_relinmhead, inm_nrele, tinm) { + SLIST_REMOVE_HEAD(&igi->igi_relinmhead, inm_nrele); + inm_release_locked(inm); + } } /* Index: netinet6/mld6.c =================================================================== --- netinet6/mld6.c (revision 229389) +++ netinet6/mld6.c (working copy) @@ -1656,7 +1656,7 @@ { struct ifmultiaddr *ifma; struct ifnet *ifp; - struct in6_multi *inm; + struct in6_multi *inm, *tinm; CTR3(KTR_MLD, "%s: cancel v2 timers on ifp %p(%s)", __func__, mli->mli_ifp, mli->mli_ifp->if_xname); @@ -1695,14 +1695,9 @@ * If we are leaving the group and switching * version, we need to release the final * reference held for issuing the INCLUDE {}. - * - * SMPNG: Must drop and re-acquire IF_ADDR_LOCK - * around in6m_release_locked(), as it is not - * a recursive mutex. */ - IF_ADDR_UNLOCK(ifp); - in6m_release_locked(inm); - IF_ADDR_LOCK(ifp); + SLIST_INSERT_HEAD(&mli->mli_relinmhead, inm, + in6m_nrele); /* FALLTHROUGH */ case MLD_G_QUERY_PENDING_MEMBER: case MLD_SG_QUERY_PENDING_MEMBER: @@ -1720,6 +1715,10 @@ } } IF_ADDR_UNLOCK(ifp); + SLIST_FOREACH_SAFE(inm, &mli->mli_relinmhead, in6m_nrele, tinm) { + SLIST_REMOVE_HEAD(&mli->mli_relinmhead, in6m_nrele); + in6m_release_locked(inm); + } } /* -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 16:57:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664241065672 for ; Tue, 3 Jan 2012 16:57:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id CE32F8FC13 for ; Tue, 3 Jan 2012 16:57:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q03GJDQK015228; Wed, 4 Jan 2012 03:19:14 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 4 Jan 2012 03:19:13 +1100 (EST) From: Ian Smith To: Randy Bush In-Reply-To: Message-ID: <20120104031114.N8995@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net Subject: Re: how to debug non-working hole in nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:57:38 -0000 On Tue, 3 Jan 2012 17:52:53 +0900, Randy Bush wrote: > ignore. i sorted it. Too late, sucked in .. diff from prior config might be bone enough? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 17:35:36 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF76B106566B; Tue, 3 Jan 2012 17:35:36 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC108FC14; Tue, 3 Jan 2012 17:35:36 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 496A225D3892; Tue, 3 Jan 2012 17:35:35 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 7C7DDBD8664; Tue, 3 Jan 2012 17:35:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ziakJtyvM7bK; Tue, 3 Jan 2012 17:35:33 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 32DE0BD8662; Tue, 3 Jan 2012 17:35:33 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201112231508.52861.jhb@freebsd.org> Date: Tue, 3 Jan 2012 17:35:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201112231508.52861.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:35:36 -0000 On 23. Dec 2011, at 20:08 , John Baldwin wrote: > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in=20 > in6_lifaddr_ioctl() does not grab a reference to an ifnet address = structure=20 > that it uses after dropping the IF_ADDR_LOCK(). Based on other code = that uses=20 > a similar pattern of finding an ifa while under the lock and then = using it=20 > after dropping the lock, I believe it should be acquiring a reference = on the=20 > ifa and then dropping that reference when it is done using the ifa. = This=20 > (untested) patch should fix this I believe: I almost assume it's been tested by now. =46rom reading it looks right. /bz > Index: in6.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- in6.c (revision 228777) > +++ in6.c (working copy) > @@ -1767,6 +1767,8 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, = c > if (IN6_ARE_ADDR_EQUAL(&candidate, &match)) > break; > } > + if (ifa !=3D NULL) > + ifa_ref(ifa); > IF_ADDR_UNLOCK(ifp); > if (!ifa) > return EADDRNOTAVAIL; > @@ -1779,16 +1781,20 @@ in6_lifaddr_ioctl(struct socket *so, u_long = cmd, c > bcopy(&ia->ia_addr, &iflr->addr, = ia->ia_addr.sin6_len); > error =3D sa6_recoverscope( > (struct sockaddr_in6 *)&iflr->addr); > - if (error !=3D 0) > + if (error !=3D 0) { > + ifa_free(ifa); > return (error); > + } >=20 > if ((ifp->if_flags & IFF_POINTOPOINT) !=3D 0) { > bcopy(&ia->ia_dstaddr, &iflr->dstaddr, > ia->ia_dstaddr.sin6_len); > error =3D sa6_recoverscope( > (struct sockaddr_in6 = *)&iflr->dstaddr); > - if (error !=3D 0) > + if (error !=3D 0) { > + ifa_free(ifa); > return (error); > + } > } else > bzero(&iflr->dstaddr, = sizeof(iflr->dstaddr)); >=20 > @@ -1796,6 +1802,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, = c > in6_mask2len(&ia->ia_prefixmask.sin6_addr, = NULL); >=20 > iflr->flags =3D ia->ia6_flags; /* XXX */ > + ifa_free(ifa); >=20 > return 0; > } else { > @@ -1819,6 +1826,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, = c > ia->ia_prefixmask.sin6_len); >=20 > ifra.ifra_flags =3D ia->ia6_flags; > + ifa_free(ifa); > return in6_control(so, SIOCDIFADDR_IN6, = (caddr_t)&ifra, > ifp, td); > } >=20 >=20 > --=20 > John Baldwin --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 17:47:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 191EE106564A; Tue, 3 Jan 2012 17:47:39 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id CD8EA8FC13; Tue, 3 Jan 2012 17:47:38 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 1CE479DC522; Tue, 3 Jan 2012 18:47:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120103152909.GA83706@sandvine.com> Date: Tue, 3 Jan 2012 18:47:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:47:39 -0000 On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: > Thanks for the link Nikolay. >=20 > Borja, I assume it's the PR submission form that gave you trouble - > sorry for that. Based on your report it sounds to me like the bug is > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option > though I'd assume it's due to a difference in our (FreeBSD's) > implementation of the option. Did you look at the OpenBSD/FreeBSD > differences in your investigation? Both bird and quagga work as expected on FreeBSD. You can leave TCP_MD5 = enabled in the kernel. If you specify "password" options for a BGP peer, = it will enable TCP_MD5. Of course in FreeBSD it's a bit clumsy and you = have to use setkey(8) to set the keys. But it works. Borja. From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 18:03:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F5431065676; Tue, 3 Jan 2012 18:03:57 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 2292C8FC16; Tue, 3 Jan 2012 18:03:57 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 236D225D3892; Tue, 3 Jan 2012 18:03:56 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 518E8BD866A; Tue, 3 Jan 2012 18:03:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id VIub6QdgBB00; Tue, 3 Jan 2012 18:03:54 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 01BE0BD8669; Tue, 3 Jan 2012 18:03:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> Date: Tue, 3 Jan 2012 18:03:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> To: Borja Marcos X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , Ed Maste , freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:03:57 -0000 On 3. Jan 2012, at 17:47 , Borja Marcos wrote: >=20 > On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: >=20 >> Thanks for the link Nikolay. >>=20 >> Borja, I assume it's the PR submission form that gave you trouble - >> sorry for that. Based on your report it sounds to me like the bug is >> in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG = option >> though I'd assume it's due to a difference in our (FreeBSD's) >> implementation of the option. Did you look at the OpenBSD/FreeBSD >> differences in your investigation? >=20 > Both bird and quagga work as expected on FreeBSD. You can leave = TCP_MD5 enabled in the kernel. If you specify "password" options for a = BGP peer, it will enable TCP_MD5. Of course in FreeBSD it's a bit clumsy = and you have to use setkey(8) to set the keys. But it works. The reason for setkey is just because the software (quagga, bird,...) = didn't grow a proper key management integration on pfkey2. Would be = easy. Might be needed soon anyway;-) Not having looked at the particular openbgpd patches in our ports tree I = would almost expect there can only be a minor issue that it would stop = to work for non-protected peers once MD5 support is present in the = kernel and that should be easy to spot. Unfortunately Doug didn't say from where he updated to this December = 8-STABLE to see if it could be the MFCs of the MD5 changes by Attilio = could make OpenBGPd as in ports cranky? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 18:53:39 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47262106566B; Tue, 3 Jan 2012 18:53:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9E58FC1A; Tue, 3 Jan 2012 18:53:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id B300646B0D; Tue, 3 Jan 2012 13:53:38 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 47EA6B944; Tue, 3 Jan 2012 13:53:38 -0500 (EST) From: John Baldwin To: "Bjoern A. Zeeb" Date: Tue, 3 Jan 2012 13:52:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231508.52861.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031352.45069.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 13:53:38 -0500 (EST) Cc: net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:53:39 -0000 On Tuesday, January 03, 2012 12:35:30 pm Bjoern A. Zeeb wrote: > > On 23. Dec 2011, at 20:08 , John Baldwin wrote: > > > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in > > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure > > that it uses after dropping the IF_ADDR_LOCK(). Based on other code that uses > > a similar pattern of finding an ifa while under the lock and then using it > > after dropping the lock, I believe it should be acquiring a reference on the > > ifa and then dropping that reference when it is done using the ifa. This > > (untested) patch should fix this I believe: > > I almost assume it's been tested by now. From reading it looks right. Hmm, I don't have a good way to test it. :( I've booted a GENERIC kernel with it, but I don't have IPv6 setup for my test machines. > /bz > > > Index: in6.c > > =================================================================== > > --- in6.c (revision 228777) > > +++ in6.c (working copy) > > @@ -1767,6 +1767,8 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > > if (IN6_ARE_ADDR_EQUAL(&candidate, &match)) > > break; > > } > > + if (ifa != NULL) > > + ifa_ref(ifa); > > IF_ADDR_UNLOCK(ifp); > > if (!ifa) > > return EADDRNOTAVAIL; > > @@ -1779,16 +1781,20 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > > bcopy(&ia->ia_addr, &iflr->addr, ia->ia_addr.sin6_len); > > error = sa6_recoverscope( > > (struct sockaddr_in6 *)&iflr->addr); > > - if (error != 0) > > + if (error != 0) { > > + ifa_free(ifa); > > return (error); > > + } > > > > if ((ifp->if_flags & IFF_POINTOPOINT) != 0) { > > bcopy(&ia->ia_dstaddr, &iflr->dstaddr, > > ia->ia_dstaddr.sin6_len); > > error = sa6_recoverscope( > > (struct sockaddr_in6 *)&iflr->dstaddr); > > - if (error != 0) > > + if (error != 0) { > > + ifa_free(ifa); > > return (error); > > + } > > } else > > bzero(&iflr->dstaddr, sizeof(iflr->dstaddr)); > > > > @@ -1796,6 +1802,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > > in6_mask2len(&ia->ia_prefixmask.sin6_addr, NULL); > > > > iflr->flags = ia->ia6_flags; /* XXX */ > > + ifa_free(ifa); > > > > return 0; > > } else { > > @@ -1819,6 +1826,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > > ia->ia_prefixmask.sin6_len); > > > > ifra.ifra_flags = ia->ia6_flags; > > + ifa_free(ifa); > > return in6_control(so, SIOCDIFADDR_IN6, (caddr_t)&ifra, > > ifp, td); > > } > > > > > > -- > > John Baldwin > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:01:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D830D1065676; Tue, 3 Jan 2012 19:01:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6954A14EF46; Tue, 3 Jan 2012 19:00:56 +0000 (UTC) Message-ID: <4F035067.30609@FreeBSD.org> Date: Tue, 03 Jan 2012 11:00:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> In-Reply-To: <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:01:25 -0000 On 01/03/2012 10:03, Bjoern A. Zeeb wrote: > > On 3. Jan 2012, at 17:47 , Borja Marcos wrote: > >> >> On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: >> >>> Thanks for the link Nikolay. >>> >>> Borja, I assume it's the PR submission form that gave you trouble - >>> sorry for that. Based on your report it sounds to me like the bug is >>> in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option >>> though I'd assume it's due to a difference in our (FreeBSD's) >>> implementation of the option. Did you look at the OpenBSD/FreeBSD >>> differences in your investigation? >> >> Both bird and quagga work as expected on FreeBSD. You can leave TCP_MD5 enabled in the kernel. If you specify "password" options for a BGP peer, it will enable TCP_MD5. Of course in FreeBSD it's a bit clumsy and you have to use setkey(8) to set the keys. But it works. > > The reason for setkey is just because the software (quagga, bird,...) didn't grow a proper key management integration on pfkey2. Would be easy. Might be needed soon anyway;-) > > Not having looked at the particular openbgpd patches in our ports tree I would almost expect there can only be a minor issue that it would stop to work for non-protected peers once MD5 support is present in the kernel and that should be easy to spot. > > Unfortunately Doug didn't say from where he updated to this December 8-STABLE to see if it could be the MFCs of the MD5 changes by Attilio could make OpenBGPd as in ports cranky? I mentioned December 29, sorry if that wasn't explicit enough, I didn't have the svn revision close to hand. Is r226260 the MFC that you're referring to? The log says, "Skip TCP_SIGNATURE calculation for INP_TIMEWAIT case." If so, that happened in October so we're well past that in our version of -stable. I'll be working on the various suggestions (thanks everyone for them, most helpful!) and report back on what works. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:07:12 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9059D1065670; Tue, 3 Jan 2012 19:07:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA8568FC1E; Tue, 3 Jan 2012 19:07:11 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q03J6wqS049780; Wed, 4 Jan 2012 04:07:08 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q03J6tTY082722; Wed, 4 Jan 2012 04:06:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 04:06:11 +0900 (JST) Message-Id: <20120104.040611.1847309275485655567.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <4F027BC0.1080101@FreeBSD.org> References: <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jan__4_04_06_11_2012_717)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 04:07:09 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: ndenev@gmail.com, emaste@FreeBSD.org, borjam@sarenet.es, freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:07:12 -0000 ----Security_Multipart(Wed_Jan__4_04_06_11_2012_717)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F027BC0.1080101@FreeBSD.org>: do> We have a pair of physical FreeBSD systems configured as routers do> designed to operate in an active/standby CARP configuration. Everything do> used to work fine, but since an upgrade to 8.2-STABLE on December 29th do> the two routers don't speak BGP to each other anymore. They both do> function fine individually, and failover works. It is only the openbgpd do> communication between them that's not flowing. Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG option on the listening sockets. [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff While this is an ugly hack and I will investigate more reasonable solution for that, I want to narrow down the cause first. Can anyone who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if this works or not? -- Hiroki ----Security_Multipart(Wed_Jan__4_04_06_11_2012_717)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8DUaMACgkQTyzT2CeTzy0giACfSkwnqscci6nP71yC7Jwi+QHa BVYAoKl5IiyjZW96saGtXe2OM2RFuUKm =P7eV -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jan__4_04_06_11_2012_717)---- From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:16:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50034106564A; Tue, 3 Jan 2012 19:16:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id F0DBD8FC12; Tue, 3 Jan 2012 19:16:18 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id E604A25D3811; Tue, 3 Jan 2012 19:16:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C9392BD8676; Tue, 3 Jan 2012 19:16:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NdzuNyjgfCdK; Tue, 3 Jan 2012 19:16:15 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 530E8BD8679; Tue, 3 Jan 2012 19:16:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F035067.30609@FreeBSD.org> Date: Tue, 3 Jan 2012 19:16:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <245C4A7C-3E63-4587-AAF3-840F67212D47@lists.zabbadoz.net> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <4F035067.30609@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: attilio@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:16:19 -0000 On 3. Jan 2012, at 19:00 , Doug Barton wrote: > On 01/03/2012 10:03, Bjoern A. Zeeb wrote: >>=20 >> On 3. Jan 2012, at 17:47 , Borja Marcos wrote: >>=20 >>>=20 >>> On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: >>>=20 >>>> Thanks for the link Nikolay. >>>>=20 >>>> Borja, I assume it's the PR submission form that gave you trouble - >>>> sorry for that. Based on your report it sounds to me like the bug = is >>>> in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG = option >>>> though I'd assume it's due to a difference in our (FreeBSD's) >>>> implementation of the option. Did you look at the OpenBSD/FreeBSD >>>> differences in your investigation? >>>=20 >>> Both bird and quagga work as expected on FreeBSD. You can leave = TCP_MD5 enabled in the kernel. If you specify "password" options for a = BGP peer, it will enable TCP_MD5. Of course in FreeBSD it's a bit clumsy = and you have to use setkey(8) to set the keys. But it works. >>=20 >> The reason for setkey is just because the software (quagga, bird,...) = didn't grow a proper key management integration on pfkey2. Would be = easy. Might be needed soon anyway;-) >>=20 >> Not having looked at the particular openbgpd patches in our ports = tree I would almost expect there can only be a minor issue that it would = stop to work for non-protected peers once MD5 support is present in the = kernel and that should be easy to spot. >>=20 >> Unfortunately Doug didn't say from where he updated to this December = 8-STABLE to see if it could be the MFCs of the MD5 changes by Attilio = could make OpenBGPd as in ports cranky? >=20 > I mentioned December 29, sorry if that wasn't explicit enough, I = didn't > have the svn revision close to hand. >=20 > Is r226260 the MFC that you're referring to? The log says, "Skip > TCP_SIGNATURE calculation for INP_TIMEWAIT case." If so, that happened > in October so we're well past that in our version of -stable. >=20 > I'll be working on the various suggestions (thanks everyone for them, > most helpful!) and report back on what works. I was wondering from *where* you were updating, not to which revision. I.e. was it an 8.2-RELEASE you were coming from or something earlier? --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:25:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 883B4106566C; Tue, 3 Jan 2012 19:25:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 44D7F14DACA; Tue, 3 Jan 2012 19:25:36 +0000 (UTC) Message-ID: <4F03562F.4070106@FreeBSD.org> Date: Tue, 03 Jan 2012 11:25:35 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <4F035067.30609@FreeBSD.org> <245C4A7C-3E63-4587-AAF3-840F67212D47@lists.zabbadoz.net> In-Reply-To: <245C4A7C-3E63-4587-AAF3-840F67212D47@lists.zabbadoz.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:25:37 -0000 On 01/03/2012 11:16, Bjoern A. Zeeb wrote: > I was wondering from *where* you were updating, not to which revision. D'oh! Sorry ... the previous kernel was from stable/8 about 6 months ago. Well before Attilio's merge. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:36:11 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56CB106566C for ; Tue, 3 Jan 2012 19:36:11 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 14C078FC18 for ; Tue, 3 Jan 2012 19:36:10 +0000 (UTC) Received: (qmail 82207 invoked from network); 3 Jan 2012 19:36:08 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 3 Jan 2012 19:36:08 -0000 Date: Tue, 03 Jan 2012 20:36:08 +0100 (CET) Message-Id: <20120103.203608.74677765.sthaug@nethelp.no> To: hrs@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <20120104.040611.1847309275485655567.hrs@allbsd.org> References: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ndenev@gmail.com, dougb@FreeBSD.org, emaste@FreeBSD.org, borjam@sarenet.es, freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:36:11 -0000 > Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for > net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG > option on the listening sockets. > > [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff > > While this is an ugly hack and I will investigate more reasonable > solution for that, I want to narrow down the cause first. Can anyone > who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if > this works or not? 8-STABLE on several servers, csup'ed only a couple of days ago, with options TCP_SIGNATURE options IPSEC device crypto device cryptodev and Quagga bgpd talking to Juniper M/MX routers using MD5 key on the BGP sessions. No problems. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 19:36:26 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5314E106566B; Tue, 3 Jan 2012 19:36:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 020828FC0A; Tue, 3 Jan 2012 19:36:25 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so19162373obb.13 for ; Tue, 03 Jan 2012 11:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a8ZEoAlLi7dHwuCXefoc/AcGmHtWHbPr9fepw0dvkdU=; b=rKcNs1Ah2f5E3Ec1TPg8n3HdSImJDUXov+7hGZfY5cMikN5ZjYLPOmW3E9nuWrLoxM fUOQ2l8wRGrYncFAbTINv033zRQGOHaNOybXKwO37NP1NoUpJ4TPCsgd6wKYkd0vsjki ju1SZKs/y9wigL96gZodWF5fyEgnhdebhdt9w= MIME-Version: 1.0 Received: by 10.182.45.102 with SMTP id l6mr46060874obm.0.1325619385543; Tue, 03 Jan 2012 11:36:25 -0800 (PST) Sender: pluknet@gmail.com Received: by 10.182.171.67 with HTTP; Tue, 3 Jan 2012 11:36:25 -0800 (PST) In-Reply-To: <201112231508.52861.jhb@freebsd.org> References: <201112231508.52861.jhb@freebsd.org> Date: Tue, 3 Jan 2012 22:36:25 +0300 X-Google-Sender-Auth: u3E2DURq3QNvbebMsNqjwdc0cVg Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:36:26 -0000 On 24 December 2011 00:08, John Baldwin wrote: > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structu= re > that it uses after dropping the IF_ADDR_LOCK(). =A0Based on other code th= at uses > a similar pattern of finding an ifa while under the lock and then using i= t > after dropping the lock, I believe it should be acquiring a reference on = the > ifa and then dropping that reference when it is done using the ifa. =A0Th= is > (untested) patch should fix this I believe: [Some thoughts on this.] FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which uses an unreferenced ifa. Even when ifa reference is acquired, does this protect ifa internals from concurrent changes? I would additionally lock ifa to serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pair exists to lock ifa with ifa_mtx. But there is only one place where such locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced in 2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr reference counts. Two years later ifa_mtx started to be used explicitly in one place to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed in favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free(), and now as said in r194602: "The ifa_mtx is now used for exactly one ioctl, and possibly should be removed." Now I'm losing the chain, sorry.. > Index: in6.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- in6.c =A0 =A0 =A0 (revision 228777) > +++ in6.c =A0 =A0 =A0 (working copy) > @@ -1767,6 +1767,8 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (IN6_ARE_ADDR_EQUAL(&ca= ndidate, &match)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ifa !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_ref(ifa); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF_ADDR_UNLOCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!ifa) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return EADDRNOTAVAIL; > @@ -1779,16 +1781,20 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, = c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy(&ia->ia_addr, &iflr-= >addr, ia->ia_addr.sin6_len); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D sa6_recoverscope= ( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(struct sockaddr_i= n6 *)&iflr->addr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error !=3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error !=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_free(if= a); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (er= ror); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ifp->if_flags & IFF_P= OINTOPOINT) !=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy(&ia-= >ia_dstaddr, &iflr->dstaddr, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ia= ->ia_dstaddr.sin6_len); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D = sa6_recoverscope( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(s= truct sockaddr_in6 *)&iflr->dstaddr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error != =3D 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error != =3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ifa_free(ifa); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0return (error); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bzero(&ifl= r->dstaddr, sizeof(iflr->dstaddr)); > > @@ -1796,6 +1802,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in6_mask2len(&ia->= ia_prefixmask.sin6_addr, NULL); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0iflr->flags =3D ia->ia6_fl= ags; =A0 =A0/* XXX */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_free(ifa); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > @@ -1819,6 +1826,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ia->ia_prefixmask.= sin6_len); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifra.ifra_flags =3D ia->ia= 6_flags; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_free(ifa); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return in6_control(so, SIO= CDIFADDR_IN6, (caddr_t)&ifra, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifp, td); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 20:06:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EA31065670; Tue, 3 Jan 2012 20:06:30 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id DDC808FC0C; Tue, 3 Jan 2012 20:06:29 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8D25925D385D; Tue, 3 Jan 2012 20:06:28 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B70BFBD8682; Tue, 3 Jan 2012 20:06:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 3oTE4JI-63YH; Tue, 3 Jan 2012 20:06:25 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B4851BD8681; Tue, 3 Jan 2012 20:06:25 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201031123.46973.jhb@freebsd.org> Date: Tue, 3 Jan 2012 20:06:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <084220A8-F373-4344-9C9A-E0907C926CC0@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <20111229225539.GD12721@FreeBSD.org> <201201031123.46973.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:06:30 -0000 On 3. Jan 2012, at 16:23 , John Baldwin wrote: > On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote: >> On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote: >> J> - if_addr_uses.patch This changes callers of the existing = macros to use >> J> either read or write locks. This is the = patch that >> J> could use the most review. >>=20 >> Reviewing your patch I've found several problems not introduced by = it, >> but already existing, and somewhat related to your patch: >>=20 >> 1) Unneeded use of _SAFE version of TAILQ: >>=20 >> igmp.c:3338 >> in6.c:1339 >> mld6.c:2993 >=20 > I'll fix these. >=20 >> 2) Potential race when dropping a lock inside FOREACH loop: >>=20 >> igmp.c:2058 >> mld6.c:1419 >> mld6.c:1704 (this one isn't even a SAFE, so would crash earlier) >=20 > These are not easy to fix. :( Dropping the lock is of course the > wrong thing to do. However, there are a few layering violations that > make this hard to fix properly. Actually, we might be able to use > an approach similar to that used in mld_ifdetach() and igmp_ifdetach() > to fix the cancel timers cases. Patch below >=20 >> 3) I've found that in6_ifawithifp() doesn't do what it is supposed >> to, as well as uses incorrect locking during this. As last resort >> it should run through global list of addresses, not run throgh the >> ifp one again. Patch attached. >=20 > This looks good to me. Maybe you can get bz@ to review it? Will look at that one next. The two below seem fine. Would have loved the lock assertions that the mld6 one has on igmp as well but that's a different (unrelated) story:-) /bz > Index: netinet/igmp.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- netinet/igmp.c (revision 229389) > +++ netinet/igmp.c (working copy) > @@ -2004,7 +2003,7 @@ > { > struct ifmultiaddr *ifma; > struct ifnet *ifp; > - struct in_multi *inm; > + struct in_multi *inm, *tinm; >=20 > CTR3(KTR_IGMPV3, "%s: cancel v3 timers on ifp %p(%s)", __func__, > igi->igi_ifp, igi->igi_ifp->if_xname); > @@ -2050,14 +2049,8 @@ > * transition to REPORTING to ensure the host = leave > * message is sent upstream to the old querier = -- > * transition to NOT would lose the leave and = race. > - * > - * SMPNG: Must drop and re-acquire IF_ADDR_LOCK > - * around inm_release_locked(), as it is not > - * a recursive mutex. > */ > - IF_ADDR_UNLOCK(ifp); > - inm_release_locked(inm); > - IF_ADDR_LOCK(ifp); > + SLIST_INSERT_HEAD(&igi->igi_relinmhead, inm, = inm_nrele); > /* FALLTHROUGH */ > case IGMP_G_QUERY_PENDING_MEMBER: > case IGMP_SG_QUERY_PENDING_MEMBER: > @@ -2076,6 +2069,10 @@ > _IF_DRAIN(&inm->inm_scq); > } > IF_ADDR_UNLOCK(ifp); > + SLIST_FOREACH_SAFE(inm, &igi->igi_relinmhead, inm_nrele, tinm) { > + SLIST_REMOVE_HEAD(&igi->igi_relinmhead, inm_nrele); > + inm_release_locked(inm); > + } > } >=20 > /* > Index: netinet6/mld6.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- netinet6/mld6.c (revision 229389) > +++ netinet6/mld6.c (working copy) > @@ -1656,7 +1656,7 @@ > { > struct ifmultiaddr *ifma; > struct ifnet *ifp; > - struct in6_multi *inm; > + struct in6_multi *inm, *tinm; >=20 > CTR3(KTR_MLD, "%s: cancel v2 timers on ifp %p(%s)", __func__, > mli->mli_ifp, mli->mli_ifp->if_xname); > @@ -1695,14 +1695,9 @@ > * If we are leaving the group and switching > * version, we need to release the final > * reference held for issuing the INCLUDE {}. > - * > - * SMPNG: Must drop and re-acquire IF_ADDR_LOCK > - * around in6m_release_locked(), as it is not > - * a recursive mutex. > */ > - IF_ADDR_UNLOCK(ifp); > - in6m_release_locked(inm); > - IF_ADDR_LOCK(ifp); > + SLIST_INSERT_HEAD(&mli->mli_relinmhead, inm, > + in6m_nrele); > /* FALLTHROUGH */ > case MLD_G_QUERY_PENDING_MEMBER: > case MLD_SG_QUERY_PENDING_MEMBER: > @@ -1720,6 +1715,10 @@ > } > } > IF_ADDR_UNLOCK(ifp); > + SLIST_FOREACH_SAFE(inm, &mli->mli_relinmhead, in6m_nrele, tinm) = { > + SLIST_REMOVE_HEAD(&mli->mli_relinmhead, in6m_nrele); > + in6m_release_locked(inm); > + } > } >=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" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 20:17:38 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BC3106566C; Tue, 3 Jan 2012 20:17:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 50E328FC18; Tue, 3 Jan 2012 20:17:38 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id BE72B46B0C; Tue, 3 Jan 2012 15:17:37 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 482E3B922; Tue, 3 Jan 2012 15:17:37 -0500 (EST) From: John Baldwin To: Sergey Kandaurov Date: Tue, 3 Jan 2012 15:17:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231508.52861.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031517.36251.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 15:17:37 -0500 (EST) Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:17:38 -0000 On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote: > On 24 December 2011 00:08, John Baldwin wrote: > > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in > > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure > > that it uses after dropping the IF_ADDR_LOCK(). Based on other code that uses > > a similar pattern of finding an ifa while under the lock and then using it > > after dropping the lock, I believe it should be acquiring a reference on the > > ifa and then dropping that reference when it is done using the ifa. This > > (untested) patch should fix this I believe: > > [Some thoughts on this.] > > FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which uses > an unreferenced ifa. Even when ifa reference is acquired, does this protect > ifa internals from concurrent changes? I would additionally lock ifa to > serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pair > exists to lock ifa with ifa_mtx. But there is only one place where such > locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced in > 2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr reference > counts. Two years later ifa_mtx started to be used explicitly in one place > to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed in > favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free(), > and now as said in r194602: "The ifa_mtx is now used for exactly one ioctl, > and possibly should be removed." > > Now I'm losing the chain, sorry.. Hmm, I'm not sure if ifa objects become immutable or not once they are referenced in the list. Other places in the code seem to use the ifa without locking it though, merely obtaining a reference. The in.c code doesn't even grab the IF_ADDR_LOCK(). :( The below patch should fix that and add the same fix as done to the in6.c code. Index: in.c =================================================================== --- in.c (revision 229406) +++ in.c (working copy) @@ -784,6 +784,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca } } + IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != AF_INET6) continue; @@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca if (candidate.s_addr == match.s_addr) break; } + if (ifa != NULL) + ifa_ref(ifa); + IF_ADDR_UNLOCK(ifp); if (ifa == NULL) return (EADDRNOTAVAIL); ia = (struct in_ifaddr *)ifa; @@ -812,6 +816,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca in_mask2len(&ia->ia_sockmask.sin_addr); iflr->flags = 0; /*XXX*/ + ifa_free(ifa); return (0); } else { @@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca } bcopy(&ia->ia_sockmask, &ifra.ifra_dstaddr, ia->ia_sockmask.sin_len); + ifa_free(ifa); return (in_control(so, SIOCDIFADDR, (caddr_t)&ifra, ifp, td)); -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 20:44:51 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67ADA106564A; Tue, 3 Jan 2012 20:44:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14BD58FC1C; Tue, 3 Jan 2012 20:44:50 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so19261492obb.13 for ; Tue, 03 Jan 2012 12:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=apUZyQFi7WQAwmxNTnKaD8RiMhDd6d+PFotOHaS+rdY=; b=RtEG9xAGnHQ/BK8W90O5w2yqlBjT6VvHEU/PmHxRpDw/DqKjzw+d7iAAie6hZo7jBj 5R230Z820UkqheLvb2D8TGmj38hVsiIeZh9lwrS/fYWNwa7fay10CCXxoq9rOF6mcagt n3CAJuxaaGoBiD5hmg1OgV5z34dmC2mlvGXw8= MIME-Version: 1.0 Received: by 10.182.117.97 with SMTP id kd1mr19706642obb.50.1325623490543; Tue, 03 Jan 2012 12:44:50 -0800 (PST) Sender: pluknet@gmail.com Received: by 10.182.171.67 with HTTP; Tue, 3 Jan 2012 12:44:50 -0800 (PST) In-Reply-To: <201201031517.36251.jhb@freebsd.org> References: <201112231508.52861.jhb@freebsd.org> <201201031517.36251.jhb@freebsd.org> Date: Tue, 3 Jan 2012 23:44:50 +0300 X-Google-Sender-Auth: 7HkS5KXwzhXMpEgly1XF-TPGDa4 Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:44:51 -0000 On 4 January 2012 00:17, John Baldwin wrote: > On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote: >> On 24 December 2011 00:08, John Baldwin wrote: >> > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in >> > in6_lifaddr_ioctl() does not grab a reference to an ifnet address stru= cture >> > that it uses after dropping the IF_ADDR_LOCK(). =A0Based on other code= that uses >> > a similar pattern of finding an ifa while under the lock and then usin= g it >> > after dropping the lock, I believe it should be acquiring a reference = on the >> > ifa and then dropping that reference when it is done using the ifa. = =A0This >> > (untested) patch should fix this I believe: >> >> [Some thoughts on this.] >> >> FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which us= es >> an unreferenced ifa. Even when ifa reference is acquired, does this prot= ect >> ifa internals from concurrent changes? I would additionally lock ifa to >> serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pai= r >> exists to lock ifa with ifa_mtx. But there is only one place where such >> locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced = in >> 2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr referen= ce >> counts. Two years later ifa_mtx started to be used explicitly in one pla= ce >> to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed = in >> favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free()= , >> and now as said in r194602: "The ifa_mtx is now used for exactly one ioc= tl, >> and possibly should be removed." >> >> Now I'm losing the chain, sorry.. > > Hmm, I'm not sure if ifa objects become immutable or not once they are > referenced in the list. =A0Other places in the code seem to use the ifa > without locking it though, merely obtaining a reference. Yes, this is a main concern. > The in.c code doesn't even grab the IF_ADDR_LOCK(). :( =A0The below patch > should fix that and add the same fix as done to the in6.c code. > > Index: in.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- in.c =A0 =A0 =A0 =A0(revision 229406) > +++ in.c =A0 =A0 =A0 =A0(working copy) > @@ -784,6 +784,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_LOCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_= link) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ifa->ifa_addr->sa_fami= ly !=3D AF_INET6) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > @@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (candidate.s_addr =3D= =3D match.s_addr) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ifa !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_ref(ifa); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_UNLOCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ifa =3D=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EADDRNOTAVAIL); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ia =3D (struct in_ifaddr *)ifa; > @@ -812,6 +816,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in_mask2le= n(&ia->ia_sockmask.sin_addr); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0iflr->flags =3D 0; =A0 =A0= =A0 =A0/*XXX*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_free(ifa); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > @@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcopy(&ia->ia_sockmask, &i= fra.ifra_dstaddr, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ia->ia_soc= kmask.sin_len); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifa_free(ifa); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (in_control(so, SIO= CDIFADDR, (caddr_t)&ifra, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifp, td)); > > With this patch in_lifaddr_ioctl() now looks more syntactically similar to in6_lifaddr_ioctl(). They could look even more similar by eliminating a lot of whitespace changes present here or there. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 20:52:52 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D4A67106566C; Tue, 3 Jan 2012 20:52:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7E79414DE63; Tue, 3 Jan 2012 20:52:15 +0000 (UTC) Message-ID: <4F036A7F.9030906@FreeBSD.org> Date: Tue, 03 Jan 2012 12:52:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> In-Reply-To: <20120104.040611.1847309275485655567.hrs@allbsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ndenev@gmail.com, emaste@FreeBSD.org, borjam@sarenet.es, freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:52:52 -0000 On 01/03/2012 11:06, Hiroki Sato wrote: > Doug Barton wrote > in <4F027BC0.1080101@FreeBSD.org>: > > do> We have a pair of physical FreeBSD systems configured as routers > do> designed to operate in an active/standby CARP configuration. Everything > do> used to work fine, but since an upgrade to 8.2-STABLE on December 29th > do> the two routers don't speak BGP to each other anymore. They both > do> function fine individually, and failover works. It is only the openbgpd > do> communication between them that's not flowing. > > Doug, does your kernel have TCP_SIGNATURE option? Yes. > The patch[*] for > net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG > option on the listening sockets. > > [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff > > While this is an ugly hack and I will investigate more reasonable > solution for that, I want to narrow down the cause first. Can anyone > who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if > this works or not? This patch works even if net.inet.tcp.signature_verify_input=1. If I turn that sysctl off on both sides they can talk to each other even without the patch. So that would definitely seem to indicate that the tcp_signature stuff is the source of the problem. What unfortunately did not work is configuring signatures on both sides. With the sysctl enabled, IPSEC set up on both hosts, and the tcp md5sig option in both bgpd.conf files, we got the same result as before, no communication between them. When -HUP'ing and/or restarting openbgpd with the tcp md5sig option enabled we get "pfkey setup failed." So, "working iBGP + no signatures" is a good next step. "iBGP + signatures" would be an even better one. :) We're happy to test more patches, etc.; and thanks again to everyone who has responded so far. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 21:04:01 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E561065688; Tue, 3 Jan 2012 21:04:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6CAE08FC15; Tue, 3 Jan 2012 21:04:00 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q03L3mbw077696; Wed, 4 Jan 2012 06:03:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q03L3l6C083828; Wed, 4 Jan 2012 06:03:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 06:03:27 +0900 (JST) Message-Id: <20120104.060327.1335862860296491365.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F036A7F.9030906@FreeBSD.org> References: <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jan__4_06_03_27_2012_282)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 06:03:59 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: ndenev@gmail.com, emaste@FreeBSD.org, borjam@sarenet.es, freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:04:01 -0000 ----Security_Multipart(Wed_Jan__4_06_03_27_2012_282)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4F036A7F.9030906@FreeBSD.org>: do> This patch works even if net.inet.tcp.signature_verify_input=1. If I do> turn that sysctl off on both sides they can talk to each other even do> without the patch. So that would definitely seem to indicate that the do> tcp_signature stuff is the source of the problem. do> do> What unfortunately did not work is configuring signatures on both sides. do> With the sysctl enabled, IPSEC set up on both hosts, and the tcp md5sig do> option in both bgpd.conf files, we got the same result as before, no do> communication between them. When -HUP'ing and/or restarting openbgpd do> with the tcp md5sig option enabled we get "pfkey setup failed." do> do> So, "working iBGP + no signatures" is a good next step. "iBGP + do> signatures" would be an even better one. :) We're happy to test more do> patches, etc.; and thanks again to everyone who has responded so far. Okay, thank you for your report. I will take some time to fix TCP_MD5SIG support in openbgpd and inform you when another patch is ready. -- Hiroki ----Security_Multipart(Wed_Jan__4_06_03_27_2012_282)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8DbR8ACgkQTyzT2CeTzy1drQCglm+AWVP4TvNJlleoHd0HmTTq zZEAni9yHXnm9ZBGGyhz9bYxjbZrj8DT =DR0G -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jan__4_06_03_27_2012_282)---- From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 21:22:20 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DBC106568A; Tue, 3 Jan 2012 21:22:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 622828FC12; Tue, 3 Jan 2012 21:22:20 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6CA3E25D38FF; Tue, 3 Jan 2012 21:22:19 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9B223BD8691; Tue, 3 Jan 2012 21:22:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id khae+xitpQct; Tue, 3 Jan 2012 21:22:17 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 53B6DBD8690; Tue, 3 Jan 2012 21:22:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111229225539.GD12721@FreeBSD.org> Date: Tue, 3 Jan 2012 21:22:16 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1AA3AF93-E622-4B3F-B882-9F0439364A91@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <20111229225539.GD12721@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org, Robert Watson , John Baldwin Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:22:20 -0000 On 29. Dec 2011, at 22:55 , Gleb Smirnoff wrote: > 3) I've found that in6_ifawithifp() doesn't do what it is supposed > to, as well as uses incorrect locking during this. As last resort > it should run through global list of addresses, not run throgh the > ifp one again. Patch attached. the first half of the patch is simple style which either goes on its own or not at all please. I think the second half of the patch is wrong. Mislead by either the KAME rev 1.1 comment or the locking. The locking sneaked in at http://svnweb.freebsd.org/base?view=revision&revision=194971 and I am not sure why reading it now. I guess an oversight by both Robert and I. The difference between the first and 2nd loop is the scope check and it's an "withifp" function, meaning we want an address of that interface and if you look at the highly expensive part in ip6_output() where we call it we expect the address to be on the given interface or to not be returned. So I'd say fix the locking and be done (and don't do the besta -> ia) change. If we want to optimize all this we might ponder to cache the first non-scope matching address and the 1st non-scope matching deprecated address and return that saving the 2nd loop. However not sure if the 2nd loop or the ifa_ref()s would be more expensive... Also wonder that for Apple... http://fxr.watson.org/fxr/source/bsd/netinet6/in6.c?v=xnu-1699.24.8#L3042 /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 21:24:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 279511065670 for ; Tue, 3 Jan 2012 21:24:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 1036A8FC0A for ; Tue, 3 Jan 2012 21:24:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RiBqa-0005C1-6U; Tue, 03 Jan 2012 21:24:40 +0000 Date: Wed, 04 Jan 2012 06:24:39 +0900 Message-ID: From: Randy Bush To: Ian Smith In-Reply-To: <20120104031114.N8995@sola.nimnet.asn.au> References: <20120104031114.N8995@sola.nimnet.asn.au> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net Subject: Re: how to debug non-working hole in nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:24:41 -0000 >> ignore. i sorted it. > Too late, sucked in .. diff from prior config might be bone enough? i had forgotten to remove the nat enable from /etc/ppp/ppp.conf when i moved to natd. randy From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 21:45:35 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A911065670; Tue, 3 Jan 2012 21:45:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ECF7B8FC1C; Tue, 3 Jan 2012 21:45:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id A0E6546B0D; Tue, 3 Jan 2012 16:45:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0A8FFB944; Tue, 3 Jan 2012 16:45:34 -0500 (EST) From: John Baldwin To: Sergey Kandaurov Date: Tue, 3 Jan 2012 16:08:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231508.52861.jhb@freebsd.org> <201201031517.36251.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031608.59688.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 16:45:34 -0500 (EST) Cc: Bjoern Zeeb , net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:45:35 -0000 On Tuesday, January 03, 2012 3:44:50 pm Sergey Kandaurov wrote: > On 4 January 2012 00:17, John Baldwin wrote: > > On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote: > >> On 24 December 2011 00:08, John Baldwin wrote: > >> > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in > >> > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure > >> > that it uses after dropping the IF_ADDR_LOCK(). Based on other code that uses > >> > a similar pattern of finding an ifa while under the lock and then using it > >> > after dropping the lock, I believe it should be acquiring a reference on the > >> > ifa and then dropping that reference when it is done using the ifa. This > >> > (untested) patch should fix this I believe: > >> > >> [Some thoughts on this.] > >> > >> FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which uses > >> an unreferenced ifa. Even when ifa reference is acquired, does this protect > >> ifa internals from concurrent changes? I would additionally lock ifa to > >> serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pair > >> exists to lock ifa with ifa_mtx. But there is only one place where such > >> locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced in > >> 2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr reference > >> counts. Two years later ifa_mtx started to be used explicitly in one place > >> to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed in > >> favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free(), > >> and now as said in r194602: "The ifa_mtx is now used for exactly one ioctl, > >> and possibly should be removed." > >> > >> Now I'm losing the chain, sorry.. > > > > Hmm, I'm not sure if ifa objects become immutable or not once they are > > referenced in the list. Other places in the code seem to use the ifa > > without locking it though, merely obtaining a reference. > > Yes, this is a main concern. > > > The in.c code doesn't even grab the IF_ADDR_LOCK(). :( The below patch > > should fix that and add the same fix as done to the in6.c code. > > > > Index: in.c > > =================================================================== > > --- in.c (revision 229406) > > +++ in.c (working copy) > > @@ -784,6 +784,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > > } > > } > > > > + IF_ADDR_LOCK(ifp); > > TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { > > if (ifa->ifa_addr->sa_family != AF_INET6) > > continue; > > @@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > > if (candidate.s_addr == match.s_addr) > > break; > > } > > + if (ifa != NULL) > > + ifa_ref(ifa); > > + IF_ADDR_UNLOCK(ifp); > > if (ifa == NULL) > > return (EADDRNOTAVAIL); > > ia = (struct in_ifaddr *)ifa; > > @@ -812,6 +816,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > > in_mask2len(&ia->ia_sockmask.sin_addr); > > > > iflr->flags = 0; /*XXX*/ > > + ifa_free(ifa); > > > > return (0); > > } else { > > @@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > > } > > bcopy(&ia->ia_sockmask, &ifra.ifra_dstaddr, > > ia->ia_sockmask.sin_len); > > + ifa_free(ifa); > > > > return (in_control(so, SIOCDIFADDR, (caddr_t)&ifra, > > ifp, td)); > > > > > > With this patch in_lifaddr_ioctl() now looks more syntactically similar > to in6_lifaddr_ioctl(). They could look even more similar by eliminating > a lot of whitespace changes present here or there. Hmmm. Actually, it seems to be a bit more broken. Note that it is expecting to get a sockaddr_in, but it is checking for AF_INET6, not AF_INET in its loop. That bug seems to go back to the original import from KAME. I'm not sure if the two can be merged since they work on different underyling data structures though. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 21:45:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E638D1065670; Tue, 3 Jan 2012 21:45:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A5B3B8FC14; Tue, 3 Jan 2012 21:45:36 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 41EF146B0A; Tue, 3 Jan 2012 16:45:36 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F0EBB91E; Tue, 3 Jan 2012 16:45:35 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Tue, 3 Jan 2012 16:45:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <20111229225539.GD12721@FreeBSD.org> In-Reply-To: <20111229225539.GD12721@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201031645.32590.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 16:45:35 -0500 (EST) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:45:37 -0000 On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote: > Reviewing your patch I've found several problems not introduced by it, > but already existing, and somewhat related to your patch: > > 2) Potential race when dropping a lock inside FOREACH loop: > > igmp.c:2058 > mld6.c:1419 > mld6.c:1704 (this one isn't even a SAFE, so would crash earlier) Ok, I think I have a patch to fix the middle one. I've (ab)used the list used to defer calls to in6m_release_locked() and used it to defer calls to mld_v1_transmit_report() from under the loop. Note that the v2 timers in the same loop already use this list to defer calls to in6m_release_locked() so it should be safe to use the temporary list for v1 as well. Index: mld6.c =================================================================== --- mld6.c (revision 229420) +++ mld6.c (working copy) @@ -121,7 +121,8 @@ static int mld_v1_input_query(struct ifnet *, cons /*const*/ struct mld_hdr *); static int mld_v1_input_report(struct ifnet *, const struct ip6_hdr *, /*const*/ struct mld_hdr *); -static void mld_v1_process_group_timer(struct in6_multi *, const int); +static void mld_v1_process_group_timer(struct mld_ifinfo *, + struct in6_multi *); static void mld_v1_process_querier_timers(struct mld_ifinfo *); static int mld_v1_transmit_report(struct in6_multi *, const int); static void mld_v1_update_group(struct in6_multi *, const int); @@ -1336,8 +1337,8 @@ mld_fasttimo_vnet(void) struct ifqueue qrq; /* Query response packets */ struct ifnet *ifp; struct mld_ifinfo *mli; - struct ifmultiaddr *ifma, *tifma; - struct in6_multi *inm; + struct ifmultiaddr *ifma; + struct in6_multi *inm, *tinm; int uri_fasthz; uri_fasthz = 0; @@ -1401,24 +1402,14 @@ mld_fasttimo_vnet(void) } IF_ADDR_LOCK(ifp); - TAILQ_FOREACH_SAFE(ifma, &ifp->if_multiaddrs, ifma_link, - tifma) { + TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family != AF_INET6 || ifma->ifma_protospec == NULL) continue; inm = (struct in6_multi *)ifma->ifma_protospec; switch (mli->mli_version) { case MLD_VERSION_1: - /* - * XXX Drop IF_ADDR lock temporarily to - * avoid recursion caused by a potential - * call by in6ifa_ifpforlinklocal(). - * rwlock candidate? - */ - IF_ADDR_UNLOCK(ifp); - mld_v1_process_group_timer(inm, - mli->mli_version); - IF_ADDR_LOCK(ifp); + mld_v1_process_group_timer(mli, inm); break; case MLD_VERSION_2: mld_v2_process_group_timers(mli, &qrq, @@ -1428,9 +1419,25 @@ mld_fasttimo_vnet(void) } IF_ADDR_UNLOCK(ifp); - if (mli->mli_version == MLD_VERSION_2) { - struct in6_multi *tinm; - + switch (mli->mli_version) { + case MLD_VERSION_1: + /* + * Transmit reports for this lifecycle. This + * is done while not holding IF_ADDR_LOCK + * since this can call + * in6ifa_ifpforlinklocal() which locks + * IF_ADDR_LOCK internally as well as + * ip6_output() to transmit a packet. + */ + SLIST_FOREACH_SAFE(inm, &mli->mli_relinmhead, + in6m_nrele, tinm) { + SLIST_REMOVE_HEAD(&mli->mli_relinmhead, + in6m_nrele); + (void)mld_v1_transmit_report(inm, + MLD_LISTENER_REPORT); + } + break; + case MLD_VERSION_2: mld_dispatch_queue(&qrq, 0); mld_dispatch_queue(&scq, 0); @@ -1444,6 +1451,7 @@ mld_fasttimo_vnet(void) in6m_nrele); in6m_release_locked(inm); } + break; } } @@ -1457,7 +1465,7 @@ out_locked: * Will update the global pending timer flags. */ static void -mld_v1_process_group_timer(struct in6_multi *inm, const int version) +mld_v1_process_group_timer(struct mld_ifinfo *mli, struct in6_multi *inm) { int report_timer_expired; @@ -1484,8 +1492,8 @@ static void case MLD_REPORTING_MEMBER: if (report_timer_expired) { inm->in6m_state = MLD_IDLE_MEMBER; - (void)mld_v1_transmit_report(inm, - MLD_LISTENER_REPORT); + SLIST_INSERT_HEAD(&mli->mli_relinmhead, inm, + in6m_nrele); } break; case MLD_G_QUERY_PENDING_MEMBER: -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 22:14:50 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18E6106564A; Tue, 3 Jan 2012 22:14:49 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD7CE8FC08; Tue, 3 Jan 2012 22:14:48 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q03MEaIL094552; Wed, 4 Jan 2012 07:14:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q03MEYSY084288; Wed, 4 Jan 2012 07:14:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 07:14:22 +0900 (JST) Message-Id: <20120104.071422.69305300858758112.hrs@allbsd.org> To: jhb@FreeBSD.org From: Hiroki Sato In-Reply-To: <201201031608.59688.jhb@freebsd.org> References: <201201031517.36251.jhb@freebsd.org> <201201031608.59688.jhb@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Jan__4_07_14_22_2012_438)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 07:14:46 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: pluknet@FreeBSD.org, bz@FreeBSD.org, net@FreeBSD.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:14:50 -0000 ----Security_Multipart0(Wed_Jan__4_07_14_22_2012_438)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jan__4_07_14_22_2012_691)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Jan__4_07_14_22_2012_691)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Baldwin wrote in <201201031608.59688.jhb@freebsd.org>: jh> > With this patch in_lifaddr_ioctl() now looks more syntactically similar jh> > to in6_lifaddr_ioctl(). They could look even more similar by eliminating jh> > a lot of whitespace changes present here or there. jh> jh> Hmmm. Actually, it seems to be a bit more broken. Note that it is expecting jh> to get a sockaddr_in, but it is checking for AF_INET6, not AF_INET in its jh> loop. That bug seems to go back to the original import from KAME. I'm not jh> sure if the two can be merged since they work on different underyling data jh> structures though. Hmm, a fix for that bug was not merged for some reason. Something like the attached patch should be applied. -- Hiroki ----Next_Part(Wed_Jan__4_07_14_22_2012_691)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in.c.20110104-1.diff" Index: in.c =================================================================== --- in.c (revision 229434) +++ in.c (working copy) @@ -735,7 +735,7 @@ if (iflr->flags & IFLR_PREFIX) return (EINVAL); - /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR_IN6). */ + /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR_IN). */ bzero(&ifra, sizeof(ifra)); bcopy(iflr->iflr_name, ifra.ifra_name, sizeof(ifra.ifra_name)); @@ -785,7 +785,7 @@ } TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family != AF_INET6) + if (ifa->ifa_addr->sa_family != AF_INET) continue; if (match.s_addr == 0) break; @@ -817,7 +817,7 @@ } else { struct in_aliasreq ifra; - /* fill in_aliasreq and do ioctl(SIOCDIFADDR_IN6) */ + /* fill in_aliasreq and do ioctl(SIOCDIFADDR_IN) */ bzero(&ifra, sizeof(ifra)); bcopy(iflr->iflr_name, ifra.ifra_name, sizeof(ifra.ifra_name)); ----Next_Part(Wed_Jan__4_07_14_22_2012_691)---- ----Security_Multipart0(Wed_Jan__4_07_14_22_2012_438)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8Dfb4ACgkQTyzT2CeTzy1heACg24CLnk58h0Vd9idaW064ejJ9 rloAn2nr/j7T1w718X+9pUKTF9MFhXgc =xxZ4 -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Jan__4_07_14_22_2012_438)---- From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 22:20:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FC0E106567C; Tue, 3 Jan 2012 22:20:00 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 35FEE8FC1C; Tue, 3 Jan 2012 22:20:00 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1468B25D37C7; Tue, 3 Jan 2012 22:19:59 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4F5B0BD869D; Tue, 3 Jan 2012 22:19:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id a8TrLAa1VHJ3; Tue, 3 Jan 2012 22:19:57 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1E9F5BD869C; Tue, 3 Jan 2012 22:19:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201112291527.26763.jhb@freebsd.org> Date: Tue, 3 Jan 2012 22:19:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:20:00 -0000 On 29. Dec 2011, at 20:27 , John Baldwin wrote: > I've gone ahead with this approach. I have three separate patches = that should > implement Phase 1. All of them can be found at > http://www.FreeBSD.org/~jhb/patches/ >=20 > - if_addr_dev.patch This fixes a few new device drivers that were = using > the locking macros directly rather than the = wrapper > functions Robert added. I've already sent = this > directly to the relevant driver maintainers = for their > review. > - if_addr_macros.patch This adds new locking macros to support read = locks vs > write locks. However, they all still map to = mutex > operations. The first two look good. I wondered why you didn't need the = r-wraper-functions but obviously they had been named like that already:) I'll look at the one below in more detail and get back to you. > - if_addr_uses.patch This changes callers of the existing macros = to use > either read or write locks. This is the patch = that > could use the most review. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 22:22:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90691065672; Tue, 3 Jan 2012 22:22:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1C78FC1C; Tue, 3 Jan 2012 22:22:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5471B46B06; Tue, 3 Jan 2012 17:22:12 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D44F2B965; Tue, 3 Jan 2012 17:22:11 -0500 (EST) From: John Baldwin To: Hiroki Sato Date: Tue, 3 Jan 2012 17:22:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201201031517.36251.jhb@freebsd.org> <201201031608.59688.jhb@freebsd.org> <20120104.071422.69305300858758112.hrs@allbsd.org> In-Reply-To: <20120104.071422.69305300858758112.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201031722.11253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 17:22:11 -0500 (EST) Cc: bz@freebsd.org, pluknet@freebsd.org, net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:22:12 -0000 On Tuesday, January 03, 2012 5:14:22 pm Hiroki Sato wrote: > John Baldwin wrote > in <201201031608.59688.jhb@freebsd.org>: > > jh> > With this patch in_lifaddr_ioctl() now looks more syntactically similar > jh> > to in6_lifaddr_ioctl(). They could look even more similar by eliminating > jh> > a lot of whitespace changes present here or there. > jh> > jh> Hmmm. Actually, it seems to be a bit more broken. Note that it is expecting > jh> to get a sockaddr_in, but it is checking for AF_INET6, not AF_INET in its > jh> loop. That bug seems to go back to the original import from KAME. I'm not > jh> sure if the two can be merged since they work on different underyling data > jh> structures though. > > Hmm, a fix for that bug was not merged for some reason. Something > like the attached patch should be applied. Ah, great, I've merged that into the patch, thanks! Index: in.c =================================================================== --- in.c (revision 229406) +++ in.c (working copy) @@ -735,7 +735,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca if (iflr->flags & IFLR_PREFIX) return (EINVAL); - /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR_IN6). */ + /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR). */ bzero(&ifra, sizeof(ifra)); bcopy(iflr->iflr_name, ifra.ifra_name, sizeof(ifra.ifra_name)); @@ -784,8 +784,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca } } + IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family != AF_INET6) + if (ifa->ifa_addr->sa_family != AF_INET) continue; if (match.s_addr == 0) break; @@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca if (candidate.s_addr == match.s_addr) break; } + if (ifa != NULL) + ifa_ref(ifa); + IF_ADDR_UNLOCK(ifp); if (ifa == NULL) return (EADDRNOTAVAIL); ia = (struct in_ifaddr *)ifa; @@ -812,12 +816,13 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca in_mask2len(&ia->ia_sockmask.sin_addr); iflr->flags = 0; /*XXX*/ + ifa_free(ifa); return (0); } else { struct in_aliasreq ifra; - /* fill in_aliasreq and do ioctl(SIOCDIFADDR_IN6) */ + /* fill in_aliasreq and do ioctl(SIOCDIFADDR) */ bzero(&ifra, sizeof(ifra)); bcopy(iflr->iflr_name, ifra.ifra_name, sizeof(ifra.ifra_name)); @@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca } bcopy(&ia->ia_sockmask, &ifra.ifra_dstaddr, ia->ia_sockmask.sin_len); + ifa_free(ifa); return (in_control(so, SIOCDIFADDR, (caddr_t)&ifra, ifp, td)); -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 3 23:17:04 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BBF0106564A; Tue, 3 Jan 2012 23:17:04 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 849648FC0C; Tue, 3 Jan 2012 23:17:03 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3F2CC25D385D; Tue, 3 Jan 2012 23:17:02 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4686FBD86A8; Tue, 3 Jan 2012 23:17:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id zM1hD3dvsWeB; Tue, 3 Jan 2012 23:16:59 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 74213BD86A7; Tue, 3 Jan 2012 23:16:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201031722.11253.jhb@freebsd.org> Date: Tue, 3 Jan 2012 23:16:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <03930D32-DC79-49E1-96AF-0698704D28BE@freebsd.org> References: <201201031517.36251.jhb@freebsd.org> <201201031608.59688.jhb@freebsd.org> <20120104.071422.69305300858758112.hrs@allbsd.org> <201201031722.11253.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: Hiroki Sato , pluknet@freebsd.org, net@freebsd.org Subject: Re: [PATCH] Use of unreferenced ifa in in6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:17:04 -0000 On 3. Jan 2012, at 22:22 , John Baldwin wrote: > On Tuesday, January 03, 2012 5:14:22 pm Hiroki Sato wrote: >> John Baldwin wrote >> in <201201031608.59688.jhb@freebsd.org>: >>=20 >> jh> > With this patch in_lifaddr_ioctl() now looks more syntactically = similar >> jh> > to in6_lifaddr_ioctl(). They could look even more similar by = eliminating >> jh> > a lot of whitespace changes present here or there. >> jh> >> jh> Hmmm. Actually, it seems to be a bit more broken. Note that it = is expecting >> jh> to get a sockaddr_in, but it is checking for AF_INET6, not = AF_INET in its >> jh> loop. That bug seems to go back to the original import from = KAME. I'm not >> jh> sure if the two can be merged since they work on different = underyling data >> jh> structures though. >>=20 >> Hmm, a fix for that bug was not merged for some reason. Something >> like the attached patch should be applied. >=20 > Ah, great, I've merged that into the patch, thanks! >=20 > Index: in.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- in.c (revision 229406) > +++ in.c (working copy) > @@ -735,7 +735,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > if (iflr->flags & IFLR_PREFIX) > return (EINVAL); >=20 > - /* copy args to in_aliasreq, perform = ioctl(SIOCAIFADDR_IN6). */ > + /* copy args to in_aliasreq, perform ioctl(SIOCAIFADDR). = */ > bzero(&ifra, sizeof(ifra)); > bcopy(iflr->iflr_name, ifra.ifra_name, > sizeof(ifra.ifra_name)); > @@ -784,8 +784,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > } > } >=20 > + IF_ADDR_LOCK(ifp); > TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { > - if (ifa->ifa_addr->sa_family !=3D AF_INET6) > + if (ifa->ifa_addr->sa_family !=3D AF_INET) > continue; > if (match.s_addr =3D=3D 0) > break; When doing "noise changes" like fixing comment in the same go (I'd = prefer that to be independent of the locking/refcount changes if possible, you could also wrap the long line: 792 candidate.s_addr =3D ((struct = sockaddr_in *)&ifa->ifa_addr)->sin_addr.s_addr; Otherwise looks good. > @@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > if (candidate.s_addr =3D=3D match.s_addr) > break; > } > + if (ifa !=3D NULL) > + ifa_ref(ifa); > + IF_ADDR_UNLOCK(ifp); > if (ifa =3D=3D NULL) > return (EADDRNOTAVAIL); > ia =3D (struct in_ifaddr *)ifa; > @@ -812,12 +816,13 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, = ca > in_mask2len(&ia->ia_sockmask.sin_addr); >=20 > iflr->flags =3D 0; /*XXX*/ > + ifa_free(ifa); >=20 > return (0); > } else { > struct in_aliasreq ifra; >=20 > - /* fill in_aliasreq and do = ioctl(SIOCDIFADDR_IN6) */ > + /* fill in_aliasreq and do ioctl(SIOCDIFADDR) */ > bzero(&ifra, sizeof(ifra)); > bcopy(iflr->iflr_name, ifra.ifra_name, > sizeof(ifra.ifra_name)); > @@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca > } > bcopy(&ia->ia_sockmask, &ifra.ifra_dstaddr, > ia->ia_sockmask.sin_len); > + ifa_free(ifa); >=20 > return (in_control(so, SIOCDIFADDR, = (caddr_t)&ifra, > ifp, td)); >=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" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 00:50:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66EE01065675; Wed, 4 Jan 2012 00:50:58 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id DBB3E8FC0A; Wed, 4 Jan 2012 00:50:57 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D888F25D3810; Wed, 4 Jan 2012 00:50:56 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F0456BD770A; Wed, 4 Jan 2012 00:50:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id UKAmUWi2Y1Gx; Wed, 4 Jan 2012 00:50:53 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8D395BD7708; Wed, 4 Jan 2012 00:50:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201031645.32590.jhb@freebsd.org> Date: Wed, 4 Jan 2012 00:50:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <35C8CBEE-0C97-48B5-8E4D-633A35B34D66@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <20111229225539.GD12721@FreeBSD.org> <201201031645.32590.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:50:58 -0000 On 3. Jan 2012, at 21:45 , John Baldwin wrote: > On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote: >> Reviewing your patch I've found several problems not introduced by = it, >> but already existing, and somewhat related to your patch: >>=20 >> 2) Potential race when dropping a lock inside FOREACH loop: >>=20 >> igmp.c:2058 >> mld6.c:1419 >> mld6.c:1704 (this one isn't even a SAFE, so would crash earlier) >=20 > Ok, I think I have a patch to fix the middle one. I've (ab)used the = list used > to defer calls to in6m_release_locked() and used it to defer calls to > mld_v1_transmit_report() from under the loop. Note that the v2 timers = in > the same loop already use this list to defer calls to = in6m_release_locked() > so it should be safe to use the temporary list for v1 as well. It seems to look fine indeed. > Index: mld6.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mld6.c (revision 229420) > +++ mld6.c (working copy) > @@ -121,7 +121,8 @@ static int mld_v1_input_query(struct ifnet = *, cons > /*const*/ struct mld_hdr *); > static int mld_v1_input_report(struct ifnet *, const struct ip6_hdr = *, > /*const*/ struct mld_hdr *); > -static void mld_v1_process_group_timer(struct in6_multi *, const = int); > +static void mld_v1_process_group_timer(struct mld_ifinfo *, > + struct in6_multi *); > static void mld_v1_process_querier_timers(struct mld_ifinfo *); > static int mld_v1_transmit_report(struct in6_multi *, const int); > static void mld_v1_update_group(struct in6_multi *, const int); > @@ -1336,8 +1337,8 @@ mld_fasttimo_vnet(void) > struct ifqueue qrq; /* Query response packets */ > struct ifnet *ifp; > struct mld_ifinfo *mli; > - struct ifmultiaddr *ifma, *tifma; > - struct in6_multi *inm; > + struct ifmultiaddr *ifma; > + struct in6_multi *inm, *tinm; > int uri_fasthz; >=20 > uri_fasthz =3D 0; > @@ -1401,24 +1402,14 @@ mld_fasttimo_vnet(void) > } >=20 > IF_ADDR_LOCK(ifp); > - TAILQ_FOREACH_SAFE(ifma, &ifp->if_multiaddrs, ifma_link, > - tifma) { > + TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { > if (ifma->ifma_addr->sa_family !=3D AF_INET6 || > ifma->ifma_protospec =3D=3D NULL) > continue; > inm =3D (struct in6_multi = *)ifma->ifma_protospec; > switch (mli->mli_version) { > case MLD_VERSION_1: > - /* > - * XXX Drop IF_ADDR lock temporarily to > - * avoid recursion caused by a potential > - * call by in6ifa_ifpforlinklocal(). > - * rwlock candidate? > - */ > - IF_ADDR_UNLOCK(ifp); > - mld_v1_process_group_timer(inm, > - mli->mli_version); > - IF_ADDR_LOCK(ifp); > + mld_v1_process_group_timer(mli, inm); > break; > case MLD_VERSION_2: > mld_v2_process_group_timers(mli, &qrq, > @@ -1428,9 +1419,25 @@ mld_fasttimo_vnet(void) > } > IF_ADDR_UNLOCK(ifp); >=20 > - if (mli->mli_version =3D=3D MLD_VERSION_2) { > - struct in6_multi *tinm; > - > + switch (mli->mli_version) { > + case MLD_VERSION_1: > + /* > + * Transmit reports for this lifecycle. This > + * is done while not holding IF_ADDR_LOCK > + * since this can call > + * in6ifa_ifpforlinklocal() which locks > + * IF_ADDR_LOCK internally as well as > + * ip6_output() to transmit a packet. > + */ > + SLIST_FOREACH_SAFE(inm, &mli->mli_relinmhead, > + in6m_nrele, tinm) { > + SLIST_REMOVE_HEAD(&mli->mli_relinmhead, > + in6m_nrele); > + (void)mld_v1_transmit_report(inm, > + MLD_LISTENER_REPORT); > + } > + break; > + case MLD_VERSION_2: > mld_dispatch_queue(&qrq, 0); > mld_dispatch_queue(&scq, 0); >=20 > @@ -1444,6 +1451,7 @@ mld_fasttimo_vnet(void) > in6m_nrele); > in6m_release_locked(inm); > } > + break; > } > } >=20 > @@ -1457,7 +1465,7 @@ out_locked: > * Will update the global pending timer flags. > */ > static void > -mld_v1_process_group_timer(struct in6_multi *inm, const int version) > +mld_v1_process_group_timer(struct mld_ifinfo *mli, struct in6_multi = *inm) > { > int report_timer_expired; >=20 > @@ -1484,8 +1492,8 @@ static void > case MLD_REPORTING_MEMBER: > if (report_timer_expired) { > inm->in6m_state =3D MLD_IDLE_MEMBER; > - (void)mld_v1_transmit_report(inm, > - MLD_LISTENER_REPORT); > + SLIST_INSERT_HEAD(&mli->mli_relinmhead, inm, > + in6m_nrele); > } > break; > case MLD_G_QUERY_PENDING_MEMBER: >=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" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 02:36:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7966C106564A for ; Wed, 4 Jan 2012 02:36:14 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 347E58FC1A for ; Wed, 4 Jan 2012 02:36:14 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RiGi5-0004uh-CV for freebsd-net@freebsd.org; Wed, 04 Jan 2012 03:36:13 +0100 Date: Wed, 4 Jan 2012 03:36:00 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1609249417.20120104033600@nitronet.pl> To: freebsd-ipv6@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Subject: NDP Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 02:36:14 -0000 Hi lists, I'm observing something strange. ipv6_enable="YES" ipv6_gateway_enable="YES" ipv6_network_interfaces="vlan3901" ipv6_ifconfig_vlan3901="2001:7f8:42::a503:9310:1/64" vlan3901: flags=8943 metric 0 mtu 1500 options=3 ether 00:15:17:38:13:7f inet6 fe80::92e2:baff:fe02:20bc%vlan3901 prefixlen 64 scopeid 0xf inet 195.182.218.230 netmask 0xfffffe00 broadcast 195.182.219.255 inet6 2001:7f8:42::a503:9310:1 prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active vlan: 3901 parent interface: igb1 NDP doesn't work. After adding a static entry with ndp -s, communication is possible. net.inet6.ip6.fw.enable: 0 Any ideas? :) Pawel. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 03:19:55 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6EDC106566B for ; Wed, 4 Jan 2012 03:19:55 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 301698FC12 for ; Wed, 4 Jan 2012 03:19:50 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q043JbN3068836; Wed, 4 Jan 2012 12:19:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q043JX4E020156; Wed, 4 Jan 2012 12:19:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 12:18:29 +0900 (JST) Message-Id: <20120104.121829.822190667587442229.hrs@allbsd.org> To: ptyll@nitronet.pl From: Hiroki Sato In-Reply-To: <1609249417.20120104033600@nitronet.pl> References: <1609249417.20120104033600@nitronet.pl> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Jan__4_12_18_29_2012_868)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 12:19:48 +0900 (JST) X-Spam-Status: No, score=-103.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ZERO,QENCPTR1,RDNS_NONE,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-ipv6@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: NDP Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:19:55 -0000 ----Security_Multipart0(Wed_Jan__4_12_18_29_2012_868)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jan__4_12_18_29_2012_152)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Jan__4_12_18_29_2012_152)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Tyll wrote in <1609249417.20120104033600@nitronet.pl>: pt> Hi lists, pt> pt> I'm observing something strange. pt> pt> ipv6_enable="YES" pt> ipv6_gateway_enable="YES" pt> ipv6_network_interfaces="vlan3901" pt> ipv6_ifconfig_vlan3901="2001:7f8:42::a503:9310:1/64" pt> pt> vlan3901: flags=8943 metric 0 mtu 1500 pt> options=3 pt> ether 00:15:17:38:13:7f pt> inet6 fe80::92e2:baff:fe02:20bc%vlan3901 prefixlen 64 scopeid 0xf pt> inet 195.182.218.230 netmask 0xfffffe00 broadcast 195.182.219.255 pt> inet6 2001:7f8:42::a503:9310:1 prefixlen 64 pt> nd6 options=3 pt> media: Ethernet autoselect (1000baseT ) pt> status: active pt> vlan: 3901 parent interface: igb1 pt> pt> NDP doesn't work. pt> pt> After adding a static entry with ndp -s, communication is possible. pt> net.inet6.ip6.fw.enable: 0 pt> pt> Any ideas? :) Does the attached patch (for 8.x kernel) fix your problem? -- Hiroki ----Next_Part(Wed_Jan__4_12_18_29_2012_152)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in6_ifattach.c.RELENG_8.20110104-1.diff" Index: sys/netinet6/in6_ifattach.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v retrieving revision 1.74.2.3.4.1 diff -u -r1.74.2.3.4.1 in6_ifattach.c --- sys/netinet6/in6_ifattach.c 21 Dec 2010 17:09:25 -0000 1.74.2.3.4.1 +++ sys/netinet6/in6_ifattach.c 4 Jan 2012 03:17:29 -0000 @@ -267,6 +267,7 @@ /* get EUI64 */ switch (ifp->if_type) { case IFT_ETHER: + case IFT_L2VLAN: case IFT_FDDI: case IFT_ISO88025: case IFT_ATM: ----Next_Part(Wed_Jan__4_12_18_29_2012_152)---- ----Security_Multipart0(Wed_Jan__4_12_18_29_2012_868)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8DxQUACgkQTyzT2CeTzy32pwCfSlISPZw1oJWnahHlh68ZvQCW ApcAn2hG1JRa3G9qZByUPWOBRtFP0JLs =Uh9h -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Jan__4_12_18_29_2012_868)---- From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 04:21:21 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61AD2106566C for ; Wed, 4 Jan 2012 04:21:21 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 19C778FC15 for ; Wed, 4 Jan 2012 04:21:21 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RiILo-000A4g-96 for freebsd-net@FreeBSD.org; Wed, 04 Jan 2012 05:21:20 +0100 Date: Wed, 4 Jan 2012 05:21:07 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1161157726.20120104052107@nitronet.pl> To: Hiroki Sato In-Reply-To: <20120104.121829.822190667587442229.hrs@allbsd.org> References: <1609249417.20120104033600@nitronet.pl> <20120104.121829.822190667587442229.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-net@FreeBSD.org Subject: Re: NDP Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:21:21 -0000 Hi Hiroki, > Does the attached patch (for 8.x kernel) fix your problem? Unfortunately, it doesn't. :( From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 04:33:56 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CCE9106564A for ; Wed, 4 Jan 2012 04:33:56 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id AF2E48FC19 for ; Wed, 4 Jan 2012 04:33:55 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q044Xhi3086851; Wed, 4 Jan 2012 13:33:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q044XfUX020845; Wed, 4 Jan 2012 13:33:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 13:33:36 +0900 (JST) Message-Id: <20120104.133336.214755626966668809.hrs@allbsd.org> To: ptyll@nitronet.pl From: Hiroki Sato In-Reply-To: <1161157726.20120104052107@nitronet.pl> References: <1609249417.20120104033600@nitronet.pl> <20120104.121829.822190667587442229.hrs@allbsd.org> <1161157726.20120104052107@nitronet.pl> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jan__4_13_33_36_2012_485)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 13:33:53 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: NDP Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:33:56 -0000 ----Security_Multipart(Wed_Jan__4_13_33_36_2012_485)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Tyll wrote in <1161157726.20120104052107@nitronet.pl>: pt> Hi Hiroki, pt> pt> > Does the attached patch (for 8.x kernel) fix your problem? pt> Unfortunately, it doesn't. :( Okay, so could you explain in more detail what symptoms made you think NDP didn't work properly? The results of "ifconfig -a", "ndp -na", "netstat -nrf inet6", and "ifmcstat" would be helpful for further diagnosis. -- Hiroki ----Security_Multipart(Wed_Jan__4_13_33_36_2012_485)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8D1qAACgkQTyzT2CeTzy0XqQCfXeKyTNAlK/NcjXqNipZZA7At 3TYAnRQ/gLxVQYIHtv+zx9/NHTpWHSlK =dKsZ -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jan__4_13_33_36_2012_485)---- From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 04:59:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB4051065672 for ; Wed, 4 Jan 2012 04:59:03 +0000 (UTC) (envelope-from azanar@carrel.org) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2FE2A8FC13 for ; Wed, 4 Jan 2012 04:59:02 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so23180821wgb.1 for ; Tue, 03 Jan 2012 20:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.138.151 with SMTP id a23mr30436475wej.52.1325651367967; Tue, 03 Jan 2012 20:29:27 -0800 (PST) Received: by 10.216.12.148 with HTTP; Tue, 3 Jan 2012 20:29:27 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Jan 2012 20:29:27 -0800 Message-ID: From: Ed Carrel To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:59:03 -0000 Hi freebsd-net, I originally sent this to -questions@, but was redirected here by that list. My original question is below: I am running into a roadblock getting PF to filter traffic on a Netgraph interface representing an L2TP/IPSec connection. I have done some narrowing down of the problem, but was hoping to get some advice on figuring out where to go digging next, or things to try. For context, here is what I have setup so far: I am running FreeBSD 8.2 with IPSec support compiled into the kernel. Here's the details from uname: # uname -a FreeBSD **** 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #2: Sun Nov 27 04:12:16 PST 2011 **** i386 I am following what seems like a typical setup of racoon(8) and setkey(8), and am having mpd5 handle construction of the L2TP nodes in netgraph. I can provide the details on the configuration of each of these, if desired. When I startup racoon in the foreground and ask mpd to construct an L2TP link, I can see both the IPSec tunnel and the L2TP link establish without a problem. I am able to ping the remote end, and, if I set up a routing rule, can contact and ssh to hosts at the other end of the tunnel. Here's how netgraph sees the world when thing are established: # ngctl list There are 13 total nodes: Name: Type: ksocket ID: 000001b3 Num hooks: 1 Name: Type: l2tp ID: 000001b1 Num hooks: 3 Name: Type: socket ID: 000001b0 Num hooks: 1 Name: ng0 Type: iface ID: 000001b6 Num hooks: 1 Name: ngctl26124 Type: socket ID: 000001bd Num hooks: 0 Name: ngctl19375 Type: socket ID: 000000ba Num hooks: 0 Name: mpd25875-stats Type: socket ID: 000001b8 Num hooks: 0 Name: mpd25875-WPLink-lt Type: tee ID: 000001af Num hooks: 2 Name: mpd25875-cso Type: socket ID: 000001ad Num hooks: 0 Name: mpd25875-eso Type: socket ID: 000001ae Num hooks: 0 Name: mpd25875-lso Type: socket ID: 000001ac Num hooks: 1 Name: mpd25875-WPBundle-1 Type: ppp ID: 000001b7 Num hooks: 3 Name: ng0-tee Type: tee ID: 000001b9 Num hooks: 2 # The problem I have is that PF only sees traffic on the outbound side of the netgraph interface. But, the rest of the network stack appears to see data going both ways: # ifconfig ng0 ng0: flags=88d1 metric 0 mtu 1322 inet 10.10.7.40 --> 10.10.0.2 netmask 0xffffffff # pfctl -vvs Interfaces -i ng0 ng0 Cleared: Sun Dec 25 21:14:44 2011 References: [ States: 0 Rules: 9 ] In4/Pass: [ Packets: 0 Bytes: 0 ] In4/Block: [ Packets: 0 Bytes: 0 ] Out4/Pass: [ Packets: 5555 Bytes: 446225 ] Out4/Block: [ Packets: 622 Bytes: 56336 ] In6/Pass: [ Packets: 0 Bytes: 0 ] In6/Block: [ Packets: 0 Bytes: 0 ] Out6/Pass: [ Packets: 0 Bytes: 0 ] Out6/Block: [ Packets: 0 Bytes: 0 ] # netstat -I ng0 -bn Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll ng0 1322 56 0 0 5069 98 0 6032 0 ng0 1322 10.10.7.40/32 10.10.7.40 56 - - 5069 54 - 3472 - I have stood up this interface several times, hence the differing numbers between the PF and netstat. The cause for concern is the lack of packets going through PF when inbound on ng0 -- no problem both seeing them and applying rules going outbound. There isn't a peep about the inbound traffic within pflog0, either. I can see traffic going both ways in tcpdump, and nothing looks peculiar about the packets. # tcpdump -c 10 -i ng0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes 22:06:37.201732 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [S], seq 3442571726, win 65535, options [mss 1282,nop,wscale 3,sackOK,TS val 694436002 ecr 0], length 0 22:06:37.263336 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [S.], seq 1974232057, ack 3442571727, win 14480, options [mss 1282,sackOK,TS val 370681934 ecr 694436002,nop,wscale 7], length 0 22:06:37.263577 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [.], ack 1, win 8255, options [nop,nop,TS val 694436064 ecr 370681934], length 0 22:06:37.282835 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [P.], ack 1, win 114, options [nop,nop,TS val 370681940 ecr 694436064], length 21 22:06:37.283931 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 22, win 8255, options [nop,nop,TS val 694436084 ecr 370681940], length 40 22:06:37.300729 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [.], ack 41, win 114, options [nop,nop,TS val 370681945 ecr 694436084], length 0 22:06:37.300943 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 22, win 8255, options [nop,nop,TS val 694436101 ecr 370681945], length 848 22:06:37.304154 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [P.], ack 41, win 114, options [nop,nop,TS val 370681945 ecr 694436084], length 984 22:06:37.372460 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [.], ack 889, win 127, options [nop,nop,TS val 370681967 ecr 694436101], length 0 22:06:37.372663 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 1006, win 8255, options [nop,nop,TS val 694436173 ecr 370681945], length 24 10 packets captured 22 packets received by filter 0 packets dropped by kernel As I noted above, I can interact with hosts over the tunnel so long as PF blindly passes traffic. Attempting to do any sort of stateful connection tracking causes PF to litter /var/log/messages with notices of a "loose state match," which I think is to be expected since it is only seeing the outbound half the network conversation. A suggestion someone on questions@ had was to leverage a gif interface, but with this already creating the ng0 interface, I'm not sure what that would accomplish, or if it is possible to bridge a gif with ng in that way. I'd be happy to research this more if enlightenment lies down that path. Ideas on things to try or investigate next? I can provide a paste of any relevant config or log files, just let me know. Thanks, Ed Carrel From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 05:10:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5AF106566B for ; Wed, 4 Jan 2012 05:10:21 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id ADB338FC13 for ; Wed, 4 Jan 2012 05:10:20 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so22366794vcb.13 for ; Tue, 03 Jan 2012 21:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=fv3V6AJlB/cTkAE6JhQrMu8L8TWmI+3uu/blZfp9BTg=; b=cjof3fONO/HNehvN+pfqk4t5x/wF4iTtLGOpaUjQ66VJsRPn1othhK0XVcpZaqmEIu HsGZJXRxreAJOW1F27WJuhaUUXVkIy7iKhV5C4dV8qHawluVUq5lQKduZ6VShnNvUpP3 1HDoDAvvDn4GRHAXU+hEsAusXsXom9Edw8Hd8= MIME-Version: 1.0 Received: by 10.220.142.84 with SMTP id p20mr31330641vcu.19.1325653820051; Tue, 03 Jan 2012 21:10:20 -0800 (PST) Received: by 10.220.108.144 with HTTP; Tue, 3 Jan 2012 21:10:20 -0800 (PST) Date: Tue, 3 Jan 2012 21:10:20 -0800 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Any recommendations for a 10G NIC from Broadcom X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:10:21 -0000 Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems promising. I am looking for features such as multi-queue, MSI-X, TSO etc. Any recommendations would be greatly appreciated. -vijay PS: I'd be using FreeBSD 8.2 initially, and FreeBSD 9.x in a few months. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 05:24:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095FC106564A; Wed, 4 Jan 2012 05:24:06 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65E988FC13; Wed, 4 Jan 2012 05:24:04 +0000 (UTC) Received: by eekc50 with SMTP id c50so19511220eek.13 for ; Tue, 03 Jan 2012 21:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4TgdzyaUrHCc6kYLQrHLWeVIOyw9pZax/PXZFQ5cElU=; b=DOX1+tKmxKSv63CkZf9k2DU5q3rXw/aSYTgi/2eU/2xfU1927pq6AwlZOOoU+jUMnS 02y5ob6mnzrhDfSNS/u0mETQtpEZIW9uvuQhMWLuwF5KfdEj7lhK4+B2gosLUA06EC6w kofGbiNUgdDy0yaGthAz4MmytaI4lffKrRfog= Received: by 10.213.114.3 with SMTP id c3mr617050ebq.146.1325654641639; Tue, 03 Jan 2012 21:24:01 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id y12sm214063083eeb.11.2012.01.03.21.23.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 21:24:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: <4F036A7F.9030906@FreeBSD.org> Date: Wed, 4 Jan 2012 07:23:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> References: <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:24:06 -0000 On Jan 3, 2012, at 10:52 PM, Doug Barton wrote: > On 01/03/2012 11:06, Hiroki Sato wrote: >> Doug Barton wrote >> in <4F027BC0.1080101@FreeBSD.org>: >>=20 >> do> We have a pair of physical FreeBSD systems configured as routers >> do> designed to operate in an active/standby CARP configuration. = Everything >> do> used to work fine, but since an upgrade to 8.2-STABLE on December = 29th >> do> the two routers don't speak BGP to each other anymore. They both >> do> function fine individually, and failover works. It is only the = openbgpd >> do> communication between them that's not flowing. >>=20 >> Doug, does your kernel have TCP_SIGNATURE option?=20 >=20 > Yes. >=20 >> The patch[*] for >> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG >> option on the listening sockets. >>=20 >> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff >>=20 >> While this is an ugly hack and I will investigate more reasonable >> solution for that, I want to narrow down the cause first. Can anyone >> who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if >> this works or not? >=20 > This patch works even if net.inet.tcp.signature_verify_input=3D1. If I > turn that sysctl off on both sides they can talk to each other even > without the patch. So that would definitely seem to indicate that the > tcp_signature stuff is the source of the problem. >=20 > What unfortunately did not work is configuring signatures on both = sides. > With the sysctl enabled, IPSEC set up on both hosts, and the tcp = md5sig > option in both bgpd.conf files, we got the same result as before, no > communication between them. When -HUP'ing and/or restarting openbgpd > with the tcp md5sig option enabled we get "pfkey setup failed." >=20 > So, "working iBGP + no signatures" is a good next step. "iBGP + > signatures" would be an even better one. :) We're happy to test more > patches, etc.; and thanks again to everyone who has responded so far. >=20 >=20 > Doug >=20 > --=20 >=20 > You can observe a lot just by watching. -- Yogi Berra >=20 > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ >=20 You are setting the keys with setkey for both directions of a single = session, right? i.e.: =20 add X.X.X.X Y.Y.Y.Y tcp 0x1000 -A tcp-md5 "SomePass"; add Y.Y.Y.Y X.X.X.X tcp 0x1000 -A tcp-md5 "SomePass"; As before it was only needed to set the "outgoing" direction key, which = should not work anymore unless=20 net.inet.tcp.signature_verify_input is zero. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 05:27:48 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CC761106564A for ; Wed, 4 Jan 2012 05:27:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 05E9A1506B4; Wed, 4 Jan 2012 05:27:47 +0000 (UTC) Message-ID: <4F03E353.80105@FreeBSD.org> Date: Tue, 03 Jan 2012 21:27:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Nikolay Denev References: <20120103152909.GA83706@sandvine.com> <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> In-Reply-To: <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:27:48 -0000 On 01/03/2012 21:23, Nikolay Denev wrote: > You are setting the keys with setkey for both directions of a single session, right? Yes. But thanks for asking. :) Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 05:33:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611E1106564A; Wed, 4 Jan 2012 05:33:30 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97AAE8FC0A; Wed, 4 Jan 2012 05:33:29 +0000 (UTC) Received: by eekc50 with SMTP id c50so19515229eek.13 for ; Tue, 03 Jan 2012 21:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1s8XubGk/svkO2sYDGnsix2cGcF8bVo1PhAWYcTVRhE=; b=XaEZWZy3FtvTW0ynpmoctBpMBEvMTwUIy0x9oPstAIBBq7nLrAhxBhLhdLekh/PCIp NNVS+AIpCaENNadf5cz3YTx4CYuBqdJfLAugZGALacMwDJ9vy8mvZ6quZHNGiu6AMfls 9/iO+qo9cjjU5ZlJfb2gQ410Qk1ROeYZkwNQ8= Received: by 10.14.16.221 with SMTP id h69mr22088700eeh.126.1325655208333; Tue, 03 Jan 2012 21:33:28 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id u53sm167373199eeu.6.2012.01.03.21.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 21:33:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20120103.203608.74677765.sthaug@nethelp.no> Date: Wed, 4 Jan 2012 07:33:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5739312A-614C-492A-BB89-F386B7F74CF5@gmail.com> References: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <20120103.203608.74677765.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1251.1) Cc: dougb@FreeBSD.org, freebsd-net@FreeBSD.org, hrs@FreeBSD.org, emaste@FreeBSD.org, borjam@sarenet.es Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:33:30 -0000 On Jan 3, 2012, at 9:36 PM, sthaug@nethelp.no wrote: >> Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for >> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG >> option on the listening sockets. >>=20 >> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff >>=20 >> While this is an ugly hack and I will investigate more reasonable >> solution for that, I want to narrow down the cause first. Can anyone >> who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if >> this works or not? >=20 > 8-STABLE on several servers, csup'ed only a couple of days ago, with=20= >=20 > options TCP_SIGNATURE > options IPSEC > device crypto > device cryptodev >=20 > and Quagga bgpd talking to Juniper M/MX routers using MD5 key on the > BGP sessions. No problems. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no This was always working for me. My problem was that I had two routers having BGP sessions to an ISP with md5 and a session between themselves = without md5. After I upgraded to 8-STABLE some time ago, the md5 sessions still = worked, but the ones without did not. tcpdump showed packets with md5 digest fields = all zeroes. If one of the machines does not have md5 signature support it will = probably work, since when one of the routers tries to speak tcpmd5 even with incorrect = digest field, the other one tries to respond also with tcpmd5. Also there are some things in the tcp(4) manual page that should be = fixed to reflect the new behaviour (the part mentioning that incoming digests are not = verified): TCP_MD5SIG This option enables the use of MD5 digests (also known = as TCP-MD5) on writes to the specified socket. In the = current release, only outgoing traffic is digested; digests on incoming traffic are not verified. The current = default behavior for the system is to respond to a system = advertis- ing this option with TCP-MD5; this may change. Also in the case of my failing BGP sessions I expected to see errors as = per the man page : If an SADB entry cannot be found for the destination, = the outgoing traffic will have an invalid digest option prepended, and the following error message will be = visible on the system console: tcp_signature_compute: SADB = lookup failed for %d.%d.%d.%d. But this was not happening. Regards, Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 08:27:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12C07106566C; Wed, 4 Jan 2012 08:27:31 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id BEDE48FC08; Wed, 4 Jan 2012 08:27:30 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 34D879DC498; Wed, 4 Jan 2012 09:27:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120103152909.GA83706@sandvine.com> Date: Wed, 4 Jan 2012 09:27:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:27:31 -0000 On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: > Thanks for the link Nikolay. >=20 > Borja, I assume it's the PR submission form that gave you trouble - > sorry for that. Based on your report it sounds to me like the bug is > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option > though I'd assume it's due to a difference in our (FreeBSD's) > implementation of the option. Did you look at the OpenBSD/FreeBSD > differences in your investigation? I looked at OpenBGPd. By the way, I was having the same issue on the = different FreeBSD 9 RC's I was trying. Have a look at session.c, line 148, function setup_listeners() opt =3D 1;=20 if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,=20 &opt, sizeof(opt)) =3D=3D -1) {=20 if (errno =3D=3D ENOPROTOOPT) { /* system = w/o md5sig */=20 log_warnx("md5sig not available, = disabling");=20 sysdep.no_md5sig =3D 1;=20 } else=20 fatal("setsockopt TCP_MD5SIG");=20 }=20 Seems that the function is using the setsockopt to check the = availability of TCP_MD5.=20 But, even though I haven't had a look at it on OpenBSD, I can make an = educated guess: Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. = According to my packet captures, in case there's no properly set key = with setkey(8) it will use whatever key. Look at the captures mentioned = here: = http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/e= a347a919dbc165d/eeaa2965fc4f64c9?show_docid=3Deeaa2965fc4f64c9&pli=3D1 Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless = there's a valid key associated to the socket, either using setkey(8) (I = don't know if they use it) or via the API for setting keys. Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a = socket unless (or until) a key is associated, or OpenBGPd should be = modified so that it won't "probe" the availability of TCP_MD5SIG by = actually setting it. Of course, if setting it for a socket is the best = way to detect it, you can always create a temporary socket, you don't = even need to bind() it, set TCP_MD5SIG, so that you will know if it = succeeds or returns an error, and destroy the socket.=20 The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a = socket no matter if I have configured the BGP peer with or without = TCP_MD5. Neither Quagga nor Bird do it. Borja. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 08:34:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68094106564A for ; Wed, 4 Jan 2012 08:34:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E29D38FC0C for ; Wed, 4 Jan 2012 08:34:51 +0000 (UTC) Received: by iadj38 with SMTP id j38so40540974iad.13 for ; Wed, 04 Jan 2012 00:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xdTX5mtsdLJfLNWhGrMahDwZRCMtE+q6y3CN4Btg2jc=; b=HM/vrxXKApxBjbZ1Z4FiL49wbmW0gMbQoPPy3933MmIBTeBJXn07IPUW6gXoLTKGkI DeE4sUKbS1vE5xqrUEEGDWpwGBcL9/CYMA6+TrlGQCY1ED5JyGSzUTWIPmPp+BHyRkDu DogwskDocl9tffHmO8Fu/CvUqHkkaihTYVP3Q= MIME-Version: 1.0 Received: by 10.42.151.68 with SMTP id d4mr58073344icw.36.1325664218119; Wed, 04 Jan 2012 00:03:38 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.20.71 with HTTP; Wed, 4 Jan 2012 00:03:38 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Jan 2012 09:03:38 +0100 X-Google-Sender-Auth: Uu8V4H-yTeaZRBW7htQBpzyIJIc Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Ed Carrel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:34:52 -0000 On Wed, Jan 4, 2012 at 5:29 AM, Ed Carrel wrote: > Hi freebsd-net, > > I originally sent this to -questions@, but was redirected here by that > list. My original question is below: > > I am running into a roadblock getting PF to filter traffic on a Netgraph > interface representing an L2TP/IPSec connection. I have done some narrowing > down of the problem, but was hoping to get some advice on figuring out > where to go digging next, or things to try. > > For context, here is what I have setup so far: I am running FreeBSD 8.2 > with IPSec support compiled into the kernel. Here's the details from uname: > > # uname -a > FreeBSD **** 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #2: Sun Nov 27 04:12:16 > PST 2011 **** i386 > > I am following what seems like a typical setup of racoon(8) and setkey(8), > and am having mpd5 handle construction of the L2TP nodes in netgraph. I can > provide the details on the configuration of each of these, if desired. When > I startup racoon in the foreground and ask mpd to construct an L2TP link, I > can see both the IPSec tunnel and the L2TP link establish without a > problem. I am able to ping the remote end, and, if I set up a routing rule, > can contact and ssh to hosts at the other end of the tunnel. > > Here's how netgraph sees the world when thing are established: > > # ngctl list > There are 13 total nodes: > Name: Type: ksocket ID: 000001b3 Num hooks: 1 > Name: Type: l2tp ID: 000001b1 Num hooks: 3 > Name: Type: socket ID: 000001b0 Num hooks: 1 > Name: ng0 Type: iface ID: 000001b6 Num hooks: 1 > Name: ngctl26124 Type: socket ID: 000001bd Num hooks: 0 > Name: ngctl19375 Type: socket ID: 000000ba Num hooks: 0 > Name: mpd25875-stats Type: socket ID: 000001b8 Num hooks: 0 > Name: mpd25875-WPLink-lt Type: tee ID: 000001af Num hooks: 2 > Name: mpd25875-cso Type: socket ID: 000001ad Num hooks: 0 > Name: mpd25875-eso Type: socket ID: 000001ae Num hooks: 0 > Name: mpd25875-lso Type: socket ID: 000001ac Num hooks: 1 > Name: mpd25875-WPBundle-1 Type: ppp ID: 000001b7 Num hooks: > 3 > Name: ng0-tee Type: tee ID: 000001b9 Num hooks: 2 > # > > The problem I have is that PF only sees traffic on the outbound side of the > netgraph interface. But, the rest of the network stack appears to see data > going both ways: > > # ifconfig ng0 > ng0: flags=88d1 metric 0 > mtu 1322 > inet 10.10.7.40 --> 10.10.0.2 netmask 0xffffffff > > # pfctl -vvs Interfaces -i ng0 > ng0 > Cleared: Sun Dec 25 21:14:44 2011 > References: [ States: 0 Rules: 9 ] > In4/Pass: [ Packets: 0 Bytes: 0 ] > In4/Block: [ Packets: 0 Bytes: 0 ] > Out4/Pass: [ Packets: 5555 Bytes: 446225 ] > Out4/Block: [ Packets: 622 Bytes: 56336 ] > In6/Pass: [ Packets: 0 Bytes: 0 ] > In6/Block: [ Packets: 0 Bytes: 0 ] > Out6/Pass: [ Packets: 0 Bytes: 0 ] > Out6/Block: [ Packets: 0 Bytes: 0 ] > > # netstat -I ng0 -bn > Name Mtu Network Address Ipkts Ierrs Idrop Ibytes > Opkts Oerrs Obytes Coll > ng0 1322 56 0 0 5069 > 98 0 6032 0 > ng0 1322 10.10.7.40/32 10.10.7.40 56 - - > 5069 > 54 - 3472 - > > I have stood up this interface several times, hence the differing numbers > between the PF and netstat. The cause for concern is the lack of packets > going through PF when inbound on ng0 -- no problem both seeing them and > applying rules going outbound. There isn't a peep about the inbound traffic > within pflog0, either. > > I can see traffic going both ways in tcpdump, and nothing looks peculiar > about the packets. > > # tcpdump -c 10 -i ng0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes > 22:06:37.201732 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [S], seq > 3442571726, win 65535, options [mss 1282,nop,wscale 3,sackOK,TS val > 694436002 ecr 0], length 0 > 22:06:37.263336 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [S.], seq > 1974232057, ack 3442571727, win 14480, options [mss 1282,sackOK,TS val > 370681934 ecr 694436002,nop,wscale 7], length 0 > 22:06:37.263577 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [.], ack 1, win > 8255, options [nop,nop,TS val 694436064 ecr 370681934], length 0 > 22:06:37.282835 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [P.], ack 1, win > 114, options [nop,nop,TS val 370681940 ecr 694436064], length 21 > 22:06:37.283931 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 22, > win 8255, options [nop,nop,TS val 694436084 ecr 370681940], length 40 > 22:06:37.300729 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [.], ack 41, win > 114, options [nop,nop,TS val 370681945 ecr 694436084], length 0 > 22:06:37.300943 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 22, > win 8255, options [nop,nop,TS val 694436101 ecr 370681945], length 848 > 22:06:37.304154 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [P.], ack 41, > win 114, options [nop,nop,TS val 370681945 ecr 694436084], length 984 > 22:06:37.372460 IP 10.10.4.3.ssh > 10.10.7.40.43113: Flags [.], ack 889, > win 127, options [nop,nop,TS val 370681967 ecr 694436101], length 0 > 22:06:37.372663 IP 10.10.7.40.43113 > 10.10.4.3.ssh: Flags [P.], ack 1006, > win 8255, options [nop,nop,TS val 694436173 ecr 370681945], length 24 > 10 packets captured > 22 packets received by filter > 0 packets dropped by kernel > > As I noted above, I can interact with hosts over the tunnel so long as PF > blindly passes traffic. Attempting to do any sort of stateful connection > tracking causes PF to litter /var/log/messages with notices of a "loose > state match," which I think is to be expected since it is only seeing the > outbound half the network conversation. > > A suggestion someone on questions@ had was to leverage a gif interface, > but > with this already creating the ng0 interface, I'm not sure what that would > accomplish, or if it is possible to bridge a gif with ng in that way. I'd > be happy to research this more if enlightenment lies down that path. > > Ideas on things to try or investigate next? I can provide a paste of any > relevant config or log files, just let me know. > > Can you see if on the enc(4) interface pf(4) sees both side of the traffic? Also please describe/post what is the ruleset of blindly passing packets and the ruleset that you define as 'keep state'!? > Thanks, > > Ed Carrel > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 09:31:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E153106566B for ; Wed, 4 Jan 2012 09:31:03 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 564DB8FC08 for ; Wed, 4 Jan 2012 09:31:03 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so22607982vbb.13 for ; Wed, 04 Jan 2012 01:31:02 -0800 (PST) Received: by 10.52.30.13 with SMTP id o13mr47965vdh.89.1325669462492; Wed, 04 Jan 2012 01:31:02 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id iv10sm7623659vdb.18.2012.01.04.01.31.01 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 01:31:01 -0800 (PST) Message-ID: <4F041C54.4010904@my.gd> Date: Wed, 04 Jan 2012 10:31:00 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Any recommendations for a 10G NIC from Broadcom X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:31:03 -0000 On 1/4/12 6:10 AM, Vijay Singh wrote: > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > promising. I am looking for features such as multi-queue, MSI-X, TSO > etc. Any recommendations would be greatly appreciated. > Now, I'm going to offer you an indirect response. Jack Vogel, who works at Intel, writes and maintains the code for most (all?) the Intel NICs on FreeBSD. If I had to make a choice between Broadcom and Intel, I'd go with Intel for this very reason. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 09:55:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73867106566B for ; Wed, 4 Jan 2012 09:55:07 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id D769E8FC14 for ; Wed, 4 Jan 2012 09:55:06 +0000 (UTC) Received: (qmail 15382 invoked by uid 1001); 4 Jan 2012 09:28:24 -0000 Date: Wed, 4 Jan 2012 10:28:24 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20120104092824.GA24657@diehard.n-r-g.com> Mail-Followup-To: freebsd-net@freebsd.org References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:55:07 -0000 On Wed, Jan 04, 2012 at 09:27:28AM +0100, Borja Marcos wrote: > > On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: > > > Thanks for the link Nikolay. > > > > Borja, I assume it's the PR submission form that gave you trouble - > > sorry for that. Based on your report it sounds to me like the bug is > > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option > > though I'd assume it's due to a difference in our (FreeBSD's) > > implementation of the option. Did you look at the OpenBSD/FreeBSD > > differences in your investigation? > > I looked at OpenBGPd. By the way, I was having the same issue on the different FreeBSD 9 RC's I was trying. > > Have a look at session.c, line 148, function setup_listeners() > > opt = 1; > if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG, > &opt, sizeof(opt)) == -1) { > if (errno == ENOPROTOOPT) { /* system w/o md5sig */ > log_warnx("md5sig not available, disabling"); > sysdep.no_md5sig = 1; > } else > fatal("setsockopt TCP_MD5SIG"); > } > > Seems that the function is using the setsockopt to check the > availability of TCP_MD5. > > But, even though I haven't had a look at it on OpenBSD, I can make an > educated guess: > > Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. > According to my packet captures, in case there's no properly set key > with setkey(8) it will use whatever key. Look at the captures mentioned > here: > > http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1 > > > Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless > there's a valid key associated to the socket, either using setkey(8) (I > don't know if they use it) or via the API for setting keys. > > > Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a > socket unless (or until) a key is associated, or OpenBGPd should be > modified so that it won't "probe" the availability of TCP_MD5SIG by > actually setting it. Of course, if setting it for a socket is the best > way to detect it, you can always create a temporary socket, you don't > even need to bind() it, set TCP_MD5SIG, so that you will know if it > succeeds or returns an error, and destroy the socket. > > The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a > socket no matter if I have configured the BGP peer with or without > TCP_MD5. Neither Quagga nor Bird do it. > OpenBGPD sets the TCP_MD5SIG flag on the listening socket so that it can be ensured that an accepted connection (SYN, SYN/ACK & first ACK) is also protected by the TCP MD5 signature. On startup OpenBGPD will install the necessary TCP MD5 SAs and our network stack ensures that SAs are also matched for incomming connections when the TCP_MD5SIG is set on the listening socket (in which case the option is inherited to the accpeted socket). If you can not set the TCP_MD5SIG option on listening sockets then you can not protect and acctually accept incomming connections. A proper neighbor would not accept the SYN/ACK sent back that does not have the MD5SIG. How does FreeBSD avoid the chicken and egg problem of accepting connections with MD5SIG? -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 10:59:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9999106564A for ; Wed, 4 Jan 2012 10:59:19 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 748688FC17 for ; Wed, 4 Jan 2012 10:59:19 +0000 (UTC) Received: by iadj38 with SMTP id j38so40783346iad.13 for ; Wed, 04 Jan 2012 02:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=W+/tvvsOyIG6L5lnxP1pNhvfqk4sR3Xo4ncSmDChhsc=; b=EqEwSOL3hfi0lvL5gpCg7xUnBr1j8hIDSZPU2C/evUmc61kES8bi6G0EY01hCQfzeg FrIQFyXtDC/JXWoNLoTIilqMZ5/8d4Hq7Ex8xsyTqgrqoTKln9sSFChBq1NBU2J71FOT QV+R5vwwkNwth6F6BjP9PIMJyS7kmQE05Evf0= MIME-Version: 1.0 Received: by 10.42.161.132 with SMTP id t4mr56941280icx.16.1325674758863; Wed, 04 Jan 2012 02:59:18 -0800 (PST) Received: by 10.231.41.206 with HTTP; Wed, 4 Jan 2012 02:59:18 -0800 (PST) Date: Wed, 4 Jan 2012 12:59:18 +0200 Message-ID: From: Sami Halabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 10:59:19 -0000 Hi, I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating pptp/l2tp tunnels. I'm using MPPC (Compression & Encryption), my current onfiguration i use only IPv4. I keep getting in the logs the following: Jan 3 19:15:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is too small for IPv6 Jan 3 20:00:40 mpd2 kernel: nd6_setmtu0: new link MTU on ng151 (1218) is too small for IPv6 Jan 3 20:09:27 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is too small for IPv6 Jan 3 20:30:13 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is too small for IPv6 Jan 3 20:34:33 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is too small for IPv6 Jan 3 21:06:46 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 3 21:42:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 3 22:12:49 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is too small for IPv6 Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is too small for IPv6 Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is too small for IPv6 Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is too small for IPv6 Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is too small for IPv6 although the NG tunnels don't negotiate IPv6. a close look to the MPD log i see that this happens for connections that set MRU/MTU 1400. I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, rather than a kernel issue as the logs say. why this problem happens when no IPv6 is in work? I don't want to disable ipv6 completely since i have plans in using it in the near future. Any help appreciated, Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 12:01:18 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AEC1065670 for ; Wed, 4 Jan 2012 12:01:18 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2288FC1C for ; Wed, 4 Jan 2012 12:01:17 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q04C14ZC094814; Wed, 4 Jan 2012 21:01:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q04C12td023663; Wed, 4 Jan 2012 21:01:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Jan 2012 20:59:31 +0900 (JST) Message-Id: <20120104.205931.1091341202993271005.hrs@allbsd.org> To: sodynet1@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jan__4_20_59_31_2012_820)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 04 Jan 2012 21:01:15 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:01:18 -0000 ----Security_Multipart(Wed_Jan__4_20_59_31_2012_820)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sami Halabi wrote in : so> Hi, so> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating so> pptp/l2tp tunnels. so> so> I'm using MPPC (Compression & Encryption), my current onfiguration i use so> only IPv4. so> so> I keep getting in the logs the following: so> Jan 3 19:15:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is so> too small for IPv6 so> Jan 3 20:00:40 mpd2 kernel: nd6_setmtu0: new link MTU on ng151 (1218) is so> too small for IPv6 so> Jan 3 20:09:27 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is so> too small for IPv6 so> Jan 3 20:30:13 mpd2 kernel: nd6_setmtu0: new link MTU on ng128 (1218) is so> too small for IPv6 so> Jan 3 20:34:33 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is so> too small for IPv6 so> Jan 3 21:06:46 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 3 21:42:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is so> too small for IPv6 so> Jan 3 22:12:49 mpd2 kernel: nd6_setmtu0: new link MTU on ng137 (1218) is so> too small for IPv6 so> Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is so> too small for IPv6 so> Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is so> too small for IPv6 so> Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is so> too small for IPv6 so> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is so> too small for IPv6 so> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is so> too small for IPv6 so> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is so> too small for IPv6 so> so> although the NG tunnels don't negotiate IPv6. so> so> a close look to the MPD log i see that this happens for connections that so> set MRU/MTU 1400. so> so> I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, so> rather than a kernel issue as the logs say. so> so> why this problem happens when no IPv6 is in work? so> so> I don't want to disable ipv6 completely since i have plans in using it in so> the near future. It is because the end point of an L2TPv2 tunnel is implemented in MPD by using ng_iface(4), and it always has an inet6 hook when the kernel has IPv6 support (note that GENERIC kernel supports IPv6). This means an ngNNN interface is always IPv6-capable regardless of whether the tunnel supports IPv6 as the inner protocol (typically via IPV6CP in the case of L2TPv2) or not. IPv6 communication is denied when the tunnel does not support IPv6, but the interface ngNNN itself always supports IPv6. Thus, the warning you got is caused by a side-effect of IPv6 initialization of ngNNN. Since IPv6 specification requires the minimum MTU as 1280, an warning message will be displayed if you try to use a smaller MTU as the link MTU than that. You can ignore the messages safely, or increasing the MTU will suppress them. I am still wondering why the message appears when MTU is set to 1400, however. In the case of L2TPv2 over UDPv4, MTU reduction should be 46 because of encapsulation by IPv4, UDP, L2TP, and PPP. -- Hiroki ----Security_Multipart(Wed_Jan__4_20_59_31_2012_820)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8EPyMACgkQTyzT2CeTzy19EQCfV4dvFE6cRx2RjkTjTUBxlPnl 9K8AoJHdSdbDWaynjpo3CEj+S3SC2R/c =kt/G -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jan__4_20_59_31_2012_820)---- From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 12:01:52 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E6E21065678 for ; Wed, 4 Jan 2012 12:01:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E72E58FC23 for ; Wed, 4 Jan 2012 12:01:51 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q04C1oKl051484; Wed, 4 Jan 2012 16:01:50 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q04C1oZX051483; Wed, 4 Jan 2012 16:01:50 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Jan 2012 16:01:50 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120104120150.GG34721@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:01:52 -0000 On Wed, Jan 04, 2012 at 12:59:18PM +0200, Sami Halabi wrote: S> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating S> pptp/l2tp tunnels. S> S> I'm using MPPC (Compression & Encryption), my current onfiguration i use S> only IPv4. S> S> I keep getting in the logs the following: S> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is S> too small for IPv6 S> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is S> too small for IPv6 S> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is S> too small for IPv6 S> S> although the NG tunnels don't negotiate IPv6. S> S> a close look to the MPD log i see that this happens for connections that S> set MRU/MTU 1400. S> S> I talked to MPD developer (Alexander Motin) and this isn't a MPD problem, S> rather than a kernel issue as the logs say. Message is logged by kernel, but MTU is set by userland. Can you check value of MTU with ifconfig, looking at an interface from most recent discussed message? Is it really 1218? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 12:11:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1AD81065670; Wed, 4 Jan 2012 12:11:37 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9A38FC08; Wed, 4 Jan 2012 12:11:37 +0000 (UTC) Received: by iadj38 with SMTP id j38so40899109iad.13 for ; Wed, 04 Jan 2012 04:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VJYQOIW3rVdXKtI1vO7jsFLkaD/zH/rx27XcD454Wp4=; b=k/ESxTop6+Eb1Qw0S2XAyn/05jsyHf7hhzCFtlYTTDbEKtxmv7In+eO4rHrkkGA3pa xrm9f6dEzNs+Rs9x65fgDa30BbmtrmRoZmCC3848Ez3Un3GnN4bXQJhDZrIaWYd0XeIg 7FQ8Huu3Gx5M5BBT5sL6AopzkycvMZWfM2gFU= MIME-Version: 1.0 Received: by 10.50.40.129 with SMTP id x1mr79829709igk.4.1325679097131; Wed, 04 Jan 2012 04:11:37 -0800 (PST) Received: by 10.231.41.206 with HTTP; Wed, 4 Jan 2012 04:11:37 -0800 (PST) In-Reply-To: <20120104120150.GG34721@FreeBSD.org> References: <20120104120150.GG34721@FreeBSD.org> Date: Wed, 4 Jan 2012 14:11:37 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:11:38 -0000 Hi, i just tested the last log: %tail /var/log/messages Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) is too small for IPv6 Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) is too small for IPv6 Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) is too small for IPv6 Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) is too small for IPv6 Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) is too small for IPv6 Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is too small for IPv6 Jan 4 14:17:34 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) is too small for IPv6 %ifconfig ng120 ng120: flags=88d1 metric 0 mtu 1218 inet 188.64.96.5 --> 188.64.102.171 netmask 0xffffffff so MTU is indeed 1218 Sami 2012/1/4 Gleb Smirnoff > On Wed, Jan 04, 2012 at 12:59:18PM +0200, Sami Halabi wrote: > S> I'm using a FreeBSD8.2-R-p5 in conjunction with MPD5.5 port for creating > S> pptp/l2tp tunnels. > S> > S> I'm using MPPC (Compression & Encryption), my current onfiguration i use > S> only IPv4. > S> > S> I keep getting in the logs the following: > S> Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) > is > S> too small for IPv6 > S> Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) > is > S> too small for IPv6 > S> Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) is > S> too small for IPv6 > S> > S> although the NG tunnels don't negotiate IPv6. > S> > S> a close look to the MPD log i see that this happens for connections that > S> set MRU/MTU 1400. > S> > S> I talked to MPD developer (Alexander Motin) and this isn't a MPD > problem, > S> rather than a kernel issue as the logs say. > > Message is logged by kernel, but MTU is set by userland. Can you check > value of MTU with ifconfig, looking at an interface from most recent > discussed message? Is it really 1218? > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 12:42:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC4E106564A; Wed, 4 Jan 2012 12:42:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id EBCE68FC16; Wed, 4 Jan 2012 12:42:52 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B3EBF25D37C7; Wed, 4 Jan 2012 12:42:51 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E5D37BD874A; Wed, 4 Jan 2012 12:42:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5krsxigkax2R; Wed, 4 Jan 2012 12:42:49 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CD383BD8749; Wed, 4 Jan 2012 12:42:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 4 Jan 2012 12:42:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <677F88A9-D07A-4FDA-A324-9167B88D9040@lists.zabbadoz.net> References: <20120104120150.GG34721@FreeBSD.org> To: Sami Halabi X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: kernel: nd6_setmtu0: new link MTU on ng29 (1218) is too small for IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:42:53 -0000 On 4. Jan 2012, at 12:11 , Sami Halabi wrote: > Hi, > i just tested the last log: > %tail /var/log/messages > Jan 3 23:21:50 mpd2 kernel: nd6_setmtu0: new link MTU on ng92 (1218) = is > too small for IPv6 > Jan 4 00:00:36 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) = is > too small for IPv6 > Jan 4 00:34:48 mpd2 kernel: nd6_setmtu0: new link MTU on ng105 (1218) = is > too small for IPv6 > Jan 4 07:47:37 mpd2 kernel: nd6_setmtu0: new link MTU on ng100 (1218) = is > too small for IPv6 > Jan 4 08:31:55 mpd2 kernel: nd6_setmtu0: new link MTU on ng116 (1218) = is > too small for IPv6 > Jan 4 09:16:21 mpd2 kernel: nd6_setmtu0: new link MTU on ng123 (1218) = is > too small for IPv6 > Jan 4 12:55:32 mpd2 kernel: nd6_setmtu0: new link MTU on ng53 (1218) = is > too small for IPv6 > Jan 4 14:17:34 mpd2 kernel: nd6_setmtu0: new link MTU on ng120 (1218) = is > too small for IPv6 > %ifconfig ng120 > ng120: flags=3D88d1 = metric 0 > mtu 1218 > inet 188.64.96.5 --> 188.64.102.171 netmask 0xffffffff >=20 > so MTU is indeed 1218 But that MTU should be a result of ppp/LCP negotiations of individual = sessions. It seems you have peers thinking they want a really small MTU and you = allow it? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 12:45:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 863A3106566C; Wed, 4 Jan 2012 12:45:30 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEB08FC0A; Wed, 4 Jan 2012 12:45:30 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4E11525D3810; Wed, 4 Jan 2012 12:45:29 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5E7FEBD874A; Wed, 4 Jan 2012 12:45:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XaZA2bsP4ndn; Wed, 4 Jan 2012 12:45:27 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 430ADBD8749; Wed, 4 Jan 2012 12:45:27 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> Date: Wed, 4 Jan 2012 12:45:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Net , Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:45:30 -0000 On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: > On 29. Dec 2011, at 20:27 , John Baldwin wrote: >> I've gone ahead with this approach. I have three separate patches = that should >> implement Phase 1. All of them can be found at >> http://www.FreeBSD.org/~jhb/patches/ >>=20 >> - if_addr_dev.patch This fixes a few new device drivers that = were using >> the locking macros directly rather than the = wrapper >> functions Robert added. I've already sent = this >> directly to the relevant driver maintainers = for their >> review. >> - if_addr_macros.patch This adds new locking macros to support read = locks vs >> write locks. However, they all still map to = mutex >> operations. >=20 > The first two look good. I wondered why you didn't need the = r-wraper-functions > but obviously they had been named like that already:) >=20 >=20 > I'll look at the one below in more detail and get back to you. >=20 >> - if_addr_uses.patch This changes callers of the existing macros = to use >> either read or write locks. This is the patch = that >> could use the most review. I went through this one as well. I skipped mld6.c, in6.c, igmp.c and in.c as they need to be regenerated. in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance currently but that's unrelated. The other conversions to R/W locking seemed ok. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 13:14:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39CFA1065673 for ; Wed, 4 Jan 2012 13:14:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1136E8FC08 for ; Wed, 4 Jan 2012 13:14:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id BE7FA46B0A; Wed, 4 Jan 2012 08:14:08 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42F55B944; Wed, 4 Jan 2012 08:14:08 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 4 Jan 2012 08:09:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4F041C54.4010904@my.gd> In-Reply-To: <4F041C54.4010904@my.gd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201040809.38706.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jan 2012 08:14:08 -0500 (EST) Cc: Damien Fleuriot Subject: Re: Any recommendations for a 10G NIC from Broadcom X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:14:09 -0000 On Wednesday, January 04, 2012 4:31:00 am Damien Fleuriot wrote: > On 1/4/12 6:10 AM, Vijay Singh wrote: > > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > > promising. I am looking for features such as multi-queue, MSI-X, TSO > > etc. Any recommendations would be greatly appreciated. > > > > > Now, I'm going to offer you an indirect response. > > Jack Vogel, who works at Intel, writes and maintains the code for most > (all?) the Intel NICs on FreeBSD. > > If I had to make a choice between Broadcom and Intel, I'd go with Intel > for this very reason. OTOH, Broadcom also has a commiter on staff who helps to maintain FreeBSD drivers (David Christensen - davidch@). There is a bxe(4) driver in 9.0 and later (albeit missing a manpage) which supports some Broadcom 10G NICs: BCM57710, BCM57711, and BCM57711E. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 13:42:17 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241B4106566B for ; Wed, 4 Jan 2012 13:42:17 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 6A4FE8FC0C for ; Wed, 4 Jan 2012 13:42:15 +0000 (UTC) Received: (qmail 15401 invoked from network); 4 Jan 2012 13:42:14 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Jan 2012 13:42:14 -0000 Date: Wed, 04 Jan 2012 14:42:14 +0100 (CET) Message-Id: <20120104.144214.74742226.sthaug@nethelp.no> To: ndenev@gmail.com From: sthaug@nethelp.no In-Reply-To: <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, dougb@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:42:17 -0000 > You are setting the keys with setkey for both directions of a single session, right? > i.e.: > > add X.X.X.X Y.Y.Y.Y tcp 0x1000 -A tcp-md5 "SomePass"; > add Y.Y.Y.Y X.X.X.X tcp 0x1000 -A tcp-md5 "SomePass"; > > As before it was only needed to set the "outgoing" direction key, which should not work anymore unless > net.inet.tcp.signature_verify_input is zero. Are you sure? I have net.inet.tcp.signature_verify_input = 1 and only one line in /etc/ipsec.conf for each BGP session using MD5 keys, on 8.2-STABLE. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 15:47:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64944106566C; Wed, 4 Jan 2012 15:47:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id E4E608FC15; Wed, 4 Jan 2012 15:47:38 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CC62325D3870; Wed, 4 Jan 2012 15:47:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EB5C5BD876E; Wed, 4 Jan 2012 15:47:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CyazXpBrVY5T; Wed, 4 Jan 2012 15:47:35 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B24D1BD876D; Wed, 4 Jan 2012 15:47:35 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org> Date: Wed, 4 Jan 2012 15:47:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4D3CFC08-7DE4-4620-B8FC-162CEEA14F75@FreeBSD.org> References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Net , Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 15:47:39 -0000 On 4. Jan 2012, at 12:45 , Bjoern A. Zeeb wrote: >=20 > On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: >=20 >> On 29. Dec 2011, at 20:27 , John Baldwin wrote: >>> I've gone ahead with this approach. I have three separate patches = that should >>> implement Phase 1. All of them can be found at >>> http://www.FreeBSD.org/~jhb/patches/ >>>=20 >>> - if_addr_dev.patch This fixes a few new device drivers that = were using >>> the locking macros directly rather than the = wrapper >>> functions Robert added. I've already sent = this >>> directly to the relevant driver maintainers = for their >>> review. >>> - if_addr_macros.patch This adds new locking macros to support = read locks vs >>> write locks. However, they all still map to = mutex >>> operations. >>=20 >> The first two look good. I wondered why you didn't need the = r-wraper-functions >> but obviously they had been named like that already:) >>=20 >>=20 >> I'll look at the one below in more detail and get back to you. >>=20 >>> - if_addr_uses.patch This changes callers of the existing macros = to use >>> either read or write locks. This is the patch = that >>> could use the most review. >=20 > I went through this one as well. >=20 > I skipped mld6.c, in6.c, igmp.c and in.c as they need to be = regenerated. > in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance > currently but that's unrelated. The other conversions to R/W locking > seemed ok. The other 4 seem ok in the regen'ed version though I didn't fully check all RLOCKs into called functions in the two multicast ones. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 15:49:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29C31065675; Wed, 4 Jan 2012 15:49:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 77BD68FC14; Wed, 4 Jan 2012 15:49:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 3044846B0D; Wed, 4 Jan 2012 10:49:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B5384B924; Wed, 4 Jan 2012 10:49:57 -0500 (EST) From: John Baldwin To: "Bjoern A. Zeeb" Date: Wed, 4 Jan 2012 10:49:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> <76A806B1-6D12-46DD-BC9D-F3CBDC587330@FreeBSD.org> <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org> In-Reply-To: <21AEF92A-94B5-4115-91A7-D3BEEFDAB433@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201041049.57187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jan 2012 10:49:57 -0500 (EST) Cc: FreeBSD Net , Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 15:49:58 -0000 On Wednesday, January 04, 2012 7:45:26 am Bjoern A. Zeeb wrote: > > On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote: > > > On 29. Dec 2011, at 20:27 , John Baldwin wrote: > >> I've gone ahead with this approach. I have three separate patches that should > >> implement Phase 1. All of them can be found at > >> http://www.FreeBSD.org/~jhb/patches/ > >> > >> - if_addr_dev.patch This fixes a few new device drivers that were using > >> the locking macros directly rather than the wrapper > >> functions Robert added. I've already sent this > >> directly to the relevant driver maintainers for their > >> review. > >> - if_addr_macros.patch This adds new locking macros to support read locks vs > >> write locks. However, they all still map to mutex > >> operations. > > > > The first two look good. I wondered why you didn't need the r-wraper-functions > > but obviously they had been named like that already:) > > > > > > I'll look at the one below in more detail and get back to you. > > > >> - if_addr_uses.patch This changes callers of the existing macros to use > >> either read or write locks. This is the patch that > >> could use the most review. > > I went through this one as well. > > I skipped mld6.c, in6.c, igmp.c and in.c as they need to be regenerated. > in nd6_rtr.c/prelist_update I think we are lacking an ifa_ref() dance > currently but that's unrelated. The other conversions to R/W locking > seemed ok. if_addr_uses.patch is now updated. I think prelist_update is fine because i doesn't actually use the memory referenced by the one pointer it uses after dropping the IF_ADDR_LOCK. It merely checks it against NULL to see if it found anything useful. For that case no reference count is needed. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 17:08:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2620D1065710; Wed, 4 Jan 2012 17:08:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A049C8FC12; Wed, 4 Jan 2012 17:08:15 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so23006136vcb.13 for ; Wed, 04 Jan 2012 09:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kkz3pSLe347C0i4MJWVuj/d1WVshWqockYSfD2oVf0M=; b=ZF4GueV3eP75LmHkDOb5gtSIWlFsVcj7OfupvezYKWs7qFBzRLQ2RZ85jpwoiqkklf SWzBv3Ed5yyCVF48HXtfvgB4Ub6ewchkblUb9dPPQlcMC1PWX+qE1a7FZ42UW9F3Oroz ZY1nd3ow1GBIKGDiyNexmvfa8/KJjmAZCaM8Q= MIME-Version: 1.0 Received: by 10.220.213.137 with SMTP id gw9mr33087912vcb.3.1325696894732; Wed, 04 Jan 2012 09:08:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 4 Jan 2012 09:08:14 -0800 (PST) In-Reply-To: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> Date: Wed, 4 Jan 2012 09:08:14 -0800 X-Google-Sender-Auth: 4a9C4B-gj9zvtawsZYYdO9BmStg Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Marius Strobl , freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 17:08:16 -0000 I'm including -net here so we can try and pull in further feedback from network-cluey people. On 4 January 2012 08:03, Stefan Bethke wrote: > As discussed recently, ray@, adrian@ and myself are trying to get a frame= work and utility into the tree that allows the use and configuration of eth= ernet switch chips. =A0The switch controllers we've looked at so far share = a number of features, in particular they use 802.3 MII, MDIO and PHYs to im= plement and configure the ports they offer. =A0In addition to being a switc= h, some of them also offer one of the built-in PHYs to the ethernet control= ler as a classical PHY. [snip] > I'd like to extend miibus in such a way that the one-to-one mapping betwe= en MDIO and MII is broken up. =A0For that, I propose to add a new bus drive= r "mdiobus" (with appropriate resource management) that uses methods simila= r to miibus_if.m readreg and writereg to access an ethernet controllers' MD= IO master. =A0miibus then attaches to it as a child, claims one or more PHY= addresses and attaches PHYs to itself (as currently implemented). This sounds like a good idea. I wonder what's stopping us from doing that. = :) > There's one issue that I don't have a proposal for yet: in one platform (= AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it i= s being controlled via the switch controller's MDIO master, and the switch = controller being attached to arge1's MDIO. =A0If we want to attach an miibu= s for PHY4, we'd have to defer attachment of arge0 until arge1 has been pro= bed and can provide the MDIO attachment (and transitively the switch and it= 's mdio). =A0Note that we also have boards without a switch, but the two PH= Ys still being attached to only a single MDIO. =A0One possible way would be= for the MDIO driver to be separate from the ethernet driver, so that the n= ormal newbus dependency resolution can be used to ensure that mdio1 is atta= ched before arge0 is probed. =A0For the time being, I've worked around this= through hackery in if_arge.c. juli@ proposed something quite similar a few weeks ago. Now that I'm a little more clued up on this whole area, I now understand why she suggested it. I'm happy with "hacky" being in if_arge for now (I mean, there already _is_ ..) but this work seems like the right path to take to bring sanity to this whole setup in the longer term. Thanks for tackling this! Adrian From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 19:26:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517D1106566C for ; Wed, 4 Jan 2012 19:26:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 185218FC08 for ; Wed, 4 Jan 2012 19:26:44 +0000 (UTC) Received: by iadj38 with SMTP id j38so41538786iad.13 for ; Wed, 04 Jan 2012 11:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FL6nnQRMYCcFcN5N2Llo6M4R683H4/aHE00rncI604M=; b=N6hnZmDIW07jY03VwnPYp+WCSawuU8JVlA9T1nK5FXSPfL9WLs1OlieSVP3oFJgnR4 bT/3p2iFgazJ2C70jW/QaPBrNC4mbZ1Nc/Hp4Kgw+AE6oNslZn1S6Yot2xlzjv4SiFMH Q3CoUBazCWwuptbyREXVNICo1rtXwsv+txaWE= Received: by 10.50.46.166 with SMTP id w6mr68910061igm.6.1325705204454; Wed, 04 Jan 2012 11:26:44 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gf6sm118932146igb.1.2012.01.04.11.26.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 11:26:43 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 04 Jan 2012 11:26:41 -0800 From: YongHyeon PYUN Date: Wed, 4 Jan 2012 11:26:41 -0800 To: Vijay Singh Message-ID: <20120104192641.GA12245@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Any recommendations for a 10G NIC from Broadcom X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:26:45 -0000 On Tue, Jan 03, 2012 at 09:10:20PM -0800, Vijay Singh wrote: > Hi. I would like to try out a 10G NIC from Broadcom. The BCM5716 seems > promising. I am looking for features such as multi-queue, MSI-X, TSO > etc. Any recommendations would be greatly appreciated. > > -vijay > > PS: I'd be using FreeBSD 8.2 initially, and FreeBSD 9.x in a few months. AFAIK BCM5716 is a gigabit ethernet and bce(4) supports the controller. bce(4) lacks multi-queue support but all other hardware features are supported. Enabling multi-queue for both bce(4) and bge(4) is one of my TODO list but I couldn't find spare time to do that. As John said, bxe(4) supports Broadcom's 10G controllers, BCM5771x. The driver supports all hardware features you mentioned(including multi-queue through RSS/TSS). Unlike most other 10G controllers, these controllers support hardware based true LRO which would outperform software based implementation. bxe(4) is not available on 8.x yet. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 09:12:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CAA9106566B for ; Thu, 5 Jan 2012 09:12:59 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from mailfilter31.ihug.co.nz (mailfilter31.ihug.co.nz [203.109.136.31]) by mx1.freebsd.org (Postfix) with ESMTP id 009738FC12 for ; Thu, 5 Jan 2012 09:12:58 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=tm9qpUR5xacA:10 a=8nJEP1OIZ-IA:10 a=pOqw4vtHAW4xfxCD90uk0Q==:17 a=FpT0U-pAAAAA:8 a=aICdAxSOBveVTKwIbzoA:9 a=mJbu7byZv_bL78LjGjgA:7 a=wPNLvfGTeEIA:10 a=nPVq8361FmUA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFtmBU92XAcO/2dsb2JhbAApGqx1gQaCMR4iPRYYAwIBAgEnGBkIAQGHfiOVV58liHeDGgSVBY4AhEpW X-IronPort-AV: E=Sophos;i="4.71,461,1320577200"; d="scan'208";a="80588359" Received: from 118-92-7-14.dsl.dyn.ihug.co.nz (HELO spandex.luckie.org.nz) ([118.92.7.14]) by cust.filter2.content.vf.net.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jan 2012 21:59:24 +1300 Received: from mylar.luckie.org.nz ([192.168.1.24]) by spandex.luckie.org.nz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RijAR-000JJ9-JZ for freebsd-net@freebsd.org; Thu, 05 Jan 2012 21:59:23 +1300 Message-ID: <4F056691.4060403@luckie.org.nz> Date: Thu, 05 Jan 2012 22:00:01 +1300 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111231 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: minipcie wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:12:59 -0000 Hi I'd like to create a freebsd AP using my mini-itx board. I have a mini-pcie expansion slot and am considering this wifi card http://www.habeyusa.com/products_show.php?id=361 I currently run 8.2R but plan to upgrade to 9.0R. The main concern I have is that it lists its host interface as mini-pcie / USB, i.e. it might be a wifi card that is exposed to the system over a USB bus, which might not be optimal for a hostap. The docs say Atheros AR9285(MAC/Baseband/RF) with AR3011 -- I tend to think the AR3011 is an error in their docs as the card is not advertised as supporting bluetooth, and because an AR9285 is apparently exposed over PCIe, I tend to think the card will work fine as an hostap, but just want to double check. Anyone have any insight? Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 09:58:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434BB106564A for ; Thu, 5 Jan 2012 09:58:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id AC4C28FC08 for ; Thu, 5 Jan 2012 09:58:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q059wtiO056795; Thu, 5 Jan 2012 13:58:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q059wtgk056794; Thu, 5 Jan 2012 13:58:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Jan 2012 13:58:55 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120105095855.GI34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:58:57 -0000 Sami, I'm trying to reproduce a reordering problem with a new node, and I've found that: 1) PPTP uses sequencing, that would not pass out of sequence datagram to the PPP, and thus to MPPE. 2) L2TP uses sequencing optionally, so the problem in subject may appear only on an L2TP link with disabled sequencing. I wonder how often L2TP is running w/o sequencing control. Can you please run this script on your mpd box to estimate? #!/bin/sh IDS=$(ngctl ls | awk '{ if ($4 == "l2tp") print $6}') for id in $IDS; do id="[$id]:"; sess=$(ngctl show $id | sed -En 's/.*session_([0-9a-f]+).*/\1/p'); ngctl msg $id getsessconfig 0x$sess done In my small installation I've got only a couple of L2TP clients, and both use sequencing, so patched code in ng_mppc won't be ever executed. Rec'd response "getsessconfig" (4) from "[11f]:": Args: { session_id=0xafb6 peer_id=0x2fcf control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[f3]:": Args: { session_id=0xd34b peer_id=0x2654 control_dseq=1 enable_dseq=1 } I'd like to explicitly test the code in ng_mppc to make sure, that node can rekey up to 4096 times and continue operation. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 10:48:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92F5106566B; Thu, 5 Jan 2012 10:48:06 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0A58FC0A; Thu, 5 Jan 2012 10:48:06 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so591685obb.13 for ; Thu, 05 Jan 2012 02:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=edeK1Byfy0H97hugeF2MVTIDW8iw6QAhvxVE77sSJMU=; b=ilAAV1grPR/FDRlQnjPCGu46D+gaBGolD9D0uqeTK8chsfXEfYqAegNCE9gDFMb4bh YYrTT6Pam59WzPdLw89OM3N37Ta48oIe053eX81hCD5LJThV5A75D3DP3MZzfbz4gKUH at8Bz3scQchCDSCPV6jV8MLS78W5RQRrqCkkc= MIME-Version: 1.0 Received: by 10.50.188.132 with SMTP id ga4mr2730950igc.4.1325760485797; Thu, 05 Jan 2012 02:48:05 -0800 (PST) Received: by 10.231.41.206 with HTTP; Thu, 5 Jan 2012 02:48:05 -0800 (PST) In-Reply-To: <20120105095855.GI34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> Date: Thu, 5 Jan 2012 12:48:05 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:48:06 -0000 Hi, there is a problem whith this script: # ngctl ls | awk '{ if ($4 == "l2tp") print $6}' ngctl: send msg: No buffer space available Sami 2012/1/5 Gleb Smirnoff > Sami, > > I'm trying to reproduce a reordering problem with a new node, and > I've found that: > > 1) PPTP uses sequencing, that would not pass out of sequence datagram > to the PPP, and thus to MPPE. > 2) L2TP uses sequencing optionally, so the problem in subject may > appear only on an L2TP link with disabled sequencing. > > I wonder how often L2TP is running w/o sequencing control. Can you > please run this script on your mpd box to estimate? > > #!/bin/sh > > IDS=$(ngctl ls | awk '{ if ($4 == "l2tp") print $6}') > for id in $IDS; do > id="[$id]:"; > sess=$(ngctl show $id | sed -En 's/.*session_([0-9a-f]+).*/\1/p'); > ngctl msg $id getsessconfig 0x$sess > done > > In my small installation I've got only a couple of L2TP clients, and both > use sequencing, so patched code in ng_mppc won't be ever executed. > > Rec'd response "getsessconfig" (4) from "[11f]:": > Args: { session_id=0xafb6 peer_id=0x2fcf control_dseq=1 enable_dseq=1 } > Rec'd response "getsessconfig" (4) from "[f3]:": > Args: { session_id=0xd34b peer_id=0x2654 control_dseq=1 enable_dseq=1 } > > I'd like to explicitly test the code in ng_mppc to make sure, that node > can rekey up to 4096 times and continue operation. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 10:57:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2AA4106566B; Thu, 5 Jan 2012 10:57:30 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 14FEC8FC15; Thu, 5 Jan 2012 10:57:29 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q05AvOXf073332; Thu, 5 Jan 2012 17:57:24 +0700 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.5/8.14.5/Submit) id q05AvO6G073331; Thu, 5 Jan 2012 17:57:24 +0700 (NOVT) (envelope-from eugen) Date: Thu, 5 Jan 2012 17:57:24 +0700 From: Eugene Grosbein To: Sami Halabi Message-ID: <20120105105724.GA73290@rdtc.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:57:30 -0000 On Thu, Jan 05, 2012 at 12:48:05PM +0200, Sami Halabi wrote: > Hi, > there is a problem whith this script: > > # ngctl ls | awk '{ if ($4 == "l2tp") print $6}' > ngctl: send msg: No buffer space available You should try to increase kern.ipc.maxsockbuf, net.graph.maxdgram, net.graph.recvspace to 8M or higher with sysctl command, until this ngctl error disappears. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 11:01:18 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CBEE1065672 for ; Thu, 5 Jan 2012 11:01:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id A84E68FC12 for ; Thu, 5 Jan 2012 11:01:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q05B1GH3057148; Thu, 5 Jan 2012 15:01:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q05B1Gxv057147; Thu, 5 Jan 2012 15:01:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Jan 2012 15:01:16 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120105110116.GK34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 11:01:18 -0000 On Thu, Jan 05, 2012 at 12:48:05PM +0200, Sami Halabi wrote: S> Hi, S> there is a problem whith this script: S> S> # ngctl ls | awk '{ if ($4 == "l2tp") print $6}' S> ngctl: send msg: No buffer space available You have so much nodes, that 'ngctl ls' can't pass its reply to userland. Try to bump net.graph.recvspace sysctl to a larger value, for example: sysctl net.graph.recvspace=1048576 -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 11:21:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FEB5106566B; Thu, 5 Jan 2012 11:21:13 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 438168FC08; Thu, 5 Jan 2012 11:21:13 +0000 (UTC) Received: by iadj38 with SMTP id j38so1144286iad.13 for ; Thu, 05 Jan 2012 03:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VtLnXOdx3jzcfVZErHzZP/lJnaob3bzj8ox0L+7KU1c=; b=D8NKlhXk5IGi4j9CjuCmv00tgNJpU23LFeQyFiJCsCaqdSjX4WTdaCAZi6CgJQKtoU mTiXnjqkQiISazSOLHAPOqL1v3rwpmmBnw5Rs36jfbEkH2rG13HM0YCm1fc0Ftp7YKq9 ZXUxMq+TvWCGfDVcuS0MII/JtYwWqt4Q5dRaY= MIME-Version: 1.0 Received: by 10.50.40.129 with SMTP id x1mr2410677igk.4.1325762472631; Thu, 05 Jan 2012 03:21:12 -0800 (PST) Received: by 10.231.41.206 with HTTP; Thu, 5 Jan 2012 03:21:12 -0800 (PST) In-Reply-To: <20120105110116.GK34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> Date: Thu, 5 Jan 2012 13:21:12 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 11:21:13 -0000 Hi after i upgraded the recvspace here are the results: # ./a Rec'd response "getsessconfig" (4) from "[22995]:": Args: { session_id=0xcf4 peer_id=0x1bdc control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[228bd]:": Args: { session_id=0xee79 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[22883]:": Args: { session_id=0x1aa2 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[227f3]:": Args: { session_id=0x1414 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[22769]:": Args: { session_id=0x913f peer_id=0x4c44 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2272f]:": Args: { session_id=0x4038 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[225df]:": Args: { session_id=0xc460 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[225c5]:": Args: { session_id=0xe2b1 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[224ef]:": Args: { session_id=0xf21d peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[223e5]:": Args: { session_id=0x6d95 peer_id=0xf423 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2228c]:": Args: { session_id=0xd06c peer_id=0x8288 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[22274]:": Args: { session_id=0x8425 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[22218]:": Args: { session_id=0xedc7 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[221fc]:": Args: { session_id=0x4474 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[221ef]:": Args: { session_id=0xd2bb peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[221d5]:": Args: { session_id=0x9980 peer_id=0xa9e6 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2210d]:": Args: { session_id=0x97f peer_id=0xe8e control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[220c5]:": Args: { session_id=0x456 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2201a]:": Args: { session_id=0x1c38 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21d9c]:": Args: { session_id=0x21e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21c73]:": Args: { session_id=0xe657 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[219c1]:": Args: { session_id=0xc517 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2199f]:": Args: { session_id=0x1417 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21913]:": Args: { session_id=0x2eef peer_id=0x83f4 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21737]:": Args: { session_id=0xdbaa peer_id=0xb21b control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[216ce]:": Args: { session_id=0x60 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21560]:": Args: { session_id=0x4390 peer_id=0x6baa control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2142c]:": Args: { session_id=0xbcb5 peer_id=0x8ef8 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21231]:": Args: { session_id=0x8335 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21200]:": Args: { session_id=0x2b16 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[211f2]:": Args: { session_id=0x8022 peer_id=0x4095 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[211d7]:": Args: { session_id=0x51b7 peer_id=0xf716 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[21115]:": Args: { session_id=0x98a1 peer_id=0xd453 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[20699]:": Args: { session_id=0xb179 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[205a1]:": Args: { session_id=0x3328 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[2052f]:": Args: { session_id=0x55f peer_id=0x2a4b control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[20160]:": Args: { session_id=0xe4a5 peer_id=0x5b6 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1ff54]:": Args: { session_id=0xaa4d peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1fd8e]:": Args: { session_id=0xd9d8 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1e9bf]:": Args: { session_id=0xac50 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1dc3e]:": Args: { session_id=0x5124 peer_id=0xd652 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1d8b4]:": Args: { session_id=0xf5b9 peer_id=0xcd control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1d79e]:": Args: { session_id=0x9a87 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1d216]:": Args: { session_id=0xe89d peer_id=0xd74a control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[1c78f]:": Args: { session_id=0xe3e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[19344]:": Args: { session_id=0xf452 peer_id=0xbf7e control_dseq=1 enable_dseq=1 } Rec'd response "getsessconfig" (4) from "[18fb3]:": Args: { session_id=0x11b peer_id=0x4296 control_dseq=1 enable_dseq=1 } Sami 2012/1/5 Gleb Smirnoff > On Thu, Jan 05, 2012 at 12:48:05PM +0200, Sami Halabi wrote: > S> Hi, > S> there is a problem whith this script: > S> > S> # ngctl ls | awk '{ if ($4 == "l2tp") print $6}' > S> ngctl: send msg: No buffer space available > > You have so much nodes, that 'ngctl ls' can't pass its reply > to userland. > > Try to bump net.graph.recvspace sysctl to a larger value, for > example: > > sysctl net.graph.recvspace=1048576 > > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 11:34:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A514C1065670 for ; Thu, 5 Jan 2012 11:34:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id EC9F28FC0C for ; Thu, 5 Jan 2012 11:34:28 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q05BYRkW057370; Thu, 5 Jan 2012 15:34:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q05BYRGf057369; Thu, 5 Jan 2012 15:34:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Jan 2012 15:34:27 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120105113427.GL34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 11:34:29 -0000 On Thu, Jan 05, 2012 at 01:21:12PM +0200, Sami Halabi wrote: S> Hi S> S> after i upgraded the recvspace here are the results: S> # ./a S> Rec'd response "getsessconfig" (4) from "[22995]:": S> Args: { session_id=0xcf4 peer_id=0x1bdc control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[228bd]:": S> Args: { session_id=0xee79 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[22883]:": S> Args: { session_id=0x1aa2 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[227f3]:": S> Args: { session_id=0x1414 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[22769]:": S> Args: { session_id=0x913f peer_id=0x4c44 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2272f]:": S> Args: { session_id=0x4038 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[225df]:": S> Args: { session_id=0xc460 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[225c5]:": S> Args: { session_id=0xe2b1 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[224ef]:": S> Args: { session_id=0xf21d peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[223e5]:": S> Args: { session_id=0x6d95 peer_id=0xf423 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2228c]:": S> Args: { session_id=0xd06c peer_id=0x8288 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[22274]:": S> Args: { session_id=0x8425 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[22218]:": S> Args: { session_id=0xedc7 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[221fc]:": S> Args: { session_id=0x4474 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[221ef]:": S> Args: { session_id=0xd2bb peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[221d5]:": S> Args: { session_id=0x9980 peer_id=0xa9e6 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2210d]:": S> Args: { session_id=0x97f peer_id=0xe8e control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[220c5]:": S> Args: { session_id=0x456 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2201a]:": S> Args: { session_id=0x1c38 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21d9c]:": S> Args: { session_id=0x21e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21c73]:": S> Args: { session_id=0xe657 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[219c1]:": S> Args: { session_id=0xc517 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2199f]:": S> Args: { session_id=0x1417 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21913]:": S> Args: { session_id=0x2eef peer_id=0x83f4 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21737]:": S> Args: { session_id=0xdbaa peer_id=0xb21b control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[216ce]:": S> Args: { session_id=0x60 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21560]:": S> Args: { session_id=0x4390 peer_id=0x6baa control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2142c]:": S> Args: { session_id=0xbcb5 peer_id=0x8ef8 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21231]:": S> Args: { session_id=0x8335 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21200]:": S> Args: { session_id=0x2b16 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[211f2]:": S> Args: { session_id=0x8022 peer_id=0x4095 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[211d7]:": S> Args: { session_id=0x51b7 peer_id=0xf716 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[21115]:": S> Args: { session_id=0x98a1 peer_id=0xd453 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[20699]:": S> Args: { session_id=0xb179 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[205a1]:": S> Args: { session_id=0x3328 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[2052f]:": S> Args: { session_id=0x55f peer_id=0x2a4b control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[20160]:": S> Args: { session_id=0xe4a5 peer_id=0x5b6 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1ff54]:": S> Args: { session_id=0xaa4d peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1fd8e]:": S> Args: { session_id=0xd9d8 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1e9bf]:": S> Args: { session_id=0xac50 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1dc3e]:": S> Args: { session_id=0x5124 peer_id=0xd652 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1d8b4]:": S> Args: { session_id=0xf5b9 peer_id=0xcd control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1d79e]:": S> Args: { session_id=0x9a87 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1d216]:": S> Args: { session_id=0xe89d peer_id=0xd74a control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[1c78f]:": S> Args: { session_id=0xe3e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[19344]:": S> Args: { session_id=0xf452 peer_id=0xbf7e control_dseq=1 enable_dseq=1 } S> Rec'd response "getsessconfig" (4) from "[18fb3]:": S> Args: { session_id=0x11b peer_id=0x4296 control_dseq=1 enable_dseq=1 } Hmm, looks like enable_dseq=1 everywhere. Then I have no idea yet, when at which circumstances ng_mppc can receive an out of order datagram. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 13:33:36 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E59106564A; Thu, 5 Jan 2012 13:33:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1F78FC1C; Thu, 5 Jan 2012 13:33:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q05DXZ0n032435; Thu, 5 Jan 2012 13:33:35 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q05DXZWw032430; Thu, 5 Jan 2012 13:33:35 GMT (envelope-from glebius) Date: Thu, 5 Jan 2012 13:33:35 GMT Message-Id: <201201051333.q05DXZWw032430@freefall.freebsd.org> To: msaf1980@rambler.ru, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/123045: [ng_mppc] ng_mppc_decompress - disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:33:36 -0000 Synopsis: [ng_mppc] ng_mppc_decompress - disabling node State-Changed-From-To: feedback->closed State-Changed-By: glebius State-Changed-When: Thu Jan 5 13:33:16 UTC 2012 State-Changed-Why: Email of submitter is no longer valid. http://www.freebsd.org/cgi/query-pr.cgi?pr=123045 From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 13:43:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E140106564A; Thu, 5 Jan 2012 13:43:47 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D944D8FC0C; Thu, 5 Jan 2012 13:43:46 +0000 (UTC) Received: by iadj38 with SMTP id j38so1382652iad.13 for ; Thu, 05 Jan 2012 05:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iG9YHsFv2G2YSAbbdtRfADtGC+uwkmWsNkFUZ7ztb6g=; b=k8m7GftFG89XKpdCCEpY5K+z2cySDjYTlUXtZ8r6B389xOlsvFMG5WpvcTHxveyxQr 9yHBPtzaj7yZ7SCfvp17dq/5Jdret8gS++WjH38ABYg9GKC3NBXg0tf6I078uL9Wl2tg qbGtsAADNEsw8KwKO+k2Fucf0HWwZ2ojJ55bA= MIME-Version: 1.0 Received: by 10.42.117.193 with SMTP id u1mr2100141icq.24.1325771026097; Thu, 05 Jan 2012 05:43:46 -0800 (PST) Received: by 10.231.41.206 with HTTP; Thu, 5 Jan 2012 05:43:45 -0800 (PST) In-Reply-To: <20120105113427.GL34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> Date: Thu, 5 Jan 2012 15:43:45 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff , Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:43:47 -0000 Hmm.. Somthing strange, i did: net.graph.recvspace=8388608 net.graph.maxdgram=8388608 and i suddenly got disconnections and logs like: Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available the mpd as follows: Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:03 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 Jan 5 16:10:03 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:06 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 Jan 5 16:10:06 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown Jan 5 16:10:16 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 Jan 5 16:10:16 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:21 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 Jan 5 16:10:21 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Jan 5 16:10:23 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 Jan 5 16:10:23 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space available Now i just returned to my original sysctl: net.graph.recvspace=40960 net.graph.maxdgram=40960 and everything seems fine any ideas? Sami 2012/1/5 Gleb Smirnoff > On Thu, Jan 05, 2012 at 01:21:12PM +0200, Sami Halabi wrote: > S> Hi > S> > S> after i upgraded the recvspace here are the results: > S> # ./a > S> Rec'd response "getsessconfig" (4) from "[22995]:": > S> Args: { session_id=0xcf4 peer_id=0x1bdc control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[228bd]:": > S> Args: { session_id=0xee79 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[22883]:": > S> Args: { session_id=0x1aa2 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[227f3]:": > S> Args: { session_id=0x1414 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[22769]:": > S> Args: { session_id=0x913f peer_id=0x4c44 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[2272f]:": > S> Args: { session_id=0x4038 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[225df]:": > S> Args: { session_id=0xc460 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[225c5]:": > S> Args: { session_id=0xe2b1 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[224ef]:": > S> Args: { session_id=0xf21d peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[223e5]:": > S> Args: { session_id=0x6d95 peer_id=0xf423 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[2228c]:": > S> Args: { session_id=0xd06c peer_id=0x8288 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[22274]:": > S> Args: { session_id=0x8425 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[22218]:": > S> Args: { session_id=0xedc7 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[221fc]:": > S> Args: { session_id=0x4474 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[221ef]:": > S> Args: { session_id=0xd2bb peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[221d5]:": > S> Args: { session_id=0x9980 peer_id=0xa9e6 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[2210d]:": > S> Args: { session_id=0x97f peer_id=0xe8e control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[220c5]:": > S> Args: { session_id=0x456 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[2201a]:": > S> Args: { session_id=0x1c38 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[21d9c]:": > S> Args: { session_id=0x21e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[21c73]:": > S> Args: { session_id=0xe657 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[219c1]:": > S> Args: { session_id=0xc517 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[2199f]:": > S> Args: { session_id=0x1417 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[21913]:": > S> Args: { session_id=0x2eef peer_id=0x83f4 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[21737]:": > S> Args: { session_id=0xdbaa peer_id=0xb21b control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[216ce]:": > S> Args: { session_id=0x60 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[21560]:": > S> Args: { session_id=0x4390 peer_id=0x6baa control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[2142c]:": > S> Args: { session_id=0xbcb5 peer_id=0x8ef8 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[21231]:": > S> Args: { session_id=0x8335 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[21200]:": > S> Args: { session_id=0x2b16 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[211f2]:": > S> Args: { session_id=0x8022 peer_id=0x4095 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[211d7]:": > S> Args: { session_id=0x51b7 peer_id=0xf716 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[21115]:": > S> Args: { session_id=0x98a1 peer_id=0xd453 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[20699]:": > S> Args: { session_id=0xb179 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[205a1]:": > S> Args: { session_id=0x3328 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[2052f]:": > S> Args: { session_id=0x55f peer_id=0x2a4b control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[20160]:": > S> Args: { session_id=0xe4a5 peer_id=0x5b6 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1ff54]:": > S> Args: { session_id=0xaa4d peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1fd8e]:": > S> Args: { session_id=0xd9d8 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1e9bf]:": > S> Args: { session_id=0xac50 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1dc3e]:": > S> Args: { session_id=0x5124 peer_id=0xd652 control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[1d8b4]:": > S> Args: { session_id=0xf5b9 peer_id=0xcd control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1d79e]:": > S> Args: { session_id=0x9a87 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[1d216]:": > S> Args: { session_id=0xe89d peer_id=0xd74a control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[1c78f]:": > S> Args: { session_id=0xe3e5 peer_id=0x1 control_dseq=1 enable_dseq=1 } > S> Rec'd response "getsessconfig" (4) from "[19344]:": > S> Args: { session_id=0xf452 peer_id=0xbf7e control_dseq=1 enable_dseq=1 > } > S> Rec'd response "getsessconfig" (4) from "[18fb3]:": > S> Args: { session_id=0x11b peer_id=0x4296 control_dseq=1 enable_dseq=1 } > > Hmm, looks like enable_dseq=1 everywhere. Then I have no idea yet, when > at which circumstances ng_mppc can receive an out of order datagram. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 13:44:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F45C1065677 for ; Thu, 5 Jan 2012 13:44:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id C048E8FC13 for ; Thu, 5 Jan 2012 13:44:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q05DiXUv057953; Thu, 5 Jan 2012 17:44:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q05DiX1V057952; Thu, 5 Jan 2012 17:44:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Jan 2012 17:44:33 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120105134433.GO34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FsscpQKzF/jJk6ya" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:44:35 -0000 --FsscpQKzF/jJk6ya Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sami, I am running not with the exact patch that I've sent to you, but with additional debugging printf, see attach. I'd like to make sure that after such a large rekeying event the PPP link is still valid. Since I can't cook this reordering case by hand, can you please eventually patch your ng_mppc with attached patch and reload it. The functionality is the same as the previous patch, but a printf is added. And we need to ping peers IP address as soon as we see the printf in logs. If the event happens very rarely, then some script needs to be written, that monitors system log and once printf fires, it should find interface name via ng_mppc node ID, and then take peers IP address and send a ping probe. If ping is replied, then MPPE survives this large rekeying and code can be considered functional. -- Totus tuus, Glebius. --FsscpQKzF/jJk6ya Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="ng_mppc.c.diff" Index: ng_mppc.c =================================================================== --- ng_mppc.c (revision 229571) +++ ng_mppc.c (working copy) @@ -98,15 +98,6 @@ /* Key length */ #define KEYLEN(b) (((b) & MPPE_128) ? 16 : 8) -/* - * When packets are lost with MPPE, we may have to re-key arbitrarily - * many times to 'catch up' to the new jumped-ahead sequence number. - * Since this can be expensive, we pose a limit on how many re-keyings - * we will do at one time to avoid a possible D.O.S. vulnerability. - * This should instead be a configurable parameter. - */ -#define MPPE_MAX_REKEY 1000 - /* MPPC packet header bits */ #define MPPC_FLAG_FLUSHED 0x8000 /* xmitter reset state */ #define MPPC_FLAG_RESTART 0x4000 /* compress history restart */ @@ -641,20 +632,22 @@ #endif #ifdef NETGRAPH_MPPC_ENCRYPTION if ((d->cfg.bits & MPPE_BITS) != 0) { - u_int rekey; + u_int rekey; + + /* How many times are we going to have to re-key? */ + rekey = ((d->cfg.bits & MPPE_STATELESS) != 0) ? + numLost : (numLost / (MPPE_UPDATE_MASK + 1)); + if (rekey > 1000) + log(LOG_ERR, "%s: %d packets dropped, " + "node [%x]\n", __func__, numLost, + node->nd_ID); - /* How many times are we going to have to re-key? */ - rekey = ((d->cfg.bits & MPPE_STATELESS) != 0) ? - numLost : (numLost / (MPPE_UPDATE_MASK + 1)); - if (rekey > MPPE_MAX_REKEY) { - log(LOG_ERR, "%s: too many (%d) packets" - " dropped, disabling node %p!", - __func__, numLost, node); - priv->recv.cfg.enable = 0; - goto failed; - } - - /* Re-key as necessary to catch up to peer */ + /* + * When packets are lost or re-ordered with MPPE, + * we may have to re-key up to 0xfff times to 'catch + * up' to the new jumped-ahead sequence number. Yep, + * this is heavy, but what else can we do? + */ while (d->cc != cc) { if ((d->cfg.bits & MPPE_STATELESS) != 0 || (d->cc & MPPE_UPDATE_MASK) --FsscpQKzF/jJk6ya-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 13:49:04 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BE7E106568C; Thu, 5 Jan 2012 13:49:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id DC7508FC14; Thu, 5 Jan 2012 13:49:03 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q05Dn2Wa057994; Thu, 5 Jan 2012 17:49:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q05Dn2YM057993; Thu, 5 Jan 2012 17:49:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Jan 2012 17:49:02 +0400 From: Gleb Smirnoff To: Sami Halabi Message-ID: <20120105134902.GP34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Alexander Motin Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:49:04 -0000 On Thu, Jan 05, 2012 at 03:43:45PM +0200, Sami Halabi wrote: S> Hmm.. S> S> Somthing strange, i did: S> net.graph.recvspace=8388608 S> net.graph.maxdgram=8388608 S> S> S> and i suddenly got disconnections and logs like: S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available S> S> the mpd as follows: S> S> Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:03 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 S> Jan 5 16:10:03 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:06 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 S> Jan 5 16:10:06 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown S> Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown S> Jan 5 16:10:16 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 S> Jan 5 16:10:16 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:21 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 S> Jan 5 16:10:21 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> Jan 5 16:10:23 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 S> Jan 5 16:10:23 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space S> available S> S> S> Now i just returned to my original sysctl: S> net.graph.recvspace=40960 S> net.graph.maxdgram=40960 S> S> and everything seems fine S> S> any ideas? mpd has many open sockets, and each socket allocates that much recvspace and sendspace. Since there are a lot of them, it hits per-user resource limits, I suppose. We need to: 1) Change mpd to use one control socket with many hooks. This also requires improving ng_socket, to have a fast hook lookup method. 2) Implement SO_SNDBUF/SO_RCVBUF for AF_NETGRAPH socket, and utilize it in ngctl, so there would be no need to bump global tunables. Eventually I may do this, but I need brave testers, since my mpd installation is very small. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 14:16:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E352106566B; Thu, 5 Jan 2012 14:16:25 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD1538FC18; Thu, 5 Jan 2012 14:16:24 +0000 (UTC) Received: by ggnp1 with SMTP id p1so229708ggn.13 for ; Thu, 05 Jan 2012 06:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tMeSTAnCH7v11Sdjjv5bJtP8/TcnEZF/HZqEfVzafpY=; b=pwt//hJy0z70YH0j5ZCTDRGWQalBVGQT3Owc5Src1r5dsQX6vpQmQ6wxlIj6qbMwms RI3QjwH4Ka8lNj66KpH22WHQ7OumsenSniO0DS3KhgltoWeQOoHQdt2bkdYpLROHTnve 1KT1RulQ+1oArmEhi3QD54BgS+Wu3PKVe3pmI= MIME-Version: 1.0 Received: by 10.50.188.132 with SMTP id ga4mr3854007igc.4.1325772983836; Thu, 05 Jan 2012 06:16:23 -0800 (PST) Received: by 10.231.41.206 with HTTP; Thu, 5 Jan 2012 06:16:22 -0800 (PST) In-Reply-To: <20120105134902.GP34721@glebius.int.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> <20120105134902.GP34721@glebius.int.ru> Date: Thu, 5 Jan 2012 16:16:22 +0200 Message-ID: From: Sami Halabi To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:16:25 -0000 Hi, is setting these sysctl's that high recommended? i don't really know what they mean, and honestly didn't search to see what they do, i simply tried to set them high in order to improve the service. if its recommended, then i would test these changes if they will be done. Sami 2012/1/5 Gleb Smirnoff > On Thu, Jan 05, 2012 at 03:43:45PM +0200, Sami Halabi wrote: > S> Hmm.. > S> > S> Somthing strange, i did: > S> net.graph.recvspace=8388608 > S> net.graph.maxdgram=8388608 > S> > S> > S> and i suddenly got disconnections and logs like: > S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available > S> > S> the mpd as follows: > S> > S> Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 > S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:01 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 > S> Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:03 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 > S> Jan 5 16:10:03 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:06 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 > S> Jan 5 16:10:06 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart > S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call > S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available > S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Accepting PPTP connection > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: OPEN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Open event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Initial --> Starting > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerStart > S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP: attaching to peer's outgoing call > S> Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available > S> Jan 5 16:10:11 mpd2 mpd: [L-14] PPTP call cancelled in state CONNECTING > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: DOWN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Close event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: state change Starting --> Initial > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: LayerFinish > S> Jan 5 16:10:11 mpd2 mpd: [L-14] LCP: Down event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: SHUTDOWN event > S> Jan 5 16:10:11 mpd2 mpd: [L-14] Link: Shutdown > S> Jan 5 16:10:16 mpd2 mpd: Incoming L2TP packet from 172.27.173.112 1701 > S> Jan 5 16:10:16 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:21 mpd2 mpd: Incoming L2TP packet from 172.25.229.3 1701 > S> Jan 5 16:10:21 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> Jan 5 16:10:23 mpd2 mpd: Incoming L2TP packet from 172.19.246.206 1701 > S> Jan 5 16:10:23 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > S> available > S> > S> > S> Now i just returned to my original sysctl: > S> net.graph.recvspace=40960 > S> net.graph.maxdgram=40960 > S> > S> and everything seems fine > S> > S> any ideas? > > mpd has many open sockets, and each socket allocates that much recvspace > and sendspace. Since there are a lot of them, it hits per-user resource > limits, I suppose. > > We need to: > > 1) Change mpd to use one control socket with many hooks. > This also requires improving ng_socket, to have a fast hook lookup > method. > > 2) Implement SO_SNDBUF/SO_RCVBUF for AF_NETGRAPH socket, and utilize > it in ngctl, so there would be no need to bump global tunables. > > Eventually I may do this, but I need brave testers, since my mpd > installation is very small. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 15:01:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64D0D106566B for ; Thu, 5 Jan 2012 15:01:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E2EBF8FC13 for ; Thu, 5 Jan 2012 15:01:55 +0000 (UTC) Received: by eekc50 with SMTP id c50so492920eek.13 for ; Thu, 05 Jan 2012 07:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Fhybjex9VjbAXYnahIjWVTIwDSuPF4AetGgLQ4GtlVY=; b=fy3hus+2t2Xglm9Qu/n85LGZ1L3oWxdrihPO/oj7LplyBff9+kTqCDJYEkhHF1mEwJ EIjDxlgo434Kwelwk56rophr2uzef+eCGyhoeT87JrpGhnZILdKPbLEgQHckc4xAa090 aQX9hsMcd7+k1R61bgg9nthKIBRzuoA79QwhU= Received: by 10.213.13.10 with SMTP id z10mr543002ebz.63.1325774052125; Thu, 05 Jan 2012 06:34:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id b49sm203138214eec.9.2012.01.05.06.34.09 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 06:34:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4F05B4DA.5030606@FreeBSD.org> Date: Thu, 05 Jan 2012 16:34:02 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> <20120105134902.GP34721@glebius.int.ru> In-Reply-To: <20120105134902.GP34721@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Sami Halabi Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:01:56 -0000 On 05.01.2012 15:49, Gleb Smirnoff wrote: > mpd has many open sockets, and each socket allocates that much recvspace > and sendspace. Since there are a lot of them, it hits per-user resource > limits, I suppose. > > We need to: > > 1) Change mpd to use one control socket with many hooks. It is partially done. mpd uses common sockets to connect ppp, ccp and ecp nodes of all links. But some link types still could be improved. > This also requires improving ng_socket, to have a fast hook lookup > method. Agree. > 2) Implement SO_SNDBUF/SO_RCVBUF for AF_NETGRAPH socket, and utilize > it in ngctl, so there would be no need to bump global tunables. It would be nice. The biggest consumer of socket buffers I remember is `ngctl list`. May be it could be reimplemented somehow to transfer information in smaller chunks. By the way about features: there were request recently to allow PPPoE over ng_eiface interface. I think it should not be very difficult to add orphan hook and several control requests to it to behave alike to ng_ether. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 15:03:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB9E106564A; Thu, 5 Jan 2012 15:03:22 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 75FD48FC14; Thu, 5 Jan 2012 15:03:20 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q05F3HlZ074084; Thu, 5 Jan 2012 22:03:17 +0700 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.5/8.14.5/Submit) id q05F3H7I074083; Thu, 5 Jan 2012 22:03:17 +0700 (NOVT) (envelope-from eugen) Date: Thu, 5 Jan 2012 22:03:17 +0700 From: Eugene Grosbein To: Sami Halabi Message-ID: <20120105150317.GA74071@rdtc.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:03:22 -0000 On Thu, Jan 05, 2012 at 03:43:45PM +0200, Sami Halabi wrote: > Somthing strange, i did: > net.graph.recvspace=8388608 > net.graph.maxdgram=8388608 > > and i suddenly got disconnections and logs like: > Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > available > Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available You should bot increase these setting without increase of kern.ipc.maxsockbuf. First greatly increase kern.ipc.maxsockbuf (I use 80M for it) and only then increase net.graph.recvspace and net.graph.maxdgram. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 15:38:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188811065670 for ; Thu, 5 Jan 2012 15:38:01 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id ADAB78FC13 for ; Thu, 5 Jan 2012 15:38:00 +0000 (UTC) Received: (qmail 2258 invoked by uid 0); 5 Jan 2012 15:11:19 -0000 Received: from 93.159.253.120 by rms-de006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 05 Jan 2012 16:11:17 +0100 From: "Rainer Bredehorn" Message-ID: <20120105151117.209350@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: wth3b6MweSEqVr7yaXQhtpl+IGRvbwDH Subject: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:38:01 -0000 HI! FreeBSD 8 uses a strange notation for multicast routes with interface local scope something like: ff01:3::/32 Here '3' is the scope id of the interface. OpenBSD uses the same notation as proposed in RFC 4007 for link local scompe multicast addresses: ff01::%fxp1:/32 Why does FreeBSD use a different notation? Rainer. From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 16:41:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015D0106566B for ; Thu, 5 Jan 2012 16:41:48 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB418FC14 for ; Thu, 5 Jan 2012 16:41:47 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id q05GfY7Z024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 01:41:39 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 06 Jan 2012 01:41:34 +0900 Message-ID: From: Hajimu UMEMOTO To: "Rainer Bredehorn" In-Reply-To: <20120105151117.209350@gmx.net> References: <20120105151117.209350@gmx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.0-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 06 Jan 2012 01:41:39 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:41:48 -0000 Hi, >>>>> On Thu, 05 Jan 2012 16:11:17 +0100 >>>>> "Rainer Bredehorn" said: Bredehorn> FreeBSD 8 uses a strange notation for multicast routes with interface local scope something like: Bredehorn> ff01:3::/32 Bredehorn> Here '3' is the scope id of the interface. Bredehorn> OpenBSD uses the same notation as proposed in RFC 4007 for link local scompe multicast addresses: Bredehorn> ff01::%fxp1:/32 Bredehorn> Why does FreeBSD use a different notation? This issue was fixed in 8-STABLE: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/netstat/route.c#rev1.94.2.3 Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 18:25:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82189106564A for ; Thu, 5 Jan 2012 18:25:40 +0000 (UTC) (envelope-from corsmith@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C23E8FC0C for ; Thu, 5 Jan 2012 18:25:40 +0000 (UTC) Received: by dakp5 with SMTP id p5so613234dak.13 for ; Thu, 05 Jan 2012 10:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gWlBx1NJqwptT01f3w7wsgarqN/pGn+rjK489jql7kk=; b=g+T8UvkAJ96ZclTGgbysomUpXr+p3+moKJcRJeE3FCrYez3atsjgFWken/OU6FaPjJ wptQcLWoi1FUv7bhCSMmFMt84N1201f01hsGvQ8Cs24ifGTmpxcyeS08V1w6aMAV7h0B U8f3sCYzE4V6X7qItZUPAwNKJQX6RZIT7A3to= MIME-Version: 1.0 Received: by 10.68.190.4 with SMTP id gm4mr7498111pbc.76.1325787939719; Thu, 05 Jan 2012 10:25:39 -0800 (PST) Received: by 10.142.199.7 with HTTP; Thu, 5 Jan 2012 10:25:39 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Jan 2012 13:25:39 -0500 Message-ID: From: Corey Smith To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:25:40 -0000 On Tue, Dec 20, 2011 at 2:12 PM, Jack Vogel wrote: > I have had another report of this problem, I am nominally on vacation for a > couple of weeks, but have promised to look at the issue after the holidays. I am available to test any patches. Thank you for your help. -Corey Smith From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 18:36:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385A4106567B; Thu, 5 Jan 2012 18:36:24 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C2F208FC23; Thu, 5 Jan 2012 18:36:23 +0000 (UTC) Received: by iadj38 with SMTP id j38so1840653iad.13 for ; Thu, 05 Jan 2012 10:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eK0AglfGyey1bm9qPSUp9XzlV9MzqlEyU6YFOdYNvYM=; b=DUVuc5C/0xuqFUqNvbyVF1YkrIUsp0D5WfNt6VX9mCsDmJtz35Fxfjnd+sup06faLM VgZ/wmkM1PeQJIPimBSTg5vFBcJTtBMEqasqVu6SZCJMbBsWlhkjdcUwtNdXpf0/F9jn LxMII7sRKgXI6rCrnXtNUCWLzYJCOhGRQm+sI= MIME-Version: 1.0 Received: by 10.42.161.132 with SMTP id t4mr3116428icx.16.1325788583201; Thu, 05 Jan 2012 10:36:23 -0800 (PST) Received: by 10.231.41.206 with HTTP; Thu, 5 Jan 2012 10:36:23 -0800 (PST) In-Reply-To: <20120105150317.GA74071@rdtc.ru> References: <20111227044754.GK8035@FreeBSD.org> <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> <20120105150317.GA74071@rdtc.ru> Date: Thu, 5 Jan 2012 20:36:23 +0200 Message-ID: From: Sami Halabi To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:36:24 -0000 where i can find explanation for these sysctls, the manual has some of the sysctls but not all... are these values in bits or bytes? Sami On Thu, Jan 5, 2012 at 5:03 PM, Eugene Grosbein wrote: > On Thu, Jan 05, 2012 at 03:43:45PM +0200, Sami Halabi wrote: > > > Somthing strange, i did: > > net.graph.recvspace=8388608 > > net.graph.maxdgram=8388608 > > > > and i suddenly got disconnections and logs like: > > Jan 5 16:10:01 mpd2 mpd: L2TP: ppp_l2tp_ctrl_create: No buffer space > > available > > Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available > > You should bot increase these setting without increase > of kern.ipc.maxsockbuf. First greatly increase kern.ipc.maxsockbuf > (I use 80M for it) and only then increase net.graph.recvspace > and net.graph.maxdgram. > > Eugene Grosbein > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 19:30:04 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A26106571C; Thu, 5 Jan 2012 19:30:04 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with SMTP id 5138D8FC1C; Thu, 5 Jan 2012 19:30:01 +0000 (UTC) Received: by web (Postfix, from userid 143) id 95DE2DC280; Tue, 3 Jan 2012 03:27:53 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web (Postfix) with ESMTP id 5E511DC275 for ; Tue, 3 Jan 2012 03:27:51 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5B1EC1A475F; Tue, 3 Jan 2012 03:21:49 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 454141065703; Tue, 3 Jan 2012 03:21:48 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA9F106564A; Tue, 3 Jan 2012 03:21:28 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E7BF08FC0C; Tue, 3 Jan 2012 03:21:27 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so21370515vbb.13 for ; Mon, 02 Jan 2012 19:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2fEVaeTULYDT0uxBjBC2cvBv4/aKfATi9vdnhVokiZs=; b=blJn0ffL7I9/zTTTvRiBTQhti6FTgw18zMosDn4vRAF3R5ojmrE9C3zD7M0MkLrqzd 441QO+pppakWPc6/h+zrF6+iM7z1OB0mhoB8t2pOzJ7xV9bFOBAUupmvDzTlgG1pssJE KyOG4J2gCZgk/ph0tKhk9BiWJNhoaMYmdXoT8= MIME-Version: 1.0 Received: by 10.52.71.106 with SMTP id t10mr7957505vdu.103.1325559008680; Mon, 02 Jan 2012 18:50:08 -0800 (PST) Received: by 10.52.26.1 with HTTP; Mon, 2 Jan 2012 18:50:08 -0800 (PST) Date: Tue, 3 Jan 2012 10:50:08 +0800 Message-ID: From: suken woo To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: stable@freebsd.org, mobile@freebsd.org, net@freebsd.org Subject: DLink DWL-G132 USB wifi Adapter failed under 9.0 RC3 X-BeenThere: freebsd-net@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, 05 Jan 2012 19:30:04 -0000 hi lists DWL-G132 failed to load on 9.0RC3 uath0: on usbus3 uath0: timeout waiting for reply to cmd 0x4 (4) uath0: could not read capability 3 uath0: could not get device capabilities device_attach: uath0 attach returned 35 and uathload lp# uathload -v -d /dev/ugen3.2 Load firmware ar5523.bin (builtin) to /dev/ugen3.2 send block 0: 151368 bytes remaining : data... : wait for ack... uathload: error reading msg (/dev/usb/3.2.1): No error: 0 usbconfig -u 3 -a 2 dump_device_desc ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x2001 idProduct = 0x3a02 bcdDevice = 0x0001 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 20:05:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6444F1065677 for ; Thu, 5 Jan 2012 20:05:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9728FC19 for ; Thu, 5 Jan 2012 20:05:49 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so1097057vbb.13 for ; Thu, 05 Jan 2012 12:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mO78iKz8yoXyFEzFYzcBB/O6bcXqWbCFa/a5sH8OFyg=; b=d3O8uhvTxO0Hu62P+a8lGdpLCn2I6XtIAU/Yx0EvzqjCZ3ckY8CG7Jq//Wb8FxqB8J iXA64GMHBvEuFy84BrFAph4m4FyWtSC96ToQ+k4i1fg6x4iOP7jXhBmwnKqG8B/Vpelz k2rBI+cM6yuJWRHAeugl9UnNbSnkMzrGnnqMk= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr1576620vdf.117.1325793949286; Thu, 05 Jan 2012 12:05:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Thu, 5 Jan 2012 12:05:49 -0800 (PST) In-Reply-To: <4F056691.4060403@luckie.org.nz> References: <4F056691.4060403@luckie.org.nz> Date: Thu, 5 Jan 2012 12:05:49 -0800 X-Google-Sender-Auth: hr157TtNjbD2p3HOzswnHg9ov7U Message-ID: From: Adrian Chadd To: Matthew Luckie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: minipcie wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:05:50 -0000 OH! On 5 January 2012 01:00, Matthew Luckie wrote: > Hi > > I'd like to create a freebsd AP using my mini-itx board. =A0I have a mini= -pcie > expansion slot and am considering this wifi card > > http://www.habeyusa.com/products_show.php?id=3D361 > > I currently run 8.2R but plan to upgrade to 9.0R. > > The main concern I have is that it lists its host interface as mini-pcie = / > USB, i.e. it might be a wifi card that is exposed to the system over a US= B > bus, which might not be optimal for a hostap. > > The docs say Atheros AR9285(MAC/Baseband/RF) with AR3011 -- I tend to thi= nk > the AR3011 is an error in their docs as the card is not advertised as > supporting bluetooth, and because an AR9285 is apparently exposed over PC= Ie, > I tend to think the card will work fine as an hostap, but just want to > double check. > > Anyone have any insight? Yes, it's actually a dual Bluetooth + AR9285 NIC. I forget the card identifier. But it's a perfectly fine AR9285 and it'll also (hopefully) work with bluetooth. The AR9285 is Mini-PCIe. The USB is just for the bluetooth IC. They're joined together for doing bluetooth coexistence. Awesome, if you're interested, I can start pushing out bluetooth coexistence patches for you to test. Are you able to run -HEAD? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 20:19:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C701106566B; Thu, 5 Jan 2012 20:19:04 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 618A88FC16; Thu, 5 Jan 2012 20:19:02 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q05KIxSM076067; Fri, 6 Jan 2012 03:18:59 +0700 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.5/8.14.5/Submit) id q05KIxUW076066; Fri, 6 Jan 2012 03:18:59 +0700 (NOVT) (envelope-from eugen) Date: Fri, 6 Jan 2012 03:18:59 +0700 From: Eugene Grosbein To: Sami Halabi Message-ID: <20120105201859.GA76054@rdtc.ru> References: <20111227083503.GP8035@glebius.int.ru> <20120105095855.GI34721@glebius.int.ru> <20120105110116.GK34721@glebius.int.ru> <20120105113427.GL34721@glebius.int.ru> <20120105150317.GA74071@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Alexander Motin , Eugene Grosbein Subject: Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:19:04 -0000 On Thu, Jan 05, 2012 at 08:36:23PM +0200, Sami Halabi wrote: > where i can find explanation for these sysctls, the manual has some of the > sysctls but not all... > > are these values in bits or bytes? They are in bytes. You can use "sysctl -d kern.ipc.maxsockbuf" for short description but they are mostly have no documentation other than kernel sources. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 22:08:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341E9106564A for ; Thu, 5 Jan 2012 22:08:39 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6DAD8FC08 for ; Thu, 5 Jan 2012 22:08:38 +0000 (UTC) Received: by yhfq46 with SMTP id q46so423819yhf.13 for ; Thu, 05 Jan 2012 14:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iiWkHTP2PHJ0+kley8Ad7OTKr6h4Jr2/9G/cjrTnAEU=; b=fMWAh0pjsDgzK+LLPlE5b43grZz5ZlNeM2AH/hgpNNOFVld69BGXWy9GsxtoYhSswD nnChjWVqvIkTG0UTqqfMF5bn/MtL65ITxOANB8UaY/FvNkroRhMTdX8Wg/GmVngl+L2h sgSs4P3muHw/5cW2DuugCgo8eWXUUL8QeY0MU= MIME-Version: 1.0 Received: by 10.236.43.66 with SMTP id k42mr4235515yhb.116.1325799689313; Thu, 05 Jan 2012 13:41:29 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.236.24.194 with HTTP; Thu, 5 Jan 2012 13:41:29 -0800 (PST) In-Reply-To: <20120104.144214.74742226.sthaug@nethelp.no> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> Date: Thu, 5 Jan 2012 16:41:29 -0500 X-Google-Sender-Auth: fACP4rZxUg2LxgsZjksb0OR5Djw Message-ID: From: J David To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:08:39 -0000 I am experiencing the same problem with bgpd and FreeBSD 8.2-STABLE as described in this thread. =A0If I have correctly interpreted this thread, it is currently not possible to have an OpenBGPd that speaks TCP-MD5 to some peers, but not to others on FreeBSD. =A0Is that correct? (It seems possible to bend this rule by tricking it to listen for the non-MD5 connections and initiate the MD5 ones by using the hack/patch posted here that turns off MD5 on the listening socket, but only allowing connections to be initiated in one direction is out of spec and a recipe for flaky connections.) While I think I am following the discussion so far, and it has been very informative, I am not sure where to go from here to actually resolve this problem correctly. I feel like if I had/understood the answer to Claudio's question: > How does FreeBSD avoid the chicken and egg problem of accepting > connections with MD5SIG? I might feel more like I knew what to do next. Although I think, for me, the question generalizes to "How should one listen for client connections on FreeBSD if some clients will use TCP_MD5SIG and some will not?" Sorry if that's a silly question; I have not been able to dig up a lot of how-to programming information for IPSec on FreeBSD. But the tcp(4) man page suggests that if you don't set a key on the connection, "it will have an invalid digest option prepended." I also found this on the tcp(4) man page: "In the current release, only outgoing traffic is digested; digests on incoming traffic are not verified." Is this still true after the recent changes? It doesn't *feel* true based on these problems, but I haven't tested for it specifically. Thanks! From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 23:32:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF868106564A for ; Thu, 5 Jan 2012 23:32:37 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from mailfilter36.ihug.co.nz (mailfilter36.ihug.co.nz [203.109.136.36]) by mx1.freebsd.org (Postfix) with ESMTP id 830308FC13 for ; Thu, 5 Jan 2012 23:32:37 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=tm9qpUR5xacA:10 a=8nJEP1OIZ-IA:10 a=pOqw4vtHAW4xfxCD90uk0Q==:17 a=FpT0U-pAAAAA:8 a=TUyfWmFaaSIy0W2JWiYA:9 a=-jMTKf1X7wQ3jWFqMwMA:7 a=wPNLvfGTeEIA:10 a=nPVq8361FmUA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJQyBk92XAcO/2dsb2JhbAAoGoIFqnuBBoFyAQEEATgeIgEQCyEWDwkDAgECASceBg0BBwEBh3YII7V8jBEElQaOAYRKVg X-IronPort-AV: E=Sophos;i="4.71,464,1320577200"; d="scan'208";a="115480224" Received: from 118-92-7-14.dsl.dyn.ihug.co.nz (HELO spandex.luckie.org.nz) ([118.92.7.14]) by cust.filter6.content.vf.net.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2012 12:32:35 +1300 Received: from mylar.luckie.org.nz ([192.168.1.24]) by spandex.luckie.org.nz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RiwnT-000Ns8-2X; Fri, 06 Jan 2012 12:32:35 +1300 Message-ID: <4F063339.9040608@luckie.org.nz> Date: Fri, 06 Jan 2012 12:33:13 +1300 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111231 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F056691.4060403@luckie.org.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: minipcie wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:32:38 -0000 Hi Adrian, >> The docs say Atheros AR9285(MAC/Baseband/RF) with AR3011 -- I tend to think >> the AR3011 is an error in their docs as the card is not advertised as >> supporting bluetooth, and because an AR9285 is apparently exposed over PCIe, >> I tend to think the card will work fine as an hostap, but just want to >> double check. >> >> Anyone have any insight? > > Yes, it's actually a dual Bluetooth + AR9285 NIC. I forget the card > identifier. But it's a perfectly fine AR9285 and it'll also > (hopefully) work with bluetooth. > > The AR9285 is Mini-PCIe. The USB is just for the bluetooth IC. They're > joined together for doing bluetooth coexistence. > > Awesome, if you're interested, I can start pushing out bluetooth > coexistence patches for you to test. Are you able to run -HEAD? Habey have two atheros Mini-PCIe cards: http://www.habeyusa.com/products_show.php?id=361 -- HB-NB037H http://www.habeyusa.com/products_show.php?id=353 -- HB-NE785H The NB037 model is advertised as supporting bluetooth, and the NE785 model (which I asked about, and I believe to have incorrect docs) is not. To me it appears that they have copy/pasted the page for the bluetooth supporting model to the non-bluetooth supporting model. I was tempted to get the NB037 model anyway but the docs suggest that Antenna 2 is required for bluetooth -- I only have one antenna mounting position in my ITX case. I am happy to get this card and test for you if you think I'll actually be able to test bluetooth -- that only Antenna 1 is required for both wifi and bluetooth. If possible I'd prefer patches against 9.0R as the machine its going into is fairly important. Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 23:43:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E0C1065672 for ; Thu, 5 Jan 2012 23:43:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7051F8FC0A for ; Thu, 5 Jan 2012 23:43:30 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so1295585vbb.13 for ; Thu, 05 Jan 2012 15:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F6OVaOjRWjm2qF5ghLHBT8Qnc61kmL8D9MrWsgFyFe8=; b=m+p2ITeyrBfijve/M5AlhtEIH6C7hwETeMmuSRHeg1XgY+ig+3D21I3TS8k7Hd/xu1 ZDnH3A6iIw8DUCr3wRGAUH/3nfL6QVuDTyy6XOqVpSgZAaah8+f/TPLgJ0cxwAEnXorx ZiMVJ6bYRB51nOjbUUljL5S3ua3f2xT7/2e8U= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr1867796vdf.117.1325807009589; Thu, 05 Jan 2012 15:43:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Thu, 5 Jan 2012 15:43:29 -0800 (PST) In-Reply-To: <4F063339.9040608@luckie.org.nz> References: <4F056691.4060403@luckie.org.nz> <4F063339.9040608@luckie.org.nz> Date: Thu, 5 Jan 2012 15:43:29 -0800 X-Google-Sender-Auth: qK1Rq2a2aqjvwZltkbSIVXDnFfg Message-ID: From: Adrian Chadd To: Matthew Luckie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: minipcie wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:43:30 -0000 On 5 January 2012 15:33, Matthew Luckie wrote: > Habey have two atheros Mini-PCIe cards: > > http://www.habeyusa.com/products_show.php?id=3D361 -- HB-NB037H > http://www.habeyusa.com/products_show.php?id=3D353 -- HB-NE785H > > The NB037 model is advertised as supporting bluetooth, and the NE785 mode= l > (which I asked about, and I believe to have incorrect docs) is not. =A0To= me > it appears that they have copy/pasted the page for the bluetooth supporti= ng > model to the non-bluetooth supporting model. > > I was tempted to get the NB037 model anyway but the docs suggest that > Antenna 2 is required for bluetooth -- I only have one antenna mounting > position in my ITX case. =A0I am happy to get this card and test for you = if > you think I'll actually be able to test bluetooth -- that only Antenna 1 = is > required for both wifi and bluetooth. =A0If possible I'd prefer patches > against 9.0R as the machine its going into is fairly important. Hi, Please consider getting two antennas mounted. I can't stress enough how much of a pain it's going to be having only one antenna - I still haven't found the time (or someone interested to do the work) to add the bits to the driver/HAL to support single antenna operation correctly and consistently. A lot of weird behaviour people complain about (eg lots of "stuck beacon" and poor throughput) boil down to only having one antenna connected and the driver just doesn't know to disable or not use that particular antenna/radio chain. I'll only be doing development against -HEAD. The -HEAD ath/hal/net80211 code will compile and run as modules under -9. I'll publish some instructions on how to do that if you're interested but I won't be publishing patches against -9 or backporting anything except bugfixes for quite some time. Sorry, but that's what I can do with limited time and resources. Adrian From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 01:18:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF3E9106564A for ; Fri, 6 Jan 2012 01:18:40 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1468FC0C for ; Fri, 6 Jan 2012 01:18:40 +0000 (UTC) Received: by yhfq46 with SMTP id q46so482177yhf.13 for ; Thu, 05 Jan 2012 17:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=fIZx7fhgqNZzNdXDw+izpfZ9zZG+4BXS0k6d/Z4YhSw=; b=EA/eE9qtuWCwqQ8gBtIQ0JIQuFK/ytvVteta9gePhEithueel8SS0jofdp/L2TH0UX 1AcMk85kZVXV5NH4jxYDEtSuINgrcN21CpiKjXmswE7JDoekhydRKScTgv7Z+5BNE16+ 2lxOGNzaPugSwopFTSrMKbjlZ1bf2VmOBR99Q= MIME-Version: 1.0 Received: by 10.236.43.66 with SMTP id k42mr4767983yhb.116.1325812719938; Thu, 05 Jan 2012 17:18:39 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.236.24.194 with HTTP; Thu, 5 Jan 2012 17:18:39 -0800 (PST) In-Reply-To: References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> Date: Thu, 5 Jan 2012 20:18:39 -0500 X-Google-Sender-Auth: z-R6lNveliRfytnCwfn9g2jI8CU Message-ID: From: J David To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:18:40 -0000 To help understand what's going on and test some of this stuff, I hacked up a TCP-MD5-aware echo server and tried various things. The first thing I found was that setting net.inet.tcp.signature_verify_input to 0 does not stop the listener socket from setting TCP_MD5SIG. So, setting this is not a way to "mask" the availability of TCP signatures if the kernel supports them. Ultimately, the behavior of connections depends on four factors: - the server's net.inet.tcp.signature_verify_input setting - the client's net.inet.tcp.signature_verify_input setting - whether the server socket sets TCP_MD5SIG - whether the client socket sets TCP_MD5SIG (In all test cases the correct SA's are present.) Unfortunately, this creates sixteen test cases, so it took some time to try them all. 1. sverify = 0, cverify = 0, smd5 = n, cmd5 = n 5. sverify = 0, cverify = 1, smd5 = n, cmd5 = n 9. sverify = 1, cverify = 0, smd5 = n, cmd5 = n 13. sverify = 1, cverify = 1, smd5 = n, cmd5 = n These all work as expected. No MD5 signatures are requested, used or checked. 2. sverify = 0, cverify = 0, smd5 = n, cmd5 = y 10. sverify = 1, cverify = 0, smd5 = n, cmd5 = y These work. MD5 signatures generated client->server only. 6. sverify = 0, cverify = 1, smd5 = n, cmd5 = y 14. sverify = 1, cverify = 1, smd5 = n, cmd5 = y These work, but not properly. Connects and echoes, but client gets stuck in LAST_ACK, client seems to ignore server's ACK. MD5 signatures client->server only. 3. sverify = 0, cverify = 0, smd5 = y, cmd5 = n Works. MD5 signatures generated server->client only. 4. sverify = 0, cverify = 0, smd5 = y, cmd5 = y 12. sverify = 1, cverify = 0, smd5 = y, cmd5 = y Works. Signatures generated in both directions. 7. sverify = 0, cverify = 1, smd5 = y, cmd5 = n Times out. Client ignores SYN-ACK from server. Signatures generated server->client. 8. sverify = 0, cverify = 1, smd5 = y, cmd5 = y 16. sverify = 1, cverify = 1, smd5 = y, cmd5 = y Works, but not properly. Connects and echoes, but client gets stuck in LAST_ACK again, client seems to ignore server's final ACK. MD5 signatures in both directions. 11. sverify = 1, cverify = 0, smd5 = y, cmd5 = n Does not work. Server goes to SYN_RCVD, client goes to ESTABLISHED. Server appears to ignore client's ACK. MD5 signatures server->client only. 15. sverify = 1, cverify = 1, smd5 = y, cmd5 = n Times out. Server goes to SYN_RCVD, client sticks at SYN_SENT, appears to ignore SYN-ACK. Signatures server->client only. While this was a bit time-consuming, it seems worthwhile because it pointed up a couple of apparent problems that may have ramifications outside openbgpd. For openbgpd to work properly with both clients that do and don't use TCP-MD5, cases 11 and 16 both need to work. Currently neither do. That case 16 doesn't work suggests that openbgpd probably has hard-to-observe problems leaving sockets in LAST_ACK if it is the MD5-using client. Probably this has no effect in practice, because it only appears to happen as the client, which would use a different port to establish a new connection. But it does generate a lot of unnecessary retransmits so it would be nice to track this behavior down. Also, this is the actual as-designed/useful use of TCP-MD5 (generating and checking) so it seems the most important one to ensure is 100% correct. Case 11 certainly explains why OpenBGPd gets so confused; one side thinks the connection is established, the other doesn't. In order for this to work, there must be some method of "turning off" the expectation of receiving MD5-signed packets on a particular connection. In this context, the TCP_MD5SIG seems to be doing "double duty" in that it is telling the connection to both send and expect MD5 signatures, although the tcp(4) man page refers only to outgoing traffic. (Though again that may be a documentation error.) So there may be some bugs here on the FreeBSD side that may make it hard to get openbgpd working properly. There are a couple of other things that may be worth looking at, but if someone knows the way forward from here, any guidance would be appreciated. Thanks! From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 05:49:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8392510656D0 for ; Fri, 6 Jan 2012 05:49:16 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 445878FC12 for ; Fri, 6 Jan 2012 05:49:15 +0000 (UTC) Received: by qcse13 with SMTP id e13so977755qcs.13 for ; Thu, 05 Jan 2012 21:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rzAyfaEnjC6UCKLj0mKwctvcXCnnr7DlhB0QjLSYw+o=; b=A61CXpVvjzHVe2rPA3UhZB3KldorC3sIc4nPaYz1ThQPOBidT2asNWJNn+eynFzGBg sRdqVvLQ8DQ1qnN6TLbUxZTRcJ+axRUCgMO/r+d8lLPzpLLPTLVyTJAMJeowaE8GCdIj QYXCet9usJu1gl4Elcc+1NtPaoeLLHEBEs2VY= MIME-Version: 1.0 Received: by 10.224.33.65 with SMTP id g1mr5728357qad.98.1325827548517; Thu, 05 Jan 2012 21:25:48 -0800 (PST) Received: by 10.229.70.206 with HTTP; Thu, 5 Jan 2012 21:25:48 -0800 (PST) Date: Thu, 5 Jan 2012 21:25:48 -0800 Message-ID: From: Navdeep Parhar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: tcp_detach can return with inpcb lock held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 05:49:16 -0000 Looks like there's a case where tcp_detach could return with the inp lock held. I see an XXXRW comment questioning this possibility, but we should either add an assertion to verify that the case does not occur, or unlock the inpcb before returning. Or maybe both? Regards, Navdeep diff -r 35bdf8d932e8 sys/netinet/tcp_usrreq.c --- a/sys/netinet/tcp_usrreq.c Mon Dec 19 10:08:31 2011 -0800 +++ b/sys/netinet/tcp_usrreq.c Thu Jan 05 21:20:24 2012 -0800 @@ -204,8 +204,11 @@ tcp_discardcb(tp); in_pcbdetach(inp); in_pcbfree(inp); - } else + } else { in_pcbdetach(inp); + INP_WUNLOCK(inp); + } + } } From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 06:37:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7962106564A; Fri, 6 Jan 2012 06:37:51 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7B18FC0C; Fri, 6 Jan 2012 06:37:50 +0000 (UTC) Received: by eekc50 with SMTP id c50so1007468eek.13 for ; Thu, 05 Jan 2012 22:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w7CZMFck019JD6OpmnK4Cgn1bq1/1/WC502ZtnO+Dk0=; b=ZIqeQNQe/LGpTdTsLN5u5h31p2O22JQa9Vv1f5XCzqK1fCPvC3dGWh00IAMXRuQG6G y+4XNj34duMa0TrYogDFGCZk8D1sRghXt7Iy2jN9qwQYaIjJz/ANSYN4eHolUuDIv/n2 U9JJJbKiBeuvVXaRu5fZdxS4V74C9qKoDu0jc= Received: by 10.213.113.20 with SMTP id y20mr1036234ebp.34.1325831869650; Thu, 05 Jan 2012 22:37:49 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id 76sm243640500eeh.0.2012.01.05.22.37.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 22:37:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20120104.144214.74742226.sthaug@nethelp.no> Date: Fri, 6 Jan 2012 08:37:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@FreeBSD.org, dougb@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 06:37:51 -0000 On Jan 4, 2012, at 3:42 PM, sthaug@nethelp.no wrote: >> You are setting the keys with setkey for both directions of a single = session, right? >> i.e.: >>=20 >> add X.X.X.X Y.Y.Y.Y tcp 0x1000 -A tcp-md5 "SomePass"; >> add Y.Y.Y.Y X.X.X.X tcp 0x1000 -A tcp-md5 "SomePass"; >>=20 >> As before it was only needed to set the "outgoing" direction key, = which should not work anymore unless=20 >> net.inet.tcp.signature_verify_input is zero. >=20 > Are you sure? I have net.inet.tcp.signature_verify_input =3D 1 and = only > one line in /etc/ipsec.conf for each BGP session using MD5 keys, on > 8.2-STABLE. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no Hmm, you are right, it seems that my second SAD entries are not used at = all. However I'm now running with net.inet.tcp.signature_verify_input =3D 0, = because if I set it to 1 the BGP sessions to my other FreeBSD routers disconnect. (and that is = running Quagga). Am I the only one who sees this running Quagga? One difference probably = is that I have both TCP-MD5 protected sessions and ones that are not. And the not protected sessions fail if I = start checking ingress tcp signatures. From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 07:07:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B70C0106566B for ; Fri, 6 Jan 2012 07:07:47 +0000 (UTC) (envelope-from azanar@carrel.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 843718FC08 for ; Fri, 6 Jan 2012 07:07:47 +0000 (UTC) Received: by iadj38 with SMTP id j38so3069956iad.13 for ; Thu, 05 Jan 2012 23:07:47 -0800 (PST) Received: by 10.50.89.197 with SMTP id bq5mr6186709igb.24.1325833666948; Thu, 05 Jan 2012 23:07:46 -0800 (PST) Received: from rowlf.sea.carrel.org (dsl231-050-036.sea1.dsl.speakeasy.net. [216.231.50.36]) by mx.google.com with ESMTPS id py4sm128033486igc.2.2012.01.05.23.07.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 23:07:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Edward Carrel In-Reply-To: Date: Thu, 5 Jan 2012 23:06:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Ermal_Lu=E7i?= X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:07:47 -0000 On Jan 4, 2012, at 12:03 AM, Ermal Lu=E7i wrote: > Can you see if on the enc(4) interface pf(4) sees both side of the = traffic? I can on enc0. Doing a tcpdump(1) shows me traffic traveling both ways. = Should there be a pf(4) interface for me to listen on? I've listened on = pflog(4), and only seen traffic going one way, even when I have relevant = rules set to "log(all)" > Also please describe/post what is the ruleset of blindly passing = packets and the ruleset that you define as 'keep state'!? =46rom my /etc/pf.conf: pass in quick log(all) on enc0 no state pass out quick log(all) on enc0 no state pass out quick log(all) on ng0 proto tcp from ng0 to 10.0.0.0/8 pass in quick log(all) on ng0 proto tcp from 10.0.0.0/8 to ng0 If I assert the last two rules as being explicitly 'no state' things = continue to work after the stateful tracking drops the entry due to = never seeing the SYN-ACK responding to my SYN to the remote end. - Ed= From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 07:55:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E55106566C for ; Fri, 6 Jan 2012 07:55:57 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id BA1008FC0A for ; Fri, 6 Jan 2012 07:55:56 +0000 (UTC) Received: (qmail 92131 invoked from network); 6 Jan 2012 07:55:55 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jan 2012 07:55:55 -0000 Date: Fri, 06 Jan 2012 08:55:54 +0100 (CET) Message-Id: <20120106.085554.74661755.sthaug@nethelp.no> To: ndenev@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 07:55:57 -0000 > > Are you sure? I have net.inet.tcp.signature_verify_input = 1 and only > > one line in /etc/ipsec.conf for each BGP session using MD5 keys, on > > 8.2-STABLE. > > Hmm, you are right, it seems that my second SAD entries are not used at all. > However I'm now running with net.inet.tcp.signature_verify_input = 0, because if I set it to 1 > the BGP sessions to my other FreeBSD routers disconnect. (and that is running Quagga). > Am I the only one who sees this running Quagga? One difference probably is that I have both TCP-MD5 protected > sessions and ones that are not. And the not protected sessions fail if I start checking ingress tcp signatures. Have a look at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=452717+0+current/freebsd-net This is a nice summary of the different possibilities. And indicates, if I read it roght, that there *is* indeed a problem. My case is Quagga bgpd talking to several JunOS routers, only a single TCP session (with MD5) to each router. This works just fine. I have never attempted BGP with MD5 between two FreeBSD boxes. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 09:13:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F40E106566C for ; Fri, 6 Jan 2012 09:13:24 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id AD64E8FC12 for ; Fri, 6 Jan 2012 09:13:23 +0000 (UTC) Received: (qmail 28356 invoked by uid 0); 6 Jan 2012 09:13:22 -0000 Received: from 93.159.253.120 by rms-de001.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 06 Jan 2012 10:13:20 +0100 From: "Rainer Bredehorn" Message-ID: <20120106091320.209360@gmx.net> MIME-Version: 1.0 To: "Hajimu UMEMOTO" X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: Z950b6wweSEqVr7yaXQhjuV+IGRvb4AL Cc: freebsd-net@freebsd.org Subject: Re: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:13:24 -0000 Hi! The output of netstat is fixed but what about the route command? I would like to add or delete a route like "ff01::%fxp1/32" manually. The route command complains: "hostname nor servname provided, or not known" when I use the "%interface" notation. Rainer. > Bredehorn> FreeBSD 8 uses a strange notation for multicast routes with interface local scope something like: > Bredehorn> ff01:3::/32 > Bredehorn> Here '3' is the scope id of the interface. > > Bredehorn> OpenBSD uses the same notation as proposed in RFC 4007 for link local scompe multicast addresses: > Bredehorn> ff01::%fxp1:/32 > > Bredehorn> Why does FreeBSD use a different notation? > > This issue was fixed in 8-STABLE: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/netstat/route.c#rev1.94.2.3 > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 10:41:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 986881065673 for ; Fri, 6 Jan 2012 10:41:32 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 482BA8FC08 for ; Fri, 6 Jan 2012 10:41:31 +0000 (UTC) Received: from ameno.mahoroba.org (IDENT:URD8d4hJjrlWTN62RbChpVmVGRMTAq9ZdtjLnLdNJkZXNmnQ2wqsAFUZy9RET2Bq@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id q06AfJqb099255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 19:41:25 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 06 Jan 2012 19:41:19 +0900 Message-ID: From: Hajimu UMEMOTO To: "Rainer Bredehorn" In-Reply-To: <20120106091320.209360@gmx.net> References: <20120106091320.209360@gmx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-RELEASE-p5 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Fri_Jan__6_19:41:18_2012-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 06 Jan 2012 19:41:25 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:41:32 -0000 --Multipart_Fri_Jan__6_19:41:18_2012-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Fri, 06 Jan 2012 10:13:20 +0100 >>>>> "Rainer Bredehorn" said: Bredehorn> The output of netstat is fixed but what about the route command? Bredehorn> I would like to add or delete a route like "ff01::%fxp1/32" manually. Bredehorn> The route command complains: "hostname nor servname provided, or not known" Bredehorn> when I use the "%interface" notation. Okay, please try the attached patch. Sincerely, --Multipart_Fri_Jan__6_19:41:18_2012-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="route-nodelocal.diff" Content-Transfer-Encoding: 7bit Index: lib/libc/net/getaddrinfo.c diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c --- lib/libc/net/getaddrinfo.c.orig 2011-12-24 03:27:52.000000000 +0900 +++ lib/libc/net/getaddrinfo.c 2012-01-06 19:30:42.191095539 +0900 @@ -1577,7 +1577,8 @@ ip6_str2scopeid(char *scope, struct sock if (*scope == '\0') return -1; - if (IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6)) { + if (IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6) || + IN6_IS_ADDR_MC_NODELOCAL(a6)) { /* * We currently assume a one-to-one mapping between links * and interfaces, so we simply use interface indices for Index: sbin/route/route.c diff -u -p sbin/route/route.c.orig sbin/route/route.c --- sbin/route/route.c.orig 2011-09-23 09:51:37.000000000 +0900 +++ sbin/route/route.c 2012-01-06 19:30:17.819091371 +0900 @@ -375,7 +375,8 @@ routename(struct sockaddr *sa) #ifdef __KAME__ if (sa->sa_len == sizeof(struct sockaddr_in6) && (IN6_IS_ADDR_LINKLOCAL(&sin6.sin6_addr) || - IN6_IS_ADDR_MC_LINKLOCAL(&sin6.sin6_addr)) && + IN6_IS_ADDR_MC_LINKLOCAL(&sin6.sin6_addr) || + IN6_IS_ADDR_MC_NODELOCAL(&sin6.sin6_addr)) && sin6.sin6_scope_id == 0) { sin6.sin6_scope_id = ntohs(*(u_int16_t *)&sin6.sin6_addr.s6_addr[2]); @@ -500,7 +501,8 @@ netname(struct sockaddr *sa) #ifdef __KAME__ if (sa->sa_len == sizeof(struct sockaddr_in6) && (IN6_IS_ADDR_LINKLOCAL(&sin6.sin6_addr) || - IN6_IS_ADDR_MC_LINKLOCAL(&sin6.sin6_addr)) && + IN6_IS_ADDR_MC_LINKLOCAL(&sin6.sin6_addr) || + IN6_IS_ADDR_MC_NODELOCAL(&sin6.sin6_addr)) && sin6.sin6_scope_id == 0) { sin6.sin6_scope_id = ntohs(*(u_int16_t *)&sin6.sin6_addr.s6_addr[2]); @@ -1002,7 +1004,8 @@ getaddr(int which, char *str, struct hos memcpy(&su->sin6, res->ai_addr, sizeof(su->sin6)); #ifdef __KAME__ if ((IN6_IS_ADDR_LINKLOCAL(&su->sin6.sin6_addr) || - IN6_IS_ADDR_MC_LINKLOCAL(&su->sin6.sin6_addr)) && + IN6_IS_ADDR_MC_LINKLOCAL(&su->sin6.sin6_addr) || + IN6_IS_ADDR_MC_NODELOCAL(&su->sin6.sin6_addr)) && su->sin6.sin6_scope_id) { *(u_int16_t *)&su->sin6.sin6_addr.s6_addr[2] = htons(su->sin6.sin6_scope_id); --Multipart_Fri_Jan__6_19:41:18_2012-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Fri_Jan__6_19:41:18_2012-1-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 11:22:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A32F10656D7 for ; Fri, 6 Jan 2012 11:22:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3F4B8FC1D for ; Fri, 6 Jan 2012 11:22:25 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4F53746B0D; Fri, 6 Jan 2012 06:22:25 -0500 (EST) Date: Fri, 6 Jan 2012 11:22:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Navdeep Parhar In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tcp_detach can return with inpcb lock held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 11:22:26 -0000 On Thu, 5 Jan 2012, Navdeep Parhar wrote: > Looks like there's a case where tcp_detach could return with the inp lock > held. I see an XXXRW comment questioning this possibility, but we should > either add an assertion to verify that the case does not occur, or unlock > the inpcb before returning. Or maybe both? Hi Navdeep: A number of other folks have pointed this out as well -- usually while tracking a different bug, so a fix never gets committed. I believe we should commit + merge the patch you've proposed. However, as far as I'm aware, it's never triggered, so the comment is probably correct. I'm not sure if we want to make the comment an invariant, since other than avoiding this bug, it shouldn't need to be true (I think). Robert > > Regards, Navdeep > > diff -r 35bdf8d932e8 sys/netinet/tcp_usrreq.c > --- a/sys/netinet/tcp_usrreq.c Mon Dec 19 10:08:31 2011 -0800 > +++ b/sys/netinet/tcp_usrreq.c Thu Jan 05 21:20:24 2012 -0800 > @@ -204,8 +204,11 @@ > tcp_discardcb(tp); > in_pcbdetach(inp); > in_pcbfree(inp); > - } else > + } else { > in_pcbdetach(inp); > + INP_WUNLOCK(inp); > + } > + > } > } > _______________________________________________ > 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 Jan 6 12:16:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75F1106566B for ; Fri, 6 Jan 2012 12:16:06 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 736618FC12 for ; Fri, 6 Jan 2012 12:16:05 +0000 (UTC) Received: (qmail 18483 invoked by uid 0); 6 Jan 2012 12:16:04 -0000 Received: from 91.61.103.34 by rms-de001.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 06 Jan 2012 13:16:03 +0100 From: "Rainer Bredehorn" Message-ID: <20120106121604.209390@gmx.net> MIME-Version: 1.0 To: "Hajimu UMEMOTO" ,"Rainer Bredehorn" X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: U4N0b68weSEqVr7yaXQhe5x+IGRvb8CD Cc: freebsd-net@freebsd.org Subject: Re: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:16:06 -0000 Hi! Thanks! It works fine. I've tried it for FreeBSD 8.1. It would be nice to change it in FreeBSD 9.0 and 8.3! ;-) Bye, Rainer. > Bredehorn> The output of netstat is fixed but what about the route command? > Bredehorn> I would like to add or delete a route like "ff01::%fxp1/32" manually. > Bredehorn> The route command complains: "hostname nor servname provided, or not known" > Bredehorn> when I use the "%interface" notation. > > Okay, please try the attached patch. > > Sincerely, From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 13:26:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6AA106566C for ; Fri, 6 Jan 2012 13:26:31 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id EEE418FC08 for ; Fri, 6 Jan 2012 13:26:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Content-Type:Mime-Version; bh=fbyBop6NzhQWyFpnL0U+dDYi5Ms/PIMAJ4ygNgLa8HM=; b=kSg3aHidxypZbQdOwnweGdKj7Q5V8sYk2lAfNO34nKDd34NMDPsXuytX5BC/PZZSIBrtFQCxei9azWNUzhKDeetUj3kLg0l6H3R3nv5HE6C8H9h1oMr7NedsE2RBqxur; Received: from [188.65.183.9] (helo=[192.168.124.220]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rj9Cs-0009xU-AX; Fri, 06 Jan 2012 12:47:39 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Melissa Jenkins In-Reply-To: <20120106120011.9CA681065723@hub.freebsd.org> Date: Fri, 6 Jan 2012 12:47:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <79D6C44F-778D-4B07-A78D-52084306CF0F@littlebluecar.co.uk> References: <20120106120011.9CA681065723@hub.freebsd.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1251.1) X-SA-Exim-Connect-IP: 188.65.183.9 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Subject: Re: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:26:31 -0000 >=20 > On Jan 4, 2012, at 12:03 AM, Ermal Lu=E7i wrote: >=20 >> Can you see if on the enc(4) interface pf(4) sees both side of the = traffic? >=20 > I can on enc0. Doing a tcpdump(1) shows me traffic traveling both = ways. Should there be a pf(4) interface for me to listen on? I've = listened on pflog(4), and only seen traffic going one way, even when I = have relevant rules set to "log(all)" >=20 I had this problem when trying to firewall/NAT traffic from MPD - it = appeared that MPD inserts the packets directly into the middle of the = packet flow, without triggering any inbound processing by PF. IPsec does this correctly if you have set the sysctls as per the man = page on enc, as does PopTop and ppp (which was my solution to the MPD = issue) It didn't matter what firewall rules were configured, and this behaviour = was present in the 7 branch as well as 8. Mel= From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 13:31:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405DD106564A for ; Fri, 6 Jan 2012 13:31:25 +0000 (UTC) (envelope-from frank@harz2012.behrens.de) Received: from post.behrens.de (post.behrens.de [IPv6:2a01:170:1023::1:2]) by mx1.freebsd.org (Postfix) with ESMTP id B26CE8FC17 for ; Fri, 6 Jan 2012 13:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=behrens.de; h=from:to:date:mime-version:subject:content-type:content-transfer-encoding:content-description; s=pinky1; t=1325856682; i=frank@harz2012.behrens.de=20; bh=I9kfXpHjl5p1iqdnq5tgbyJXjr7GxWtXfwDl2O94NhU=; b=vgo5pF6dAIpg504fkNWjqIKhIcj0qCfO0nqZrQOxXF+xwFeB8nxoZuRXhqAuuuD7RFj1MhsLj3gQxole38Cf1A== Received: from sun.behrens ([IPv6:2a01:170:1023:0:95ef:c874:f2cf:9bb0]) by post.behrens.de (8.14.4/8.14.4) with ESMTP(MSA) id q06DVKS8041662 for ; Fri, 6 Jan 2012 14:31:20 +0100 (CET) (envelope-from frank@harz2012.behrens.de) Message-Id: <201201061331.q06DVKS8041662@post.behrens.de> From: "Frank Behrens" To: freebsd-net@freebsd.org Date: Fri, 06 Jan 2012 14:31:20 +0100 MIME-Version: 1.0 Priority: normal X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Hashcash: 1:23:120106:freebsd-net@freebsd.org::Mvx6hg8flYLIU07C:0000000000NI1J Subject: Proxy ARP for address behind tun link does not work in 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:31:25 -0000 I have a small vpn (OpenVPN) setup. To make the configuration easy the remote client gets an address from "main" network and the remote client is announced via proxy arp. This worked well and reliably for FreeBSD until (and including) version 7.x. My new server uses FreeBSD 8.2-STABLE-r223473 and this setup does not longer work: The ethernet interface for the internal network has an usual private address range: net0: ether 90:e6:ba:73:ca:f2 inet 192.168.50.10 netmask 0xffffff00 broadcast 192.168.50.255 A subnet is routed via the tun interface: tun3: inet 192.168.50.161 netmask 0xffffffe0 broadcast 192.168.50.191 This routing works well between the remote client, the vpn server and hosts in other networks. But to reach the remote client from hosts in my local network I need a proxy arp entry. When I try to insert a proxy arp entry I get an error: # arp -s 192.168.50.166 90:e6:ba:73:ca:f2 pub only cannot intuit interface index and type for 192.168.50.166 The error message is generated in arp.c, because the address 192.168.50.166 has type IFT_PPP and not IFT_ETHER (or other). I thought this was an oversight and added the type IFT_PPP to arp.c's valid_type() routine. But I had no luck, now I get "arp: writing to routing socket: Invalid argument" and the kernel writes in the log "lla_rt_output: RTM_ADD publish (proxy only) is invalid" So my questions come: Is this a configuration error or a regression in proxy arp processing? Why is there a check for the IP address type? Should we allow to use any address? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 13:45:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BF81106566C; Fri, 6 Jan 2012 13:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF388FC13; Fri, 6 Jan 2012 13:45:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 24C0F46B2D; Fri, 6 Jan 2012 08:45:14 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8C59B941; Fri, 6 Jan 2012 08:45:13 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 6 Jan 2012 08:40:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201060840.04156.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Jan 2012 08:45:13 -0500 (EST) Cc: Robert Watson , Navdeep Parhar Subject: Re: tcp_detach can return with inpcb lock held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:45:14 -0000 On Friday, January 06, 2012 6:22:25 am Robert Watson wrote: > > On Thu, 5 Jan 2012, Navdeep Parhar wrote: > > > Looks like there's a case where tcp_detach could return with the inp lock > > held. I see an XXXRW comment questioning this possibility, but we should > > either add an assertion to verify that the case does not occur, or unlock > > the inpcb before returning. Or maybe both? > > Hi Navdeep: > > A number of other folks have pointed this out as well -- usually while > tracking a different bug, so a fix never gets committed. I believe we should > commit + merge the patch you've proposed. However, as far as I'm aware, it's > never triggered, so the comment is probably correct. I'm not sure if we want > to make the comment an invariant, since other than avoiding this bug, it > shouldn't need to be true (I think). If you really think it shouldn't occur, then commit the patch below and MFC it to stable branches, but change the code in HEAD afterwards to add the assertion. Then you will eventually find out if it's wrong (hopefully) as I did with the assertions I added to tcp_input() for rcv_nxt and rcv_adv. :) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 15:35:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E132106566C for ; Fri, 6 Jan 2012 15:35:02 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 0182C8FC0C for ; Fri, 6 Jan 2012 15:35:01 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Fri, 6 Jan 2012 10:35:01 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 34C9233C02; Fri, 6 Jan 2012 10:35:01 -0500 (EST) Date: Fri, 6 Jan 2012 10:35:01 -0500 From: Ed Maste To: J David Message-ID: <20120106153500.GA78077@sandvine.com> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:35:02 -0000 On Thu, Jan 05, 2012 at 08:18:39PM -0500, J David wrote: > To help understand what's going on and test some of this stuff, I > hacked up a TCP-MD5-aware echo server and tried various things. Hi J David, Thank you very much for this extensive testing and analysis. Would you care to post your basic echo server somewhere for others to use in debugging this, just to save time for anyone who can debug further? I've reformatted your results into a table for reference: Case Verify Socket Opt Result Server Client Server Client 1 0 0 N N P 2 0 0 N Y P 3 0 0 Y N P 4 0 0 Y Y P 5 0 1 N N P 6 0 1 N Y FAIL - LAST_ACK 7 0 1 Y N FAIL - times out 8 0 1 Y Y FAIL - LAST_ACK 9 1 0 N N P 10 1 0 N Y P 11 1 0 Y N FAIL 12 1 0 Y Y P 13 1 1 N N P 14 1 1 N Y FAIL - LAST_ACK 15 1 1 Y N FAIL - times out 16 1 1 Y Y FAIL - LAST_ACK > although the tcp(4) man page refers only to outgoing > traffic. (Though again that may be a documentation error.) Yes, tcp(4) was not updated when inbound TCP-MD5 checking went in. I'll commit a change similar to the one below (after I find the appropriate markup for the sysctl ID). Index: tcp.4 =================================================================== --- tcp.4 (revision 229319) +++ tcp.4 (working copy) @@ -196,8 +196,8 @@ .It Dv TCP_MD5SIG This option enables the use of MD5 digests (also known as TCP-MD5) on writes to the specified socket. -In the current release, only outgoing traffic is digested; -digests on incoming traffic are not verified. +Outgoing traffic is digested; digests on incoming traffic are verfied +if the net.inet.tcp.signature_verify_input sysctl is nonzero. The current default behavior for the system is to respond to a system advertising this option with TCP-MD5; this may change. .Pp > So there may be some bugs here on the FreeBSD side that may make it > hard to get openbgpd working properly. Yes, your testing clearly demonstrates some kernel issues here. I'll see if I can find someone to investigate (or can help guide further debugging). Thanks again for the effort here so far. -Ed From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 16:33:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574531065670; Fri, 6 Jan 2012 16:33:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id D212F8FC0A; Fri, 6 Jan 2012 16:33:42 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C99B325D386E; Fri, 6 Jan 2012 16:33:41 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0A830BD89B6; Fri, 6 Jan 2012 16:33:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1OYQy+-FByEB; Fri, 6 Jan 2012 16:33:39 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 655DABD89B4; Fri, 6 Jan 2012 16:33:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120106153500.GA78077@sandvine.com> Date: Fri, 6 Jan 2012 16:33:38 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1558626A-39B9-4533-9057-737FBC37898A@lists.zabbadoz.net> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> <20120106153500.GA78077@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, J David Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:33:43 -0000 On 6. Jan 2012, at 15:35 , Ed Maste wrote: > Yes, your testing clearly demonstrates some kernel issues here. I'll > see if I can find someone to investigate (or can help guide further > debugging). > > Thanks again for the effort here so far. I am still having trouble with the table (as I had with the original mail, which was just too long - as is the table). The bottom lines are: 0) Drop all test cases with the sysctl turned off (they should dtrt also w/o the sysctl). It should be a SADB policy && socket option decision (depending on direction). 1) there is a problem in _syncache_add leading to the wrong behaviour in situations in respond. 2) there is another problem I haven't looked at where to say it is, basically related to the way we decide to treat (0) (but also in the other direction) 3) there is a problem of not properly checking an error case in tcp_subr.c at one point but would be void if (0/2) was done right in both directions. If you can wait till early next week I might have a patch that cleans parts of this up in general and we can go from there? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 16:34:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E06D1065673 for ; Fri, 6 Jan 2012 16:34:59 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBC068FC18 for ; Fri, 6 Jan 2012 16:34:58 +0000 (UTC) Received: by yhfq46 with SMTP id q46so765518yhf.13 for ; Fri, 06 Jan 2012 08:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E3FRJplXaGxuDnqqOMNl2BC6oF9BLPZ6FvVKAaQK6ME=; b=W/YlcSVwgSKHhQWzLW1qqtvAaR9GY75UgjTWMfKtR1w8y6Afe/QtUA0h8zmNT2V5DU UMx8T9cEO3fPA61FPqz/mOOVYqLQ1OAKRTLj4QSIEpmUSlqzz4xfoib05KbSEVJJfLHt L+mTDPKgwFpfBi4D6Q7bS7kiprEZ3rKh7JofU= MIME-Version: 1.0 Received: by 10.236.43.66 with SMTP id k42mr8168875yhb.116.1325867698337; Fri, 06 Jan 2012 08:34:58 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.236.24.194 with HTTP; Fri, 6 Jan 2012 08:34:58 -0800 (PST) In-Reply-To: <20120106153500.GA78077@sandvine.com> References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> <20120106153500.GA78077@sandvine.com> Date: Fri, 6 Jan 2012 11:34:58 -0500 X-Google-Sender-Auth: yMzYXk0AU-adjjwgpX7-xBQB9n0 Message-ID: From: J David To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:34:59 -0000 On Fri, Jan 6, 2012 at 10:35 AM, Ed Maste wrote: > Thank you very much for this extensive testing and analysis. =A0Would you > care to post your basic echo server somewhere for others to use in > debugging this, just to save time for anyone who can debug further? With a bit of clean-up to stop people who look at it from instantly going blind in self-defense, I should be able to do that later today. > +Outgoing traffic is digested; digests on incoming traffic are verfied > +if the net.inet.tcp.signature_verify_input sysctl is nonzero. Good change. This bit from tcp(4) may also be inaccurate: "Only IPv4 (AF_INET) sessions are supported." It appears to work with IPv6 as well. (Arguably it should not since tmk the standard was never defined/intended for IPv6, but there is no doubt that having it work is very useful for IPv6 BGP.) > =A0The current default behavior for the system is to respond to a system > =A0advertising this option with TCP-MD5; this may change. This behavior described in the man page did pop up last night. The bit about "this may change" is of concern because currently this answers the question of how a single bound socket is supposed to serve both clients that do and do not use TCP-MD5. It's actually quite easy/convenient, so it would be a shame if that did change. > Yes, your testing clearly demonstrates some kernel issues here. =A0I'll > see if I can find someone to investigate (or can help guide further > debugging). If I can help, I am happy to do so, but in general the kernel is something that happens to other people. :) Thanks! From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 20:39:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB51106564A; Fri, 6 Jan 2012 20:39:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 604FD8FC17; Fri, 6 Jan 2012 20:39:57 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 12DC546B2E; Fri, 6 Jan 2012 15:39:57 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 94F12B971; Fri, 6 Jan 2012 15:39:56 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 6 Jan 2012 15:39:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> In-Reply-To: <201112291527.26763.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201061539.55984.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Jan 2012 15:39:56 -0500 (EST) Cc: "Bjoern A. Zeeb" , Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:39:57 -0000 On Thursday, December 29, 2011 3:27:26 pm John Baldwin wrote: > On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote: > > Another bit of lock contention I ran into between a device driver doing slow > > MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device drivers > > typically hold this lock while iterating the list of multicast addresses to > > program their MAC filter. OTOH, ip_input() uses this lock to check to see if > > an incoming packet is a broadcast packet or not. So even with the pcbinfo > > contention from my previous patch addressed, I still ran into a problem with > > IF_ADDR_LOCK(). We already have some partial support for making this lock be > > an rwlock (the APIs that drivers now use implies an rlock), so I finished the > > transition and checked various non-driver users to see which ones could use a > > read lock (most uses can). The current patch I have for this is on 8, but if > > folks think this is a good idea I can work on porting it to HEAD. For HEAD > > the strategy I would use would be to split this up into 2 phases: > > > > 1) Add IF_ADDR locking macros to differentiate read locks vs write locks along > > with appropriate assertion macros. Update current users of the locking > > macros to use either read or write locks explicitly. To preserve KPI, > > the existing LOCK/UNLOCK macros would map to write lock operations. In > > the initial patch, the locking would still be implemented via a mtx. > > > > 2) Replace the mutex with an rwlock and update the locking macros as > > appropriate. > > > > Phase 1 should definitely be MFC'able. Phase 2 may or may not be. Robert had > > the foresight to change drivers to use explicit function wrappers around > > IF_ADDR_LOCK, and sizeof(struct mtx) == sizeof(struct rwlock), so if we > > changed the lock type the KBI for existing device drivers would all be fine. > > Most of the remaining uses of the locking macros are in parts of the kernel > > that aren't loadable (such as inet and inet6). We can look at the places that > > to do change and if any of them are in kld's then it would be up to re@ to > > decide if 2) was actually safe to merge. However, even if Phase 2 cannot be > > MFC'd, having phase 1 makes it easier for downstream consumers to apply Phase > > 2 locally if they need it. > > I've gone ahead with this approach. I have three separate patches that should > implement Phase 1. All of them can be found at > http://www.FreeBSD.org/~jhb/patches/ > > - if_addr_dev.patch This fixes a few new device drivers that were using > the locking macros directly rather than the wrapper > functions Robert added. I've already sent this > directly to the relevant driver maintainers for their > review. > - if_addr_macros.patch This adds new locking macros to support read locks vs > write locks. However, they all still map to mutex > operations. > - if_addr_uses.patch This changes callers of the existing macros to use > either read or write locks. This is the patch that > could use the most review. Now that all of this is in the tree, here is the small patch to cut the locks over to rwlocks rather than mutexes: Index: kern/subr_witness.c =================================================================== --- kern/subr_witness.c (revision 229726) +++ kern/subr_witness.c (working copy) @@ -520,7 +520,7 @@ { "udpinp", &lock_class_rw }, { "in_multi_mtx", &lock_class_mtx_sleep }, { "igmp_mtx", &lock_class_mtx_sleep }, - { "if_addr_mtx", &lock_class_mtx_sleep }, + { "if_addr_lock", &lock_class_rw }, { NULL, NULL }, /* * IPv6 multicast: @@ -529,7 +529,7 @@ { "udpinp", &lock_class_rw }, { "in6_multi_mtx", &lock_class_mtx_sleep }, { "mld_mtx", &lock_class_mtx_sleep }, - { "if_addr_mtx", &lock_class_mtx_sleep }, + { "if_addr_lock", &lock_class_rw }, { NULL, NULL }, /* * UNIX Domain Sockets Index: net/if_var.h =================================================================== --- net/if_var.h (revision 229726) +++ net/if_var.h (working copy) @@ -189,7 +189,7 @@ int if_afdata_initialized; struct rwlock if_afdata_lock; struct task if_linktask; /* task for link change events */ - struct mtx if_addr_mtx; /* mutex to protect address lists */ + struct rwlock if_addr_lock; /* lock to protect address lists */ LIST_ENTRY(ifnet) if_clones; /* interfaces of a cloner */ TAILQ_HEAD(, ifg_list) if_groups; /* linked list of groups per if */ @@ -246,15 +246,14 @@ /* * Locks for address lists on the network interface. */ -#define IF_ADDR_LOCK_INIT(if) mtx_init(&(if)->if_addr_mtx, \ - "if_addr_mtx", NULL, MTX_DEF) -#define IF_ADDR_LOCK_DESTROY(if) mtx_destroy(&(if)->if_addr_mtx) -#define IF_ADDR_WLOCK(if) mtx_lock(&(if)->if_addr_mtx) -#define IF_ADDR_WUNLOCK(if) mtx_unlock(&(if)->if_addr_mtx) -#define IF_ADDR_RLOCK(if) mtx_lock(&(if)->if_addr_mtx) -#define IF_ADDR_RUNLOCK(if) mtx_unlock(&(if)->if_addr_mtx) -#define IF_ADDR_LOCK_ASSERT(if) mtx_assert(&(if)->if_addr_mtx, MA_OWNED) -#define IF_ADDR_WLOCK_ASSERT(if) mtx_assert(&(if)->if_addr_mtx, MA_OWNED) +#define IF_ADDR_LOCK_INIT(if) rw_init(&(if)->if_addr_lock, "if_addr_lock") +#define IF_ADDR_LOCK_DESTROY(if) rw_destroy(&(if)->if_addr_lock) +#define IF_ADDR_WLOCK(if) rw_wlock(&(if)->if_addr_lock) +#define IF_ADDR_WUNLOCK(if) rw_wunlock(&(if)->if_addr_lock) +#define IF_ADDR_RLOCK(if) rw_rlock(&(if)->if_addr_lock) +#define IF_ADDR_RUNLOCK(if) rw_runlock(&(if)->if_addr_lock) +#define IF_ADDR_LOCK_ASSERT(if) rw_assert(&(if)->if_addr_lock, RA_LOCKED) +#define IF_ADDR_WLOCK_ASSERT(if) rw_assert(&(if)->if_addr_lock, RA_WLOCKED) /* XXX: Compat. */ #define IF_ADDR_LOCK(if) IF_ADDR_WLOCK(if) #define IF_ADDR_UNLOCK(if) IF_ADDR_WUNLOCK(if) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 20:56:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A82B1065706; Fri, 6 Jan 2012 20:56:56 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id D18CE8FC12; Fri, 6 Jan 2012 20:56:55 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F2F7425D3A00; Fri, 6 Jan 2012 20:56:54 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 32949BD89EC; Fri, 6 Jan 2012 20:56:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id BruLBP7ImpBC; Fri, 6 Jan 2012 20:56:52 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BAF91BD89EA; Fri, 6 Jan 2012 20:56:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201061539.55984.jhb@freebsd.org> Date: Fri, 6 Jan 2012 20:56:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201112221130.01823.jhb@freebsd.org> <201112291527.26763.jhb@freebsd.org> <201201061539.55984.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:56:56 -0000 On 6. Jan 2012, at 20:39 , John Baldwin wrote: >=20 > Now that all of this is in the tree, here is the small patch to cut = the locks > over to rwlocks rather than mutexes: I have not checked if that's all (esp. for witness) but the macro = conversion look right. > Index: kern/subr_witness.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kern/subr_witness.c (revision 229726) > +++ kern/subr_witness.c (working copy) > @@ -520,7 +520,7 @@ > { "udpinp", &lock_class_rw }, > { "in_multi_mtx", &lock_class_mtx_sleep }, > { "igmp_mtx", &lock_class_mtx_sleep }, > - { "if_addr_mtx", &lock_class_mtx_sleep }, > + { "if_addr_lock", &lock_class_rw }, > { NULL, NULL }, > /* > * IPv6 multicast: > @@ -529,7 +529,7 @@ > { "udpinp", &lock_class_rw }, > { "in6_multi_mtx", &lock_class_mtx_sleep }, > { "mld_mtx", &lock_class_mtx_sleep }, > - { "if_addr_mtx", &lock_class_mtx_sleep }, > + { "if_addr_lock", &lock_class_rw }, > { NULL, NULL }, > /* > * UNIX Domain Sockets > Index: net/if_var.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if_var.h (revision 229726) > +++ net/if_var.h (working copy) > @@ -189,7 +189,7 @@ > int if_afdata_initialized; > struct rwlock if_afdata_lock; > struct task if_linktask; /* task for link change events = */ > - struct mtx if_addr_mtx; /* mutex to protect address = lists */ > + struct rwlock if_addr_lock; /* lock to protect address lists = */ >=20 > LIST_ENTRY(ifnet) if_clones; /* interfaces of a cloner */ > TAILQ_HEAD(, ifg_list) if_groups; /* linked list of groups per = if */ > @@ -246,15 +246,14 @@ > /* > * Locks for address lists on the network interface. > */ > -#define IF_ADDR_LOCK_INIT(if) mtx_init(&(if)->if_addr_mtx, = \ > - "if_addr_mtx", NULL, MTX_DEF) > -#define IF_ADDR_LOCK_DESTROY(if) = mtx_destroy(&(if)->if_addr_mtx) > -#define IF_ADDR_WLOCK(if) mtx_lock(&(if)->if_addr_mtx) > -#define IF_ADDR_WUNLOCK(if) mtx_unlock(&(if)->if_addr_mtx) > -#define IF_ADDR_RLOCK(if) mtx_lock(&(if)->if_addr_mtx) > -#define IF_ADDR_RUNLOCK(if) mtx_unlock(&(if)->if_addr_mtx) > -#define IF_ADDR_LOCK_ASSERT(if) mtx_assert(&(if)->if_addr_mtx, = MA_OWNED) > -#define IF_ADDR_WLOCK_ASSERT(if) = mtx_assert(&(if)->if_addr_mtx, MA_OWNED) > +#define IF_ADDR_LOCK_INIT(if) rw_init(&(if)->if_addr_lock, = "if_addr_lock") > +#define IF_ADDR_LOCK_DESTROY(if) = rw_destroy(&(if)->if_addr_lock) > +#define IF_ADDR_WLOCK(if) rw_wlock(&(if)->if_addr_lock) > +#define IF_ADDR_WUNLOCK(if) rw_wunlock(&(if)->if_addr_lock) > +#define IF_ADDR_RLOCK(if) rw_rlock(&(if)->if_addr_lock) > +#define IF_ADDR_RUNLOCK(if) rw_runlock(&(if)->if_addr_lock) > +#define IF_ADDR_LOCK_ASSERT(if) rw_assert(&(if)->if_addr_lock, = RA_LOCKED) > +#define IF_ADDR_WLOCK_ASSERT(if) rw_assert(&(if)->if_addr_lock, = RA_WLOCKED) > /* XXX: Compat. */ > #define IF_ADDR_LOCK(if) IF_ADDR_WLOCK(if) > #define IF_ADDR_UNLOCK(if) IF_ADDR_WUNLOCK(if) >=20 > --=20 > John Baldwin --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Fri Jan 6 22:19:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B063C1065670 for ; Fri, 6 Jan 2012 22:19:01 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1750E8FC22 for ; Fri, 6 Jan 2012 22:19:00 +0000 (UTC) Received: (qmail 24294 invoked by uid 1001); 6 Jan 2012 22:18:59 -0000 Date: Fri, 6 Jan 2012 23:18:59 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20120106221859.GC29646@diehard.n-r-g.com> Mail-Followup-To: freebsd-net@freebsd.org References: <20120104.040611.1847309275485655567.hrs@allbsd.org> <4F036A7F.9030906@FreeBSD.org> <52D4B9DF-4BC3-4AF7-BCE0-A88E18F25650@gmail.com> <20120104.144214.74742226.sthaug@nethelp.no> <20120106153500.GA78077@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120106153500.GA78077@sandvine.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:19:01 -0000 On Fri, Jan 06, 2012 at 10:35:01AM -0500, Ed Maste wrote: > On Thu, Jan 05, 2012 at 08:18:39PM -0500, J David wrote: > > > To help understand what's going on and test some of this stuff, I > > hacked up a TCP-MD5-aware echo server and tried various things. > > Hi J David, > > Thank you very much for this extensive testing and analysis. Would you > care to post your basic echo server somewhere for others to use in > debugging this, just to save time for anyone who can debug further? > nc(1) has MD5 support (-S). There is no need for extra tools. You still need to install the SA since nc will only turn on the sockopt. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Sat Jan 7 02:08:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 695A5106566C for ; Sat, 7 Jan 2012 02:08:51 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1158FC13 for ; Sat, 7 Jan 2012 02:08:50 +0000 (UTC) Received: by yhjj52 with SMTP id j52so28760yhj.13 for ; Fri, 06 Jan 2012 18:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NbDZNfSXgokfXIJqjJmmIR0eko3NKF2DeBO87OtxLIc=; b=bDLh63lSgCbY0WiDVUVQ19a5pqHhU2fcYJU4qA7Vy0cLrt4mMPhKu1K/SOCmRpqg9o SZ4+tdI7vW25JL7J1udwr6bzRQX9K3QMsJE+aPog4KH7eM+40kH2X8FC2Pgz+ZywjKxD oa8DSkzSi89V/zT0JZFyX25fKF055oVN5fdnA= MIME-Version: 1.0 Received: by 10.236.190.202 with SMTP id e50mr10789800yhn.91.1325900506483; Fri, 06 Jan 2012 17:41:46 -0800 (PST) Received: by 10.101.14.13 with HTTP; Fri, 6 Jan 2012 17:41:46 -0800 (PST) Date: Fri, 6 Jan 2012 17:41:46 -0800 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Ipv6 gw address scope limited by redirect? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 02:08:51 -0000 Hi, The RFC 4861 (ND) states the following for the icmpv6 redirect: Source Address MUST be the link-local address assigned to the interface from which this message is sent. This combined with the following in icmp6_redirect_input ensures that if a static default route was installed with non-LLA scoped gw the redirect sent by the router will go waste. if (bcmp(&src6, gw6, sizeof(struct in6_addr)) != 0) { 2354 nd6log((LOG_ERR, 2355 "ICMP6 redirect rejected; " 2356 "not equal to gw-for-src=%s (must be same): " 2357 "%s\n", 2358 ip6_sprintf(ip6buf, gw6), 2359 icmp6_redirect_diag(&src6, &reddst6, &redtgt6))); 2360 RTFREE_LOCKED(rt); 2361 goto bad; 2362 } Does it mean that if we want to be concerned with redirects we should ensure only LLA is given as the gw in the indirect routes? Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Sat Jan 7 09:14:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B362106564A for ; Sat, 7 Jan 2012 09:14:07 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 22F208FC0A for ; Sat, 7 Jan 2012 09:14:06 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id q079DxRQ004027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jan 2012 18:14:00 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 07 Jan 2012 18:13:59 +0900 Message-ID: From: Hajimu UMEMOTO To: "Rainer Bredehorn" In-Reply-To: <20120106121604.209390@gmx.net> References: <20120106121604.209390@gmx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.0-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 07 Jan 2012 18:14:00 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 multicast routes with interface local scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 09:14:07 -0000 Hi, >>>>> On Fri, 06 Jan 2012 13:16:03 +0100 >>>>> "Rainer Bredehorn" said: Bredehorn> Thanks! It works fine. I've tried it for FreeBSD 8.1. Bredehorn> It would be nice to change it in FreeBSD 9.0 and 8.3! ;-) I've committed it into HEAD. http://svn.freebsd.org/changeset/base/229766 Unfortunately, it's too late to be in time for 9.0-RELEASE. I'll MFC it in 1 week later. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/