From owner-freebsd-net@FreeBSD.ORG Sun May 15 17:58:00 2011 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 CCAFA1065670 for ; Sun, 15 May 2011 17:58:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DDB68FC14 for ; Sun, 15 May 2011 17:58:00 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2d19:d22d:b020:7e1b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 179E14AC1C for ; Sun, 15 May 2011 21:57:59 +0400 (MSD) Date: Sun, 15 May 2011 21:57:57 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1351228297.20110515215757@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: State of multicast routing in 8-STABLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 17:58:00 -0000 Hello, Freebsd-net. Is here any solutions for routing multicast for 8-STABLE gateway with NAT? mrouted is know as very buggy (and doesn't support PIM), igmpproxy is = very unstable too... Anything else? Is it possible to use IPTV, which is multicasted by my ISP, when FreeBSD is gateway + NAT, on any computer in my network, different channels (read: different mcast addresses) from different computers? Here are some discussions on forums, but almost all of them are about 7-STABLE era and results is very controversial. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon May 16 09:23:11 2011 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 F3DA0106564A; Mon, 16 May 2011 09:23:10 +0000 (UTC) (envelope-from ivor.prebeg@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0188FC19; Mon, 16 May 2011 09:23:10 +0000 (UTC) Received: by fxm11 with SMTP id 11so4099403fxm.13 for ; Mon, 16 May 2011 02:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tDVA5kY6zyCIrQ7YxG1Unoa5ClrRajXkREAjqMKitok=; b=RMuz1e/6bjNvS6HZyOcOHwKSJyj4d0Gt/Mz05ATqkwUx+tyh7Rys6TSvv2pHkn5k5W xECFyOvimaVJcjxWgMXy2Gkr4orkxDFqnnDX75tjlfdS5AAutDpxmtVV7zza+2YKh1/O yTDFyL+SrWV47nx83lP5HwZnlpFVwJphYR5ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OicL4Cij7axh1rnEUJGnaEtRMQiOPuD2n45LBoVtUqqr2eYd1ez8sH3yWdwslaj7nY l3BrkBfC8JvaRPsE8Tghdxg5E3nnjCWjh73PEiMuH3aujoZKiJS0+GFwhM3ZBElzQ4fo Tv9NCviuNUOBd2KWgJv8MNSjJ2h0qZE1+82BE= Received: by 10.223.117.134 with SMTP id r6mr3182541faq.147.1305536357439; Mon, 16 May 2011 01:59:17 -0700 (PDT) Received: from [10.7.6.185] (95-178-144-148.dsl.optinet.hr [95.178.144.148]) by mx.google.com with ESMTPS id 18sm1476822fan.1.2011.05.16.01.59.15 (version=SSLv3 cipher=OTHER); Mon, 16 May 2011 01:59:16 -0700 (PDT) Message-ID: <4DD0E762.7070700@gmail.com> Date: Mon, 16 May 2011 10:59:14 +0200 From: Ivor Prebeg User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1351228297.20110515215757@serebryakov.spb.ru> In-Reply-To: <1351228297.20110515215757@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: State of multicast routing in 8-STABLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 09:23:11 -0000 While I worked on virtualization (vimage/jail) of PIM-SM/PIM-DM, I used XORP. It ain't perfect, but served me well. Maybe I can even find confs. On 05/15/2011 07:57 PM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Is here any solutions for routing multicast for 8-STABLE gateway with > NAT? mrouted is know as very buggy (and doesn't support PIM), igmpproxy is very > unstable too... Anything else? > > Is it possible to use IPTV, which is multicasted by my ISP, when > FreeBSD is gateway + NAT, on any computer in my network, different > channels (read: different mcast addresses) from different computers? > Here are some discussions on forums, but almost all of them are about > 7-STABLE era and results is very controversial. > From owner-freebsd-net@FreeBSD.ORG Mon May 16 09:28:37 2011 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 12CC21065675 for ; Mon, 16 May 2011 09:28:37 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A454F8FC19 for ; Mon, 16 May 2011 09:28:36 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c0e1:7989:b1b9:78c3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 3B6ED4AC1C; Mon, 16 May 2011 13:28:35 +0400 (MSD) Date: Mon, 16 May 2011 13:28:34 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1812728502.20110516132834@serebryakov.spb.ru> To: Ivor Prebeg In-Reply-To: <4DD0E762.7070700@gmail.com> References: <1351228297.20110515215757@serebryakov.spb.ru> <4DD0E762.7070700@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: State of multicast routing in 8-STABLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 09:28:37 -0000 Hello, Ivor. You wrote 16 =EC=E0=FF 2011 =E3., 12:59:14: > While I worked on virtualization (vimage/jail) of PIM-SM/PIM-DM, I used > XORP. > It ain't perfect, but served me well. Maybe I can even find confs. It seems, that PIM-SM requires that my ISP allows join of my router to routing domain, it is not possible in my case :( After reading many archives and forums (it is strange, but no new material on this topic can be found), it seems to me, that igmpproxy 0.1 is only solution in my case, and it is buggy. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon May 16 11:07:10 2011 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 0E6E9106567D for ; Mon, 16 May 2011 11:07:10 +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 EFA908FC26 for ; Mon, 16 May 2011 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4GB79Iw071280 for ; Mon, 16 May 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4GB79cR071278 for freebsd-net@FreeBSD.org; Mon, 16 May 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 May 2011 11:07:09 GMT Message-Id: <201105161107.p4GB79cR071278@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, 16 May 2011 11:07:10 -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/156978 net [lagg][patch] Take lagg rlock before checking flags 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/156493 net [msk] Marvell Yukon 2 device works only few seconds o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155636 net [msk] msk driver locks marvel yukon 88E8057 NIC o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -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/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 360 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 16 20:24:30 2011 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 8DDA0106566B; Mon, 16 May 2011 20:24:30 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64A038FC13; Mon, 16 May 2011 20:24:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4GKOUPM086043; Mon, 16 May 2011 20:24:30 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4GKOUjs086039; Mon, 16 May 2011 20:24:30 GMT (envelope-from yongari) Date: Mon, 16 May 2011 20:24:30 GMT Message-Id: <201105162024.p4GKOUjs086039@freefall.freebsd.org> To: vanatubo@googlemail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/155636: [msk] msk driver locks marvel yukon 88E8057 NIC 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, 16 May 2011 20:24:30 -0000 Synopsis: [msk] msk driver locks marvel yukon 88E8057 NIC State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon May 16 20:22:12 UTC 2011 State-Changed-Why: Would you show me dmesg output to identify which controller you have? If you have Yukon Ultra2(88E8057 I guess), could you try patch at the following URL? Let me know whether it makes any difference for you. http://people.freebsd.org/~yongari/msk/msk.ultra2.diff Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon May 16 20:22:12 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=155636 From owner-freebsd-net@FreeBSD.ORG Tue May 17 00:13:09 2011 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 457BD106566C for ; Tue, 17 May 2011 00:13:09 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6FA8FC0A for ; Tue, 17 May 2011 00:13:08 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p4H0CrY0001655 for ; Mon, 16 May 2011 17:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1305591174; bh=tVvdMVopk3WUT7SJTexhsRoHX67y/FKDOyscrL7rr54=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=fV1pC5/6WsjZIMCRGfypmk8iSo8mxnYzoeVLFzhte4ekmcragNYxqAZbmYfGoriuE JdtuR0cl3CIhK3M0oOzQj3XEjtBMPUrF47rhjUTgmj7RDhT+J/RCoq7R9DMMps22NF wmlT5m1sUAqWm+uVlpXmC7JaVIx6mxxeBPkToT08= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 16 May 2011 17:12:53 -0700 Message-ID: <1305591173.5624.15.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Subject: Fake /dev/ed0 on VM corrupted X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 00:13:09 -0000 Not sure what's going on here, but I've installed an updated 7-stable on a VM in my Fedora kvm enabled laptop and I see that /dev/ed0 is having issues when doing network operations. I could have sworn that we resolved this, but can't remember what what the fix was (probably I switched to a fake /dev/em0). Thoughts? ed0: NIC memory corrupt - invalid packet length 13905 ed0: NIC memory corrupt - invalid packet length 8263 ed0: NIC memory corrupt - invalid packet length 58250 ed0: NIC memory corrupt - invalid packet length 7531 ed0: NIC memory corrupt - invalid packet length 51706 ed0: NIC memory corrupt - invalid packet length 16108 ed0: NIC memory corrupt - invalid packet length 28242 ed0: NIC memory corrupt - invalid packet length 13162 ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 ed0: [ITHREAD] ed0: WARNING: using obsoleted if_watchdog interface ed0: Ethernet address: 52:54:00:1c:b8:82 ed0@pci0:0:3:0: class=0x020000 card=0x11001af4 chip=0x802910ec rev=0x00 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'PCI Full-Duplex Ethernet Controller with PnP Function (RTL8029)' class = network subclass = ethernet dev.ed.0.type: RTL8029 dev.ed.0.TxMem: 3072 dev.ed.0.RxMem: 13312 dev.ed.0.Mem: 16384 dev.ed.0.%desc: RealTek 8029 dev.ed.0.%driver: ed dev.ed.0.%location: slot=3 function=0 handle=\_SB_.PCI0.S3__ dev.ed.0.%pnpinfo: vendor=0x10ec device=0x8029 subvendor=0x1af4 subdevice=0x1100 class=0x020000 dev.ed.0.%parent: pci0 From owner-freebsd-net@FreeBSD.ORG Tue May 17 07:57:27 2011 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 461F01065678 for ; Tue, 17 May 2011 07:57:27 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 1054A8FC1B for ; Tue, 17 May 2011 07:57:26 +0000 (UTC) Received: (qmail 73523 invoked by uid 0); 17 May 2011 07:30:45 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 May 2011 07:30:45 -0000 Received: (qmail 73520 invoked by uid 90); 17 May 2011 07:30:45 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 May 2011 07:30:45 -0000 Date: Tue, 17 May 2011 03:30:44 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.nat.fasttrackmonkey.com To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: IPv6 alias masks/masks for routed aliases 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, 17 May 2011 07:57:27 -0000 Hello, I'm having trouble finding the canonical answer on two uses of interface aliases. First, the easy one. For IPv6 aliases, what is the proper subnet? I've found some old info on the WIDE site stating that it should be the same as the main interface (ie: if I've got a /48, my alias should use /48 as well). This runs contrary to what I know of IPv4 aliases - if you've already got another IP on the adapter, further aliases in the same subnet should be created with a /32 mask. And the second one, which is also probably easy. We're going to move at some point from a bunch of subnets on the same wire to having our own router that gets our blocks routed to it. At that point I'd like to move to routing individual IPs (or small subnets) to each host behind the router. For example, say we have the following routed to our router: 10.1.0.0/27 10.2.0.0/27 10.3.0.0/27 All the hosts behind our router are in 10.1.0.0/27. I want to send some IPs from 10.2.0.0/27 and 10.3.0.0/27 to a host at 10.1.0.2, so I do the equivalent of "ip route 10.2.0.0 255.255.255.248 10.1.0.2" (cisco speak) on the router box. How should the aliases on 10.1.0.2 be defined? Should they all have /32 masks? Should the first get a /29 and the rest a /32? Is this even a valid config? In reality, we have way more subnets, totally non-contiguous, varying masks. With VRRP on the provider's side, we immediately lose 2 IPs from each subnet in our current setup, plus the network and broadcast IPs. I'm hoping that in a routed setup I can regain not only the VRRP IPs but the top and bottom of each subnet... Considering the scarcity of IPs these days, that would be a big help. Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Tue May 17 08:57:04 2011 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 9F98D106564A for ; Tue, 17 May 2011 08:57:04 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 276BB8FC0A for ; Tue, 17 May 2011 08:57:02 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4H8ibhr059127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 17:44:48 +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 p4H8iPlA099858; Tue, 17 May 2011 17:44:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 17 May 2011 17:43:13 +0900 (JST) Message-Id: <20110517.174313.868674729938461030.hrs@allbsd.org> To: spork@bway.net 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 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_May_17_17_43_13_2011_264)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Tue, 17 May 2011 17:44:48 +0900 (JST) X-Spam-Status: No, score=6.1 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 alias masks/masks for routed aliases 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, 17 May 2011 08:57:04 -0000 ----Security_Multipart(Tue_May_17_17_43_13_2011_264)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Sprickman wrote in : sp> First, the easy one. For IPv6 aliases, what is the proper subnet? Normally it is a /64. See also Section 2.5.4 in RFC 4291. sp> And the second one, which is also probably easy. We're going to move sp> at some point from a bunch of subnets on the same wire to having our sp> own router that gets our blocks routed to it. At that point I'd like sp> to move to routing individual IPs (or small subnets) to each host sp> behind the router. sp> sp> For example, say we have the following routed to our router: sp> sp> 10.1.0.0/27 sp> 10.2.0.0/27 sp> 10.3.0.0/27 sp> sp> All the hosts behind our router are in 10.1.0.0/27. I want to send sp> some IPs from 10.2.0.0/27 and 10.3.0.0/27 to a host at 10.1.0.2, so I sp> do the equivalent of "ip route 10.2.0.0 255.255.255.248 10.1.0.2" sp> (cisco speak) on the router box. How should the aliases on 10.1.0.2 sp> be defined? Should they all have /32 masks? Should the first get a sp> /29 and the rest a /32? sp> sp> Is this even a valid config? In reality, we have way more subnets, sp> totally non-contiguous, varying masks. With VRRP on the provider's sp> side, we immediately lose 2 IPs from each subnet in our current setup, sp> plus the network and broadcast IPs. I'm hoping that in a routed setup sp> I can regain not only the VRRP IPs but the top and bottom of each sp> subnet... Considering the scarcity of IPs these days, that would be a sp> big help. Well, I could not understand what you are trying... Is 10.1.0.2 located on 10.1.0.0/27 and acting as another nexthop router? If you want to split three subnets on a single wire into three subnets on three wires, simply configuring three /27 addresses to each interface on the router works. If you want to route a part of the traffic from specific addresses to a specific host, you can add a specific route for the address range. -- Hiroki ----Security_Multipart(Tue_May_17_17_43_13_2011_264)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3SNSEACgkQTyzT2CeTzy13YwCeL++0lPWWuDi3aCQBWiyg9O31 7rQAoLqt0tweIZpRLw+JFwMWsK1G4jPU =L1ZE -----END PGP SIGNATURE----- ----Security_Multipart(Tue_May_17_17_43_13_2011_264)---- From owner-freebsd-net@FreeBSD.ORG Tue May 17 12:22:17 2011 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 9A81A106564A for ; Tue, 17 May 2011 12:22:17 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 72B748FC18 for ; Tue, 17 May 2011 12:22:17 +0000 (UTC) Received: by iwn33 with SMTP id 33so500921iwn.13 for ; Tue, 17 May 2011 05:22:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.208.142 with SMTP id gc14mr382732ibb.115.1305634936736; Tue, 17 May 2011 05:22:16 -0700 (PDT) Received: by 10.231.14.2 with HTTP; Tue, 17 May 2011 05:22:16 -0700 (PDT) X-Originating-IP: [196.215.107.196] Date: Tue, 17 May 2011 14:22:16 +0200 Message-ID: From: Cole To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 12:22:17 -0000 Hi. Ive written a kernel module that modifies the data of outgoing TCP packets. I use pfil_hook to insert my module into the outgoing packet stream. Depending on the data, the size of data in the TCP packet may change, either increasing or decreasing. When modifying the data size, I update the mbuf len, the pkthdr len, the size in the IP header, as well as modifying the TCP checksum. I also update the tcpcb->snd_nxt, and tcpcb->snd_max values. The problem I am having at the moment is only when I modify the packet and the data size decreases. Whenever the data size increases I dont have a problem. However, when the data size decreases, the TCP architecture tries to retransmit the missing data. i.e. if original data in the TCP packet is 30 bytes in size, and i modify it and it is now only 18 bytes in size, then the box retransmits the missing 12 bytes that it thought never got transmitted. This is where my problem lies, im trying to find out what variable or structure I need to update so that the box doesnt think that it needs to retransmit those missing bytes. Ive been looking at the tcbcb structure in netinet/tcp_var.h and I cannot seem to see any values inside this structure that point to the data size of the packet. Ive also looked at tcp_output.c and I see that theres functions that use tcpcb->sackhint to see if theres missing bytes. However when examing those in the kernel module of the outgoing packet, the pointer is always NULL. If anyone has any ideas or suggestions, I would be glad to hear. Thanks /Cole From owner-freebsd-net@FreeBSD.ORG Tue May 17 13:16:52 2011 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 64F59106564A for ; Tue, 17 May 2011 13:16:52 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5D98FC0A for ; Tue, 17 May 2011 13:16:51 +0000 (UTC) Received: by iwn33 with SMTP id 33so558425iwn.13 for ; Tue, 17 May 2011 06:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.209 with SMTP id fz17mr407940ibb.140.1305638211503; Tue, 17 May 2011 06:16:51 -0700 (PDT) Received: by 10.231.14.2 with HTTP; Tue, 17 May 2011 06:16:51 -0700 (PDT) X-Originating-IP: [196.215.107.196] In-Reply-To: <20110517124855.GA25571@insomnia.benzedrine.cx> References: <20110517124855.GA25571@insomnia.benzedrine.cx> Date: Tue, 17 May 2011 15:16:51 +0200 Message-ID: From: Cole To: Daniel Hartmeier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 13:16:52 -0000 Hi. These are obviously things I will need to look into regarding retransmission if the packet does actually get lost. As for the MTU issue, if the kernel mod pushes the data over the MTU size, then the packet is not changed and left as is. I was hoping to keep this clean, and use existing methods for hooking into the stream. Also the goal im working for is to be able to use this on a box doing routing to hopefully get some sort of compression working between 2 end points. So most of the data would not actual be generated from userland processes. So im back to the original issue of trying to track down the variable/structure that is holding the original size of the packet or some variable holding the expected return ACK? Thanks /Cole On 17 May 2011 14:48, Daniel Hartmeier wrote: > What if your modified (shortened) packet does get lost? If you > messed with the tcpcb in the way you intend, how do you plan on > getting retransmission working, when it's needed? > > Or what if you enlarge a packet, are you sure it won't violate > the MTU? > > It seems you're doing this on wrong side of the stack. Why don't > you hook your code into the side facing userland, where socket > writes from the userland process add data to the kernel buffer, > and the socket is still a stream? > > Or what's the reason for doing it after the stream has been > packetized already? > > Daniel > From owner-freebsd-net@FreeBSD.ORG Tue May 17 13:28:01 2011 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 509BF106566B for ; Tue, 17 May 2011 13:28:01 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9D38FC0C for ; Tue, 17 May 2011 13:27:59 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p4HCmt6u014321 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 14:48:55 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p4HCmtQh011966; Tue, 17 May 2011 14:48:55 +0200 (MEST) Date: Tue, 17 May 2011 14:48:55 +0200 From: Daniel Hartmeier To: Cole Message-ID: <20110517124855.GA25571@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 13:28:01 -0000 What if your modified (shortened) packet does get lost? If you messed with the tcpcb in the way you intend, how do you plan on getting retransmission working, when it's needed? Or what if you enlarge a packet, are you sure it won't violate the MTU? It seems you're doing this on wrong side of the stack. Why don't you hook your code into the side facing userland, where socket writes from the userland process add data to the kernel buffer, and the socket is still a stream? Or what's the reason for doing it after the stream has been packetized already? Daniel From owner-freebsd-net@FreeBSD.ORG Tue May 17 13:37:11 2011 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 515E5106566B for ; Tue, 17 May 2011 13:37:11 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id B44448FC14 for ; Tue, 17 May 2011 13:37:10 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p4HDbBWW017502 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 15:37:11 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p4HDbBeG003401; Tue, 17 May 2011 15:37:11 +0200 (MEST) Date: Tue, 17 May 2011 15:37:11 +0200 From: Daniel Hartmeier To: Cole Message-ID: <20110517133711.GB25571@insomnia.benzedrine.cx> References: <20110517124855.GA25571@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 13:37:11 -0000 On Tue, May 17, 2011 at 03:16:51PM +0200, Cole wrote: > Also the goal im working for is to be able to use > this on a box doing routing to hopefully get some sort of compression > working between 2 end points. So most of the data would not actual be > generated from userland processes. But on a router there are not tcpcbs and no variables... Daniel From owner-freebsd-net@FreeBSD.ORG Tue May 17 13:43:06 2011 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 466CE106566C for ; Tue, 17 May 2011 13:43:06 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from mail.sky.od.ua (relay.sky.od.ua [81.25.224.8]) by mx1.freebsd.org (Postfix) with ESMTP id EFFB98FC21 for ; Tue, 17 May 2011 13:43:05 +0000 (UTC) Received: from relay.sky.od.ua (mail [81.25.224.8]) by mail.sky.od.ua (Postfix) with ESMTP id 5DB992B73; Tue, 17 May 2011 16:24:20 +0300 (EEST) X-Virus-Scanned: amavisd-new at sky.od.ua Received: from mail.sky.od.ua ([81.25.224.8]) by relay.sky.od.ua (relay.sky.od.ua [81.25.224.8]) (amavisd-new, port 10024) with ESMTP id 92f0BrOifjWI; Tue, 17 May 2011 16:24:18 +0300 (EEST) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mail.sky.od.ua (Postfix) with ESMTP id 28CB92B5E; Tue, 17 May 2011 16:24:18 +0300 (EEST) Message-ID: <4DD27701.7050505@skylinetele.com> Date: Tue, 17 May 2011 16:24:17 +0300 From: "Prokofiev S.P." Organization: Skyline Telecom. User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.2.13) Gecko/20110131 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Vogel References: <4B0AA2CC.5010205@skylinetele.com> <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> In-Reply-To: <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: kern/141285: [em] hangs down/up intel nic during creating vlan 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, 17 May 2011 13:43:06 -0000 Hello All! Please close thise PR kern/141285, because in RELEASE-8.2 it is fixed. Thanks Jack Vogel ! From owner-freebsd-net@FreeBSD.ORG Tue May 17 14:32:08 2011 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 E51E4106566C; Tue, 17 May 2011 14:32:08 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 73A048FC14; Tue, 17 May 2011 14:32:08 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 27C3140026; Tue, 17 May 2011 16:32:07 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 1C55C4002D; Tue, 17 May 2011 16:32:07 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FAKE_REPLY_C autolearn=disabled version=3.3.1 X-Spam-Score: 0.1 Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id CEACF40026; Tue, 17 May 2011 16:32:06 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 9BCA1119C04; Tue, 17 May 2011 16:32:06 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 4EADC12B2DA; Tue, 17 May 2011 16:32:06 +0200 (CEST) Message-ID: <4DD286E5.2070605@daemonic.se> Date: Tue, 17 May 2011 16:32:05 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, fming@borderware.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: kern/85320: [gre] [patch] possible depletion of kernel stack in ip_gre.c when net.isr.enable = 1 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, 17 May 2011 14:32:09 -0000 Hi! The issue mentioned in the PR has been fixed in 9-current and 8 (all versions). It can probably be merged to 7-stable as well, and/or the PR closed. Thanks! Regards! -- Niclas From owner-freebsd-net@FreeBSD.ORG Tue May 17 14:40:08 2011 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 9EBAE106566C for ; Tue, 17 May 2011 14:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB398FC08 for ; Tue, 17 May 2011 14:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4HEe8xs019664 for ; Tue, 17 May 2011 14:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4HEe8Eo019663; Tue, 17 May 2011 14:40:08 GMT (envelope-from gnats) Date: Tue, 17 May 2011 14:40:08 GMT Message-Id: <201105171440.p4HEe8Eo019663@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: kern/85320: [gre] [patch] possible depletion of kernel stack in ip_gre.c when net.isr.enable = 1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 14:40:08 -0000 The following reply was made to PR kern/85320; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, fming@borderware.com Cc: freebsd-net@freebsd.org Subject: Re: kern/85320: [gre] [patch] possible depletion of kernel stack in ip_gre.c when net.isr.enable = 1 Date: Tue, 17 May 2011 16:32:05 +0200 Hi! The issue mentioned in the PR has been fixed in 9-current and 8 (all versions). It can probably be merged to 7-stable as well, and/or the PR closed. Thanks! Regards! -- Niclas From owner-freebsd-net@FreeBSD.ORG Tue May 17 16:27:03 2011 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 E25521065676 for ; Tue, 17 May 2011 16:27:03 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 534A08FC15 for ; Tue, 17 May 2011 16:27:03 +0000 (UTC) Received: from [192.168.1.195] (p508FA4AF.dip.t-dialin.net [80.143.164.175]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6A0841C0C0BED; Tue, 17 May 2011 18:27:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20110517162034.GA92657@DataIX.net> Date: Tue, 17 May 2011 18:27:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43344BAA-EC28-47A7-99AA-076C39464EC4@fh-muenster.de> References: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de> <20110517162034.GA92657@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) Cc: net@freebsd.org Subject: Re: netstat fix 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, 17 May 2011 16:27:04 -0000 On May 17, 2011, at 6:20 PM, Jason Hellenthal wrote: >=20 > Michael, >=20 > On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote: >> Dear all, >>=20 >> fwip0 1500 = 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00 0 0 0 = 0 0 0 0 0 >>=20 >=20 > I agree with your patch but on another note. You probably know better > than I, Is it common for fwip* to have a MAC(hardware address) that = long > ? I have no idea if it is common. But also other addresses (like IPv6) are truncated in the output by netstat... Best regards Michael >=20 > I have never seen this before. Not a firewire user here. >=20 > --=20 >=20 > Regards, (jhell) > Jason Hellenthal >=20 From owner-freebsd-net@FreeBSD.ORG Tue May 17 16:45:21 2011 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 D0628106564A for ; Tue, 17 May 2011 16:45:21 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7F68FC14 for ; Tue, 17 May 2011 16:45:21 +0000 (UTC) Received: by yxl31 with SMTP id 31so285183yxl.13 for ; Tue, 17 May 2011 09:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=8od2v0pSiCvQGfzJT85PE8URyrXff3yZOlYf9dUVHfQ=; b=eZr+OeQOsUAJtAEGmHHuWh41PtJTMdv6KgzP0aAFmADhEd3r5OOb4CUIoFZpG0jvyQ whV1gsp8Ax93LV3+lyYZfcQAZ4JluzFLCj5dAnGbdERdN2EPYY8lVXZexO67cOTex7B4 niO7PDwYnrO3X38Y9Ua72Gk5zaOuPiEo9OFvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=eEAjHYwODPX6+E7QxeIr0mElORxBE2c5e4MJLjpItzFhfvXNO+prZmynKGPnLQ0RTn stTqomUQZoGdAY7A01EQ/tzGFqMsAYFqDGM9LMjoR2vd/dxMJ886De2UoeyXviVPpyv3 e9jgjRrtLBa37nmsnv2KoXAZfVYhRanxgpe3U= Received: by 10.236.145.70 with SMTP id o46mr743265yhj.288.1305649240662; Tue, 17 May 2011 09:20:40 -0700 (PDT) Received: from DataIX.net ([99.190.81.196]) by mx.google.com with ESMTPS id s21sm256045yhn.93.2011.05.17.09.20.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 09:20:38 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4HGKZUC094331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 12:20:35 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4HGKYgX094330; Tue, 17 May 2011 12:20:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 17 May 2011 12:20:34 -0400 From: Jason Hellenthal To: Michael Tuexen Message-ID: <20110517162034.GA92657@DataIX.net> References: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: net@freebsd.org Subject: Re: netstat fix 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, 17 May 2011 16:45:22 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael, On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote: > Dear all, >=20 > fwip0 1500 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00= 0 0 0 0 0 0 0 0 >=20 I agree with your patch but on another note. You probably know better than I, Is it common for fwip* to have a MAC(hardware address) that long ? I have never seen this before. Not a firewire user here. --=20 Regards, (jhell) Jason Hellenthal --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJN0qBSAAoJEJBXh4mJ2FR+TzMH/R0EFdIvEp2GMKWzf0do49lT 1HeHAU+guMsA0RzvKNFNRBZ/ixBSnTvWVLNlLWm+fEVzmOfal/npMOc7hsC2iqRN YLOzbqwlg990Q9isNB2/7Db0bL1gz3K5X0A5VYwhp9l87cjmWe4edHWJG52qA9AX kQOxDh/Iq5Q9w9dgNaMuyILuX5Q2GPHI8kDoTS0gpdcZoqGfPcNrHmLJK+m8AhE0 4HSz87nEsSGVhjDyAfjaKZ9YV1qbSc33z05ILI8V5BjBB7/yiFJ/cfSbI3Tje9iI 0VidEpfUYDQCaWAgDIZWAWM72r5k7BHCHNTIqg6zyFNlEEgiY/6P+P8vflCr7fg= =FK7j -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Tue May 17 17:02:10 2011 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 B8842106567C for ; Tue, 17 May 2011 17:02:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9CA8FC36 for ; Tue, 17 May 2011 17:02:10 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QMNeq-000JjH-PG; Tue, 17 May 2011 13:02:08 -0400 Date: Tue, 17 May 2011 13:02:08 -0400 From: Gary Palmer To: Jason Hellenthal Message-ID: <20110517170208.GC37035@in-addr.com> References: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de> <20110517162034.GA92657@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110517162034.GA92657@DataIX.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Michael Tuexen , net@freebsd.org Subject: Re: netstat fix 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, 17 May 2011 17:02:10 -0000 On Tue, May 17, 2011 at 12:20:34PM -0400, Jason Hellenthal wrote: > > Michael, > > On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote: > > Dear all, > > > > fwip0 1500 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00:00 0 0 0 0 0 0 0 0 > > > > I agree with your patch but on another note. You probably know better > than I, Is it common for fwip* to have a MAC(hardware address) that long > ? Yes. My FreeBSD 7.4 box: % ifconfig fwip0 fwip0: flags=8802 metric 0 mtu 1500 lladdr 80.5b.6.0.46.c.bd.0.a.2.ff.fe.0.0.0.0 % netstat -ni -I fwip0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fwip0 1500 80:5b:06:00:46:0c:bd:00:0a:02:ff:fe:00:00:00:00 0 0 0 0 0 Pretty sure I remember long MAC addresses on fwip0 as long as I've had the FireWire card Regards, Gary From owner-freebsd-net@FreeBSD.ORG Tue May 17 17:04:39 2011 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 B19F3106564A for ; Tue, 17 May 2011 17:04:39 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 67A5A8FC12 for ; Tue, 17 May 2011 17:04:39 +0000 (UTC) Received: by iyj12 with SMTP id 12so818500iyj.13 for ; Tue, 17 May 2011 10:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=exm+2qoUeLuB+rJsUk9ZDdN4tr/4X9eEHVbAvKXU+H0=; b=oMk6Lb144AR8egR9xlNsFCaIpGJw36eNWksJonlGQEBXBvgAtn8xOVI9x4bvt9B+DZ T2VlEZf53NQz1Lf0paD8Xu796OdxqKYmY64r1wLfO06IynuQfRSnRcT3OUWz+iAIFb5w KdJSRVV7LSgk6kjg9rxMyDDiFoPFQd3V38VCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=QyxI6RkWB8ReDGbWbpj+0XQDEv3v/8yiG3uhnsrPQFeoxJXvZEDhSZThmhSotMz+bD KEPSROzR3wefQQGzaoXVBckngKeACX5r0F4sNEz3LTHeoxr4kAf74a61+AqpBfyLREdQ iSmNfgvuwPIZRN5BpN0qdO/O1mwOsYvDN9OFs= Received: by 10.42.220.134 with SMTP id hy6mr952346icb.386.1305651878641; Tue, 17 May 2011 10:04:38 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net [99.190.81.196]) by mx.google.com with ESMTPS id 14sm308219ibc.25.2011.05.17.10.04.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 10:04:37 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4HH4YOK096083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2011 13:04:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4HH4Xb9096082; Tue, 17 May 2011 13:04:33 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 17 May 2011 13:04:33 -0400 From: Jason Hellenthal To: Michael Tuexen Message-ID: <20110517170433.GB92657@DataIX.net> References: <3FEFBA56-63FC-403A-960E-627FD347AA06@fh-muenster.de> <20110517162034.GA92657@DataIX.net> <43344BAA-EC28-47A7-99AA-076C39464EC4@fh-muenster.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <43344BAA-EC28-47A7-99AA-076C39464EC4@fh-muenster.de> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: net@freebsd.org Subject: Re: netstat fix 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, 17 May 2011 17:04:39 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael, On Tue, May 17, 2011 at 06:27:01PM +0200, Michael Tuexen wrote: > On May 17, 2011, at 6:20 PM, Jason Hellenthal wrote: >=20 > >=20 > > Michael, > >=20 > > On Sun, May 08, 2011 at 07:23:37PM +0200, Michael Tuexen wrote: > >> Dear all, > >>=20 > >> fwip0 1500 00:30:05:b3:50:0b:40:e4:0a:02:ff:fe:00:00:00= :00 0 0 0 0 0 0 0 0 > >>=20 > >=20 > > I agree with your patch but on another note. You probably know better > > than I, Is it common for fwip* to have a MAC(hardware address) that long > > ? > I have no idea if it is common. But also other addresses (like IPv6) > are truncated in the output by netstat... >=20 Yeah that can be expected of IPv6. There is just not enough room in the world of screen space to display those properly or in some globally exceptable way unless we want to start changing netstat to display addreesses line by line. Ive been looking around a bit "EUI-64" ... never mind ;) http://en.wikipedia.org/wiki/EUI-64 Relavent section: In addition, the EUI-64 numbering system encompasses both MAC-48 and EUI-48 identifiers by a simple translation mechanism. To convert a MAC-48 into an EUI-64, copy the OUI, append the two octets FF-FF, and then copy the organization-specified part. To convert an EUI-48 into an EUI-64, the same process is used, but the sequence inserted is "FF-FE". In both cases, the process can be trivially reversed when necessary. Organizations issuing EUI-64s are cautioned against issuing identifiers that could be confused with these forms. The IEEE policy is to discourage new uses of 48-bit identifiers in favor of the EUI-64 system. IPv6one of the most prominent standards that uses EUI-64treats MAC-48 as EUI-48 instead (as it is chosen from the same address pool). This results in extending MAC addresses (such as IEEE 802 MAC address) to EUI-64 using FF-FE rather than FF-FF. --=20 Regards, (jhell) Jason Hellenthal --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJN0qqhAAoJEJBXh4mJ2FR+qjkH/jD0hXdb7fJ+z4f6jB/+2Jbu fIYt8ZG6PYfc7phoOVUQUGwYL6ZhAzaE9zxPUSRAn/58ZiOpS76t3VzA8epu9Mgh P2xRawF9JC0zsd/94+zdbbPsQewQMtNSmEBbvNdhmIGljfgb1pH6CwsJf3fQ2we0 dlOrjnWODU0TBbJXTAwLdKTZ4qu2l5Z1uQUs3W2OwT71mOCeqb5vgVxErSxOEzUA fmW+wU3cx4GLVoLOXZXvUxPso9jm74Vrw41jE8MvknZuE16QPMCuvlMZKIERYYOY GmGDu6J65D83uRtDGaolDWP1B+v2BeTYpa1PyqAuaVhBrCUrAnMK6011x3jgC7s= =Sfgu -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-net@FreeBSD.ORG Tue May 17 17:40:00 2011 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 BEAE51065670 for ; Tue, 17 May 2011 17:40:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id A049C8FC15 for ; Tue, 17 May 2011 17:40:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp020.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLC008R1P2NP800@asmtp020.mac.com> for freebsd-net@freebsd.org; Tue, 17 May 2011 10:40:00 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-17_04:2011-05-13, 2011-05-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105170095 From: Chuck Swiger In-reply-to: Date: Tue, 17 May 2011 10:39:59 -0700 Message-id: <9250F168-6DD4-41E3-8F4C-39D72A4DF6DC@mac.com> References: <20110517124855.GA25571@insomnia.benzedrine.cx> To: Cole X-Mailer: Apple Mail (2.1084) Cc: freebsd-net Net Subject: Re: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 17:40:00 -0000 On May 17, 2011, at 6:16 AM, Cole wrote: > I was hoping to keep this clean, and use existing methods for hooking > into the stream. Also the goal im working for is to be able to use > this on a box doing routing to hopefully get some sort of compression > working between 2 end points. So most of the data would not actual be > generated from userland processes. Why don't you use a userland proxy or routing mechanism which supports compression, like OpenVPN or OpenSSH port forwarding? Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue May 17 18:36:19 2011 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 15FFE1065677 for ; Tue, 17 May 2011 18:36:19 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DED838FC20 for ; Tue, 17 May 2011 18:36:18 +0000 (UTC) Received: by iyj12 with SMTP id 12so920987iyj.13 for ; Tue, 17 May 2011 11:36:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.152.199 with SMTP id j7mr967641icw.404.1305657378156; Tue, 17 May 2011 11:36:18 -0700 (PDT) Received: by 10.231.14.2 with HTTP; Tue, 17 May 2011 11:36:18 -0700 (PDT) X-Originating-IP: [196.215.107.196] In-Reply-To: <9250F168-6DD4-41E3-8F4C-39D72A4DF6DC@mac.com> References: <20110517124855.GA25571@insomnia.benzedrine.cx> <9250F168-6DD4-41E3-8F4C-39D72A4DF6DC@mac.com> Date: Tue, 17 May 2011 20:36:18 +0200 Message-ID: From: Cole To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Net Subject: Re: Kern Mod and TCP retrasmit 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: Tue, 17 May 2011 18:36:19 -0000 Hey. Im doing this to learn, but I was only testing with compression going one way and no decompression just to make sure it was all working. However if I implement decompression, then everything should be working 100%, and I wont have to worry about breaking TCP or modifying sequence numbers or anything of the sort. But thanks for the suggestions. Regards /Cole On 17 May 2011 19:39, Chuck Swiger wrote: > On May 17, 2011, at 6:16 AM, Cole wrote: >> I was hoping to keep this clean, and use existing methods for hooking >> into the stream. Also the goal im working for is to be able to use >> this on a box doing routing to hopefully get some sort of compression >> working between 2 end points. So most of the data would not actual be >> generated from userland processes. > > Why don't you use a userland proxy or routing mechanism which supports compression, like OpenVPN or OpenSSH port forwarding? > > Regards, > -- > -Chuck > > From owner-freebsd-net@FreeBSD.ORG Wed May 18 08:00:09 2011 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 4AC211065673 for ; Wed, 18 May 2011 08:00:09 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1C74E8FC13 for ; Wed, 18 May 2011 08:00:09 +0000 (UTC) Received: from [10.17.45.145] (173-228-119-230.dsl.dynamic.sonic.net [173.228.119.230]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id p4I7JaQl088400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 18 May 2011 00:19:37 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=monkeybrains.net; s=monkey; t=1305703177; bh=MN7nORdKuJ6zclW45pTv34USm1ZAJfWdK4l9H2otDqM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=m0ODD6mLcMvDHN9WFv60NdHdR2F2UaQnFZ848AQP+rOzWPsd+i160vsmsEvAiqM4S 8vUQAHOL0c7QqdXahvzR5fy7EQcL9QgPUcEOHaPZHgX3YEIvu17PzkXeA382CTRC6V sbBCzYNBKY3NFQ3c+LglBdH7hvrHGkz6Aj0cwC/U= Message-ID: <4DD3730A.7090106@monkeybrains.net> Date: Wed, 18 May 2011 00:19:38 -0700 From: Rudy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11pre) Gecko/20100928 Shredder/3.1.5pre MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: request: have ifconfig purge routes that are being added via ifconfig 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, 18 May 2011 08:00:09 -0000 Summary: * ifconfig FAILs if route exists when adding an alias * ifconfig SILENTLY adds the IP even when route exists when creating virtual interaces * DESIRED functionality: purge routes to make way for IPs with ifconfig * Less desired: stop the SILENT adding of IPs as that makes for a bogus network Background: OSPF adds route, eg 1.2.3.0/24, into the kernel If I try to add 1.2.3.4/24 to my router, it fails as that route already exists. Workaround: route del 1.2.3.0/14 && ifconfig igb0 alias 1.2.3.4/24 However, if I can create a vlan with an IP that conflicts with an existing route. Add this to rc.conf: ifconfig_vlan2="1.2.3.4/24 vlan 2 vlandev igb0 then ifconfig vlan2 create Voila: you get a static route to 1.2.3.0/24 to your other router AND the local IP. Makes for a very messed up routing siltation. Workaround: route del 1.2.3.0/14 && ifconfig vlan2 create Proposal: Change the way ifconfig works. [1] Optimally, automatically do the 'route del' first [2] Otherwise, bring these two methods of adding IPs into sync and have the 'ifconfig vlan2 create' NOT add the IP when an existing route exists. Rudy From owner-freebsd-net@FreeBSD.ORG Wed May 18 08:28:28 2011 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 8E066106566B for ; Wed, 18 May 2011 08:28:28 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC0C8FC13 for ; Wed, 18 May 2011 08:28:27 +0000 (UTC) Received: (qmail 37660 invoked by uid 0); 18 May 2011 08:28:27 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 May 2011 08:28:27 -0000 Received: (qmail 37652 invoked by uid 90); 18 May 2011 08:28:26 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 May 2011 08:28:26 -0000 Date: Wed, 18 May 2011 04:28:26 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.nat.fasttrackmonkey.com To: Hiroki Sato In-Reply-To: <20110517.174313.868674729938461030.hrs@allbsd.org> Message-ID: References: <20110517.174313.868674729938461030.hrs@allbsd.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 alias masks/masks for routed aliases 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, 18 May 2011 08:28:28 -0000 On Tue, 17 May 2011, Hiroki Sato wrote: > Charles Sprickman wrote > in : > > sp> First, the easy one. For IPv6 aliases, what is the proper subnet? > > Normally it is a /64. See also Section 2.5.4 in RFC 4291. My understanding was that a /64 was a common subnet since it's the minimum size required for host autoconfiguration. What I'm really looking for is the FreeBSD-specific recommendation for configuring aliases - I understand that I'll probably have a /64 on the LAN, but when setting a netmask on a single IPv6 alias are the rules different than they are for IPv4? So if I've got a lan block that's a /64 and I configure an alias on a FreeBSD host, do I give the alias the lan subnet (/64) or a host subnet (/128)? For IPv4, I believe that it should always be the host subnet (/32). Which is proper on a FreeBSD host for IPv6? > sp> And the second one, which is also probably easy. We're going to move > sp> at some point from a bunch of subnets on the same wire to having our > sp> own router that gets our blocks routed to it. At that point I'd like > sp> to move to routing individual IPs (or small subnets) to each host > sp> behind the router. > sp> > sp> For example, say we have the following routed to our router: > sp> > sp> 10.1.0.0/27 > sp> 10.2.0.0/27 > sp> 10.3.0.0/27 > sp> > sp> All the hosts behind our router are in 10.1.0.0/27. I want to send > sp> some IPs from 10.2.0.0/27 and 10.3.0.0/27 to a host at 10.1.0.2, so I > sp> do the equivalent of "ip route 10.2.0.0 255.255.255.248 10.1.0.2" > sp> (cisco speak) on the router box. How should the aliases on 10.1.0.2 > sp> be defined? Should they all have /32 masks? Should the first get a > sp> /29 and the rest a /32? > sp> > sp> Is this even a valid config? In reality, we have way more subnets, > sp> totally non-contiguous, varying masks. With VRRP on the provider's > sp> side, we immediately lose 2 IPs from each subnet in our current setup, > sp> plus the network and broadcast IPs. I'm hoping that in a routed setup > sp> I can regain not only the VRRP IPs but the top and bottom of each > sp> subnet... Considering the scarcity of IPs these days, that would be a > sp> big help. > > Well, I could not understand what you are trying... Is 10.1.0.2 > located on 10.1.0.0/27 and acting as another nexthop router? It's on the 10.1.0.0/27 LAN, but it is not a gateway. It's simply a host that will have additional space routed to it for services running on it that will be binding to these other IPs (ie: 10.2.0.2-12 or some such). > If you want to split three subnets on a single wire into three subnets > on three wires, simply configuring three /27 addresses to each interface > on the router works. If you want to route a part of the traffic from > specific addresses to a specific host, you can add a specific route for > the address range. The current setup looks like this on the ISP side: interface vlanxxx ip address 10.1.0.0 255.255.255.224 ip address 10.2.0.0 255.255.255.240 secondary ip address 10.3.0.0 255.255.255.248 secondary ip address 10.4.0.0 255.255.255.224 secondary ip address 10.5.0.0 255.255.255.240 secondary ip address 10.6.0.0 255.255.255.240 secondary Each of our hosts has an IP in the 10.1.0.0/27 subnet, and uses 10.1.0.1 as the default gateway. Most hosts additionally have aliases in the other subnets, ie: ifconfig fxp0 alias 10.2.0.2 netmask 255.255.255.240 (first one gets the actual subnet) ifconfig fxp0 alias 10.2.0.3 netmask 255.255.255.255 (subsequent get a host mask) We are looking to add a pair of Free/OpenBSD boxes with CARP and have the ISP give us a /30 for the "WAN" side and then route all those subnets to our own "router". We would then route individual IPs or small subnets (if contiguous makes sense) to our hosts behind the router. Again, in Cisco speak: interface fastethernet 0/1 ip address 10.1.0.1 255.255.255.224 ! ip route 10.2.0.3 255.255.255.255 10.1.0.2 ip route 10.2.0.4 255.255.255.255 10.1.0.3 ip route 10.2.0.5 255.255.255.255 10.1.0.3 ip route 10.2.0.6 255.255.255.255 10.1.0.4 ip route 10.2.0.7 255.255.255.255 10.1.0.5 ip route 10.3.0.1 255.255.255.255 10.1.0.5 ip route 10.3.0.2 255.255.255.255 10.1.0.5 (and so on) On hosts 10.1.0.2-5, would they each get a /32 netmask on the associated alias? Thanks, Charles > -- Hiroki > From owner-freebsd-net@FreeBSD.ORG Wed May 18 12:31:50 2011 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 52940106566B for ; Wed, 18 May 2011 12:31:50 +0000 (UTC) (envelope-from jack.shang@huawei.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 301278FC1D for ; Wed, 18 May 2011 12:31:49 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1QMfun-0002MA-DZ for freebsd-net@freebsd.org; Wed, 18 May 2011 05:31:49 -0700 Date: Wed, 18 May 2011 05:31:49 -0700 (PDT) From: JACK To: freebsd-net@freebsd.org Message-ID: <1305721909414-4406356.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Is it a bug of RADIX ????? 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, 18 May 2011 12:31:50 -0000 After inserting the following IPv4 routers: 0x360AD0A2/30 0x360ADFEC/20 0x360AD082/30 I try to delete the above routes, when delete the second route(0x360ADFEC/20), the operation fail. struct radix_node * rn_delete (........) { ... /* * Delete our route from mask lists. */ if (netmask != NULL) { if ((x = rn_addmask(netmask, TRUE, head_off)) == NULL) return (NULL); netmask = x->rn_key; while (tt->rn_mask != netmask) if ((tt = tt->rn_dupedkey) == NULL) return (NULL); // rn_delete return here!!! } ... } but, if I delete as the following order, all routers was deleted successfully: 0x360AD0A2/30 0x360AD082/30 0x360ADFEC/20 so, is it a bug of RADIX? /jack -- View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406356.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Wed May 18 12:32:21 2011 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 5DA2B1065673 for ; Wed, 18 May 2011 12:32:21 +0000 (UTC) (envelope-from jack.shang@huawei.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4B88FC27 for ; Wed, 18 May 2011 12:32:21 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1QMfhX-0001E0-Tq for freebsd-net@freebsd.org; Wed, 18 May 2011 05:18:07 -0700 Date: Wed, 18 May 2011 05:18:07 -0700 (PDT) From: JACK To: freebsd-net@freebsd.org Message-ID: <1305721087918-4406316.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Is it a bug of RADIX ???? 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, 18 May 2011 12:32:21 -0000 After inserting the following IPv4 routers: 0x360AD0A2/30 0x360ADFEC/20 0x360AD082/30 I try to delete the above routes, when delete the second route(0x360ADFEC/20), the operation fail. struct radix_node * rn_delete (........) { ... /* * Delete our route from mask lists. */ if (netmask != NULL) { if ((x = rn_addmask(netmask, TRUE, head_off)) == NULL) return (NULL); netmask = x->rn_key; while (tt->rn_mask != netmask) if ((tt = tt->rn_dupedkey) == NULL) return (NULL); // rn_delete return here!!! } ... } but, if I delete as the following order, all routers was deleted successfully: 0x360AD0A2/30 0x360AD082/30 0x360ADFEC/20 so, is it a bug of RADIX? /jack -- View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406316p4406316.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Wed May 18 12:32:22 2011 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 4BCEF106567B for ; Wed, 18 May 2011 12:32:22 +0000 (UTC) (envelope-from jack.shang@huawei.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9028FC1C for ; Wed, 18 May 2011 12:32:22 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1QMfqS-0001to-2g for freebsd-net@freebsd.org; Wed, 18 May 2011 05:27:20 -0700 Date: Wed, 18 May 2011 05:27:20 -0700 (PDT) From: JACK To: freebsd-net@freebsd.org Message-ID: <1305721640076-4406338.post@n5.nabble.com> In-Reply-To: <1305721087918-4406316.post@n5.nabble.com> References: <1305721087918-4406316.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Is it a bug of RADIX ???? 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, 18 May 2011 12:32:22 -0000 Is anyone here? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406316p4406338.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Wed May 18 12:56:21 2011 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 60B82106564A for ; Wed, 18 May 2011 12:56:21 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [IPv6:2a02:978:2:1000::3]) by mx1.freebsd.org (Postfix) with ESMTP id DCD938FC14 for ; Wed, 18 May 2011 12:56:20 +0000 (UTC) Received: from bibi.ipfw.ru (birdie.ipv6.meganet.ru [IPv6:2a02:978::1008]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 5D97935CD77; Wed, 18 May 2011 16:55:18 +0400 (MSD) Message-ID: <4DD3C17E.9070903@ipfw.ru> Date: Wed, 18 May 2011 16:54:22 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110301 Thunderbird/3.1.7 MIME-Version: 1.0 To: JACK References: <1305721909414-4406356.post@n5.nabble.com> In-Reply-To: <1305721909414-4406356.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Is it a bug of RADIX ????? 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, 18 May 2011 12:56:21 -0000 On 18.05.2011 16:31, JACK wrote: > After inserting the following IPv4 routers: > > 0x360AD0A2/30 > 0x360ADFEC/20 > 0x360AD082/30 > > I try to delete the above routes, when delete the second > route(0x360ADFEC/20), the operation fail. Can you specify exact commands you are issuing to add/remove routes? (or "route monitor" output if you are doing this from some dynamic routing software) The following order works for me (8.2-STABLE): 16:44 [0] bibi# route add -net 54.10.208.162/30 10.11.0.1 add net 54.10.208.162: gateway 10.11.0.1 16:45 [0] bibi# route add -net 54.10.223.236/20 10.11.0.1 add net 54.10.223.236: gateway 10.11.0.1 16:46 [0] bibi# route add -net 54.10.208.130/30 10.11.0.1 add net 54.10.208.130: gateway 10.11.0.1 16:46 [0] bibi# netstat -rn -finet | grep 54 54.10.208.0/20 10.11.0.1 UGS 0 0 em0 54.10.208.128/30 10.11.0.1 UGS 0 0 em0 54.10.208.160/30 10.11.0.1 UGS 0 0 em0 16:46 [0] bibi# route delete 54.10.208.0/20 delete net 54.10.208.0 16:48 [0] bibi# route delete 54.10.208.128/30 delete net 54.10.208.128 16:49 [0] bibi# route delete 54.10.208.160/30 delete net 54.10.208.160 16:49 [0] bibi# netstat -rn -finet | grep 54 16:49 [0] bibi# > struct radix_node * rn_delete (........) > { > ... > /* > * Delete our route from mask lists. > */ > if (netmask != NULL) { > if ((x = rn_addmask(netmask, TRUE, head_off)) == NULL) > return (NULL); > netmask = x->rn_key; > while (tt->rn_mask != netmask) > if ((tt = tt->rn_dupedkey) == NULL) > return (NULL); // rn_delete return here!!! > } > ... > } > > but, if I delete as the following order, all routers was deleted > successfully: > > 0x360AD0A2/30 > 0x360AD082/30 > 0x360ADFEC/20 > > > so, is it a bug of RADIX? > > /jack > > > > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406356.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed May 18 15:36:42 2011 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 55DB11065674 for ; Wed, 18 May 2011 15:36:42 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [IPv6:2a02:978:2:1000::3]) by mx1.freebsd.org (Postfix) with ESMTP id CCFFD8FC1C for ; Wed, 18 May 2011 15:36:41 +0000 (UTC) Received: from bibi.ipfw.ru (birdie.ipv6.meganet.ru [IPv6:2a02:978::1008]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 4FCD635C510; Wed, 18 May 2011 19:35:39 +0400 (MSD) Message-ID: <4DD3E713.3070008@ipfw.ru> Date: Wed, 18 May 2011 19:34:43 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110301 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Jack Shang(hongzhang)" References: <1305721909414-4406356.post@n5.nabble.com> <4DD3C17E.9070903@ipfw.ru> <78D2B330B6A30B4CB554FD2EC08D7434F3668E@szxeml508-mbx.china.huawei.com> In-Reply-To: <78D2B330B6A30B4CB554FD2EC08D7434F3668E@szxeml508-mbx.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" Subject: Re: =?gb2312?b?tPC4tDogSXMgaXQgYSBidWcgb2YgUkFESVggPz8/Pz8=?= 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, 18 May 2011 15:36:42 -0000 On 18.05.2011 19:15, Jack Shang(hongzhang) wrote: > I do these by call the radix routine such as rn_addroute and rn_delete directly. Okay. Can you provide FreeBSD version and a piece of code triggering such a situation? IMHO radix assumes destination address to have host bits cleared, code in rtrequest1_fib does this via rt_maskedcopy(). Are you sure you need to pass 0x360AD0A2/30 0x360ADFEC/20 0x360AD082/30 instead of: 0x360AD0A0/30 0x360AD000/20 0x360AD080/30 ? > ________________________________________ > ·¢¼þÈË: Alexander V. Chernikov [melifaro@ipfw.ru] > ·¢ËÍʱ¼ä: 2011Äê5ÔÂ18ÈÕ 20:54 > µ½: Jack Shang(hongzhang) > Cc: freebsd-net@freebsd.org > Ö÷Ìâ: Re: Is it a bug of RADIX ????? > > On 18.05.2011 16:31, JACK wrote: >> After inserting the following IPv4 routers: >> >> 0x360AD0A2/30 >> 0x360ADFEC/20 >> 0x360AD082/30 >> >> I try to delete the above routes, when delete the second >> route(0x360ADFEC/20), the operation fail. > Can you specify exact commands you are issuing to add/remove routes? > (or "route monitor" output if you are doing this from some dynamic > routing software) > > The following order works for me (8.2-STABLE): > > 16:44 [0] bibi# route add -net 54.10.208.162/30 10.11.0.1 > add net 54.10.208.162: gateway 10.11.0.1 > 16:45 [0] bibi# route add -net 54.10.223.236/20 10.11.0.1 > add net 54.10.223.236: gateway 10.11.0.1 > 16:46 [0] bibi# route add -net 54.10.208.130/30 10.11.0.1 > add net 54.10.208.130: gateway 10.11.0.1 > > 16:46 [0] bibi# netstat -rn -finet | grep 54 > 54.10.208.0/20 10.11.0.1 UGS 0 0 em0 > 54.10.208.128/30 10.11.0.1 UGS 0 0 em0 > 54.10.208.160/30 10.11.0.1 UGS 0 0 em0 > 16:46 [0] bibi# route delete 54.10.208.0/20 > delete net 54.10.208.0 > 16:48 [0] bibi# route delete 54.10.208.128/30 > delete net 54.10.208.128 > 16:49 [0] bibi# route delete 54.10.208.160/30 > delete net 54.10.208.160 > 16:49 [0] bibi# netstat -rn -finet | grep 54 > 16:49 [0] bibi# > > >> struct radix_node * rn_delete (........) >> { >> ... >> /* >> * Delete our route from mask lists. >> */ >> if (netmask != NULL) { >> if ((x = rn_addmask(netmask, TRUE, head_off)) == NULL) >> return (NULL); >> netmask = x->rn_key; >> while (tt->rn_mask != netmask) >> if ((tt = tt->rn_dupedkey) == NULL) >> return (NULL); // rn_delete return here!!! >> } >> ... >> } >> >> but, if I delete as the following order, all routers was deleted >> successfully: >> >> 0x360AD0A2/30 >> 0x360AD082/30 >> 0x360ADFEC/20 >> >> >> so, is it a bug of RADIX? >> >> /jack >> >> >> >> >> -- >> View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406356.html >> Sent from the freebsd-net mailing list archive at Nabble.com. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed May 18 16:27:56 2011 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 B6E0B106566C for ; Wed, 18 May 2011 16:27:56 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 014C48FC18 for ; Wed, 18 May 2011 16:27:55 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 18 May 2011 08:59:24 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id p4IFwsZu036356 for ; Wed, 18 May 2011 08:58:54 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id p4IFws95036355 for freebsd-net@freebsd.org; Wed, 18 May 2011 08:58:54 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201105181558.p4IFws95036355@ambrisko.com> To: freebsd-net@freebsd.org Date: Wed, 18 May 2011 08:58:54 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ELM1305734334-34657-0_" Content-Transfer-Encoding: 7bit Subject: IPv6 ifconfig down/up issue versus IPv4 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, 18 May 2011 16:27:56 -0000 --ELM1305734334-34657-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Recently, I ran into a problem in which IPv4 works fine but IPv6 doesn't. I use a trick to "fail-over" NICs via ifconfig down the bad link and then ifconfig up the good link. Both NICs have the same IP. The 2nd IP is assigned when the 1st NIC is down. This works fine with IPv4 since on down it removes the NIC's local route that was set when the IP was assigned ie. the /x network. In the IPv4 stack it calls if_up and if_down to purge the route and if_up to recreate the NIC's route. Only when you delete the IP does the route go away. This doesn't happen with IPv6, instead the route is created when the NIC is first assigned an IP and persists when the NIC is down and even when another is up. You can see this with route get or netstat -r pointing to a NIC that doesn't exist. I have a prototype/first hack to fix it by modeling the IPv4 paradigm and deal with the routes/multicast groups. I'd like someone to take a look and tell me what I messed up and how it should be done better. This appears to be a fairly simple bug in FreeBSD that was just never looked at before since it is a bit of a corner case. A lot of this problem can be seen tested via netstat -r ndp -a ifmcstat Thanks, Doug A. diff -upr ../src/sys/net/if.c sys/net/if.c --- ../src/sys/net/if.c 2009-07-27 12:48:10.000000000 -0700 +++ sys/net/if.c 2011-05-17 12:51:38.000000000 -0700 @@ -1449,6 +1449,9 @@ if_unroute(struct ifnet *ifp, int flag, carp_carpdev_state(ifp->if_carp); #endif rt_ifmsg(ifp); +#ifdef INET6 + in6_if_down(ifp); +#endif } /* diff -upr ../src/sys/netinet6/in6.c sys/netinet6/in6.c --- ../src/sys/netinet6/in6.c 2009-07-27 12:48:10.000000000 -0700 +++ sys/netinet6/in6.c 2011-05-17 12:59:27.000000000 -0700 @@ -132,6 +132,9 @@ static void in6_unlink_ifa(struct in6_if struct in6_multihead in6_multihead; /* XXX BSS initialization */ int (*faithprefix_p)(struct in6_addr *); +static int in6_join_multicast_groups(struct ifnet *ifp, + struct in6_aliasreq *ifra, struct in6_ifaddr *ia, int flags, + int hostIsNew); /* * Subroutine for in6_ifaddloop() and in6_ifremloop(). @@ -788,6 +791,7 @@ in6_control(struct socket *so, u_long cm return (0); } + /* * Update parameters of an IPv6 interface address. * If necessary, a new entry is created and linked into address chains. @@ -802,10 +806,6 @@ in6_update_ifa(struct ifnet *ifp, struct struct in6_ifaddr *oia; struct sockaddr_in6 dst6; struct in6_addrlifetime *lt; - struct in6_multi_mship *imm; - struct in6_multi *in6m_sol; - struct rtentry *rt; - int delay; char ip6buf[INET6_ADDRSTRLEN]; /* Validate parameters */ @@ -1049,6 +1049,41 @@ in6_update_ifa(struct ifnet *ifp, struct * not just go to unlink. */ + if ((error = in6_join_multicast_groups(ifp, ifra, ia, flags, hostIsNew))) { + goto cleanup; + } + + + return (error); + + unlink: + /* + * XXX: if a change of an existing address failed, keep the entry + * anyway. + */ + if (hostIsNew) + in6_unlink_ifa(ia, ifp); + return (error); + + cleanup: + in6_purgeaddr(&ia->ia_ifa); + return error; +} + +static int +in6_join_multicast_groups(struct ifnet *ifp, struct in6_aliasreq *ifra, + struct in6_ifaddr *ia, int flags, int hostIsNew) +{ + int error = 0; + struct in6_multi_mship *imm; + struct rtentry *rt; + struct in6_multi *in6m_sol; + int delay; + char ip6buf[INET6_ADDRSTRLEN]; + +/* Up the interface */ +ifp->if_flags |= IFF_UP; + /* Join necessary multicast groups */ in6m_sol = NULL; if ((ifp->if_flags & IFF_MULTICAST) != 0) { @@ -1263,7 +1295,7 @@ in6_update_ifa(struct ifnet *ifp, struct ip6_sprintf(ip6buf, &mltaddr.sin6_addr), if_name(ifp), error)); goto cleanup; - } + } LIST_INSERT_HEAD(&ia->ia6_memberships, imm, i6mm_chain); #undef MLTMASK_LEN } @@ -1306,20 +1338,8 @@ in6_update_ifa(struct ifnet *ifp, struct nd6_dad_start((struct ifaddr *)ia, delay); } + cleanup: return (error); - - unlink: - /* - * XXX: if a change of an existing address failed, keep the entry - * anyway. - */ - if (hostIsNew) - in6_unlink_ifa(ia, ifp); - return (error); - - cleanup: - in6_purgeaddr(&ia->ia_ifa); - return error; } void @@ -1727,7 +1747,7 @@ in6_ifinit(struct ifnet *ifp, struct in6 /* we could do in(6)_socktrim here, but just omit it at this moment. */ - if (newhost && nd6_need_cache(ifp) != 0) { + if (newhost) { /* * set the rtrequest function to create llinfo. It also * adjust outgoing interface of the route for the local @@ -2120,6 +2140,93 @@ in6_ifawithifp(struct ifnet *ifp, struct return NULL; } +extern struct inpcbinfo udbinfo; +extern struct inpcbinfo ripcbinfo; +/*static*/ void in6_purgemaddrs(struct ifnet *); + +void +in6_if_down(struct ifnet *ifp) +{ + struct in6_ifaddr *ia /*, *oia*/; + struct ifaddr *ifa, *next; + struct rtentry *rt; + short rtflags; + struct sockaddr_in6 sin6; + struct in6_multi_mship *imm; + + /* remove neighbor management table */ + nd6_purge(ifp); + + /* undo everything done by in6_ifattach(), just in case */ + for (ifa = ifp->if_addrlist.tqh_first; ifa; ifa = next) { + next = ifa->ifa_list.tqe_next; + + if (ifa->ifa_addr->sa_family != AF_INET6 + /* DJA || !IN6_IS_ADDR_LINKLOCAL(&satosin6(&ifa->ifa_addr)->sin6_addr) */) { + continue; + } + + ia = (struct in6_ifaddr *)ifa; + + /* + * leave from multicast groups we have joined for the interface + */ + while ((imm = ia->ia6_memberships.lh_first) != NULL) { + LIST_REMOVE(imm, i6mm_chain); + in6_leavegroup(imm); + } + +#define rtinitflags(x) \ + ((((x)->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) != 0) \ + ? RTF_HOST : RTF_UP) + /* remove from the routing table */ + if ((ia->ia_flags & IFA_ROUTE) && + (rt = rtalloc1((struct sockaddr *)&ia->ia_addr, 0, 0UL))) { + rtflags = rt->rt_flags; + rtfree(rt); + if(ifa->ifa_addr->sa_family == AF_INET6) + rtinit(ifa, (int)RTM_DELETE, + rtinitflags(ifp)); + } + + } + + in6_pcbpurgeif0(&udbinfo, ifp); + in6_pcbpurgeif0(&ripcbinfo, ifp); + /* leave from all multicast groups joined */ + in6_purgemaddrs(ifp); + + /* + * remove neighbor management table. we call it twice just to make + * sure we nuke everything. maybe we need just one call. + * XXX: since the first call did not release addresses, some prefixes + * might remain. We should call nd6_purge() again to release the + * prefixes after removing all addresses above. + * (Or can we just delay calling nd6_purge until at this point?) + */ + nd6_purge(ifp); + + /* remove route to link-local allnodes multicast (ff02::1) */ + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = in6addr_linklocal_allnodes; + if (in6_setscope(&sin6.sin6_addr, ifp, NULL)) + /* XXX: should not fail */ + return; + /* XXX grab lock first to avoid LOR */ + if (rt_tables[0][AF_INET6] != NULL) { + RADIX_NODE_HEAD_LOCK(rt_tables[0][AF_INET6]); + rt = rtalloc1((struct sockaddr *)&sin6, 0, RTF_RNH_LOCKED); + if (rt) { + if (rt->rt_ifp == ifp) + rtexpunge(rt); + RTFREE_LOCKED(rt); + } + RADIX_NODE_HEAD_UNLOCK(rt_tables[0][AF_INET6]); + } +} + /* * perform DAD when interface becomes IFF_UP. */ @@ -2128,20 +2235,92 @@ in6_if_up(struct ifnet *ifp) { struct ifaddr *ifa; struct in6_ifaddr *ia; + struct in6_aliasreq ifra_store, *ifra; + /* DJA */ TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) { if (ifa->ifa_addr->sa_family != AF_INET6) continue; ia = (struct in6_ifaddr *)ifa; - if (ia->ia6_flags & IN6_IFF_TENTATIVE) { + + + in6_ifinit(ifp, ia, &ia->ia_addr, 1); + + ifra = &ifra_store; + bzero(&ifra_store, sizeof(ifra_store)); + bcopy(if_name(ifp), ifra_store.ifra_name, + sizeof(ifra_store.ifra_name)); + bcopy(&ia->ia_addr, &ifra_store.ifra_addr, + sizeof(ifra_store.ifra_addr)); + bcopy(&ia->ia_dstaddr, &ifra_store.ifra_dstaddr, + sizeof(ifra_store.ifra_dstaddr)); + bcopy(&ia->ia_prefixmask, &ifra_store.ifra_prefixmask, + sizeof(ifra_store.ifra_prefixmask)); + ifra_store.ifra_flags = ia->ia6_flags; + bcopy(&ia->ia6_lifetime, &ifra_store.ifra_lifetime, + sizeof(ifra->ifra_lifetime)); + + /* Join necessary multicast groups */ + if (in6_join_multicast_groups(ifp, ifra, ia, 0, 0)) { + in6_purgeaddr(&ia->ia_ifa); + continue; + } + + int i, error = 0; + struct nd_prefixctl pr0; + struct nd_prefix *pr; + /* + * then, make the prefix on-link on the interface. + * XXX: we'd rather create the prefix before the address, but + * we need at least one address to install the corresponding + * interface route, so we configure the address first. + */ + + /* + * convert mask to prefix length (prefixmask has already + * been validated in in6_update_ifa(). + */ + bzero(&pr0, sizeof(pr0)); + pr0.ndpr_ifp = ifp; + pr0.ndpr_plen = in6_mask2len(&ifra->ifra_prefixmask.sin6_addr, + NULL); + + if (pr0.ndpr_plen == 128) { + continue; /* we don't need to install a host route. */ + } + pr0.ndpr_prefix = ifra->ifra_addr; + /* apply the mask for safety. */ + for (i = 0; i < 4; i++) { + pr0.ndpr_prefix.sin6_addr.s6_addr32[i] &= + ifra->ifra_prefixmask.sin6_addr.s6_addr32[i]; + } + + /* + * XXX: since we don't have an API to set prefix (not address) + * lifetimes, we just use the same lifetimes as addresses. + * The (temporarily) installed lifetimes can be overridden by + * later advertised RAs (when accept_rtadv is non 0), which is + * an intended behavior. + */ + pr0.ndpr_raf_onlink = 1; /* should be configurable? */ + pr0.ndpr_raf_auto = + ((ifra->ifra_flags & IN6_IFF_AUTOCONF) != 0); + pr0.ndpr_vltime = ifra->ifra_lifetime.ia6t_vltime; + pr0.ndpr_pltime = ifra->ifra_lifetime.ia6t_pltime; + + /* add the prefix if not yet. */ + if ((pr = nd6_prefix_lookup(&pr0)) == NULL) { /* - * The TENTATIVE flag was likely set by hand - * beforehand, implicitly indicating the need for DAD. - * We may be able to skip the random delay in this - * case, but we impose delays just in case. + * nd6_prelist_add will install the corresponding + * interface route. */ - nd6_dad_start(ifa, - arc4random() % (MAX_RTR_SOLICITATION_DELAY * hz)); + if ((error = nd6_prelist_add(&pr0, NULL, &pr)) != 0) + return; + if (pr == NULL) { + log(LOG_ERR, "nd6_prelist_add succeeded but " + "no prefix\n"); + return; /* XXX panic here? */ + } } } Only in sys/netinet6: in6.c.orig Only in sys/netinet6: in6.c~ diff -upr ../src/sys/netinet6/in6.h sys/netinet6/in6.h --- ../src/sys/netinet6/in6.h 2009-04-14 20:14:26.000000000 -0700 +++ sys/netinet6/in6.h 2011-04-19 09:41:23.000000000 -0700 @@ -620,6 +620,7 @@ int in6_localaddr __P((struct in6_addr * int in6_addrscope __P((struct in6_addr *)); struct in6_ifaddr *in6_ifawithifp __P((struct ifnet *, struct in6_addr *)); extern void in6_if_up __P((struct ifnet *)); +extern void in6_if_down __P((struct ifnet *)); struct sockaddr; extern u_char ip6_protox[]; diff -upr ../src/sys/netinet6/in6_ifattach.c sys/netinet6/in6_ifattach.c --- ../src/sys/netinet6/in6_ifattach.c 2009-04-14 20:14:26.000000000 -0700 +++ sys/netinet6/in6_ifattach.c 2011-04-19 10:29:31.000000000 -0700 @@ -78,7 +78,7 @@ static int generate_tmp_ifid(u_int8_t *, static int get_ifid(struct ifnet *, struct ifnet *, struct in6_addr *); static int in6_ifattach_linklocal(struct ifnet *, struct ifnet *); static int in6_ifattach_loopback(struct ifnet *); -static void in6_purgemaddrs(struct ifnet *); +/*static*/ void in6_purgemaddrs(struct ifnet *); #define EUI64_GBIT 0x01 #define EUI64_UBIT 0x02 @@ -886,7 +886,7 @@ in6_tmpaddrtimer(void *ignored_arg) splx(s); } -static void +/*static*/ void in6_purgemaddrs(struct ifnet *ifp) { struct in6_multi *in6m; --ELM1305734334-34657-0_ Content-Transfer-Encoding: 7bit Content-Type: text/x-patch Content-Disposition: attachment; filename="ipv6_down_up_routing.patch" Content-Description: diff -upr ../src/sys/net/if.c sys/net/if.c --- ../src/sys/net/if.c 2009-07-27 12:48:10.000000000 -0700 +++ sys/net/if.c 2011-05-17 12:51:38.000000000 -0700 @@ -1449,6 +1449,9 @@ if_unroute(struct ifnet *ifp, int flag, carp_carpdev_state(ifp->if_carp); #endif rt_ifmsg(ifp); +#ifdef INET6 + in6_if_down(ifp); +#endif } /* diff -upr ../src/sys/netinet6/in6.c sys/netinet6/in6.c --- ../src/sys/netinet6/in6.c 2009-07-27 12:48:10.000000000 -0700 +++ sys/netinet6/in6.c 2011-05-17 12:59:27.000000000 -0700 @@ -132,6 +132,9 @@ static void in6_unlink_ifa(struct in6_if struct in6_multihead in6_multihead; /* XXX BSS initialization */ int (*faithprefix_p)(struct in6_addr *); +static int in6_join_multicast_groups(struct ifnet *ifp, + struct in6_aliasreq *ifra, struct in6_ifaddr *ia, int flags, + int hostIsNew); /* * Subroutine for in6_ifaddloop() and in6_ifremloop(). @@ -788,6 +791,7 @@ in6_control(struct socket *so, u_long cm return (0); } + /* * Update parameters of an IPv6 interface address. * If necessary, a new entry is created and linked into address chains. @@ -802,10 +806,6 @@ in6_update_ifa(struct ifnet *ifp, struct struct in6_ifaddr *oia; struct sockaddr_in6 dst6; struct in6_addrlifetime *lt; - struct in6_multi_mship *imm; - struct in6_multi *in6m_sol; - struct rtentry *rt; - int delay; char ip6buf[INET6_ADDRSTRLEN]; /* Validate parameters */ @@ -1049,6 +1049,41 @@ in6_update_ifa(struct ifnet *ifp, struct * not just go to unlink. */ + if ((error = in6_join_multicast_groups(ifp, ifra, ia, flags, hostIsNew))) { + goto cleanup; + } + + + return (error); + + unlink: + /* + * XXX: if a change of an existing address failed, keep the entry + * anyway. + */ + if (hostIsNew) + in6_unlink_ifa(ia, ifp); + return (error); + + cleanup: + in6_purgeaddr(&ia->ia_ifa); + return error; +} + +static int +in6_join_multicast_groups(struct ifnet *ifp, struct in6_aliasreq *ifra, + struct in6_ifaddr *ia, int flags, int hostIsNew) +{ + int error = 0; + struct in6_multi_mship *imm; + struct rtentry *rt; + struct in6_multi *in6m_sol; + int delay; + char ip6buf[INET6_ADDRSTRLEN]; + +/* Up the interface */ +ifp->if_flags |= IFF_UP; + /* Join necessary multicast groups */ in6m_sol = NULL; if ((ifp->if_flags & IFF_MULTICAST) != 0) { @@ -1263,7 +1295,7 @@ in6_update_ifa(struct ifnet *ifp, struct ip6_sprintf(ip6buf, &mltaddr.sin6_addr), if_name(ifp), error)); goto cleanup; - } + } LIST_INSERT_HEAD(&ia->ia6_memberships, imm, i6mm_chain); #undef MLTMASK_LEN } @@ -1306,20 +1338,8 @@ in6_update_ifa(struct ifnet *ifp, struct nd6_dad_start((struct ifaddr *)ia, delay); } + cleanup: return (error); - - unlink: - /* - * XXX: if a change of an existing address failed, keep the entry - * anyway. - */ - if (hostIsNew) - in6_unlink_ifa(ia, ifp); - return (error); - - cleanup: - in6_purgeaddr(&ia->ia_ifa); - return error; } void @@ -1727,7 +1747,7 @@ in6_ifinit(struct ifnet *ifp, struct in6 /* we could do in(6)_socktrim here, but just omit it at this moment. */ - if (newhost && nd6_need_cache(ifp) != 0) { + if (newhost) { /* * set the rtrequest function to create llinfo. It also * adjust outgoing interface of the route for the local @@ -2120,6 +2140,93 @@ in6_ifawithifp(struct ifnet *ifp, struct return NULL; } +extern struct inpcbinfo udbinfo; +extern struct inpcbinfo ripcbinfo; +/*static*/ void in6_purgemaddrs(struct ifnet *); + +void +in6_if_down(struct ifnet *ifp) +{ + struct in6_ifaddr *ia /*, *oia*/; + struct ifaddr *ifa, *next; + struct rtentry *rt; + short rtflags; + struct sockaddr_in6 sin6; + struct in6_multi_mship *imm; + + /* remove neighbor management table */ + nd6_purge(ifp); + + /* undo everything done by in6_ifattach(), just in case */ + for (ifa = ifp->if_addrlist.tqh_first; ifa; ifa = next) { + next = ifa->ifa_list.tqe_next; + + if (ifa->ifa_addr->sa_family != AF_INET6 + /* DJA || !IN6_IS_ADDR_LINKLOCAL(&satosin6(&ifa->ifa_addr)->sin6_addr) */) { + continue; + } + + ia = (struct in6_ifaddr *)ifa; + + /* + * leave from multicast groups we have joined for the interface + */ + while ((imm = ia->ia6_memberships.lh_first) != NULL) { + LIST_REMOVE(imm, i6mm_chain); + in6_leavegroup(imm); + } + +#define rtinitflags(x) \ + ((((x)->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) != 0) \ + ? RTF_HOST : RTF_UP) + /* remove from the routing table */ + if ((ia->ia_flags & IFA_ROUTE) && + (rt = rtalloc1((struct sockaddr *)&ia->ia_addr, 0, 0UL))) { + rtflags = rt->rt_flags; + rtfree(rt); + if(ifa->ifa_addr->sa_family == AF_INET6) + rtinit(ifa, (int)RTM_DELETE, + rtinitflags(ifp)); + } + + } + + in6_pcbpurgeif0(&udbinfo, ifp); + in6_pcbpurgeif0(&ripcbinfo, ifp); + /* leave from all multicast groups joined */ + in6_purgemaddrs(ifp); + + /* + * remove neighbor management table. we call it twice just to make + * sure we nuke everything. maybe we need just one call. + * XXX: since the first call did not release addresses, some prefixes + * might remain. We should call nd6_purge() again to release the + * prefixes after removing all addresses above. + * (Or can we just delay calling nd6_purge until at this point?) + */ + nd6_purge(ifp); + + /* remove route to link-local allnodes multicast (ff02::1) */ + bzero(&sin6, sizeof(sin6)); + sin6.sin6_len = sizeof(struct sockaddr_in6); + sin6.sin6_family = AF_INET6; + sin6.sin6_addr = in6addr_linklocal_allnodes; + if (in6_setscope(&sin6.sin6_addr, ifp, NULL)) + /* XXX: should not fail */ + return; + /* XXX grab lock first to avoid LOR */ + if (rt_tables[0][AF_INET6] != NULL) { + RADIX_NODE_HEAD_LOCK(rt_tables[0][AF_INET6]); + rt = rtalloc1((struct sockaddr *)&sin6, 0, RTF_RNH_LOCKED); + if (rt) { + if (rt->rt_ifp == ifp) + rtexpunge(rt); + RTFREE_LOCKED(rt); + } + RADIX_NODE_HEAD_UNLOCK(rt_tables[0][AF_INET6]); + } +} + /* * perform DAD when interface becomes IFF_UP. */ @@ -2128,20 +2235,92 @@ in6_if_up(struct ifnet *ifp) { struct ifaddr *ifa; struct in6_ifaddr *ia; + struct in6_aliasreq ifra_store, *ifra; + /* DJA */ TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) { if (ifa->ifa_addr->sa_family != AF_INET6) continue; ia = (struct in6_ifaddr *)ifa; - if (ia->ia6_flags & IN6_IFF_TENTATIVE) { + + + in6_ifinit(ifp, ia, &ia->ia_addr, 1); + + ifra = &ifra_store; + bzero(&ifra_store, sizeof(ifra_store)); + bcopy(if_name(ifp), ifra_store.ifra_name, + sizeof(ifra_store.ifra_name)); + bcopy(&ia->ia_addr, &ifra_store.ifra_addr, + sizeof(ifra_store.ifra_addr)); + bcopy(&ia->ia_dstaddr, &ifra_store.ifra_dstaddr, + sizeof(ifra_store.ifra_dstaddr)); + bcopy(&ia->ia_prefixmask, &ifra_store.ifra_prefixmask, + sizeof(ifra_store.ifra_prefixmask)); + ifra_store.ifra_flags = ia->ia6_flags; + bcopy(&ia->ia6_lifetime, &ifra_store.ifra_lifetime, + sizeof(ifra->ifra_lifetime)); + + /* Join necessary multicast groups */ + if (in6_join_multicast_groups(ifp, ifra, ia, 0, 0)) { + in6_purgeaddr(&ia->ia_ifa); + continue; + } + + int i, error = 0; + struct nd_prefixctl pr0; + struct nd_prefix *pr; + /* + * then, make the prefix on-link on the interface. + * XXX: we'd rather create the prefix before the address, but + * we need at least one address to install the corresponding + * interface route, so we configure the address first. + */ + + /* + * convert mask to prefix length (prefixmask has already + * been validated in in6_update_ifa(). + */ + bzero(&pr0, sizeof(pr0)); + pr0.ndpr_ifp = ifp; + pr0.ndpr_plen = in6_mask2len(&ifra->ifra_prefixmask.sin6_addr, + NULL); + + if (pr0.ndpr_plen == 128) { + continue; /* we don't need to install a host route. */ + } + pr0.ndpr_prefix = ifra->ifra_addr; + /* apply the mask for safety. */ + for (i = 0; i < 4; i++) { + pr0.ndpr_prefix.sin6_addr.s6_addr32[i] &= + ifra->ifra_prefixmask.sin6_addr.s6_addr32[i]; + } + + /* + * XXX: since we don't have an API to set prefix (not address) + * lifetimes, we just use the same lifetimes as addresses. + * The (temporarily) installed lifetimes can be overridden by + * later advertised RAs (when accept_rtadv is non 0), which is + * an intended behavior. + */ + pr0.ndpr_raf_onlink = 1; /* should be configurable? */ + pr0.ndpr_raf_auto = + ((ifra->ifra_flags & IN6_IFF_AUTOCONF) != 0); + pr0.ndpr_vltime = ifra->ifra_lifetime.ia6t_vltime; + pr0.ndpr_pltime = ifra->ifra_lifetime.ia6t_pltime; + + /* add the prefix if not yet. */ + if ((pr = nd6_prefix_lookup(&pr0)) == NULL) { /* - * The TENTATIVE flag was likely set by hand - * beforehand, implicitly indicating the need for DAD. - * We may be able to skip the random delay in this - * case, but we impose delays just in case. + * nd6_prelist_add will install the corresponding + * interface route. */ - nd6_dad_start(ifa, - arc4random() % (MAX_RTR_SOLICITATION_DELAY * hz)); + if ((error = nd6_prelist_add(&pr0, NULL, &pr)) != 0) + return; + if (pr == NULL) { + log(LOG_ERR, "nd6_prelist_add succeeded but " + "no prefix\n"); + return; /* XXX panic here? */ + } } } Only in sys/netinet6: in6.c.orig Only in sys/netinet6: in6.c~ diff -upr ../src/sys/netinet6/in6.h sys/netinet6/in6.h --- ../src/sys/netinet6/in6.h 2009-04-14 20:14:26.000000000 -0700 +++ sys/netinet6/in6.h 2011-04-19 09:41:23.000000000 -0700 @@ -620,6 +620,7 @@ int in6_localaddr __P((struct in6_addr * int in6_addrscope __P((struct in6_addr *)); struct in6_ifaddr *in6_ifawithifp __P((struct ifnet *, struct in6_addr *)); extern void in6_if_up __P((struct ifnet *)); +extern void in6_if_down __P((struct ifnet *)); struct sockaddr; extern u_char ip6_protox[]; diff -upr ../src/sys/netinet6/in6_ifattach.c sys/netinet6/in6_ifattach.c --- ../src/sys/netinet6/in6_ifattach.c 2009-04-14 20:14:26.000000000 -0700 +++ sys/netinet6/in6_ifattach.c 2011-04-19 10:29:31.000000000 -0700 @@ -78,7 +78,7 @@ static int generate_tmp_ifid(u_int8_t *, static int get_ifid(struct ifnet *, struct ifnet *, struct in6_addr *); static int in6_ifattach_linklocal(struct ifnet *, struct ifnet *); static int in6_ifattach_loopback(struct ifnet *); -static void in6_purgemaddrs(struct ifnet *); +/*static*/ void in6_purgemaddrs(struct ifnet *); #define EUI64_GBIT 0x01 #define EUI64_UBIT 0x02 @@ -886,7 +886,7 @@ in6_tmpaddrtimer(void *ignored_arg) splx(s); } -static void +/*static*/ void in6_purgemaddrs(struct ifnet *ifp) { struct in6_multi *in6m; --ELM1305734334-34657-0_-- From owner-freebsd-net@FreeBSD.ORG Thu May 19 02:46:11 2011 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 E1B0E1065680 for ; Thu, 19 May 2011 02:46:11 +0000 (UTC) (envelope-from jack.shang@huawei.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 907BD8FC18 for ; Thu, 19 May 2011 02:46:11 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1QMtFa-0003jt-QI for freebsd-net@freebsd.org; Wed, 18 May 2011 19:46:10 -0700 Date: Wed, 18 May 2011 19:46:10 -0700 (PDT) From: JACK To: freebsd-net@freebsd.org Message-ID: <78D2B330B6A30B4CB554FD2EC08D7434F36F04@szxeml508-mbx.china.huawei.com> In-Reply-To: <4DD3E713.3070008@ipfw.ru> References: <1305721909414-4406356.post@n5.nabble.com> <4DD3C17E.9070903@ipfw.ru> <4DD3E713.3070008@ipfw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RE: RE: Is it a bug of RADIX ????? 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, 19 May 2011 02:46:12 -0000 THANKS FOR YOUR REPLY! :) the version I used can be found here: http://fxr.watson.org/fxr/source/net/radix.c?v=3DDFBSD I'm not use the rt_maskedcopy, I 'build' the key by my rdx_build_rtentry. Maybe there is some bug in my rdx_build_rtentry? but I can't find it! 
struct rtsockaddr {
    u_char   sa_len;         /* total length */
    // u_char   sa_family;      /* address family */
    u_char   sa_data[18 + 1];    /* actually longer; address value */
};

struct rtentry {
    struct  radix_node rt_nodes[2]; /* tree glue, and other values */
    struct  rtsockaddr key;
    struct  rtsockaddr msk;
    int     rt_index;
};

void rdx_build_rtentry (
    struct rtentry             *rt,
    unsigned int                uiVpnId,
    unsigned int               *puiKey,
    int                         iKeyLen)
{
    int                         k;
    int                         dwLen;

    dwLen =3D (iKeyLen / 32) + !!(iKeyLen & 31);
    rt->key.sa_len =3D 1 + 2 + (iKeyLen / 8) + !!(iKeyLen & 7);
    rt->msk.sa_len =3D rt->key.sa_len;

    rt->key.sa_data[0] =3D (uiVpnId >> 8) & 0xFF;
    rt->key.sa_data[1] =3D uiVpnId & 0xFF;
    rt->msk.sa_data[0] =3D 0xFF;
    rt->msk.sa_data[1] =3D 0xFF;

    for (k =3D 0; k < dwLen; k++)
    {
        rt->key.sa_data[k * 4 + 2] =3D (puiKey[k] >> 24) & 0xFF;
        rt->key.sa_data[k * 4 + 3] =3D (puiKey[k] >> 16) & 0xFF;
        rt->key.sa_data[k * 4 + 4] =3D (puiKey[k] >> 8) & 0xFF;
        rt->key.sa_data[k * 4 + 5] =3D puiKey[k] & 0xFF;
        rt->msk.sa_data[k * 4 + 2] =3D 0xFF;
        rt->msk.sa_data[k * 4 + 3] =3D 0xFF;
        rt->msk.sa_data[k * 4 + 4] =3D 0xFF;
        rt->msk.sa_data[k * 4 + 5] =3D 0xFF;
    }

    for (k =3D iKeyLen / 8 + 2 + !!(iKeyLen & 7);=20
         // k < rt->key.sa_len;=20
         k < sizeof(rt->key.sa_data);
         k++)
    {
        rt->key.sa_data[k] =3D 0;
        rt->msk.sa_data[k] =3D 0;
    }

    if (k =3D (iKeyLen & 0x7))
    {
        rt->key.sa_data[iKeyLen / 8 + 2] &=3D ((1 << k) - 1) << (8 - k);
        rt->msk.sa_data[iKeyLen / 8 + 2] &=3D ((1 << k) - 1) << (8 - k);
    }

    if (1 && 0x36 =3D=3D rt->key.sa_data[2]
          && 0x0a =3D=3D rt->key.sa_data[3])
    {
        int i =3D 0;
        printf ("\r\n%04X/%08X/%2d -> ", uiVpnId, puiKey[0], iKeyLen);
        printf ("%02X ", rt->key.sa_len);
        for (i =3D 0; i < rt->key.sa_len - 0; i++)
        {
            printf ("%02X ", (unsigned char)rt->key.sa_data[i]);
        }
        printf ("/ ");
        printf ("%02X ", rt->key.sa_len);
        for (i =3D 0; i < rt->msk.sa_len - 0; i++)
        {
            printf ("%02X ", (unsigned char)rt->msk.sa_data[i]);
        }
    }
}

int rdx_insert_key (
    struct radix_node_head     *rdx_hdr,
    unsigned int                uiVpnId,
    unsigned int               *puiKey,
    int                         iKeyLen,
    unsigned int                index)
{
    struct rtentry             *rt;

    R_Malloc(rt, struct rtentry *, sizeof(*rt));
    bzero(rt, sizeof(*rt));

    rdx_build_rtentry (rt, uiVpnId, puiKey, iKeyLen);
    rt->rt_index =3D index;

    if (NULL =3D=3D rdx_hdr->rnh_addaddr((char*)&rt->key, (char*)&rt->msk, =
rdx_hdr, rt->rt_nodes))
    {
        return RDX_ALREADY_EXIST;
    }

    return RDX_OK;
}

int rdx_delete_key (
    struct radix_node_head     *rdx_hdr,
    unsigned int                uiVpnId,
    unsigned int               *puiKey,
    int                         iKeyLen)
{
    struct rtentry             rt =3D {0};
    struct rtentry            *rt_hit;

    rdx_build_rtentry (&rt, uiVpnId, puiKey, iKeyLen);

    rt_hit =3D (struct rtentry *) rdx_hdr->rnh_deladdr((char*)&rt.key, (cha=
r*)&rt.msk, rdx_hdr);
    if (NULL =3D=3D rt_hit)
    {
        return RDX_NOT_EXIST;
    }

    Free (rt_hit);
    return RDX_OK;
}

rdx_hdr =3D NULL;
rn_inithead((void **)&rdx_hdr, 8); // I just want to skip the first byte of=
 key
and the output of inserting and deleting was as below: 
Inserting ...
0000/360AD0A2/30 -> 07 00 00 36 0A D0 A0 00 / 07 FF FF FF FF FF FC 00
0000/360ADFEC/20 -> 06 00 00 36 0A D0 00 / 06 FF FF FF FF F0 00
0000/360AD082/30 -> 07 00 00 36 0A D0 80 00 / 07 FF FF FF FF FF FC 00
Dumping ...
07 00 00 36 0A D0 80 / 07 FF FF FF FF FF FC
07 00 00 36 0A D0 A0 / 07 FF FF FF FF FF FC
06 00 00 36 0A D0 / 06 FF FF FF FF F0
Deleting ...
0000/360AD0A2/30 -> 07 00 00 36 0A D0 A0 00 / 07 FF FF FF FF FF FC 00
0000/360ADFEC/20 -> 06 00 00 36 0A D0 00 / 06 FF FF FF FF F0 00 <<<<< fail =
here
0000/360AD082/30 -> 07 00 00 36 0A D0 80 00 / 07 FF FF FF FF FF FC 00
/jack JACKSHANG/62185 HUAWEI TECHNOLOGIES CO.,LTD.=20 Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China E-mail: JACK.SHANG@HUAWEI.COM www.huawei.com ---------------------------------------------------------------------------= ---------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWE= I, which=20 is intended only for the person or entity whose address is listed above. An= y use of the=20 information contained herein in any way (including, but not limited to, tot= al or partial=20 disclosure, reproduction, or dissemination) by persons other than the inten= ded=20 recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by=20 phone or email immediately and delete it! =E5=8F=91=E4=BB=B6=E4=BA=BA: Alexander V. Chernikov-2 [via FreeBSD] [mailto= :ml-node+4406813-1462758870-209672@n5.nabble.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B45=E6=9C=8818=E6=97=A5 23= :37 =E6=94=B6=E4=BB=B6=E4=BA=BA: Jack Shang(hongzhang) =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: Is it a bug of RADIX ????? On 18.05.2011 19:15, Jack Shang(hongzhang) wrote:=20 > I do these by call the radix routine such as rn_addroute and rn_delete di= rectly.=20 Okay. Can you provide FreeBSD version and a piece of code triggering=20 such a situation?=20 IMHO radix assumes destination address to have host bits cleared, code in= =20 rtrequest1_fib does this via rt_maskedcopy().=20 Are you sure you need to pass=20 0x360AD0A2/30=20 0x360ADFEC/20=20 0x360AD082/30=20 instead of:=20 0x360AD0A0/30=20 0x360AD000/20=20 0x360AD080/30=20 ?=20 > ________________________________________=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Alexander V. Chernikov [[hidden email]]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B45=E6=9C=8818=E6=97=A5 = 20:54=20 > =E5=88=B0: Jack Shang(hongzhang)=20 > Cc: [hidden email]=20 > =E4=B8=BB=E9=A2=98: Re: Is it a bug of RADIX ?????=20 >=20 > On 18.05.2011 16:31, JACK wrote:=20 >> After inserting the following IPv4 routers:=20 >>=20 >> 0x360AD0A2/30=20 >> 0x360ADFEC/20=20 >> 0x360AD082/30=20 >>=20 >> I try to delete the above routes, when delete the second=20 >> route(0x360ADFEC/20), the operation fail.=20 > Can you specify exact commands you are issuing to add/remove routes?=20 > (or "route monitor" output if you are doing this from some dynamic=20 > routing software)=20 >=20 > The following order works for me (8.2-STABLE):=20 >=20 > 16:44 [0] bibi# route add -net 54.10.208.162/30 10.11.0.1=20 > add net 54.10.208.162: gateway 10.11.0.1=20 > 16:45 [0] bibi# route add -net 54.10.223.236/20 10.11.0.1=20 > add net 54.10.223.236: gateway 10.11.0.1=20 > 16:46 [0] bibi# route add -net 54.10.208.130/30 10.11.0.1=20 > add net 54.10.208.130: gateway 10.11.0.1=20 >=20 > 16:46 [0] bibi# netstat -rn -finet | grep 54=20 > 54.10.208.0/20 =C2=A0 =C2=A0 10.11.0.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= UGS =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2= =A0em0=20 > 54.10.208.128/30 =C2=A0 10.11.0.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UGS = =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0em0= =20 > 54.10.208.160/30 =C2=A0 10.11.0.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UGS = =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0em0= =20 > 16:46 [0] bibi# route delete 54.10.208.0/20=20 > delete net 54.10.208.0=20 > 16:48 [0] bibi# route delete 54.10.208.128/30=20 > delete net 54.10.208.128=20 > 16:49 [0] bibi# route delete 54.10.208.160/30=20 > delete net 54.10.208.160=20 > 16:49 [0] bibi# netstat -rn -finet | grep 54=20 > 16:49 [0] bibi#=20 >=20 >=20 >> struct radix_node * rn_delete (........)=20 >> {=20 >> =C2=A0 =C2=A0 =C2=A0...=20 >> =C2=A0 =C2=A0 =C2=A0/*=20 >> =C2=A0 =C2=A0 =C2=A0 * Delete our route from mask lists.=20 >> =C2=A0 =C2=A0 =C2=A0 */=20 >> =C2=A0 =C2=A0 =C2=A0if (netmask !=3D NULL) {=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((x =3D rn_addmask(netmask, TRUE, h= ead_off)) =3D=3D NULL)=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (NULL);=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0netmask =3D x->rn_key;=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0while (tt->rn_mask !=3D netmask)=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((tt =3D tt->rn_duped= key) =3D=3D NULL)=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (NU= LL); // rn_delete return here!!!=20 >> =C2=A0 =C2=A0 =C2=A0}=20 >> =C2=A0 =C2=A0 =C2=A0...=20 >> }=20 >>=20 >> but, if I delete as the following order, all routers was deleted=20 >> successfully:=20 >>=20 >> 0x360AD0A2/30=20 >> 0x360AD082/30=20 >> 0x360ADFEC/20=20 >>=20 >>=20 >> so, is it a bug of RADIX?=20 >>=20 >> /jack=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it= -a-bug-of-RADIX-tp4406356p4406356.html >> Sent from the freebsd-net mailing list archive at Nabble.com.=20 >> _______________________________________________=20 >> [hidden email] mailing list=20 >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "[hidden email]"=20 _______________________________________________=20 [hidden email] mailing list=20 http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[hidden email]"=20 ________________________________________ If you reply to this email, your message will be added to the discussion be= low: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406813= .html=20 To unsubscribe from Is it a bug of RADIX ?????, click here.=20 -- View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-= bug-of-RADIX-tp4406356p4408573.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Thu May 19 07:50:33 2011 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 E51C51065698 for ; Thu, 19 May 2011 07:50:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 874158FC1C for ; Thu, 19 May 2011 07:50:33 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p4J5I429014889 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 May 2011 22:18:07 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DD4A807.3090601@freebsd.org> Date: Wed, 18 May 2011 22:17:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: JACK References: <1305721909414-4406356.post@n5.nabble.com> <4DD3C17E.9070903@ipfw.ru> <4DD3E713.3070008@ipfw.ru> <78D2B330B6A30B4CB554FD2EC08D7434F36F04@szxeml508-mbx.china.huawei.com> In-Reply-To: <78D2B330B6A30B4CB554FD2EC08D7434F36F04@szxeml508-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Is it a bug of RADIX ????? 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, 19 May 2011 07:50:34 -0000 On 5/18/11 7:46 PM, JACK wrote: > THANKS FOR YOUR REPLY! :) > > the version I used can be found here: > http://fxr.watson.org/fxr/source/net/radix.c?v=DFBSD that is DragonFlyBSD not FreeBSD. While our friends atr DragonFlyBSD derived their work from FreeBSD, and we communicate, they are still a separate group with their own mailing lists etc. From owner-freebsd-net@FreeBSD.ORG Thu May 19 08:37:37 2011 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 9B3DF106566C for ; Thu, 19 May 2011 08:37:37 +0000 (UTC) (envelope-from igor.anishchuk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5962C8FC18 for ; Thu, 19 May 2011 08:37:37 +0000 (UTC) Received: by qwc9 with SMTP id 9so1644763qwc.13 for ; Thu, 19 May 2011 01:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=n0x+Hhi2iq3f+kCNNU03J5BF1Gg+spLQxlZejgvxXkM=; b=fvLPHhf7dpz8f4VZ2R06Rh6Mbw9lqdhg+gKZOKNS34kHKjoaI5SYN5pMTItYF1W+Wq CmedLRBpipYEcFDWY/XrBv1rG0NbdJFqu67NkntHoKzqIqZ4CnIhdoWaVrDmy9inULaI oWVg06cqfZ+R3+sx3nf9rndzAO7qFRlHV75Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XSY/OekohL6NknjGmqbGfuHT5tiCYwaj20Rwi+ZqmJUu6eOpfZnV/wRGXhFwoXWgC/ uSa/ej4uC7FeHIuAnfytfaKKqOKI5Mcyha/iN6T7wRvUrCn5b+YIYm1ogLwn5h4Ekzjw MAOTlYc5b6u1Le4GTQ+SVn0Y1PDLNwitNy4+M= MIME-Version: 1.0 Received: by 10.224.61.1 with SMTP id r1mr2202680qah.105.1305788290420; Wed, 18 May 2011 23:58:10 -0700 (PDT) Received: by 10.224.60.199 with HTTP; Wed, 18 May 2011 23:58:10 -0700 (PDT) Date: Thu, 19 May 2011 09:58:10 +0300 Message-ID: From: Igor Anishchuk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: ixgbe> vlan addition and removal brings the interfaces down and up 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, 19 May 2011 08:37:37 -0000 Hi All, I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters with direct attach cables and there is one thing keeps bothering me. I've been searching the Internet for any information with no luck. I would also assume that the problem is widely known, and I found one related PR kern/141285 but that one was closed unsolved. When a VLAN interface is added or removed to from the ix interfaces the parent interface is briefly brought down and up. This event is visible for all applications and the switches. With my use case I add and remove VLAN interfaces on the fly and the described behavior causes undesired effects, especially for BGP daemons that are configured to monitor one of permanent VLAN interfaces. I use FreeBSD 7-STABLE and the behavior is the same with stock drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web site. I have attempted to disable -vlanhwtag, -vlanhwfilter and -vlanhwtso with no effect. Could someone help me to stop the cards behaving this way? I do not mind some performance penalties, nor running in permanent promiscuous mode. I just want the card to stay up all the time regardless of the vlan interfaces attached to it. Any help, links, patches are much appreciated. Regards, Igor Anishchuk From owner-freebsd-net@FreeBSD.ORG Thu May 19 10:20:43 2011 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 81F281065670 for ; Thu, 19 May 2011 10:20:43 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3418FC12 for ; Thu, 19 May 2011 10:20:42 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4JAKJEo079828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 May 2011 19:20:30 +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 p4JAK7Ei061227; Thu, 19 May 2011 19:20:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 19 May 2011 19:07:28 +0900 (JST) Message-Id: <20110519.190728.881895202152708492.hrs@allbsd.org> To: spork@bway.net From: Hiroki Sato In-Reply-To: References: <20110517.174313.868674729938461030.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_May_19_19_07_28_2011_851)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 19 May 2011 19:20:30 +0900 (JST) X-Spam-Status: No, score=6.1 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 alias masks/masks for routed aliases 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, 19 May 2011 10:20:43 -0000 ----Security_Multipart(Thu_May_19_19_07_28_2011_851)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Sprickman wrote in : sp> On Tue, 17 May 2011, Hiroki Sato wrote: sp> sp> > Charles Sprickman wrote sp> > in sp> > : sp> > sp> > sp> First, the easy one. For IPv6 aliases, what is the proper subnet? sp> > sp> > Normally it is a /64. See also Section 2.5.4 in RFC 4291. sp> sp> My understanding was that a /64 was a common subnet since it's the sp> minimum size required for host autoconfiguration. What I'm really sp> looking for is the FreeBSD-specific recommendation for configuring sp> aliases - I understand that I'll probably have a /64 on the LAN, but sp> when setting a netmask on a single IPv6 alias are the rules different sp> than they are for IPv4? So if I've got a lan block that's a /64 and I sp> configure an alias on a FreeBSD host, do I give the alias the lan sp> subnet (/64) or a host subnet (/128)? For IPv4, I believe that it sp> should always be the host subnet (/32). There is no FreeBSD-specific configuration. The recommendation is /64 because various IPv6 specs assume /64 prefix length for a global unicast address on a host and FreeBSD implementation supports configuration of multiple /64 addresses on a single interface. There is no reason to use /128 or ones longer than 64 while you can configure a GUA with such a longer prefix. sp> The current setup looks like this on the ISP side: I am still not sure of the network topology. Something like this? (ISP) | |10.[123456].0.0 (router) |10.1.0.1/27 | (hosts) 10.1.0.x/27 10.2.0.2/28 10.2.0.3/32 : Hmm, I may misunderstand something. If this diagram is correct, I am wondering why the router has 10.[123456].0.0 addresses on the WAN side, not on the FE0/1 side. I feel like simply configuring 10.[123456].0.1 on the LAN side instead and an address on the ISP side which can communicate ISP's router would work. -- Hiroki ----Security_Multipart(Thu_May_19_19_07_28_2011_851)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3U6+AACgkQTyzT2CeTzy3jjwCeMDX2uC40TapE4toeClSjGH2x jt4An2pGqEIaSd+l2bv4c9O6B/p3KGTP =MzT6 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_May_19_19_07_28_2011_851)---- From owner-freebsd-net@FreeBSD.ORG Thu May 19 14:19:31 2011 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 78876106564A for ; Thu, 19 May 2011 14:19:31 +0000 (UTC) (envelope-from williamejsalt@googlemail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 428EE8FC1B for ; Thu, 19 May 2011 14:19:30 +0000 (UTC) Received: by iwn33 with SMTP id 33so3116105iwn.13 for ; Thu, 19 May 2011 07:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=qNe1KkFQycXWtsE5NXgUeesdKIFNiCh+y5NcqLQkb2Q=; b=n0vcBkTMjMO/WzS47zbwnCpbFP2LPqsyB0KOs3N/DKYF7CcRowWoc9okHIBfiqZ3R0 /5KEZ3rQ5bm2L5QIA0TmyXD2l4cKaEZOfuC/PAojuk+NWZEemxMSjAp7lghIvAXFwzKT /7ROowW3r2m9r5ttj07PTwdMQDiszoJnEBj2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F7hlAGQunr9pN9i9Y7GAKwDOLr6G00ukASQXmx9Z7yW73ejulaYvPZ9r1r3tnxu5EF 98LuwN6Qq2MLdj8vMppkIx3sXbgnwA/+vQYE36WEQnsSfnU51TahJKhvCeFD8cuct4D1 4oad6jZnHJ7d01/xo5o9x9dDWggxD/Fzt2Y/A= MIME-Version: 1.0 Received: by 10.42.220.136 with SMTP id hy8mr3747768icb.114.1305813176460; Thu, 19 May 2011 06:52:56 -0700 (PDT) Received: by 10.231.32.72 with HTTP; Thu, 19 May 2011 06:52:56 -0700 (PDT) Date: Thu, 19 May 2011 14:52:56 +0100 Message-ID: From: William Salt To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 19 May 2011 15:15:46 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Intel 10GbE Tuning under freebsd 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, 19 May 2011 14:19:31 -0000 Hi All, I have just got a couple of 10GbE intel X520-DA2 cards to test. Im running freebsd 8.1 on a super micro intel xeon server, and a hp core 2 duo workstation, both machines have 4gb of ram. Both are attached via sfp+ cables to a brocade turbo iron switch, which simply has jumbo frames enabled. Initial testing was pretty basic, i simply enabled jumbo frames, and increased max send/recv buffer to 16MB, which should be more than enough. I then ran iperf and managed to get approximately 5gbps, i was expecting around 8.5gbps. However, i realise that the ix driver probably needs to be tuned, as well as the OS. After a bit of googling, i cant find a tuning guide under freebsd for 10GbE, or many recommendations, and wondered if anyone has already successfully managed to tune freebsd with intel 10gbe nics, to gain a higher throughput? If so, has anyone got any tips, or sample configs? Thanks in advance Will From owner-freebsd-net@FreeBSD.ORG Thu May 19 16:37:56 2011 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 F32DD1065673 for ; Thu, 19 May 2011 16:37:56 +0000 (UTC) (envelope-from jfvogel@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 A8E0D8FC16 for ; Thu, 19 May 2011 16:37:56 +0000 (UTC) Received: by vws18 with SMTP id 18so2801630vws.13 for ; Thu, 19 May 2011 09:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R7cLkFm27VA7Rfkf15cb16IaR2LqEi9vuufUuOehYYc=; b=TyRFclh4G+/ZVCmC1MXkHtQeMV47kJJ+YWak/NYkKf6JcXvgniomxd63lJLC96N/yU JtpHmeK5WDUAQRd4b6hTP0dCCninqdIz03AuZK5sjO4n05L9oyDTgqECD9dxgfgh/ELk yt+TDeY0jphXdZ3e3XnRQHVGfFQ6D6Lwbtrc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xYwK6xndLz+M3f51/4iFxhOL60Sb+lELhQQug69hcJ2ykMI3/YFChbLwE2MRPgTsSn gm6H1js+goZDwnpUwQbrkDh6DxIeyjLZ9u/Cy1MpFqG3C7z8QChBw4O67GUjyJtCbeGj AZfc3C6hPEku4DwkjH1Lx4el4kUCOkVcnNrCk= MIME-Version: 1.0 Received: by 10.52.179.103 with SMTP id df7mr4947426vdc.148.1305823063789; Thu, 19 May 2011 09:37:43 -0700 (PDT) Received: by 10.52.183.233 with HTTP; Thu, 19 May 2011 09:37:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 09:37:43 -0700 Message-ID: From: Jack Vogel To: William Salt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GbE Tuning under freebsd 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, 19 May 2011 16:37:57 -0000 First, get the latest driver if you are using the native 8.1 its way old. Second, make sure you're in a PCI Express 2.0 slot, at least 8x, and if you are using a consumer type system there are often slots that are not wired with as many lanes as you might think, so verify that. Oh, and remember, both sides of the link effect things so check both. Newer driver versions will warn you if you don't have adequate bandwidth. Third, make sure you have the system interrupt storm threshold increased, hw.intr_storm_threshold, its way too low by default for 10G rates, I would initially increase it to 10000, there will be messages about throttling if its not high enough, increase til you don't see them. Fourth, make sure your mbuf pool numbers are high enough in the size that you need. The ixgbe driver uses standard 2K clusters when using standard MTU, but as soon as you use jumbos it will go to 4K and then 9K as the jumbo size increases. increase the relevant kern.ipc.nmb... This should get you in the ballpark, let me know if you have further questions or issues. Good luck, Jack On Thu, May 19, 2011 at 6:52 AM, William Salt wrote: > Hi All, > I have just got a couple of 10GbE intel X520-DA2 cards to test. Im > running freebsd 8.1 on a super micro intel xeon server, and a hp core 2 duo > workstation, both machines have 4gb of ram. > Both are attached via sfp+ cables to a brocade turbo iron switch, which > simply has jumbo frames enabled. > > Initial testing was pretty basic, i simply enabled jumbo frames, and > increased max send/recv buffer to 16MB, which should be more than enough. > I then ran iperf and managed to get approximately 5gbps, i was expecting > around 8.5gbps. > However, i realise that the ix driver probably needs to be tuned, as well > as > the OS. > > After a bit of googling, i cant find a tuning guide under freebsd for > 10GbE, > or many recommendations, and wondered if anyone has already successfully > managed to tune freebsd with intel 10gbe nics, to gain a higher throughput? > If so, has anyone got any tips, or sample configs? > > Thanks in advance > Will > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 19 16:45:10 2011 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 E9C4E106564A for ; Thu, 19 May 2011 16:45:10 +0000 (UTC) (envelope-from jfvogel@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 A0F588FC18 for ; Thu, 19 May 2011 16:45:10 +0000 (UTC) Received: by vws18 with SMTP id 18so2809034vws.13 for ; Thu, 19 May 2011 09:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QQSzf/Ye/gqj8wSFESl+4PBJBsKeqh1t6Zreyqoi02U=; b=B7+hVvaARE9GZcivz7EXkNq87SwcWX8SkBD/ZyiDvKDihVsE7SQtZlYWwSZbfGFra2 q3lWAXeZY6ZVbPIH7/tmM//ZY4oGDc7fWwUmdI4mmfWcl8DMKdNdy6ICxpt+De0dItk5 WUIlBZvcB/aFoFKAKdGB3MSrmCUsbxTNy6fSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CxIDxzxkC4pycjNvpAnJfAo7mEd3ZjtwQQ/OTWisrbE3pEOtmT7nhq+oN8RvFee6zV 1UW9hkjZkCFtwImKI9k7lOTjOiLlQh63LMtkfu6LvrhzzzcGh+u88yDUX/HpgOcVXH8v 5XilRmgLad00u+Sf76yFqlzz5jz8dNlQizdhY= MIME-Version: 1.0 Received: by 10.52.179.103 with SMTP id df7mr4958274vdc.148.1305823509537; Thu, 19 May 2011 09:45:09 -0700 (PDT) Received: by 10.52.183.233 with HTTP; Thu, 19 May 2011 09:45:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 09:45:09 -0700 Message-ID: From: Jack Vogel To: William Salt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GbE Tuning under freebsd 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, 19 May 2011 16:45:11 -0000 Oh, another thought, LRO is not enabled by default, it causes problems when you are forwarding, but if you are just passing back to back traffic it helps enormously, so use ifconfig to enable it on the interface. Jack From owner-freebsd-net@FreeBSD.ORG Thu May 19 16:55:42 2011 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 3E7BD106566B for ; Thu, 19 May 2011 16:55:42 +0000 (UTC) (envelope-from kip.macy@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 E5C098FC13 for ; Thu, 19 May 2011 16:55:41 +0000 (UTC) Received: by vxc34 with SMTP id 34so2859386vxc.13 for ; Thu, 19 May 2011 09:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x1T+UUWtMqejhEmnUidLVCjNgv4kci8wdcAMuxt2Fio=; b=X5W6KcQd+MRjeLNadx0X/57lxdaBajkETJ1wMq+YrLp/BRP46jrZ4hh23uyQUazWdF P81ygwQFrkNUR7I7nor9G6tTwzTkGmK+J+Dz3c2AH9cmK+9+hsU4HR8JH0QtvccDZEuz 7ueR6z7v4VoYMv1DGu46gfJmTekz+ZHzQQdvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qRO/I5BdQGoDat0cWUWeP/f0PKtjQAR/hzyPRTXVJQNIw/7NSfnUhH765pFg5m5vZl NrgI+pPzChOoJX4njlDnV57RTObYe1DQzJJnk8Q1SxvobyJ2zY+tV4aetmQjtCPVjaMv O4Co6D3YF1YRwta8MUF/A3HHs7C35K5ywOXRQ= MIME-Version: 1.0 Received: by 10.52.31.103 with SMTP id z7mr4945663vdh.89.1305822498445; Thu, 19 May 2011 09:28:18 -0700 (PDT) Received: by 10.52.112.73 with HTTP; Thu, 19 May 2011 09:28:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 18:28:18 +0200 Message-ID: From: Kip Macy To: William Salt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GbE Tuning under freebsd 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, 19 May 2011 16:55:42 -0000 Four very quick points: - Enabling flowtable can help provided you don't have a large (greater than a few thousand) number of peers. - I have a patch under review to cache the rtentry (L3) and llentry (L2) in the inpcb for TCP connections, which improves scaling at high packet rates. - You'll want to ensure that the number of transmit and receive queues is getting configured properly (at least one per core up to the maximum number supported by the cards) - If you have very large numbers of connections you'll want to increase the size of the TCB hash, to dramatically reduce the lookup times when receiving packets. I hope that helps a little bit. Cheers, Kip On Thu, May 19, 2011 at 3:52 PM, William Salt wrote: > Hi All, > =A0 =A0 =A0 =A0 I have just got a couple of 10GbE intel X520-DA2 cards to= test. Im > running freebsd 8.1 on a super micro intel xeon server, and a hp core 2 d= uo > workstation, both machines have 4gb of ram. > Both are attached via sfp+ cables to a brocade turbo iron switch, which > simply has jumbo frames enabled. > > Initial testing was pretty basic, i simply enabled jumbo frames, and > increased max send/recv buffer to 16MB, which should be more than enough. > I then ran iperf and managed to get approximately 5gbps, i was expecting > around 8.5gbps. > However, i realise that the ix driver probably needs to be tuned, as well= as > the OS. > > After a bit of googling, i cant find a tuning guide under freebsd for 10G= bE, > or many recommendations, and wondered if anyone has already successfully > managed to tune freebsd with intel 10gbe nics, to gain a higher throughpu= t? > If so, has anyone got any tips, or sample configs? > > Thanks in advance > Will > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 19 17:58:17 2011 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 14FFB106566C for ; Thu, 19 May 2011 17:58:17 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id C755B8FC19 for ; Thu, 19 May 2011 17:58:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 0956F8BC002; Thu, 19 May 2011 13:59:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNz7s8BTiyEv; Thu, 19 May 2011 13:59:22 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id D9ED68BC001; Thu, 19 May 2011 13:59:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: Date: Thu, 19 May 2011 13:58:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> References: To: Igor Anishchuk X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down and up 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, 19 May 2011 17:58:17 -0000 I have a patch that will fix this. Please give me a little while to = clean it up, and I will send it out on the list. -Andrew On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: > Hi All, >=20 > I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters > with direct attach cables and there is one thing keeps bothering me. > I've been searching the Internet for any information with no luck. I > would also assume that the problem is widely known, and I found one > related PR kern/141285 but that one was closed unsolved. >=20 > When a VLAN interface is added or removed to from the ix interfaces > the parent interface is briefly brought down and up. This event is > visible for all applications and the switches. With my use case I add > and remove VLAN interfaces on the fly and the described behavior > causes undesired effects, especially for BGP daemons that are > configured to monitor one of permanent VLAN interfaces. >=20 > I use FreeBSD 7-STABLE and the behavior is the same with stock > drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web > site. I have attempted to disable -vlanhwtag, -vlanhwfilter and > -vlanhwtso with no effect. >=20 > Could someone help me to stop the cards behaving this way? I do not > mind some performance penalties, nor running in permanent promiscuous > mode. I just want the card to stay up all the time regardless of the > vlan interfaces attached to it. >=20 > Any help, links, patches are much appreciated. >=20 > Regards, >=20 > Igor Anishchuk > _______________________________________________ > 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" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Thu May 19 20:18:25 2011 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 1D7D5106564A for ; Thu, 19 May 2011 20:18:25 +0000 (UTC) (envelope-from atkin901@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id DBAF28FC15 for ; Thu, 19 May 2011 20:18:24 +0000 (UTC) Received: by pxi11 with SMTP id 11so2441872pxi.7 for ; Thu, 19 May 2011 13:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version :newsgroups:to:cc:subject:references:in-reply-to:x-enigmail-version :content-type:content-transfer-encoding; bh=xSv+l8U+0/LPoGHO0ixHHGFH8r35q2XombbDmnD7nwU=; b=uIEajdE9+oT82JYp8Vf4Dm9Grul5AnyJKA0ujKf0ssrK8nbphOFaY5aIsPBD57WhjY 8wAqmC1JB6CWkKlJZlicu7B7/WKCN3kAtDC3j2XZ6v8+G/GzMOUh+u9tNb4AGtmLnvYM mAcRRoEzLyM76PmDN32vb5hyEkkuX70kA9fzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:newsgroups:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=B3XeR8mYgO/R4aPJvoaEloIFbsmadvu9DWNyPWbzjIR1qf4n9RTIxafdE2aA1YXNUb KUfAVqYSJ9j4HNfwlDTK6Bb3g8kyQVnXCijxwo+wSKSVwpYGY7Ku8u6jsNrULQ2JNuz0 V3fNOvxK7R88vaX+KH4qnBEzIQTDaAN5CKmyw= Received: by 10.68.15.229 with SMTP id a5mr5045392pbd.42.1305834611930; Thu, 19 May 2011 12:50:11 -0700 (PDT) Received: from moby.pdsea.f5net.com (207.155.204.151.ptr.us.xo.net [207.155.204.151]) by mx.google.com with ESMTPS id l3sm1939238pbq.75.2011.05.19.12.50.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 12:50:10 -0700 (PDT) Message-ID: <4DD57469.9000607@gmail.com> Date: Thu, 19 May 2011 12:50:01 -0700 From: Mark Atkinson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110502 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.devel.net To: jyl_2006 References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com> <44AE4814.2020706@cisco.com> <20060708104718.GA1632@bashibuzuk.net> <44B0D157.8070503@cisco.com> <1305363576917-4395319.post@n5.nabble.com> In-Reply-To: <1305363576917-4395319.post@n5.nabble.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 20:18:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/14/2011 01:59, jyl_2006 wrote: > I have download files from http://www.sctp.org/app.tar.bz2,and when I input > gmake, > It shows that: > cc:../user/FreeBSD/libsctpuser.a:No such file or directory. > I have tryed to search file named "libsctpuser.a",but nothing have found. > Anyone who can help me? SCTP on FreeBSD is easier than the ancient SCTP demo code. 1. Take any regular TCP app source and find the socket calls in it. 2. change netinet/in.h to netinet/sctp.h 3. change protocol IPPROTO_SCTP 4. compile and launch. example change from port swww/bozohttpd. - --- ./daemon-bozo.c 2010-09-20 15:49:42.000000000 -0700 +++ /usr/ports/www/bozohttpd-sctp/work/bozohttpd-20100920/daemon-bozo.c 2011-04-28 08:03:22.000000000 -0700 @@ -36,7 +36,7 @@ #include #include - -#include +#include #include #include @@ -98,7 +98,7 @@ httpd->sock = bozomalloc(httpd, httpd->nsock * sizeof(*httpd->sock)); httpd->fds = bozomalloc(httpd, httpd->nsock * sizeof(*httpd->fds)); for (i = 0, r = r0; r != NULL; r = r->ai_next) { - - httpd->sock[i] = socket(r->ai_family, SOCK_STREAM, 0); + httpd->sock[i] = socket(r->ai_family, SOCK_STREAM, IPPROTO_SCTP); if (httpd->sock[i] == -1) continue; if (setsockopt(httpd->sock[i], SOL_SOCKET, SO_REUSEADDR, &on, example change to wget: - --- wget-svn/wget/src/connect.c 2007-07-23 14:31:01.000000000 -0700 +++ wget-sctp/wget/src/connect.c 2011-05-12 07:01:04.000000000 -0700 @@ -39,7 +39,7 @@ #ifndef WINDOWS # include # include - -# include +# include # ifndef __BEOS__ # include # endif @@ -275,7 +275,7 @@ sockaddr_set_data (sa, ip, port); /* Create the socket of the family appropriate for the address. */ - - sock = socket (sa->sa_family, SOCK_STREAM, 0); + sock = socket (sa->sa_family, SOCK_STREAM, IPPROTO_SCTP); if (sock < 0) goto err; @@ -423,7 +423,7 @@ void *setopt_ptr = (void *)&setopt_val; socklen_t setopt_size = sizeof (setopt_val); - - sock = socket (bind_address->family, SOCK_STREAM, 0); + sock = socket (bind_address->family, SOCK_STREAM, IPPROTO_SCTP); if (sock < 0) return -1; -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VdGkACgkQrDN5kXnx8ybfxQCfW53+CBn0L/V+MW3rRyxRx5hp IZEAn0iRjxj2LH2atgIBjImWbSlDmt84 =6Aja -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu May 19 22:23:12 2011 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 32050106564A for ; Thu, 19 May 2011 22:23:12 +0000 (UTC) (envelope-from prvs=1120cc9e47=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id AF5C88FC12 for ; Thu, 19 May 2011 22:23:11 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 19 May 2011 23:11:27 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 19 May 2011 23:11:20 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013294206.msg for ; Thu, 19 May 2011 23:11:20 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1120cc9e47=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "William Salt" , References: Date: Thu, 19 May 2011 23:11:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Subject: Re: Intel 10GbE Tuning under freebsd 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, 19 May 2011 22:23:12 -0000 I would recommend moving to 8.2 with the additional fixes in stable to which prevents adding IP's from disconnecting the network. In the machine what PCIe speed does it state its using? What CPU's do you have as to push closer to 10Gbps your going to need a quick machine. Regards Steve ----- Original Message ----- From: "William Salt" To: Sent: Thursday, May 19, 2011 2:52 PM Subject: Intel 10GbE Tuning under freebsd > Hi All, > I have just got a couple of 10GbE intel X520-DA2 cards to test. Im > running freebsd 8.1 on a super micro intel xeon server, and a hp core 2 duo > workstation, both machines have 4gb of ram. > Both are attached via sfp+ cables to a brocade turbo iron switch, which > simply has jumbo frames enabled. > > Initial testing was pretty basic, i simply enabled jumbo frames, and > increased max send/recv buffer to 16MB, which should be more than enough. > I then ran iperf and managed to get approximately 5gbps, i was expecting > around 8.5gbps. > However, i realise that the ix driver probably needs to be tuned, as well as > the OS. > > After a bit of googling, i cant find a tuning guide under freebsd for 10GbE, > or many recommendations, and wondered if anyone has already successfully > managed to tune freebsd with intel 10gbe nics, to gain a higher throughput? > If so, has anyone got any tips, or sample configs? > > Thanks in advance > Will > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu May 19 22:26:35 2011 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 9398E1065670 for ; Thu, 19 May 2011 22:26:35 +0000 (UTC) (envelope-from kmacybsd@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 4B3408FC13 for ; Thu, 19 May 2011 22:26:35 +0000 (UTC) Received: by vws18 with SMTP id 18so3124881vws.13 for ; Thu, 19 May 2011 15:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=DV0j0fz57S6hz4ZYtLvW7DvTszQRvFMP0GBj7KJ9iQk=; b=F8MRmpSisF9QKR+UR5d0AI01+QfoL7E9f/fKPYf/CoeqGt7jcL16AK1LcbLOibci7L Ox9TqmS2K8s5V2tr8vgDAMw9+qXcgWnO+wgCqCQ9QWWN9E9Mp5/1iSvbMEQeQoG/AyUa wH5o7y+VwTk+wWs+QIyrU5TXZ8PtdjJ04AXiE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ipECQ+ndk0FFioKxQNRLUArE+KveQNdoRr9sHoTfeIUPIfAkzw6hCYYqdh3jKwRGcP MToNju3DVTGtFZEpEb2bZft4LxCKA4IyXsjmAEbJ+vEygENcvCLwexXGDcOZBIWYexmb p0VDP1dH7qKRcE8gBDrvxM+mieBt3ZboSbR10= MIME-Version: 1.0 Received: by 10.220.247.139 with SMTP id mc11mr1082149vcb.107.1305843994685; Thu, 19 May 2011 15:26:34 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.67 with HTTP; Thu, 19 May 2011 15:26:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 May 2011 00:26:34 +0200 X-Google-Sender-Auth: C_9_ONvudNvmyyEPSgVtN4wW-DI Message-ID: From: "K. Macy" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Intel 10GbE Tuning under freebsd 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, 19 May 2011 22:26:35 -0000 > In the machine what PCIe speed does it state its using? What CPU's do you > have as to push closer to 10Gbps your going to need a quick machine. Good point. 5Gbps could indicate that the PCI-e slot is only negotiating 4x as opposed to 8x. -Kip From owner-freebsd-net@FreeBSD.ORG Thu May 19 22:36:31 2011 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 DF20C1065673 for ; Thu, 19 May 2011 22:36:30 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id B71098FC14 for ; Thu, 19 May 2011 22:36:30 +0000 (UTC) Received: by pxi11 with SMTP id 11so2526563pxi.7 for ; Thu, 19 May 2011 15:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=devV4CUpqR/uRmmEgd4It3QVRyTBJspku2ez8vU15WA=; b=dYQQ8zAS6mW/W6TsYWgUAYk/8IKTu+/CHbAvGDNiFesy8B6lR+X5DsMRV40/nywsHh 1BEkIWJ78WXs6EYx5IkBq1wj2zbcnMYYEMGmf3aKIj6mCwlkCRczOGr0jdQE9HqmQQOd E2FlLZo7Bjg3zP8M33Fov5RlXCTP3iJP5b+x4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=CErLIWtGc8KRVRCKeJ5Ie/Z6rGXCuG5c72SBq+46CeQrx9NRq0V4ETqAWbgmq4eU7I 6DjDqhf8gD+TgMGoW+PJ6ejgvv1JUA+7Lhcz4CgmDQzvXC5asqhVsbUlzT8wm9RFEsew TN6em8pBOXTEfN7fkYiG86wql0KGnF+KFROKc= MIME-Version: 1.0 Received: by 10.68.50.9 with SMTP id y9mr5932611pbn.24.1305843169086; Thu, 19 May 2011 15:12:49 -0700 (PDT) Received: by 10.68.63.104 with HTTP; Thu, 19 May 2011 15:12:49 -0700 (PDT) Date: Thu, 19 May 2011 15:12:49 -0700 Message-ID: From: Josh Carroll To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: aliases on em(4) do not work properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 22:36:31 -0000 After upgrading my hardware, I now have two new em(4) in this box running FreeBSD 8.2-RELEASE/amd64. One NIC is the onboard NIC on the Asus P8Z68-V Pro board, the other is the Intel EXPI9301CTBLK PCI-Express card. em0 is the internet-facing card and I have 4 aliases in addition to the primary address (I have a /29 IP allocation from Comcast Business Class). After this hardware upgrade, any connection with a source address of one of the aliases on em0 does not work properly, it just hangs. Here is my rc.conf entry for this interface: ipv4_addrs_em0="XYZ.14.73.185-189/29" I also tried with the deprecated way (ifconfig_em0_alias0="..."). So connections using the default IP (XYZ.14.73.185) work fine, for example I can do the following: ping -S XYZ.14.73.185 www.google.com But if I try: ping -S XYZ.14.73.186 www.google.com It drops all packets. If I modify rc.conf to use .186 as the primary IP address and make .185 an alias, then I am able to use .186 to initiate connections. What's even more interesting is I can then set the primary IP back to .185 and have .186 as an alias again, and I can still use that IP. I thought it might be a strange arp problem, but even after putting .185 back as the default IP, and doing an arp -a -d to wipe the arp table, the .186 alias still works. I haven't rebooted, but I suspect as soon as I reboot the problem will reoccur. I can confirm that later this evening when I'm physically with the hardware. I saw a thread a couple of years ago with a similar issue: http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047839.html So I don't know if this is the same problem or just the same symptoms. Here is a tcpdump on em0 (tcpdump -n -vvv -i em0 host XYZ.14.73.188) during a ping -S XYZ.14.73.188 (I had to use .188 because .186 and .187 work now after making them the default IP as I mentioned above): 13:52:00.794099 IP (tos 0x0, ttl 64, id 20808, offset 0, flags [none], proto ICMP (1), length 84) XYZ.14.73.188 > 74.125.224.114: ICMP echo request, id 14907, seq 0, length 64 13:52:00.817650 IP (tos 0x20, ttl 53, id 43491, offset 0, flags [none], proto ICMP (1), length 84) 74.125.224.114 > XYZ.14.73.188: ICMP echo reply, id 14907, seq 0, length 64 So traffic seems to pass and responses come back, but I cannot complete a TCP handshake. Here's a tcpdump of an attempt to telnet to www.google.com on port 80: 13:54:12.662323 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x6796 (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210048141 ecr 14620543,nop,wscale 6], length 0 13:54:13.049625 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x6613 (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210048528 ecr 14620543,nop,wscale 6], length 0 13:54:13.650624 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x63ba (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210049129 ecr 14620543,nop,wscale 6], length 0 13:54:14.849538 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x5f0a (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210050329 ecr 14620543,nop,wscale 6], length 0 13:54:15.646261 IP (tos 0x10, ttl 64, id 60781, offset 0, flags [none], proto TCP (6), length 60) XYZ.14.73.188.21613 > 74.125.224.113.80: Flags [S], cksum 0xb735 (correct), seq 1835043039, win 65535, options [mss 1460,nop,wscale 5,sackOK,TS val 14623543 ecr 0], length 0 13:54:15.662281 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x5bde (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210051141 ecr 14620543,nop,wscale 6], length 0 13:54:17.253367 IP (tos 0x20, ttl 53, id 61451, offset 0, flags [none], proto TCP (6), length 60) 74.125.224.113.80 > XYZ.14.73.188.21613: Flags [S.], cksum 0x55a6 (correct), seq 1796974652, ack 1835043040, win 5672, options [mss 1430,sackOK,TS val 3210052733 ecr 14620543,nop,wscale 6], length 0 ^C I tried adding an alias on em1 and I could ping things on my LAN with ping -S , so it seems particular to em0. I think em0 is the onboard NIC and em1 is the PCI-Express card. Here is the relevant pciconf output: em0@pci0:0:25:0: class=0x020000 card=0x849c1043 chip=0x15038086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbe00000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfbe28000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf080, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP em1@pci0:4:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbcc0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfbc00000, size 524288, enabled bar [18] = type I/O Port, range 32, base 0xe000, size 32, enabled bar [1c] = type Memory, range 32, base 0xfbce0000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled And here is the relevant dmesg output: em0: port 0xf080-0xf09f mem 0xfbe00000-0xfbe1ffff,0xfbe28000-0xfbe28fff irq 18 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: AA:BB:CC:DD:EE:FF em1: port 0xe000-0xe01f mem 0xfbcc0000-0xfbcdffff,0xfbc00000-0xfbc7ffff,0xfbce0000-0xfbce3fff irq 18 at device 0.0 on pci4 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: FF:EE:DD:CC:BB:AA ifconfig em0 output: em0: flags=8843 metric 0 mtu 1500 options=219b ether AA:BB:CC:DD:EE:FF inet XYZ.14.73.185 netmask 0xfffffff8 broadcast XYZ.14.73.191 inet XYZ.14.73.186 netmask 0xffffffff broadcast XYZ.14.73.186 inet XYZ.14.73.187 netmask 0xffffffff broadcast XYZ.14.73.187 inet XYZ.14.73.188 netmask 0xffffffff broadcast XYZ.14.73.188 inet XYZ.14.73.189 netmask 0xffffffff broadcast XYZ.14.73.189 media: Ethernet autoselect (1000baseT ) status: active arp -na output (LAN IPs masked out): ? (XYZ.14.73.186) at AA:BB:CC:DD:EE:FF on em0 permanent [ethernet] ? (XYZ.14.73.187) at AA:BB:CC:DD:EE:FF on em0 permanent [ethernet] ? (XYZ.14.73.185) at AA:BB:CC:DD:EE:FF on em0 permanent [ethernet] ? (XYZ.14.73.190) at 00:22:2d:6c:e0:3e on em0 expires in 113 seconds [ethernet] ? (XYZ.14.73.188) at AA:BB:CC:DD:EE:FF on em0 permanent [ethernet] ? (XYZ.14.73.189) at AA:BB:CC:DD:EE:FF on em0 permanent [ethernet] netstat -nr output: Internet: Destination Gateway Flags Refs Use Netif Expire default XYZ.14.73.190 UGS 34 27763 em0 10.0.0.0/24 link#2 U 2 96232 em1 => 10.0.0.0/8 link#2 U 1 28 em1 10.0.0.1 link#2 UHS 0 837 lo0 10.0.0.100 link#2 UHS 0 0 lo0 10.10.10.1 link#2 UHS 0 0 lo0 => 10.10.10.1/32 link#2 U 0 0 em1 10.10.10.2 link#2 UHS 0 0 lo0 => 10.10.10.2/32 link#2 U 0 0 em1 127.0.0.1 link#5 UH 0 486 lo0 XYZ.14.73.184/29 link#1 U 0 0 em0 XYZ.14.73.185 link#1 UHS 0 137 lo0 XYZ.14.73.186 link#1 UHS 0 0 lo0 => XYZ.14.73.186/32 link#1 U 0 0 em0 XYZ.14.73.187 link#1 UHS 0 0 lo0 => XYZ.14.73.187/32 link#1 U 0 0 em0 XYZ.14.73.188 link#1 UHS 0 0 lo0 => XYZ.14.73.188/32 link#1 U 0 0 em0 XYZ.14.73.189 link#1 UHS 0 0 lo0 => XYZ.14.73.189/32 link#1 U 0 0 em0 I can try building an 8-STABLE kernel to see if it works ok, but ideally I'd like to remain on 8.2-RELEASE. Please let me know what other information is needed to help debug this. Thanks, Josh From owner-freebsd-net@FreeBSD.ORG Fri May 20 15:39:27 2011 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 AF0D7106566C for ; Fri, 20 May 2011 15:39:27 +0000 (UTC) (envelope-from mrmullemeck@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4976B8FC20 for ; Fri, 20 May 2011 15:39:26 +0000 (UTC) Received: by wwc33 with SMTP id 33so3987629wwc.31 for ; Fri, 20 May 2011 08:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=5zCN5s0S9cIY5FmPIaDZk6Fubbe1mQQlepyVqdWpNto=; b=Zh0UtdQvJS9S3AfUK1B1C1orZDdRKu4mOvWqSRwCBvfsKKSGQ43wPY3dgwCtpj6i54 tvJ9rggLzR2N9uGG08otU4eFmyKboPj3RwPhi5jqAsbzliEvYdmaTAqUdHRh6xck2zKp 5dyzEZlhOIeihetIIjCjBZr0NtfUhv5g5D9UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gkK8oVAj0buetjFIo2PokvULzthzOU2Xhsef8Tttw2URQTSSKKMv49StNsytGRaOOC Oze/ln8texVwGA1Rh/2f0un7PGuQg6+yXomKjBCE+Jau3GK8nzroAhN1NVPE2CBNzAjC n3xEM+yk4fW7/X3COyKkHiA5MrkFjFQ/rNMmI= MIME-Version: 1.0 Received: by 10.216.221.30 with SMTP id q30mr4085669wep.84.1305904097295; Fri, 20 May 2011 08:08:17 -0700 (PDT) Received: by 10.216.230.131 with HTTP; Fri, 20 May 2011 08:08:17 -0700 (PDT) Date: Fri, 20 May 2011 17:08:17 +0200 Message-ID: From: MrMulleMeck To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: rtsol set IFF_UP when started - why? 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, 20 May 2011 15:39:27 -0000 When rtsol(d) starts, it check the interface status (flags). If flags are not (IFF_UP|IFF_RUNNING) rtsol concludes the interface is "not active". However, immediately after this, rtsol will activate/set the IFF_UP flag (if not set) causing DAD to start. Let say that the link is not ready yet (but in a short period of time) when rtsold starts, wouldn't this cause DAD to believe that the address is OK (no response since RS messages are actually never sent over the wire)? What is the rationale (if any) for rtsol to set the IFF_UP flag? It seems that rtsold will wait anyway for DAD later on? interface_up(char *name) { ... if (!(ifr.ifr_flags & IFF_UP)) { ifr.ifr_flags |= IFF_UP; if (ioctl(ifsock, SIOCSIFFLAGS, (caddr_t)&ifr) < 0) warnmsg(LOG_ERR, __func__, "ioctl(SIOCSIFFLAGS): %s", strerror(errno)); return(-1); } BR, MM From owner-freebsd-net@FreeBSD.ORG Sat May 21 08:58:44 2011 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 95B0F1065672 for ; Sat, 21 May 2011 08:58:44 +0000 (UTC) (envelope-from mgbowman@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id E83328FC0A for ; Sat, 21 May 2011 08:58:43 +0000 (UTC) Received: (qmail invoked by alias); 21 May 2011 08:58:42 -0000 Received: from dyn-86.106.48.187.cj.upcnet.ro (EHLO [192.168.1.4]) [86.106.48.187] by mail.gmx.com (mp-eu004) with SMTP; 21 May 2011 10:58:42 +0200 X-Authenticated: #112016834 X-Provags-ID: V01U2FsdGVkX18xDskWCT8x1gh+LGKXvdqwZx0ouYtub+Fu3P5lx1 oVv4EO5JouUh/k From: Matthew Bowman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 May 2011 11:58:40 +0300 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Bridging + VLANS 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, 21 May 2011 08:58:44 -0000 I'm drafting a plan for a N+1 redundant network and I have hit a dead = end. I have two Soekris NET5501 boards that I wish to deploy FreeBSD = (NanoBSD) on and I'm trying to make sure I can setup everything before I = move ahead. Here's my network design: = http://imageshack.us/photo/my-images/191/networkc.png/ I have an uplink to my ISP on a 2 IP /30 network (1.1.1.0/30 in the = diagram) along with a public routable /28 network (10.0.0.0/28 in the = diagram). I need to bridge the /28 network into the core on a VLAN so I = can easily add hosts deep in the network with IPs from the /28 network. = The trouble I'm having is setting up RSTP on the lagg0.4 interfaces. = =46rom what I've read you have to use MSTP for VLAN interfaces but I = can't find anything about FreeBSD implementing MSTP. RSTP on vr0 is not = a problem but I get "invalid argument" with ifconfig bridge0 stp lagg0.4 = since it's a VLAN interface. Am I overcomplicating this or am I just out of luck on this one? Thanks in advance, Matthew= From owner-freebsd-net@FreeBSD.ORG Sat May 21 18:51:51 2011 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 1BA49106566B for ; Sat, 21 May 2011 18:51:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E85D314F814; Sat, 21 May 2011 18:51:49 +0000 (UTC) Message-ID: <4DD809C2.8080704@FreeBSD.org> Date: Sat, 21 May 2011 11:51:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matthew Bowman References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Bridging + VLANS 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, 21 May 2011 18:51:51 -0000 On 05/21/2011 01:58, Matthew Bowman wrote: > I have an uplink to my ISP on a 2 IP /30 network (1.1.1.0/30 in the diagram) No help for your actual problem, sorry. I just wanted to point out that 1/8 has been assigned by IANA to APNIC, so it should not be used as a substitute for RFC 1918 space. I'm assuming that you're just using it as a placeholder for the real assignment, however I would argue that even that is a bad idea since at minimum it's a bad example that others may draw poor conclusions from. Yours in pedantry, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Sat May 21 22:38:19 2011 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 CF5EC1065672; Sat, 21 May 2011 22:38:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A76358FC12; Sat, 21 May 2011 22:38:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4LMcJtK053050; Sat, 21 May 2011 22:38:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4LMcJij053046; Sat, 21 May 2011 22:38:19 GMT (envelope-from linimon) Date: Sat, 21 May 2011 22:38:19 GMT Message-Id: <201105212238.p4LMcJij053046@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157182: [lagg] lagg interface not working together with epair interface on bridge 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, 21 May 2011 22:38:19 -0000 Old Synopsis: lagg interface not working together with epair interface on bridge New Synopsis: [lagg] lagg interface not working together with epair interface on bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 21 22:36:21 UTC 2011 Responsible-Changed-Why: Fix up formatting and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=157182 From owner-freebsd-net@FreeBSD.ORG Sat May 21 22:48:49 2011 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 4CED6106566B; Sat, 21 May 2011 22:48:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 250C48FC12; Sat, 21 May 2011 22:48:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4LMmn0d064279; Sat, 21 May 2011 22:48:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4LMmmuk064275; Sat, 21 May 2011 22:48:49 GMT (envelope-from linimon) Date: Sat, 21 May 2011 22:48:49 GMT Message-Id: <201105212248.p4LMmmuk064275@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157209: [ip6] [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) 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, 21 May 2011 22:48:49 -0000 Old Synopsis: [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) New Synopsis: [ip6] [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 21 22:48:21 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157209