From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 09:13:09 2010 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 F1E421065670; Sun, 20 Jun 2010 09:13:09 +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 C990A8FC0A; Sun, 20 Jun 2010 09:13: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 o5K9D90L031522; Sun, 20 Jun 2010 09:13:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5K9D9bd031518; Sun, 20 Jun 2010 09:13:09 GMT (envelope-from linimon) Date: Sun, 20 Jun 2010 09:13:09 GMT Message-Id: <201006200913.o5K9D9bd031518@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148004: [em] Inconsistent networking with em driver on FreeBSD 8.0-p2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 09:13:10 -0000 Old Synopsis: Inconsistent networking with em driver on FreeBSD 8.0-p2 New Synopsis: [em] Inconsistent networking with em driver on FreeBSD 8.0-p2 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 20 09:12:56 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148004 From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 03:26:08 2010 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 2707C106564A; Mon, 21 Jun 2010 03:26:08 +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 F24428FC12; Mon, 21 Jun 2010 03:26:07 +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 o5L3Q7ie067349; Mon, 21 Jun 2010 03:26:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5L3Q7vG067345; Mon, 21 Jun 2010 03:26:07 GMT (envelope-from linimon) Date: Mon, 21 Jun 2010 03:26:07 GMT Message-Id: <201006210326.o5L3Q7vG067345@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147989: [em] em Receive errors / CRC Errors / Alignment Errors 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, 21 Jun 2010 03:26:08 -0000 Old Synopsis: em Receive errors / CRC Errors / Alignment Errors New Synopsis: [em] em Receive errors / CRC Errors / Alignment Errors Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 21 03:25:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147989 From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 04:15:52 2010 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 42C981065670; Mon, 21 Jun 2010 04:15:52 +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 1A46D8FC14; Mon, 21 Jun 2010 04:15:52 +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 o5L4FpC0010900; Mon, 21 Jun 2010 04:15:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5L4FpkA010896; Mon, 21 Jun 2010 04:15:51 GMT (envelope-from linimon) Date: Mon, 21 Jun 2010 04:15:51 GMT Message-Id: <201006210415.o5L4FpkA010896@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148013: [rl] [patch] add WoL support to rl(4) 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, 21 Jun 2010 04:15:52 -0000 Old Synopsis: [patch] add WoL support to rl(4) New Synopsis: [rl] [patch] add WoL support to rl(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 21 04:15:37 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148013 From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 11:07:00 2010 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 A24CE106564A for ; Mon, 21 Jun 2010 11:07:00 +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 8998E8FC19 for ; Mon, 21 Jun 2010 11:07:00 +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 o5LB70ka098323 for ; Mon, 21 Jun 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5LB6xWp098321 for freebsd-net@FreeBSD.org; Mon, 21 Jun 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Jun 2010 11:06:59 GMT Message-Id: <201006211106.o5LB6xWp098321@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, 21 Jun 2010 11:07:00 -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/148013 net [rl] [patch] add WoL support to rl(4) o kern/148004 net [em] Inconsistent networking with em driver on FreeBSD o kern/147989 net [em] em Receive errors / CRC Errors / Alignment Errors o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147824 net [msk]: watchdog timeouts & Tx descriptor error o kern/147684 net [nfe] nVidia MCP55 driver blocks IPMI LAN on load o kern/147352 net [netinet] [patch] replace printf() with log() for "Lim o kern/147245 net [dummynet] dummynet skip traffic over configured limit o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re 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/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system 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 kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun 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/143595 net [wpi] [panic] Creating virtual interface over wpi0 in 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/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir 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/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon 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 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu 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/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on 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/140051 net [bce] [arp] ARP not sent through Bridge Firewall with 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 o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) 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/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/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/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl 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/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin 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/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/137317 net [tcp] logs full of syncache problems 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/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho 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/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se 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/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) 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/133328 net [bge] [panic] Kernel panics with Windows7 client 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/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I 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/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) 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 kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw 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 o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa 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/129352 net [xl] [patch] xl0 watchdog timeout 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 kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO 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/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t 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/127102 net [wpi] Intel 3945ABG low throughput 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/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card 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/125502 net [ral] ifconfig ral0 scan produces no output unless in 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/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets 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. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported 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/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq 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 o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to 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/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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/121080 net [bge] IPv6 NUD problem on multi address config on bge0 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/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 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 a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. 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 kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 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/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] 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 kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty 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/106243 net [nve] double fault panic in if_nve.c on high loads 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/105348 net [ath] ath device stopps TX 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/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve 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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces 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 o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre 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 s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/81095 net IPsec connection stops working if associated network i o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r 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 p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) 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 f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern 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 f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 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/35442 net [sis] [patch] Problem transmitting runts in if_sis dri 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 444 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 14:40:03 2010 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 E580A1065670 for ; Mon, 21 Jun 2010 14:40:03 +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 D4E298FC24 for ; Mon, 21 Jun 2010 14:40:03 +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 o5LEe3m1084034 for ; Mon, 21 Jun 2010 14:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5LEe3Ct084033; Mon, 21 Jun 2010 14:40:03 GMT (envelope-from gnats) Date: Mon, 21 Jun 2010 14:40:03 GMT Message-Id: <201006211440.o5LEe3Ct084033@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:40:04 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Alex Kozlov To: Rui Paulo , bug-followup@FreeBSD.org, vince@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Mon, 21 Jun 2010 17:38:59 +0300 On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: > > I confirm this. Atheros 9280, work fine with 8.0R usb stick, > > timeout after few pings with 8.1-BETA1. > > I can try to find a particular commit, that causes this > > regression, if its help. > Yes, please. Sorry for the delay. I think that the culprit is r203959. -- Adios From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:05:23 2010 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 945391065672 for ; Mon, 21 Jun 2010 16:05:23 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFB58FC08 for ; Mon, 21 Jun 2010 16:05:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OQjUu-00049u-EO for freebsd-net@freebsd.org; Mon, 21 Jun 2010 18:05:20 +0200 Received: from firewall.andxor.it ([195.223.2.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2010 18:05:20 +0200 Received: from lapo by firewall.andxor.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2010 18:05:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Lapo Luchini Date: Mon, 21 Jun 2010 18:05:12 +0200 Lines: 16 Message-ID: <4C1F8DB8.6080804@lapo.it> References: <4B98CF44.2080605@keff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: firewall.andxor.it User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100219 SeaMonkey/2.0.3 In-Reply-To: <4B98CF44.2080605@keff.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=C8F252FB Subject: Re: 6to4/stf relay 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, 21 Jun 2010 16:05:23 -0000 Sebastian Hyrwall wrote: > stf0 in FreeBSD has a non-changeable mtu of 1280. If you're setting up a > 6to4-relay using FreeBSD doesn't this break stuff for other end-hosts > using your relay? Linux for example has a default MTU of 1480. A lower-than-strictly-necessary MTU might be less efficient, but for sure doesn't break anything. OTOH 20 bytes less than the underlying used IPv4 connection (which is known at the time of creation) should be a better default (?). -- Lapo Luchini - http://lapo.it/ “The Magic Words are Squeamish Ossifrage” (Ron Rivest, RSA-129 challenge, 1977) From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:40:03 2010 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 1E53A1065672 for ; Mon, 21 Jun 2010 16:40:03 +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 E7B8E8FC1D for ; Mon, 21 Jun 2010 16:40:02 +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 o5LGe2qd087394 for ; Mon, 21 Jun 2010 16:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5LGe2It087393; Mon, 21 Jun 2010 16:40:02 GMT (envelope-from gnats) Date: Mon, 21 Jun 2010 16:40:02 GMT Message-Id: <201006211640.o5LGe2It087393@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:40:03 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Rui Paulo To: Alex Kozlov Cc: bug-followup@FreeBSD.org, vince@unsane.co.uk Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Mon, 21 Jun 2010 17:30:30 +0100 On 21 Jun 2010, at 15:38, Alex Kozlov wrote: > On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: >>> I confirm this. Atheros 9280, work fine with 8.0R usb stick, >>> timeout after few pings with 8.1-BETA1. >>> I can try to find a particular commit, that causes this >>> regression, if its help. >> Yes, please. > Sorry for the delay. I think that the culprit is r203959. Please try this patch. Index: ar9280_attach.c =================================================================== --- ar9280_attach.c (revision 209351) +++ ar9280_attach.c (working copy) @@ -346,7 +346,7 @@ regWrites = ath_hal_ini_write(ah, &AH5212(ah)->ah_ini_common, 1, regWrites); - if (AR_SREV_MERLIN_20(ah) && IS_5GHZ_FAST_CLOCK_EN(ah, chan)) { + if (AR_SREV_MERLIN_20_OR_LATER(ah) && IS_5GHZ_FAST_CLOCK_EN(ah, chan)) { /* 5GHz channels w/ Fast Clock use different modal values */ regWrites = ath_hal_ini_write(ah, &AH9280(ah)->ah_ini_xmodes, modesIndex, regWrites); Index: ar5416_reset.c =================================================================== --- ar5416_reset.c (revision 209351) +++ ar5416_reset.c (working copy) @@ -636,7 +636,8 @@ /* treat channel B as channel G , no B mode suport in owl */ rfMode = IEEE80211_IS_CHAN_CCK(chan) ? AR_PHY_MODE_DYNAMIC : AR_PHY_MODE_OFDM; - if (AR_SREV_MERLIN_20(ah) && IS_5GHZ_FAST_CLOCK_EN(ah, chan)) { + if (AR_SREV_MERLIN_20_OR_LATER(ah) && + IS_5GHZ_FAST_CLOCK_EN(ah, chan)) { /* phy mode bits for 5GHz channels require Fast Clock */ rfMode |= AR_PHY_MODE_DYNAMIC | AR_PHY_MODE_DYN_CCK_DISABLE; @@ -1126,7 +1127,7 @@ { uint32_t pll; - if (AR_SREV_MERLIN_20(ah) && + if (AR_SREV_MERLIN_20_OR_LATER(ah) && chan != AH_NULL && IEEE80211_IS_CHAN_5GHZ(chan)) { /* * PLL WAR for Merlin 2.0/2.1 Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 19:13:36 2010 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 0480C106566B; Mon, 21 Jun 2010 19:13:36 +0000 (UTC) (envelope-from anjali@juniper.net) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2D18FC16; Mon, 21 Jun 2010 19:13:35 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTB+53k3cW19CvX/GCWsv81bgZ2zFnEld@postini.com; Mon, 21 Jun 2010 12:13:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 21 Jun 2010 12:09:45 -0700 From: Anjali Kulkarni To: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" Date: Mon, 21 Jun 2010 12:09:45 -0700 Thread-Topic: About Marvell Yukon drivers skgeinit and sky2 Thread-Index: AQHLEXN9uySAKNFp702lKoWf1//FKg== Message-ID: <50B3A5560BA4D74CADEC55A48B4641B23D5AD26EBF@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Anjali Kulkarni Subject: About Marvell Yukon drivers skgeinit and sky2 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, 21 Jun 2010 19:13:36 -0000 Hi, As I understand, there are 2 flavors of the Marvel Yukon driver. One is for= Yukon-I devices, and is called skgeinit, and other is for Yukon-II devices= and called sky2 driver.=20 Looking at the release notes for 7.0, it looks like this driver which was i= n sys/dev/yukon, is now present as the msk(4) driver in sys/dev/msk and sys= /dev/sk?. I do not see a yukon under dev anymore. I see only 2 files in the= msk directory, is it really moved here?=20 Is the Yukon-II sky2 driver support present in Freebsd 6.1? How easy would = it to backport this to 6.1? If yes, then is there a way to disable the skgeinit(which seems to be the d= efault) and enable the sky2 driver? Anjali From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:18:18 2010 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 D5F05106566C; Tue, 22 Jun 2010 09:18:18 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-gw0-f68.google.com (mail-gw0-f68.google.com [74.125.83.68]) by mx1.freebsd.org (Postfix) with ESMTP id 79EB88FC1D; Tue, 22 Jun 2010 09:18:18 +0000 (UTC) Received: by gwj16 with SMTP id 16so1290908gwj.7 for ; Tue, 22 Jun 2010 02:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=azxVqYAwS05Zl3MpODQ0JbCqU1b3fNxVq2uOIUnct8E=; b=l5iTjgJZThJUS8cPP8nmOyl12yU+3/EO7KJLFy6UDbuvONljptu3EZS5RcJ0QqsjLJ WSAsgaFHq1fBAtCTwYUbXYnXoQfOwwZf2Lvao5r62nzytophTOdJIgxx8BEMVnrKy8Jq +4zRM6iLc69wk+j+cks7JNiaCnGE6ChG60tgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Op4IAblxqPKDVPv9MZD9+Obu1vGzWErf1d31eJwQsmvHbIRULWiSXPRQC30Z4ye8hU zsnyNFhUI9mqZr/1/zdGKcbRviMzDS572/WnAOWwiEHcxMWJBn8RTC52PgF9fc3GFwM+ vh1t1ZLVpjlsE2REq8W5ySJ/sQR46XLCcuuKY= Received: by 10.150.150.3 with SMTP id x3mr5739124ybd.435.1277198297599; Tue, 22 Jun 2010 02:18:17 -0700 (PDT) Received: from [192.168.0.135] ([186.137.80.175]) by mx.google.com with ESMTPS id v21sm5859867ybk.25.2010.06.22.02.18.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 02:18:16 -0700 (PDT) Sender: Fernando Gont Message-ID: <4C207FD4.2060300@gont.com.ar> Date: Tue, 22 Jun 2010 06:18:12 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andre Oppermann Subject: Extended SYN cookies 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, 22 Jun 2010 09:18:18 -0000 Hi, folks, I have a few questions wrt the FreeBSD TCP extended syncookies. I'm quoting the explanation in the code: > * Timestamp we send: > * 31|................................|0 > * DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 > * D = MD5 Digest (third dword) (only as filler) What about the second MD5 dword? -- It doesn't seem to be used anywhere... > * S = Requested send window scale > * R = Requested receive window scale What's this snd_window rcv_window thing? I mean, why do you need to include in the cookie the TCP wscale option *you* adverised? Isn't it expected to be the same in all cases? > * A = SACK allowed > * 5 = TCP-MD5 enabled (not implemented yet) > * XORed with MD5 Digest (forth dword) Any reason for XOR'ing the timestamp with the MD5 Digest? > * The timestamp isn't cryptographically secure and doesn't need to be. What's the motivator of this comment? MD5 itself (used here) being cryptographically weak, or what? > * Some problems with SYN cookies remain however: > * Consider the problem of a recreated (and retransmitted) cookie. If the > * original SYN was accepted, the connection is established. The second > * SYN is inflight, and if it arrives with an ISN that falls within the > * receive window, the connection is killed. What do you mean by "recreated", specifically? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:19:08 2010 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 A9156106567C for ; Tue, 22 Jun 2010 11:19:08 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out9.libero.it (cp-out9.libero.it [212.52.84.109]) by mx1.freebsd.org (Postfix) with ESMTP id 683F08FC1C for ; Tue, 22 Jun 2010 11:19:08 +0000 (UTC) Received: from soth.ventu (151.51.48.186) by cp-out9.libero.it (8.5.107) id 4C1F3FC9001E73C1 for freebsd-net@freebsd.org; Tue, 22 Jun 2010 13:19:03 +0200 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.3) with ESMTP id o5MBIwjF088228 for ; Tue, 22 Jun 2010 13:18:58 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <4C209C22.7080900@netfence.it> Date: Tue, 22 Jun 2010 13:18:58 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.1.9) Gecko/20100402 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Atheros ale problems 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, 22 Jun 2010 11:19:08 -0000 Hello. I'm having problems with 8.0/amd64 with the following card: ale0@pci0:1:0:0: class=0x020000 card=0x83041043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet This is connected to a 100Mb/s Full Duplex switch with no fancy features. Sometimes, while connected through ssh to this box, I get kicked out with: Disconnecting: Corrupted MAC on input. or: Disconnecting: Bad packet length 1686869659. At the same time on the server's log and console, I see: kernel: ale0: watchdog timeout -- resetting kernel: ale0: could not disable Tx/Rx MAC(0x00000008)! kernel: ale0: link state changed to DOWN kernel: ale0: link state changed to UP I'm setting up this box, so I can't speak of other protocols/applications yet. I saw some threads about this dating back to 2008 and related to EEEPCs, but this was supposed to be fixed. Any help? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 13:20:28 2010 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 A2D94106566C for ; Tue, 22 Jun 2010 13:20:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 14E598FC19 for ; Tue, 22 Jun 2010 13:20:27 +0000 (UTC) Received: (qmail 23668 invoked from network); 22 Jun 2010 11:59:40 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2010 11:59:40 -0000 Message-ID: <4C20B89B.4050101@freebsd.org> Date: Tue, 22 Jun 2010 15:20:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Fernando Gont References: <4C207FD4.2060300@gont.com.ar> In-Reply-To: <4C207FD4.2060300@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Extended SYN cookies 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, 22 Jun 2010 13:20:28 -0000 On 22.06.2010 11:18, Fernando Gont wrote: > Hi, folks, > > I have a few questions wrt the FreeBSD TCP extended syncookies. I'm > quoting the explanation in the code: > > >> * Timestamp we send: >> * 31|................................|0 >> * DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 >> * D = MD5 Digest (third dword) (only as filler) > > What about the second MD5 dword? -- It doesn't seem to be used anywhere... From looking at the code it indeed isn't used anywhere. I don't remember any specific reason and there probably isn't any. Each dword containing the MD5 output is as good as any other provided it isn't used twice. >> * S = Requested send window scale >> * R = Requested receive window scale > > What's this snd_window rcv_window thing? I mean, why do you need to > include in the cookie the TCP wscale option *you* adverised? Isn't it > expected to be the same in all cases? Most of the time yes. If the application changed the socket buffer size on the accept socket the window may be scaled differently. You are right though, the send window scale stays the same for a given socket. Unless the application changes the socket buffer size while there are outstanding SYN-ACK's around. It's a race condition. Better be on the safe side and include it. It also makes the implementation a tiny bit simpler as we get the information directly from the cookie instead of fetching it from somewhere else. >> * A = SACK allowed >> * 5 = TCP-MD5 enabled (not implemented yet) >> * XORed with MD5 Digest (forth dword) > > Any reason for XOR'ing the timestamp with the MD5 Digest? To prevent direct manipulation of the values we put into the cookie and more importantly to seed/randomize the lower bits of the timestamp. Otherwise they would be very predictable. >> * The timestamp isn't cryptographically secure and doesn't need to be. > > What's the motivator of this comment? MD5 itself (used here) being > cryptographically weak, or what? A (too) short sentence about a couple of things: a) MD5 is rather weak these days and can be broken with reasonable effort. It is fast though. Preventing someone from breaking it for a few minutes is sufficient for SYN cookies to work properly. The secret will be changed every minute or so. b) The values that are XOR'ed in the timestamp are not cryptographically secure. With a little guesswork you may be able to reverse a few bits and gain some information. However this is all TCP session information and you'll know it anyway. It's about making it hard to change the parameters we will use for the new session when the ACK returns. >> * Some problems with SYN cookies remain however: >> * Consider the problem of a recreated (and retransmitted) cookie. If the >> * original SYN was accepted, the connection is established. The second >> * SYN is inflight, and if it arrives with an ISN that falls within the >> * receive window, the connection is killed. > > What do you mean by "recreated", specifically? Duplicated in the network, by accident or malicious. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 13:40:04 2010 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 330311065676 for ; Tue, 22 Jun 2010 13:40:04 +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 229228FC17 for ; Tue, 22 Jun 2010 13:40:04 +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 o5MDe4iD006293 for ; Tue, 22 Jun 2010 13:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5MDe3jf006292; Tue, 22 Jun 2010 13:40:04 GMT (envelope-from gnats) Date: Tue, 22 Jun 2010 13:40:04 GMT Message-Id: <201006221340.o5MDe3jf006292@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 13:40:04 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Alex Kozlov To: Rui Paulo , bug-followup@FreeBSD.org, vince@unsane.co.uk, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Tue, 22 Jun 2010 16:35:59 +0300 On Mon, Jun 21, 2010 at 05:30:30PM +0100, Rui Paulo wrote: > On 21 Jun 2010, at 15:38, Alex Kozlov wrote: > > On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: > >>> I confirm this. Atheros 9280, work fine with 8.0R usb stick, > >>> timeout after few pings with 8.1-BETA1. > >>> I can try to find a particular commit, that causes this > >>> regression, if its help. > >> Yes, please. > > Sorry for the delay. I think that the culprit is r203959. > Please try this patch. Patch does not help, but if I change line in AR_SREV_MERLIN_20 from AH_PRIVATE((_ah))->ah_macRev == AR_XSREV_REVISION_MERLIN_20 to AH_PRIVATE((_ah))->ah_macRev >= AR_XSREV_REVISION_MERLIN_20 net works again. -- Adios From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 14:18:00 2010 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 AF637106564A for ; Tue, 22 Jun 2010 14:18:00 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2FC8FC1C for ; Tue, 22 Jun 2010 14:18:00 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id B09C922887 for ; Tue, 22 Jun 2010 15:59:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ovvZKr1ocYt for ; Tue, 22 Jun 2010 15:59:50 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 8D7EF22910; Tue, 22 Jun 2010 15:59:50 +0200 (CEST) To: X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 15:59:50 +0200 From: Message-ID: <87260c422232fa7409a4b374341dd106@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: vpn trouble 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, 22 Jun 2010 14:18:00 -0000 Hi, I try to configure VPN over my server and my client Sheme is like this 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 When I try to ping 10.10.1.90, all packets are lost. What can I change to run it? Thanks This is my setting: # setkey -DP 10.10.1.90[any] 78.x.x.x[any] any in ipsec esp/tunnel/95.x.x.x-78.x.x.x/require created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 2010 lifetime: 0(s) validtime: 0(s) spid=16461 seq=1 pid=83142 refcnt=1 78.x.x.x[any] 10.10.1.90[any] any out ipsec esp/tunnel/78.x.x.x-95.x.x.x/require created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 2010 lifetime: 0(s) validtime: 0(s) spid=16460 seq=0 pid=83142 refcnt=1 #cat racoon.conf path include "/usr/local/etc/racoon"; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; log debug; padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp 78.x.x.x [500]; } timer { counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. phase1 30 sec; phase2 15 sec; } remote 95.x.x.x { exchange_mode main, aggressive; # For Firewall-1 Aggressive mode lifetime time 8 hour; # sec,min,hour proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group 2 ; lifetime time 28800 sec; } } sainfo anonymous { pfs_group 2; lifetime time 3600 sec; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate ; } Racoon log: Foreground mode. 2010-06-22 15:52:50: INFO: @(#)ipsec-tools 0.7.3 (http://ipsec-tools.sourceforge.net) 2010-06-22 15:52:50: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/) 2010-06-22 15:52:50: INFO: Reading configuration from "/usr/local/etc/racoon/racoon.conf" 2010-06-22 15:52:50: DEBUG: hmac(modp1024) 2010-06-22 15:52:50: DEBUG: compression algorithm can not be checked because sadb message doesn't support it. 2010-06-22 15:52:50: DEBUG: getsainfo params: loc='ANONYMOUS', rmt='ANONYMOUS', peer='NULL', id=0 2010-06-22 15:52:50: DEBUG: getsainfo pass #2 2010-06-22 15:52:50: INFO: 78.x.x.x[500] used as isakmp port (fd=4) 2010-06-22 15:52:50: DEBUG: pk_recv: retry[0] recv() 2010-06-22 15:52:50: DEBUG: get pfkey X_SPDDUMP message 2010-06-22 15:52:50: DEBUG: pk_recv: retry[0] recv() 2010-06-22 15:52:50: DEBUG: get pfkey X_SPDDUMP message 2010-06-22 15:52:50: DEBUG: sub:0x7fffffffe480: 78.x.x.x/32[0] 10.10.1.90/32[0] proto=any dir=out 2010-06-22 15:52:50: DEBUG: db :0x5a8610: 10.10.1.90/32[0] 78.x.x.x/32[0] proto=any dir=in 2010-06-22 15:53:32: DEBUG: caught rtm:14, need update interface address list 2010-06-22 15:53:47: DEBUG: pk_recv: retry[0] recv() 2010-06-22 15:53:47: DEBUG: get pfkey ACQUIRE message 2010-06-22 15:53:47: DEBUG: suitable outbound SP found: 78.x.x.x/32[0] 10.10.1.90/32[0] proto=any dir=out. 2010-06-22 15:53:47: DEBUG: sub:0x7fffffffe430: 10.10.1.90/32[0] 78.x.x.x/32[0] proto=any dir=in 2010-06-22 15:53:47: DEBUG: db :0x5a8610: 10.10.1.90/32[0] 78.x.x.x/32[0] proto=any dir=in 2010-06-22 15:53:47: DEBUG: suitable inbound SP found: 10.10.1.90/32[0] 78.x.x.x/32[0] proto=any dir=in. 2010-06-22 15:53:47: DEBUG: new acquire 78.x.x.x/32[0] 10.10.1.90/32[0] proto=any dir=out 2010-06-22 15:53:47: DEBUG: configuration found for 95.x.x.x. 2010-06-22 15:53:47: DEBUG: getsainfo params: loc='78.x.x.x', rmt='10.10.1.90', peer='NULL', id=0 2010-06-22 15:53:47: DEBUG: getsainfo pass #2 2010-06-22 15:53:47: DEBUG: evaluating sainfo: loc='ANONYMOUS', rmt='ANONYMOUS', peer='ANY', id=0 2010-06-22 15:53:47: DEBUG: selected sainfo: loc='ANONYMOUS', rmt='ANONYMOUS', peer='ANY', id=0 2010-06-22 15:53:47: DEBUG: (proto_id=ESP spisize=4 spi=00000000 spi_p=00000000 encmode=Tunnel reqid=0:0) 2010-06-22 15:53:47: DEBUG: (trns_id=3DES encklen=0 authtype=hmac-md5) 2010-06-22 15:53:47: DEBUG: in post_acquire 2010-06-22 15:53:47: DEBUG: configuration found for 95.x.x.x. 2010-06-22 15:53:47: INFO: IPsec-SA request for 95.x.x.x queued due to no phase1 found. 2010-06-22 15:53:47: DEBUG: === 2010-06-22 15:53:47: INFO: initiate new phase 1 negotiation: 78.x.x.x[500]<=>95.x.x.x[500] 2010-06-22 15:53:47: INFO: begin Identity Protection mode. 2010-06-22 15:53:47: DEBUG: new cookie: 6fa45a7481c1aec5 2010-06-22 15:53:47: DEBUG: add payload of len 48, next type 13 2010-06-22 15:53:47: DEBUG: add payload of len 16, next type 0 2010-06-22 15:53:47: DEBUG: 100 bytes from 78.x.x.x[500] to 95.x.x.x[500] 2010-06-22 15:53:47: DEBUG: sockname 78.x.x.x[500] 2010-06-22 15:53:47: DEBUG: send packet from 78.x.x.x[500] 2010-06-22 15:53:47: DEBUG: send packet to 95.x.x.x[500] 2010-06-22 15:53:47: DEBUG: 1 times of 100 bytes message will be sent to 95.x.x.x[500] 2010-06-22 15:53:47: DEBUG: 6fa45a74 81c1aec5 00000000 00000000 01100200 00000000 00000064 0d000034 00000001 00000001 00000028 01010001 00000020 01010000 800b0001 800c7080 80010005 80030001 80020001 80040002 00000014 afcad713 68a1f1c9 6b8696fc 77570100 2010-06-22 15:53:47: DEBUG: resend phase1 packet 6fa45a7481c1aec5:0000000000000000 2010-06-22 15:54:07: DEBUG: 100 bytes from 78.x.x.x[500] to 95.x.x.x[500] 2010-06-22 15:54:07: DEBUG: sockname 78.x.x.x[500] 2010-06-22 15:54:07: DEBUG: send packet from 78.x.x.x[500] 2010-06-22 15:54:07: DEBUG: send packet to 95.x.x.x[500] 2010-06-22 15:54:07: DEBUG: 1 times of 100 bytes message will be sent to 95.x.x.x[500] 2010-06-22 15:54:07: DEBUG: 6fa45a74 81c1aec5 00000000 00000000 01100200 00000000 00000064 0d000034 00000001 00000001 00000028 01010001 00000020 01010000 800b0001 800c7080 80010005 80030001 80020001 80040002 00000014 afcad713 68a1f1c9 6b8696fc 77570100 And tcpdump #tcpdump -i bce1 host 95.x.x.x 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I ident 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I ident 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I ident From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 14:35:48 2010 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 5410F106566C for ; Tue, 22 Jun 2010 14:35:48 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB768FC12 for ; Tue, 22 Jun 2010 14:35:45 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id E0F302798BC; Tue, 22 Jun 2010 16:35:43 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id C14621702D; Tue, 22 Jun 2010 16:35:43 +0200 (CEST) Date: Tue, 22 Jun 2010 16:35:43 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100622143543.GA72020@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87260c422232fa7409a4b374341dd106@ewipo.pl> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 14:35:48 -0000 On Tue, Jun 22, 2010 at 03:59:50PM +0200, ralf@dzie-ciuch.pl wrote: > > Hi, Hi. > I try to configure VPN over my server and my client [....] According to your racoon's debug (and confirmed by tcpdump), racoon tries to initiate a phase1 negociation, but never gets any answer from peer, so you may start by checking peer's logs, and/or compare both configurations. [....] > exchange_mode main, aggressive; # For Firewall-1 Aggressive mode If that comment in your racoon.conf is right, this is probably your (first ?) configuration issue: as initiator, racoon will use the first listed mode, so it will try a main mode negociation here. Note that, if you have complete access to configurations, aggressive mode has a lower security level than main mode, so should be avoided when main mode can also be used ! Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:12:07 2010 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 2F783106566B for ; Tue, 22 Jun 2010 15:12:07 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id E40848FC1C for ; Tue, 22 Jun 2010 15:12:06 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id ACE272291B; Tue, 22 Jun 2010 17:11:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi72rnPnkfG1; Tue, 22 Jun 2010 17:11:58 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 2236722919; Tue, 22 Jun 2010 17:11:58 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 17:11:58 +0200 From: In-Reply-To: <20100622143543.GA72020@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> Message-ID: X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 15:12:07 -0000 Hi, Thanks for help I new on it and I never use VPN, only I have to do it. Please tell me how to check peer's log? I dont know how to check it? Have I change my racoon.conf exchange to aggressive, main? I forgot send last time - on the other side is cisco router, maybe this is important Regards Ralf On Tue, 22 Jun 2010 16:35:43 +0200, VANHULLEBUS Yvan wrote: > On Tue, Jun 22, 2010 at 03:59:50PM +0200, ralf@dzie-ciuch.pl wrote: >> >> Hi, > > Hi. > > >> I try to configure VPN over my server and my client > [....] > > According to your racoon's debug (and confirmed by tcpdump), racoon > tries to initiate a phase1 negociation, but never gets any answer from > peer, so you may start by checking peer's logs, and/or compare both > configurations. > > [....] >> exchange_mode main, aggressive; # For Firewall-1 Aggressive mode > > If that comment in your racoon.conf is right, this is probably your > (first ?) configuration issue: as initiator, racoon will use the first > listed mode, so it will try a main mode negociation here. > > Note that, if you have complete access to configurations, aggressive > mode has a lower security level than main mode, so should be avoided > when main mode can also be used ! > > > Yvan. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:35:44 2010 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 95804106564A for ; Tue, 22 Jun 2010 15:35:44 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5AE8FC14 for ; Tue, 22 Jun 2010 15:35:44 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 3FB052798BC; Tue, 22 Jun 2010 17:35:42 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 2CF8C1702D; Tue, 22 Jun 2010 17:35:42 +0200 (CEST) Date: Tue, 22 Jun 2010 17:35:42 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100622153541.GA72211@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 15:35:44 -0000 On Tue, Jun 22, 2010 at 05:11:58PM +0200, ralf@dzie-ciuch.pl wrote: > > Hi, > > Thanks for help > > I new on it and I never use VPN, only I have to do it. > Please tell me how to check peer's log? I dont know how to check it? If that's really a firewall-1 as said in comments, I just don't know.... > Have I change my racoon.conf exchange to aggressive, main? To just have it work, looks like you should just set "aggressive" (stilla according to the comment in your configuration !!!). To have a correct setup with a correct security level, you should change peer's configuration to use main mode, and just keep "main" as exchange_mode in racoon's conf ! > I forgot send last time - on the other side is cisco router, maybe this is > important Ok, so this is not a firewall-1, but I still don't know how to get the configuration or how to get logs...... Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:53:01 2010 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 362D2106566B; Tue, 22 Jun 2010 15:53:01 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id ACA558FC1B; Tue, 22 Jun 2010 15:53:00 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 7219B22910; Tue, 22 Jun 2010 17:52:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTPpXc1h92wp; Tue, 22 Jun 2010 17:52:51 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id A4B89228F9; Tue, 22 Jun 2010 17:52:51 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 17:52:51 +0200 From: In-Reply-To: <20100622153541.GA72211@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> Message-ID: <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 15:53:01 -0000 Hmmm, aggressive mode wasn't help :( Still I got only negotiation, so I try to send packets but I don't receive it at all. On my server 78.x.x.x I got ipfw allow all from any to any. On the other side 95.x.x.x they tell me that they do it everything right - only I can't connect :( Maybe I don't set route correctly? Is this mean that I don't receive password from other side? ERROR: phase1 negotiation failed due to time up. 5d300bcf894a18f5:0000000000000000 Best regards Ralf On Tue, 22 Jun 2010 17:35:42 +0200, VANHULLEBUS Yvan wrote: > On Tue, Jun 22, 2010 at 05:11:58PM +0200, ralf@dzie-ciuch.pl wrote: >> >> Hi, >> >> Thanks for help >> >> I new on it and I never use VPN, only I have to do it. >> Please tell me how to check peer's log? I dont know how to check it? > > If that's really a firewall-1 as said in comments, I just don't > know.... > > >> Have I change my racoon.conf exchange to aggressive, main? > > To just have it work, looks like you should just set "aggressive" > (stilla according to the comment in your configuration !!!). > > To have a correct setup with a correct security level, you should > change peer's configuration to use main mode, and just keep "main" as > exchange_mode in racoon's conf ! > > >> I forgot send last time - on the other side is cisco router, maybe this >> is >> important > > Ok, so this is not a firewall-1, but I still don't know how to get the > configuration or how to get logs...... > > > Yvan. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 16:30:08 2010 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 6FE761065674 for ; Tue, 22 Jun 2010 16:30: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 5EC7A8FC08 for ; Tue, 22 Jun 2010 16:30: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 o5MGU8jt050366 for ; Tue, 22 Jun 2010 16:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5MGU8vc050361; Tue, 22 Jun 2010 16:30:08 GMT (envelope-from gnats) Date: Tue, 22 Jun 2010 16:30:08 GMT Message-Id: <201006221630.o5MGU8vc050361@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:30:08 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Rui Paulo To: Alex Kozlov Cc: bug-followup@FreeBSD.org, vince@unsane.co.uk Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Tue, 22 Jun 2010 17:20:25 +0100 On 22 Jun 2010, at 14:35, Alex Kozlov wrote: > On Mon, Jun 21, 2010 at 05:30:30PM +0100, Rui Paulo wrote: >> On 21 Jun 2010, at 15:38, Alex Kozlov wrote: >>> On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: >>>>> I confirm this. Atheros 9280, work fine with 8.0R usb stick, >>>>> timeout after few pings with 8.1-BETA1. >>>>> I can try to find a particular commit, that causes this >>>>> regression, if its help. >>>> Yes, please. >>> Sorry for the delay. I think that the culprit is r203959. >> Please try this patch. > Patch does not help, but if I change line in AR_SREV_MERLIN_20 from > AH_PRIVATE((_ah))->ah_macRev =3D=3D AR_XSREV_REVISION_MERLIN_20 > to > AH_PRIVATE((_ah))->ah_macRev >=3D AR_XSREV_REVISION_MERLIN_20 > net works again. Yes, I know but that change is incorrect. I need to find the problem = where the check should be AR_SREV_MERLIN_20_OR_LATER() instead of = AR_SREV_MERLIN_20(). Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 17:19:49 2010 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 BD35B1065672 for ; Tue, 22 Jun 2010 17:19:49 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 76D128FC12 for ; Tue, 22 Jun 2010 17:19:49 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 295E6B0380CF for ; Tue, 22 Jun 2010 13:19:48 -0400 (EDT) Thread-Index: AcsSLx2KYW1ajgbpRpGmyIIBFZ+a7Q== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 13:19:46 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Tue, 22 Jun 2010 12:19:45 -0500 Date: Tue, 22 Jun 2010 12:19:45 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20100622171944.GQ2620@verio.net> Mail-Followup-To: freebsd-net@freebsd.org Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 References: <87260c422232fa7409a4b374341dd106@ewipo.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <87260c422232fa7409a4b374341dd106@ewipo.pl> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 22 Jun 2010 17:19:46.0797 (UTC) FILETIME=[1CE8C1D0:01CB122F] Subject: Re: vpn trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 17:19:49 -0000 ralf@dzie-ciuch.pl wrote: > > I try to configure VPN over my server and my client > > Sheme is like this > 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 Are you trying to set up IPSEC tunneling of networks behind these gateways, or are you only trying to secure traffic between the peers themselves? The fact that you don't receive any reply to your IKE packets would indicate something basic, like something is blocking traffic. > # setkey -DP > 10.10.1.90[any] 78.x.x.x[any] any > in ipsec > esp/tunnel/95.x.x.x-78.x.x.x/require > created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 2010 > lifetime: 0(s) validtime: 0(s) > spid=16461 seq=1 pid=83142 > refcnt=1 > 78.x.x.x[any] 10.10.1.90[any] any > out ipsec > esp/tunnel/78.x.x.x-95.x.x.x/require > created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 2010 > lifetime: 0(s) validtime: 0(s) > spid=16460 seq=0 pid=83142 > refcnt=1 Your IPSEC policy specifies "esp/tunnel" mode, but if you are not actually encapsulating traffic originating from somewhere else, you might do better to just use "transport" mode to encrypt without encapsulation. > And tcpdump > #tcpdump -i bce1 host 95.x.x.x > > > 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I > ident > 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I > ident > 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I > ident My first thought was that your IPSEC policy attempts to encrypt all traffic between you and your peers, but the IKE traffic is also traffic between you and your peers, so doesn't it lead to a policy loop of some sort? Will the IPSEC layer attempt to capture and encrypt the IKE packets? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 17:25:34 2010 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 354AB106564A for ; Tue, 22 Jun 2010 17:25:34 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from mail.suszko.eu (suszko.eu [174.136.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id F3BA98FC14 for ; Tue, 22 Jun 2010 17:25:33 +0000 (UTC) Received: from oxygen.suszko.eu (localhost [127.0.0.1]) by mail.suszko.eu (Postfix) with ESMTP id B61053F47D; Tue, 22 Jun 2010 17:00:34 +0000 (UTC) X-Virus-Scanned: amavisd-new using ClamaAV Received: from gda-arsenic (unknown [62.61.57.118]) by mail.suszko.eu (Postfix) with ESMTPSA id 94F6E3F474; Tue, 22 Jun 2010 17:00:33 +0000 (UTC) Date: Tue, 22 Jun 2010 19:08:19 +0200 From: Maciej Suszko To: freebsd-net@freebsd.org Message-ID: <20100622190819.270aaa74@gda-arsenic> In-Reply-To: <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Ify9D1+r8WdySmm7nNrXHH0"; protocol="application/pgp-signature" Subject: Re: vpn trouble 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, 22 Jun 2010 17:25:34 -0000 --Sig_/Ify9D1+r8WdySmm7nNrXHH0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable wrote: >=20 > Hmmm, aggressive mode wasn't help :( > Still I got only negotiation, so I try to send packets but I don't > receive it at all. >=20 > On my server 78.x.x.x I got ipfw allow all from any to any. > On the other side 95.x.x.x they tell me that they do it everything > right - only I can't connect :( >=20 > Maybe I don't set route correctly? >=20 > Is this mean that I don't receive password from other side? > ERROR: phase1 negotiation failed due to time up. > 5d300bcf894a18f5:0000000000000000 All the addresses you write about (despite of those x) and especially this 10.10.1.90 sound familiar (anyway it might be conicidence). I've got more than dozen working tunnels of this kind. You can try this way: Set up a gif tunnel in rc.conf: cloned_interfaces=3D"gif0" ifconfig_gif0=3D"tunnel 78.x.x.x 95.x.x.x" ifconfig_gif0_alias0=3D"10.20.0.1 netmask 255.255.255.255 10.10.1.90" 10.20.0.1 is your internal end of the tunnel, so use any address from beyond the net 10.10.1.90 is in. in racoon.conf something like this: remote 95.x.x.x [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 78.x.x.x; peers_identifier address 95.x.x.x; lifetime time 8 hour; passive off; proposal_check obey; generate_policy off; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group 2; } } sainfo (address 10.20.0.1/32 any address 10.10.1.90/32 any) { pfs_group 2; lifetime time 3600 sec; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate; } The other side needs to know you have 10.20.0.1 on your side of the tunnel - this way you should have working IPSEC bettween both 10. ends. --=20 regards, Maciej Suszko. --Sig_/Ify9D1+r8WdySmm7nNrXHH0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwg7gYACgkQCikUk0l7iGpjvgCffAp8jZSl0tP13FvNKw9dvDfI ToQAniSrDHXL4ZP8RPJsCKgEHIAKGAzC =AGWW -----END PGP SIGNATURE----- --Sig_/Ify9D1+r8WdySmm7nNrXHH0-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 17:33:55 2010 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 32D9C1065672 for ; Tue, 22 Jun 2010 17:33:55 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id E99288FC1E for ; Tue, 22 Jun 2010 17:33:54 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 74DD622919; Tue, 22 Jun 2010 19:33:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2mDzDXd3GBf; Tue, 22 Jun 2010 19:33:45 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 7EBBE22902; Tue, 22 Jun 2010 19:33:45 +0200 (CEST) To: David DeSimone X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 19:33:45 +0200 From: In-Reply-To: <20100622171944.GQ2620@verio.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622171944.GQ2620@verio.net> Message-ID: <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 17:33:55 -0000 Hi, I try to set VPN like I wrote earlier. 78.x is server and this is not NAT. He dont forward anything. >> I try to configure VPN over my server and my client >> >> Sheme is like this >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 > > Are you trying to set up IPSEC tunneling of networks behind these > gateways, or are you only trying to secure traffic between the peers > themselves? I try to set tunnel behing my server 78.x and gateway 95.x translating packets to 10.x. I can only set 78.x side. > > The fact that you don't receive any reply to your IKE packets would > indicate something basic, like something is blocking traffic. But how to check it? Telnet to port 500 wont work. But when I set SSH to listen on port 500 I can login, port is not blocked > >> # setkey -DP >> 10.10.1.90[any] 78.x.x.x[any] any >> in ipsec >> esp/tunnel/95.x.x.x-78.x.x.x/require >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 2010 >> lifetime: 0(s) validtime: 0(s) >> spid=16461 seq=1 pid=83142 >> refcnt=1 >> 78.x.x.x[any] 10.10.1.90[any] any >> out ipsec >> esp/tunnel/78.x.x.x-95.x.x.x/require >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 2010 >> lifetime: 0(s) validtime: 0(s) >> spid=16460 seq=0 pid=83142 >> refcnt=1 > > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not > actually encapsulating traffic originating from somewhere else, you > might do better to just use "transport" mode to encrypt without > encapsulation. Hmmm, I don't understand it? I set policy only for there IP's and connection for it is ESP encrypced > >> And tcpdump >> #tcpdump -i bce1 host 95.x.x.x >> >> >> 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I >> ident >> 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I >> ident >> 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: phase 1 I >> ident > > My first thought was that your IPSEC policy attempts to encrypt all > traffic between you and your peers, but the IKE traffic is also traffic > between you and your peers, so doesn't it lead to a policy loop of some > sort? Will the IPSEC layer attempt to capture and encrypt the IKE > packets? Can you explain how can I check it? I new on it and I don't understand some things. Regards Ralf From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 17:42:12 2010 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 C49861065674 for ; Tue, 22 Jun 2010 17:42:12 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 8576B8FC12 for ; Tue, 22 Jun 2010 17:42:12 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 479F722910; Tue, 22 Jun 2010 19:42:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJirvvi0h8Vi; Tue, 22 Jun 2010 19:42:03 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id A3E26228F9; Tue, 22 Jun 2010 19:42:03 +0200 (CEST) To: Maciej Suszko X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 19:42:03 +0200 From: In-Reply-To: <20100622190819.270aaa74@gda-arsenic> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> Message-ID: <4f378cfb416582c3081377ba714e508a@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 17:42:12 -0000 >> Hmmm, aggressive mode wasn't help :( >> Still I got only negotiation, so I try to send packets but I don't >> receive it at all. >> >> On my server 78.x.x.x I got ipfw allow all from any to any. >> On the other side 95.x.x.x they tell me that they do it everything >> right - only I can't connect :( >> >> Maybe I don't set route correctly? >> >> Is this mean that I don't receive password from other side? >> ERROR: phase1 negotiation failed due to time up. >> 5d300bcf894a18f5:0000000000000000 > > All the addresses you write about (despite of those x) and especially > this 10.10.1.90 sound familiar (anyway it might be conicidence). I've > got more than dozen working tunnels of this kind. You can try this way: > > Set up a gif tunnel in rc.conf: > > cloned_interfaces="gif0" > ifconfig_gif0="tunnel 78.x.x.x 95.x.x.x" > ifconfig_gif0_alias0="10.20.0.1 netmask 255.255.255.255 10.10.1.90" > > 10.20.0.1 is your internal end of the tunnel, so use any address from > beyond the net 10.10.1.90 is in. > > > in racoon.conf something like this: > > remote 95.x.x.x [500] > { > exchange_mode main,aggressive; > doi ipsec_doi; > situation identity_only; > my_identifier address 78.x.x.x; > peers_identifier address 95.x.x.x; > lifetime time 8 hour; > passive off; > proposal_check obey; > generate_policy off; > proposal { > encryption_algorithm 3des; > hash_algorithm md5; > authentication_method pre_shared_key; > dh_group 2; > } > } > > sainfo (address 10.20.0.1/32 any address 10.10.1.90/32 any) > { > pfs_group 2; > lifetime time 3600 sec; > encryption_algorithm 3des; > authentication_algorithm hmac_md5; > compression_algorithm deflate; > } > > The other side needs to know you have 10.20.0.1 on your side of the > tunnel - this way you should have working IPSEC bettween both 10. ends. So as you write they should set: ?? 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 (other side) And additionaly I thing I should correct set spd policy to: spdadd 10.20.0.1 10.10.1.90 any -P out ipsec esp/tunnel/78.x.x.x-95.x.x.x/require; spdadd 10.10.1.90 10.20.0.1 any -P in ipsec esp/tunnel/95.x.x.x-78.x.x.x/require; Am I wrong? Regards Ralf From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:11:37 2010 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 B5215106566B for ; Tue, 22 Jun 2010 18:11:37 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from mail.suszko.eu (suszko.eu [174.136.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6DE8FC0A for ; Tue, 22 Jun 2010 18:11:37 +0000 (UTC) Received: from oxygen.suszko.eu (localhost [127.0.0.1]) by mail.suszko.eu (Postfix) with ESMTP id 86C233F47D; Tue, 22 Jun 2010 18:03:45 +0000 (UTC) X-Virus-Scanned: amavisd-new using ClamaAV Received: from gda-arsenic (unknown [62.61.57.118]) by mail.suszko.eu (Postfix) with ESMTPSA id 3A3853F474; Tue, 22 Jun 2010 18:03:44 +0000 (UTC) Date: Tue, 22 Jun 2010 20:11:30 +0200 From: Maciej Suszko To: Message-ID: <20100622201130.5824d585@gda-arsenic> In-Reply-To: <4f378cfb416582c3081377ba714e508a@ewipo.pl> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3A.lGlBAur05zO14p_5oVjJ"; protocol="application/pgp-signature" Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 18:11:37 -0000 --Sig_/3A.lGlBAur05zO14p_5oVjJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable wrote: >=20 >=20 > >> Hmmm, aggressive mode wasn't help :( > >> Still I got only negotiation, so I try to send packets but I don't > >> receive it at all. > >>=20 > >> On my server 78.x.x.x I got ipfw allow all from any to any. > >> On the other side 95.x.x.x they tell me that they do it everything > >> right - only I can't connect :( > >>=20 > >> Maybe I don't set route correctly? > >>=20 > >> Is this mean that I don't receive password from other side? > >> ERROR: phase1 negotiation failed due to time up. > >> 5d300bcf894a18f5:0000000000000000 > >=20 > > All the addresses you write about (despite of those x) and > > especially this 10.10.1.90 sound familiar (anyway it might be > > conicidence). I've got more than dozen working tunnels of this > > kind. You can try this way: > >=20 > > Set up a gif tunnel in rc.conf: > >=20 > > cloned_interfaces=3D"gif0" > > ifconfig_gif0=3D"tunnel 78.x.x.x 95.x.x.x" > > ifconfig_gif0_alias0=3D"10.20.0.1 netmask 255.255.255.255 10.10.1.90" > >=20 > > 10.20.0.1 is your internal end of the tunnel, so use any address > > from beyond the net 10.10.1.90 is in. > >=20 > >=20 > > in racoon.conf something like this: > >=20 > > remote 95.x.x.x [500] > > { > > exchange_mode main,aggressive; > > doi ipsec_doi; > > situation identity_only; > > my_identifier address 78.x.x.x; > > peers_identifier address 95.x.x.x; > > lifetime time 8 hour; > > passive off; > > proposal_check obey; > > generate_policy off; > > proposal { > > encryption_algorithm 3des; > > hash_algorithm md5; > > authentication_method pre_shared_key; > > dh_group 2; > > } > > } > >=20 > > sainfo (address 10.20.0.1/32 any address 10.10.1.90/32 any) > > { > > pfs_group 2; > > lifetime time 3600 sec; > > encryption_algorithm 3des; > > authentication_algorithm hmac_md5; > > compression_algorithm deflate; > > } > >=20 > > The other side needs to know you have 10.20.0.1 on your side of the > > tunnel - this way you should have working IPSEC bettween both 10. > > ends. >=20 > So as you write they should set: ?? > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 > (other side) Yes, indeed. > And additionaly I thing I should correct set spd policy to: >=20 > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec > esp/tunnel/78.x.x.x-95.x.x.x/require; > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec > esp/tunnel/95.x.x.x-78.x.x.x/require; >=20 > Am I wrong? No, you're right :) You can set up the tunnel first - check whether both 10. are accessible from both sides, then you "cover" communication between them with IPSEC. --=20 regards, Maciej Suszko. --Sig_/3A.lGlBAur05zO14p_5oVjJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwg/NUACgkQCikUk0l7iGrP3wCeIhASZ9EtJw6upxnXEosEuONM 2HYAnicpFDl8hMR1xAjNvt+uFsMqjEA4 =MiZT -----END PGP SIGNATURE----- --Sig_/3A.lGlBAur05zO14p_5oVjJ-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:20:32 2010 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 A7BE31065674 for ; Tue, 22 Jun 2010 18:20:32 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF8E8FC14 for ; Tue, 22 Jun 2010 18:20:32 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (unknown [198.87.7.165]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id D546B1FF00D1 for ; Tue, 22 Jun 2010 14:20:30 -0400 (EDT) Thread-Index: AcsSN5jEHz94qZKgQ16TjZfgu9/ovw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 14:20:29 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Tue, 22 Jun 2010 13:20:28 -0500 Date: Tue, 22 Jun 2010 13:20:28 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20100622182028.GT2620@verio.net> Mail-Followup-To: freebsd-net@freebsd.org Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622171944.GQ2620@verio.net> <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 22 Jun 2010 18:20:29.0509 (UTC) FILETIME=[98227F50:01CB1237] Subject: Re: vpn trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 18:20:32 -0000 ralf@dzie-ciuch.pl wrote: > > >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 > > I try to set VPN like I wrote earlier. > 78.x is server and this is not NAT. He dont forward anything. > > I try to set tunnel behing my server 78.x and gateway 95.x translating > packets to 10.x. I can only set 78.x side. I think I understand now: Your IP is 78.x.x.x Your peer's IP is 95.x.x.x Your peer has a network 10.10.1.90 (with some netmask?) behind it. > > The fact that you don't receive any reply to your IKE packets would > > indicate something basic, like something is blocking traffic. > > But how to check it? Telnet to port 500 wont work. But when I set > SSH to listen on port 500 I can login, port is not blocked Telnet and SSH use TCP. IKE uses UDP, so you cannot use those sorts of utilities to test it. You could attempt to use netcat tool "nc -u" to send packets through, but really, tcpdump is probably your best troubleshooting tool. You would still see the incoming IKE replies via tcpdump, even if your firewall was blocking them. > > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not > > actually encapsulating traffic originating from somewhere else, you > > might do better to just use "transport" mode to encrypt without > > encapsulation. > > Hmmm, I don't understand it? I set policy only for there IP's and > connection for it is ESP encrypced Now that I understand you are trying to reach a network behind your peer, tunnel mode is appropriate, so forget about my transport mode comments. > > My first thought was that your IPSEC policy attempts to encrypt all > > traffic between you and your peers, but the IKE traffic is also > > traffic between you and your peers, so doesn't it lead to a policy > > loop of some sort? Will the IPSEC layer attempt to capture and > > encrypt the IKE packets? > > Can you explain how can I check it? I new on it and I don't > understand some things. I'm sorry, due to my previous misunderstanding I didn't see that your policy is set up the way it should be. The IPSEC SA policy is set up correctly, and your racoon configuration also looks correct. Setting up VPN without cooperation from your peer is generally very difficult. I would suggest that your peer access his Cisco device logs and tell you if he sees any error messages related to your IP. He might easily be blocking your IP by failing to enter it into an access list somewhere, and you will not be able to tell, from your perspective. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:22:46 2010 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 C713C106564A for ; Tue, 22 Jun 2010 18:22:46 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADDF8FC16 for ; Tue, 22 Jun 2010 18:22:46 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (unknown [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id BEE59B0380D1 for ; Tue, 22 Jun 2010 14:22:45 -0400 (EDT) Thread-Index: AcsSN+konsqVKXCMQLOwmYmfm2oTDg== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 14:22:44 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Tue, 22 Jun 2010 13:22:43 -0500 Date: Tue, 22 Jun 2010 13:22:43 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20100622182242.GU2620@verio.net> Mail-Followup-To: freebsd-net@freebsd.org Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100622201130.5824d585@gda-arsenic> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 22 Jun 2010 18:22:44.0381 (UTC) FILETIME=[E88654D0:01CB1237] Subject: Re: vpn trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 18:22:46 -0000 Maciej Suszko wrote: > > > So as you write they should set: ?? > > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 > > (other side) > > Yes, indeed. > > > And additionaly I thing I should correct set spd policy to: > > > > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec > > esp/tunnel/78.x.x.x-95.x.x.x/require; > > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec > > esp/tunnel/95.x.x.x-78.x.x.x/require; > > > > Am I wrong? > > No, you're right :) > > You can set up the tunnel first - check whether both 10. are accessible > from both sides, then you "cover" communication between them with IPSEC. Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint VPN equipment? In our tests we were able to use pure IPSEC tunnel encapsulation to interoperate with these sorts of devices, so we never found a need for GIF encapsulation. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:26:43 2010 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 F17C1106564A for ; Tue, 22 Jun 2010 18:26:42 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from mail.suszko.eu (suszko.eu [174.136.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id D62938FC16 for ; Tue, 22 Jun 2010 18:26:42 +0000 (UTC) Received: from oxygen.suszko.eu (localhost [127.0.0.1]) by mail.suszko.eu (Postfix) with ESMTP id E6ADD3F47D; Tue, 22 Jun 2010 18:18:50 +0000 (UTC) X-Virus-Scanned: amavisd-new using ClamaAV Received: from gda-arsenic (unknown [62.61.57.118]) by mail.suszko.eu (Postfix) with ESMTPSA id 8825F3F474; Tue, 22 Jun 2010 18:18:49 +0000 (UTC) Date: Tue, 22 Jun 2010 20:26:36 +0200 From: Maciej Suszko To: freebsd-net@freebsd.org Message-ID: <20100622202636.714bced5@gda-arsenic> In-Reply-To: <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622171944.GQ2620@verio.net> <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/e607x.rueu45EtWTdepL51a"; protocol="application/pgp-signature" Subject: Re: vpn trouble 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, 22 Jun 2010 18:26:43 -0000 --Sig_/e607x.rueu45EtWTdepL51a Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable wrote: >=20 > Hi, >=20 > I try to set VPN like I wrote earlier. > 78.x is server and this is not NAT. He dont forward anything. >=20 > >> I try to configure VPN over my server and my client > >>=20 > >> Sheme is like this > >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 > >=20 > > Are you trying to set up IPSEC tunneling of networks behind these > > gateways, or are you only trying to secure traffic between the peers > > themselves? >=20 > I try to set tunnel behing my server 78.x and gateway 95.x translating > packets to 10.x. I can only set 78.x side. >=20 > >=20 > > The fact that you don't receive any reply to your IKE packets would > > indicate something basic, like something is blocking traffic. >=20 > But how to check it? Telnet to port 500 wont work. But when I set SSH > to listen on port 500 I can login, port is not blocked Telnet host 500 uses proto tcp, isakmp - udp. > >> # setkey -DP > >> 10.10.1.90[any] 78.x.x.x[any] any > >> in ipsec > >> esp/tunnel/95.x.x.x-78.x.x.x/require > >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 > >> 2010 lifetime: 0(s) validtime: 0(s) > >> spid=3D16461 seq=3D1 pid=3D83142 > >> refcnt=3D1 > >> 78.x.x.x[any] 10.10.1.90[any] any > >> out ipsec > >> esp/tunnel/78.x.x.x-95.x.x.x/require > >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 > >> 2010 lifetime: 0(s) validtime: 0(s) > >> spid=3D16460 seq=3D0 pid=3D83142 > >> refcnt=3D1 > >=20 > > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not > > actually encapsulating traffic originating from somewhere else, you > > might do better to just use "transport" mode to encrypt without > > encapsulation. >=20 > Hmmm, I don't understand it? I set policy only for there IP's and > connection for it is ESP encrypced >=20 > >=20 > >> And tcpdump > >> #tcpdump -i bce1 host 95.x.x.x=20 > >>=20 > >>=20 > >> 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: > >> phase 1 I ident > >> 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: > >> phase 1 I ident > >> 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: > >> phase 1 I ident > >=20 > > My first thought was that your IPSEC policy attempts to encrypt all > > traffic between you and your peers, but the IKE traffic is also > > traffic between you and your peers, so doesn't it lead to a policy > > loop of some sort? Will the IPSEC layer attempt to capture and > > encrypt the IKE packets? >=20 > Can you explain how can I check it? I new on it and I don't understand > some things. I've got such tunnels up and working - tunnel mode, encryption between peers, without using any internal networks - strange, but working :) - policy looks like that: spdadd 195.x.x.x 213.x.x.x any -P out ipsec esp/tunnel/195.x.x.x-213.x.x.x/= require; spdadd 213.x.x.x 195.x.x.x any -P in ipsec esp/tunnel/213.x.x.x-195.x.x.x/= require; --=20 regards, Maciej Suszko. --Sig_/e607x.rueu45EtWTdepL51a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwhAF8ACgkQCikUk0l7iGoc1wCfSz2Al4p8uuQxR5ZG7lAKSarR J04AnR2GJkCAaSPevcxjYn4YoSwwojaQ =CVB6 -----END PGP SIGNATURE----- --Sig_/e607x.rueu45EtWTdepL51a-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:30:47 2010 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 B0D73106566B for ; Tue, 22 Jun 2010 18:30:47 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 4830C8FC1D for ; Tue, 22 Jun 2010 18:30:47 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 0AF372291A; Tue, 22 Jun 2010 20:30:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr-J85SA2itD; Tue, 22 Jun 2010 20:30:38 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 2E57A228F9; Tue, 22 Jun 2010 20:30:38 +0200 (CEST) To: Maciej Suszko X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 20:30:38 +0200 From: In-Reply-To: <20100622202636.714bced5@gda-arsenic> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622171944.GQ2620@verio.net> <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> <20100622202636.714bced5@gda-arsenic> Message-ID: <7fcefb2d592f4b443c09af6904eecfee@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 18:30:47 -0000 Thanks guys, I try it tomorrow and I send you is it works or not. Regards Ralf On Tue, 22 Jun 2010 20:26:36 +0200, Maciej Suszko wrote: > wrote: >> >> Hi, >> >> I try to set VPN like I wrote earlier. >> 78.x is server and this is not NAT. He dont forward anything. >> >> >> I try to configure VPN over my server and my client >> >> >> >> Sheme is like this >> >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 >> > >> > Are you trying to set up IPSEC tunneling of networks behind these >> > gateways, or are you only trying to secure traffic between the peers >> > themselves? >> >> I try to set tunnel behing my server 78.x and gateway 95.x translating >> packets to 10.x. I can only set 78.x side. >> >> > >> > The fact that you don't receive any reply to your IKE packets would >> > indicate something basic, like something is blocking traffic. >> >> But how to check it? Telnet to port 500 wont work. But when I set SSH >> to listen on port 500 I can login, port is not blocked > > Telnet host 500 uses proto tcp, isakmp - udp. > >> >> # setkey -DP >> >> 10.10.1.90[any] 78.x.x.x[any] any >> >> in ipsec >> >> esp/tunnel/95.x.x.x-78.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16461 seq=1 pid=83142 >> >> refcnt=1 >> >> 78.x.x.x[any] 10.10.1.90[any] any >> >> out ipsec >> >> esp/tunnel/78.x.x.x-95.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16460 seq=0 pid=83142 >> >> refcnt=1 >> > >> > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not >> > actually encapsulating traffic originating from somewhere else, you >> > might do better to just use "transport" mode to encrypt without >> > encapsulation. >> >> Hmmm, I don't understand it? I set policy only for there IP's and >> connection for it is ESP encrypced >> >> > >> >> And tcpdump >> >> #tcpdump -i bce1 host 95.x.x.x >> >> >> >> >> >> 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> > >> > My first thought was that your IPSEC policy attempts to encrypt all >> > traffic between you and your peers, but the IKE traffic is also >> > traffic between you and your peers, so doesn't it lead to a policy >> > loop of some sort? Will the IPSEC layer attempt to capture and >> > encrypt the IKE packets? >> >> Can you explain how can I check it? I new on it and I don't understand >> some things. > > I've got such tunnels up and working - tunnel mode, encryption between > peers, without using any internal networks - strange, but working :) - > policy looks like that: > spdadd 195.x.x.x 213.x.x.x any -P out ipsec > esp/tunnel/195.x.x.x-213.x.x.x/require; > spdadd 213.x.x.x 195.x.x.x any -P in ipsec > esp/tunnel/213.x.x.x-195.x.x.x/require; From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:41:14 2010 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 68B8B1065673 for ; Tue, 22 Jun 2010 18:41:14 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from mail.suszko.eu (suszko.eu [174.136.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD3F8FC24 for ; Tue, 22 Jun 2010 18:41:14 +0000 (UTC) Received: from oxygen.suszko.eu (localhost [127.0.0.1]) by mail.suszko.eu (Postfix) with ESMTP id 4B9D13F474; Tue, 22 Jun 2010 18:33:22 +0000 (UTC) X-Virus-Scanned: amavisd-new using ClamaAV Received: from gda-arsenic (unknown [62.61.57.118]) by mail.suszko.eu (Postfix) with ESMTPSA id 4BF693F473; Tue, 22 Jun 2010 18:33:21 +0000 (UTC) Date: Tue, 22 Jun 2010 20:41:07 +0200 From: Maciej Suszko To: Message-ID: <20100622204107.6c604c17@gda-arsenic> In-Reply-To: <20100622182242.GU2620@verio.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/5C5DXajOX0hCikxqryYx.Zy"; protocol="application/pgp-signature" Subject: Re: vpn trouble 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, 22 Jun 2010 18:41:14 -0000 --Sig_/5C5DXajOX0hCikxqryYx.Zy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "David DeSimone" wrote: > Maciej Suszko wrote: > > > > > So as you write they should set: ?? > > > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 > > > (other side) > >=20 > > Yes, indeed. > >=20 > > > And additionaly I thing I should correct set spd policy to: > > >=20 > > > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec > > > esp/tunnel/78.x.x.x-95.x.x.x/require; > > > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec > > > esp/tunnel/95.x.x.x-78.x.x.x/require; > > >=20 > > > Am I wrong? > >=20 > > No, you're right :) > >=20 > > You can set up the tunnel first - check whether both 10. are > > accessible from both sides, then you "cover" communication between > > them with IPSEC. >=20 > Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint > VPN equipment? In our tests we were able to use pure IPSEC tunnel > encapsulation to interoperate with these sorts of devices, so we never > found a need for GIF encapsulation. I'm not sure what's on the other side, AFAIK some hardware solution. --=20 regards, Maciej Suszko. --Sig_/5C5DXajOX0hCikxqryYx.Zy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwhA8YACgkQCikUk0l7iGrkAACfdRvHx0bJoS8YaKANcCo+atxB kOUAoIf0PmOku+P994nEvUalXWPa5eMA =A7S8 -----END PGP SIGNATURE----- --Sig_/5C5DXajOX0hCikxqryYx.Zy-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 19:29:10 2010 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 876E8106566B for ; Tue, 22 Jun 2010 19:29:10 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4968FC1B for ; Tue, 22 Jun 2010 19:29:10 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Z0z41e0040cQ2SLA47G0jT; Tue, 22 Jun 2010 19:16:00 +0000 Received: from smtp.ericx.net ([76.24.209.147]) by omta10.emeryville.ca.mail.comcast.net with comcast id Z7Fu1e0023BMG6c8W7FxnT; Tue, 22 Jun 2010 19:15:59 +0000 Received: from smtp.ericx.net (localhost.ericx.net [127.0.0.1]) by smtp.ericx.net (Postfix) with ESMTP id 09DF3129F0A7 for ; Tue, 22 Jun 2010 15:16:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ericx.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=selector1; bh=zIXgOa6 hYtRvbz9Ut+B4OGdkOGI=; b=pvdDf8sTExlQ0cD7m5C+Ra9DH6mUfsC5z3NZHPz F0i3efBA/L0BLAnFG00oQs74fmmpRXRv+GbbZPLvgUnOhlmxJMUKTYHKw1jyROq+ +SWFv/9GLHYVOXStFjFItWEXR/QJRROAImxbeLQP5drSveFQV4cymY9CgvrJQHm1 P0ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ericx.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=selector1; b=p 3GO1YOaGAWWb1EaOorelS07mYpV63H2xhKKdBEiREWH2ZVnnUFh+FKaRZDbeGkOc 7YO1z5qZSSvG7GF9FUIlDVCX/jS1At98nbr533ypphDJV9Hoxa7QvgqC7rur9FK6 gNQesmZXfxNcAwvBARTBX29LmIXUd1JsGq0Fip/6cQ= Received: from [10.0.0.54] (unknown [75.150.112.177]) by smtp.ericx.net (Postfix) with ESMTPSA id BB90B129F0A6 for ; Tue, 22 Jun 2010 15:16:18 -0400 (EDT) Message-ID: <4C210B0F.6060203@ericx.net> Date: Tue, 22 Jun 2010 15:12:15 -0400 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> In-Reply-To: <20100622182242.GU2620@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: vpn trouble 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, 22 Jun 2010 19:29:10 -0000 On 6/22/2010 2:22 PM, David DeSimone wrote: > Maciej Suszko wrote: >> >>> So as you write they should set: ?? >>> 10.20.0.1 (my ip on gif device)<-> 78.x<-> 95.x<-> 10.10.1.90 >>> (other side) >> >> Yes, indeed. >> >>> And additionaly I thing I should correct set spd policy to: >>> >>> spdadd 10.20.0.1 10.10.1.90 any -P out ipsec >>> esp/tunnel/78.x.x.x-95.x.x.x/require; >>> spdadd 10.10.1.90 10.20.0.1 any -P in ipsec >>> esp/tunnel/95.x.x.x-78.x.x.x/require; >>> >>> Am I wrong? >> >> No, you're right :) >> >> You can set up the tunnel first - check whether both 10. are accessible >> from both sides, then you "cover" communication between them with IPSEC. > > Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint > VPN equipment? In our tests we were able to use pure IPSEC tunnel > encapsulation to interoperate with these sorts of devices, so we never > found a need for GIF encapsulation. > I managed to do an IP in IP tunnel with IPsec encryption between a FreeBSD and a cisco router running 12.1(mumble) several years ago. It is a desirable option if you want to use routing (e.g. ospf). You can't route an IPSec tunnel (actually, is this now possible with enc0 interfaces?) but you can route to the gif interfaces. http://rfc-ref.org/RFC-TEXTS/3884/ From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 19:55:19 2010 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 819A41065670 for ; Tue, 22 Jun 2010 19:55:19 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 414468FC08 for ; Tue, 22 Jun 2010 19:55:19 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id E70A422910; Tue, 22 Jun 2010 21:55:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2XfLmp1o4hC; Tue, 22 Jun 2010 21:55:10 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 334CD228F9; Tue, 22 Jun 2010 21:55:10 +0200 (CEST) To: "Eric W. Bates" X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.250.193.50 MIME-Version: 1.0 Date: Tue, 22 Jun 2010 21:55:10 +0200 From: In-Reply-To: <4C210B0F.6060203@ericx.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <4C210B0F.6060203@ericx.net> Message-ID: <655d7279cefc01b3fbe0016c598fcd72@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 22 Jun 2010 19:55:19 -0000 > > I managed to do an IP in IP tunnel with IPsec encryption between a > FreeBSD and a cisco router running 12.1(mumble) several years ago. > > It is a desirable option if you want to use routing (e.g. ospf). You > can't route an IPSec tunnel (actually, is this now possible with enc0 > interfaces?) but you can route to the gif interfaces. > Can you tell me how to use route command to use it like above? From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 21:46:19 2010 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 939371065677 for ; Tue, 22 Jun 2010 21:46:19 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 45BF48FC16 for ; Tue, 22 Jun 2010 21:46:19 +0000 (UTC) Received: from [32.177.5.176] ([32.177.5.176]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5MLk7bg056721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 22 Jun 2010 17:46:17 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277243178; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer; b=jNn B3jkIBjIMhjQGnOICxODYyF3GGNAZVv7pw6BP/uXHY7AgNbsKbaHJA6PJnVhfjWJyEQ n2SfbRcgKBAGDKlA== Message-Id: From: Randall Stewart To: net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Jun 2010 17:46:02 -0400 X-Mailer: Apple Mail (2.936) Cc: Subject: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 21:46:19 -0000 Hi all: I have had some fun in my day job playing with exchanging 64bit numbers. Unfortunately there is no ntohll() OR htonll() which would be the logical thing (for us old farts) to use. Yes, I have found htobe64() and friends.. and that would work.. but I still cannot help but feeling we should have the ntohll() and htonll().. for consistency if nothing else. Any objections to this showing up in a head near you soon (speak soon or I will commit the patches to add these ;-D) R ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:01:27 2010 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 8B90F1065672 for ; Tue, 22 Jun 2010 22:01:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 22E068FC15 for ; Tue, 22 Jun 2010 22:01:26 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-064-188-037.pools.arcor-ip.net [88.64.188.37]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MWhTP-1OgsrN0Kk7-00XwVn; Wed, 23 Jun 2010 00:01:18 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 23 Jun 2010 00:01:17 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.0-RELEASE-p3; KDE/4.4.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006230001.17407.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+2tI9mjZrPqCkDtn+75oYnXGCNnHIP2Kh1zuQ WB0nD1jlKwG6O/S4jAorMyuPbSm4lz9ncZwi5WpPIObKyFJ7Nf GrZSmFuLHykWXnRccMpyA== Cc: Randall Stewart Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 22:01:27 -0000 On Tuesday 22 June 2010 23:46:02 Randall Stewart wrote: > Hi all: > > I have had some fun in my day job playing with exchanging 64bit > numbers. Unfortunately > there is no ntohll() OR htonll() which would be the logical thing (for > us old farts) to use. > > Yes, I have found htobe64() and friends.. and that would work.. but I > still cannot > help but feeling we should have the ntohll() and htonll().. for > consistency if nothing > else. > > Any objections to this showing up in a head near you soon (speak soon > or I will commit > the patches to add these ;-D) Is there any precedence in other *BSDs or elsewhere? There is already enough difference in endian.h between the BSDs (OpenBSD has betohXX instead of beXXtoh) and it makes porting code difficult. I'd prefer to not add gratuitous aliases for things that already have a well-known name. Thanks, Max From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:02:09 2010 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 909B3106566C for ; Tue, 22 Jun 2010 22:02:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 57D368FC17 for ; Tue, 22 Jun 2010 22:02:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 37816730A1; Wed, 23 Jun 2010 00:12:28 +0200 (CEST) Date: Wed, 23 Jun 2010 00:12:28 +0200 From: Luigi Rizzo To: Randall Stewart Message-ID: <20100622221228.GA93249@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 22:02:09 -0000 On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: > Hi all: > > I have had some fun in my day job playing with exchanging 64bit > numbers. Unfortunately > there is no ntohll() OR htonll() which would be the logical thing (for > us old farts) to use. > > Yes, I have found htobe64() and friends.. and that would work.. but I > still cannot > help but feeling we should have the ntohll() and htonll().. for > consistency if nothing > else. > > Any objections to this showing up in a head near you soon (speak soon > or I will commit > the patches to add these ;-D) strong objection! We should instead use names with exact sizes (16,32,64). In case you want to use Roman Numbers, 64 would be LXIV :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:17:01 2010 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 6CC881065670 for ; Tue, 22 Jun 2010 22:17:01 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id F03708FC13 for ; Tue, 22 Jun 2010 22:17:00 +0000 (UTC) Received: from [32.177.5.176] ([32.177.5.176]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5MMGoB9057964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Jun 2010 18:16:58 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277245020; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=lCD9Uu3y6mUsxgVSHTw7AVkrD43NcyCcdjOnpiYU1opt2lnnJYNeuwJ pigx08ikeT8kS362loa/pGIQnB+HuWA== Message-Id: <8D3FD4E4-B089-4081-837C-9C4D82DA141E@lakerest.net> From: Randall Stewart To: Max Laier In-Reply-To: <201006230001.17407.max@love2party.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Jun 2010 18:16:43 -0400 References: <201006230001.17407.max@love2party.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 22:17:01 -0000 On Jun 22, 2010, at 6:01 PM, Max Laier wrote: > On Tuesday 22 June 2010 23:46:02 Randall Stewart wrote: >> Hi all: >> >> I have had some fun in my day job playing with exchanging 64bit >> numbers. Unfortunately >> there is no ntohll() OR htonll() which would be the logical thing >> (for >> us old farts) to use. >> >> Yes, I have found htobe64() and friends.. and that would work.. but I >> still cannot >> help but feeling we should have the ntohll() and htonll().. for >> consistency if nothing >> else. >> >> Any objections to this showing up in a head near you soon (speak soon >> or I will commit >> the patches to add these ;-D) > > Is there any precedence in other *BSDs or elsewhere? There is > already enough > difference in endian.h between the BSDs (OpenBSD has betohXX instead > of > beXXtoh) and it makes porting code difficult. I'd prefer to not add > gratuitous aliases for things that already have a well-known name. Max: Well well-known such things are not... otherwise I would not have been futzing around looking for it. Google showed nothing.. and finding the be64toh() took a while. The only thing the man page in ntohl shows is the 16/32 bit quantities and a nice disclaimer about conforming to POSIX - byteorder fun.. R > > Thanks, > Max > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:17:42 2010 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 7DE55106566B for ; Tue, 22 Jun 2010 22:17:42 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 0F89B8FC18 for ; Tue, 22 Jun 2010 22:17:41 +0000 (UTC) Received: from [32.177.5.176] ([32.177.5.176]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5MMGoBA057964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Jun 2010 18:17:39 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277245061; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=g5dQ5YxGM1j5HKaB93zWQD5rNvKyLJcGhJOyaB7hi6yCRbrEl/i8M4s ggpQHjumeEYDAhgEjDu5dZj7D4Ty2kQ== Message-Id: <274959C7-0B6C-4A96-83C1-D29A7D5107D6@lakerest.net> From: Randall Stewart To: Luigi Rizzo In-Reply-To: <20100622221228.GA93249@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Jun 2010 18:17:37 -0400 References: <20100622221228.GA93249@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 22:17:42 -0000 On Jun 22, 2010, at 6:12 PM, Luigi Rizzo wrote: > On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: >> Hi all: >> >> I have had some fun in my day job playing with exchanging 64bit >> numbers. Unfortunately >> there is no ntohll() OR htonll() which would be the logical thing >> (for >> us old farts) to use. >> >> Yes, I have found htobe64() and friends.. and that would work.. but I >> still cannot >> help but feeling we should have the ntohll() and htonll().. for >> consistency if nothing >> else. >> >> Any objections to this showing up in a head near you soon (speak soon >> or I will commit >> the patches to add these ;-D) > > strong objection! > We should instead use names with exact sizes (16,32,64). > In case you want to use Roman Numbers, 64 would be LXIV :) But htonl/nthol and friends have been used for years. Yes 32/64 and 16 are clearer but they are not consistent with what about everyone in the networking world uses. R > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:54:25 2010 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 83AD8106564A for ; Tue, 22 Jun 2010 22:54:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-1.mx.aerioconnect.net [216.240.47.61]) by mx1.freebsd.org (Postfix) with ESMTP id 64AC38FC12 for ; Tue, 22 Jun 2010 22:54:25 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o5MMsNGl023087; Tue, 22 Jun 2010 15:54:23 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 11BEE2D6017; Tue, 22 Jun 2010 15:54:22 -0700 (PDT) Message-ID: <4C213F36.4030206@elischer.org> Date: Tue, 22 Jun 2010 15:54:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Luigi Rizzo References: <20100622221228.GA93249@onelab2.iet.unipi.it> In-Reply-To: <20100622221228.GA93249@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Randall Stewart , net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 22 Jun 2010 22:54:25 -0000 On 6/22/10 3:12 PM, Luigi Rizzo wrote: > On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: >> Hi all: >> >> I have had some fun in my day job playing with exchanging 64bit >> numbers. Unfortunately >> there is no ntohll() OR htonll() which would be the logical thing (for >> us old farts) to use. >> >> Yes, I have found htobe64() and friends.. and that would work.. but I >> still cannot >> help but feeling we should have the ntohll() and htonll().. for >> consistency if nothing >> else. >> >> Any objections to this showing up in a head near you soon (speak soon >> or I will commit >> the patches to add these ;-D) > > strong objection! > We should instead use names with exact sizes (16,32,64). > In case you want to use Roman Numbers, 64 would be LXIV :) Don't know about roman numerals but I'm for using numbers. hton64 and ntoh64 would be a lot more useful > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:57:24 2010 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 5BEFD106564A for ; Tue, 22 Jun 2010 22:57:24 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF8128FC1B for ; Tue, 22 Jun 2010 22:57:23 +0000 (UTC) Received: by bwz17 with SMTP id 17so31330bwz.13 for ; Tue, 22 Jun 2010 15:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:subject:mime-version:content-type :content-transfer-encoding; bh=ebYa1dsNNrm5P/pi9zOFIeVS38ar90UesqNUvaJXSl8=; b=Iz7vDGRAvYu6tjaowAB/KbaSBKMaAXxRpKOht1XbYkj1N1ebiwI1+rkXhbjbvbSr01 OTV6AsqhvswNeE8D/6QlJeiPOkLuYbxfcxB2TLe2UfUzoMcgMA2QXnRuJ7WbArXnFg7l 13P6ltCuzgCKBWr5k+FFPnXVe/5+VZRuo+DyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:subject:mime-version :content-type:content-transfer-encoding; b=tROOXMzfgw2J2GOaMuJppEhxlBxhk1mKMjE1hwD6zw1kWgKJmHSsZQZHbS7ClqMU7R fUqtKGnx7DaAQi4QbIaRpHv/lsOMAYx9sI4L6ODPF0HC3ELQ0HYA9wagqv4n8CZR+Z2R qPKDlPChnLvrp0IdhwnDkskEPx5rIGPa8am5E= Received: by 10.204.83.197 with SMTP id g5mr3295247bkl.114.1277245823652; Tue, 22 Jun 2010 15:30:23 -0700 (PDT) Received: from [10.0.144.9] ([89.208.146.211]) by mx.google.com with ESMTPS id v14sm44364399bkz.14.2010.06.22.15.30.21 (version=SSLv3 cipher=OTHER); Tue, 22 Jun 2010 15:30:22 -0700 (PDT) Date: Wed, 23 Jun 2010 02:30:03 +0400 From: Michael Monashev X-Priority: 3 (Normal) Message-ID: <1476665685.20100623023003@gmail.com> To: FreeBSD Net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: can't disable VLAN_MTU and VLAN_HWCSUM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Monashev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:57:24 -0000 Hi FreeBSD 8.0-RELEASE-p3 $ ifconfig em0: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 inet 89.208.146.215 netmask 0xffffff00 broadcast 89.208.146.255 inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255 inet 89.208.145.139 netmask 0xffffff00 broadcast 89.208.145.255 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c vlan2: flags=8843 metric 0 mtu 9216 ether 00:15:17:35:1c:76 inet 10.0.143.5 netmask 0xffffff00 broadcast 10.0.143.255 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 lo1: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.1.1 netmask 0xffffff00 inet 127.0.1.2 netmask 0xffffffff inet 127.0.1.3 netmask 0xffffffff inet 127.0.1.4 netmask 0xffffffff inet 127.0.1.5 netmask 0xffffffff inet 127.0.1.6 netmask 0xffffffff inet 127.0.1.7 netmask 0xffffffff inet 127.0.1.8 netmask 0xffffffff inet 127.0.1.9 netmask 0xffffffff inet 127.0.1.10 netmask 0xffffffff inet 127.0.1.11 netmask 0xffffffff inet 127.0.1.12 netmask 0xffffffff inet 127.0.1.13 netmask 0xffffffff inet 127.0.1.14 netmask 0xffffffff inet 127.0.1.15 netmask 0xffffffff inet 127.0.1.16 netmask 0xffffffff inet 127.0.1.17 netmask 0xffffffff inet 127.0.1.18 netmask 0xffffffff inet 127.0.1.19 netmask 0xffffffff inet 127.0.1.20 netmask 0xffffffff $ sudo ifconfig em0 -vlanmtu $ sudo ifconfig em1 -vlanmtu $ sudo ifconfig em0 -vlanhwfilter $ sudo ifconfig em1 -vlanhwfilter $ ifconfig em0: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 9216 options=18b ether 00:15:17:35:1c:76 inet 89.208.146.215 netmask 0xffffff00 broadcast 89.208.146.255 inet 192.168.2.5 netmask 0xffffff00 broadcast 192.168.2.255 inet 89.208.145.139 netmask 0xffffff00 broadcast 89.208.145.255 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c vlan2: flags=8843 metric 0 mtu 9216 ether 00:15:17:35:1c:76 inet 10.0.143.5 netmask 0xffffff00 broadcast 10.0.143.255 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 lo1: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.1.1 netmask 0xffffff00 inet 127.0.1.2 netmask 0xffffffff inet 127.0.1.3 netmask 0xffffffff inet 127.0.1.4 netmask 0xffffffff inet 127.0.1.5 netmask 0xffffffff inet 127.0.1.6 netmask 0xffffffff inet 127.0.1.7 netmask 0xffffffff inet 127.0.1.8 netmask 0xffffffff inet 127.0.1.9 netmask 0xffffffff inet 127.0.1.10 netmask 0xffffffff inet 127.0.1.11 netmask 0xffffffff inet 127.0.1.12 netmask 0xffffffff inet 127.0.1.13 netmask 0xffffffff inet 127.0.1.14 netmask 0xffffffff inet 127.0.1.15 netmask 0xffffffff inet 127.0.1.16 netmask 0xffffffff inet 127.0.1.17 netmask 0xffffffff inet 127.0.1.18 netmask 0xffffffff inet 127.0.1.19 netmask 0xffffffff inet 127.0.1.20 netmask 0xffffffff As you can see, ifconfig didn`t change anything. How to disable VLAN_MTU and VLAN_HWCSUM flags? -- Michael From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 23:01:26 2010 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 51A4B1065672 for ; Tue, 22 Jun 2010 23:01:26 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D13D38FC0A for ; Tue, 22 Jun 2010 23:01:25 +0000 (UTC) Received: by bwz17 with SMTP id 17so32450bwz.13 for ; Tue, 22 Jun 2010 16:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=M1YkpYnCI289qF5VkJBW+wSBSCoFe+aLfyQOAmZcW9U=; b=oNiR4bBgHOzA6PuHV6WfRTZZKIQKhOYaW98MAR/HMA2r37S8KK0OWOjK6rcwyqgLSn PGV9U46nYdmY8i2PcndOaZBfwIq0d//yXc/7QONW1R3p4Fw5rbbUn6QlBL52uIgWNm+D SGBrLIVCJf2k/eyH6ohy+AggFla5IRZ/UtTNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=BiNCkBsmP076peqzK60O1cjF78gT1tPwkTpxyJp93uDQ/AqjR66RTfX/wrzXxg+3+8 0CND5hW28HxCn0Xm4PNkniIoJd031KbobQIJVMslKDpdtLHThBgOs2/TwFcHeokB1F+j 7GLAm+wMbzVRQnHpiytas4AMumLKnLLCD6xPk= Received: by 10.204.160.69 with SMTP id m5mr4839107bkx.70.1277245831301; Tue, 22 Jun 2010 15:30:31 -0700 (PDT) Received: from [10.0.144.9] ([89.208.146.211]) by mx.google.com with ESMTPS id jq1sm11073940bkb.35.2010.06.22.15.30.29 (version=SSLv3 cipher=OTHER); Tue, 22 Jun 2010 15:30:30 -0700 (PDT) Date: Wed, 23 Jun 2010 02:30:11 +0400 From: Michael Monashev X-Priority: 3 (Normal) Message-ID: <1303366548.20100623023011@gmail.com> To: FreeBSD Net In-Reply-To: <4A4CA93C.6000204@incunabulum.net> References: <4A4CA93C.6000204@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: vlan lacp and em problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Monashev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:01:26 -0000 Hi. Can somebody MFC this http://www.freebsd.org/cgi/query-pr.cgi?pr=141646 to 8.1? -- Michael From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 23:12:04 2010 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 B8210106566B for ; Tue, 22 Jun 2010 23:12:04 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 417B18FC17 for ; Tue, 22 Jun 2010 23:12:03 +0000 (UTC) Received: by bwz17 with SMTP id 17so35329bwz.13 for ; Tue, 22 Jun 2010 16:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:subject:x-enigmail-version :content-type:content-transfer-encoding; bh=MeATj/RK9jSdIXzSfSWdgSYEU0i3NOp5oqxukLSmf/o=; b=dMkPtGy3PzrjgJSWYDHiCq4xUY2sFoopEhMIGGiHzfmMdAQMmo6GxWLWfvYdBcGmHB avT50mncS79r3VOavTGJc674WXYBxS2GP8qWUmN3yHBhjDs+UH/sXLSctjij7AxCFC61 xy1qDwcV1epCFGQiSqGVvBPkL/DVkMLYItWqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; b=fvzBmaefYOC8icRH1qwX0BIF9yc/HYrhB+7ZeKVPrrdqb+/XFwQvLwSgI4qVZyulgr CAvXcz2hKId5T3/+A1ZTwBllvltWwZLaSN7w2vBjczXenJTNYzocTSYJn3RXyn9XIFPg gKbcTHvmiNh9Y1nEXmHGGB41QP9zqiAr0fZf0= Received: by 10.204.3.198 with SMTP id 6mr4820452bko.205.1277247012168; Tue, 22 Jun 2010 15:50:12 -0700 (PDT) Received: from [129.16.199.244] (dhcp-199-244.nomad.chalmers.se [129.16.199.244]) by mx.google.com with ESMTPS id z17sm11114988bkx.36.2010.06.22.15.50.11 (version=SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 15:50:11 -0700 (PDT) Sender: =?UTF-8?B?UMOBTEkgR8OhYm9yIErDoW5vcw==?= Message-ID: <4C213D07.6020203@FreeBSD.org> Date: Wed, 23 Jun 2010 00:45:27 +0200 From: Gabor PALI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: net@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: [RFC] Changes in stat structures 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, 22 Jun 2010 23:12:04 -0000 Hello, I would like to integrate my Google Summer of Code project from the last year [1]. In brief, it was about converting netstat(1) into a library and providing a relatively clean API to access various networking statistics available in the kernel. The project is far from being complete, and it needs review but I decided to split my large patch into smaller pieces and add the results continuously to the FreeBSD src/ repository, otherwise it might vanish. I do not have a src/ commit bit, thus I am also looking for a sponsor for my changes who approves or commits them. My plan of integration is simple: apply the necessary modifications to the kernel, add the sysctl export routines and data structures, add the library (called libnetstat(3)), then adapt and add applications (netstat(1), bsnmpd(1), nettop(1), etc.) to use it. This way I could get some review and continue the development of this library in an interactive style. The first piece of this set is available on my FreeBSD homepage as a separate patch [2], which technically proposes to a "standardization" for the counter values so they could be accessed from both 32-bit and 64-bit environments without problems (via kvm(3) or sysctl(3)). However, I do not know too much about the potential consequences or how such a change should be handled in the tree. For more information (and the complete patch), see the project's wiki page [3]. Any feedback is appreciated. Nothing is carved into stone, I am very open to comments :) Thank you! Cheers, :g [1] http://wiki.freebsd.org/PGJSoC2009 [2] http://people.freebsd.org/~pgj/libnetstat/libnetstat-sys.latest.diff [3] http://wiki.freebsd.org/LibNetstat From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 03:25:31 2010 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 93B8C106566B for ; Wed, 23 Jun 2010 03:25:31 +0000 (UTC) (envelope-from gigabyte.tmn@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 2238D8FC17 for ; Wed, 23 Jun 2010 03:25:30 +0000 (UTC) Received: by fxm7 with SMTP id 7so3282258fxm.13 for ; Tue, 22 Jun 2010 20:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=YMCebRhvryJOExCOBq5vSl1jS4Syhmj9eAcF64v58OY=; b=TcnFMQXLDaHITKTU8NaOlbh9Z7OKtuXftD/9U+MmNrP5EEJRv/QtvlTjBYJXnay6of 3e8vfkWmtXv90t3xOkCgkGEA9ADJ0Vdqn+XTKpmL1FpU+sE+/tAdJDy3wpN/piFFWVkX nhrlskHDg2Zm7Wg6BxAENUR53njH9bLxZBzbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=NYLJ4yjFdP3IbD2Es0u3C/LOO8LnNjJBRdw45gzXIlgvzdjJYuT08zyQYMjXlHnhy1 bvJLtpB+NBeKdX6pWsDNo/N6sym2SWDe3rM10hTLqK1n6uwaw2mW6UKBLaFFt4I/pfQK 4KNoCD4cl4bQtWyjVpLRJSQwDxvdy5E9yAdB0= Received: by 10.223.113.69 with SMTP id z5mr169247fap.19.1277263528119; Tue, 22 Jun 2010 20:25:28 -0700 (PDT) Received: from 244.dynamic-n38.in72.ru ([91.203.38.244]) by mx.google.com with ESMTPS id a3sm31486349fak.40.2010.06.22.20.25.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Jun 2010 20:25:27 -0700 (PDT) Date: Wed, 23 Jun 2010 09:22:57 +0600 From: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?= X-Priority: 3 (Normal) Message-ID: <57156839.20100623092257@gmail.com> To: freebsd-net@freebsd.org In-Reply-To: <50a120641003241158t15806da9g5993cfc3c7099bc0@mail.gmail.com> References: <50a120641003190539n7d60348ev85416f2777d6c82c@mail.gmail.com> <50a120641003241158t15806da9g5993cfc3c7099bc0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dimm404@gmail.com Subject: [patch] ng_netflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 03:25:31 -0000 If you can, add information abount AS numbers too. ASN patch for 16-bit ASN's for V5 protocol: http://www.stasyan.com/devel/ng_netflow/patch_asnum_1 Proto V5 can't handle 32-bit ASN unlike V9. But I can't understand why it's not working for me, AS numbers exists for first time after I was load AS information to node, but after some minutes I have't see any AS information in netflow datagrams. > Hello. > I saw patches for ng_netflow to make netflow v9 there > http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022911.html > What's state of this patches? Is this code included in freebsd? Or will be > include in future release? From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 06:03:48 2010 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 17710106564A for ; Wed, 23 Jun 2010 06:03:48 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id E79328FC0A for ; Wed, 23 Jun 2010 06:03:47 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5N64UQq046218 for ; Tue, 22 Jun 2010 23:04:30 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C21A3C2.9050002@mahan.org> Date: Tue, 22 Jun 2010 23:03:46 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Multicast under FBSD 8.0 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, 23 Jun 2010 06:03:48 -0000 All, Hoping for a little insight as I am not a user of multicast nor do I know much about the servers that use them. In my day job, I am helping with the moving of my company's product from FreeBSD 6.2 (i386) to FreeBSD 8.0 (amd64). One of the daemons wants to use 224.0.0.9 (routed? rip?) multicast group. The problem is this worked fine on 6.2 but when we moved to 8.0 the daemon started reporting "Network unreachable" errors when it was trying to send a packet out to the multicast group. I tracked it down to the following in the routing table: % netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.10.1.1 UG 0 0 bce0 10.10.0.0/16 link#5 U 3 1253 bce0 ... 224.0.0.2 127.0.0.1 UH 0 0 lo0 224.0.0.9 127.0.0.1 UH 0 0 lo0 Notice that 224.0.0.9 has a route pointing to the loopback interface, even though the code uses the IP_MULTICAST_IF socket option to specify the interface. If this entry does not exist or points to a true physical interface, then there is no issue. I did some research on this and found this code all changed in in_pcb.c as part of revision 105629 for FreeBSD 7.2. But I don't understand why he change and why the loopback was no longer allowed. I get asked daily by the developers of this daemon for the reason, so I was hoping to get some enlightment here. Thanks for listening, Patrick From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 06:39:11 2010 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 301E61065676 for ; Wed, 23 Jun 2010 06:39:11 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 19CC38FC12 for ; Wed, 23 Jun 2010 06:39:11 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ORJc5-000IS7-1A; Wed, 23 Jun 2010 06:39:09 +0000 Date: Wed, 23 Jun 2010 15:39:08 +0900 Message-ID: From: Randy Bush To: Luigi Rizzo In-Reply-To: <20100622221228.GA93249@onelab2.iet.unipi.it> References: <20100622221228.GA93249@onelab2.iet.unipi.it> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 06:39:11 -0000 > We should instead use names with exact sizes (16,32,64). i think it should be pink From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:42:51 2010 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 959911065670 for ; Wed, 23 Jun 2010 07:42:51 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 720ED8FC26 for ; Wed, 23 Jun 2010 07:42:51 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o5N7glki050106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Jun 2010 00:42:48 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o5N7glKc050104; Wed, 23 Jun 2010 00:42:47 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA19530; Wed, 23 Jun 10 00:36:34 PDT Date: Wed, 23 Jun 2010 00:32:57 -0700 From: perryh@pluto.rain.com To: ralf@dzie-ciuch.pl Message-Id: <4c21b8a9./EVL61iCXfDcUxtj%perryh@pluto.rain.com> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 07:42:53 -0000 wrote: > I forgot send last time - on the other side is cisco router ... Perhaps vpnc would be easier to set up than raccoon? From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:43:09 2010 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 59D941065674 for ; Wed, 23 Jun 2010 07:43:09 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 109A88FC12 for ; Wed, 23 Jun 2010 07:43:08 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id BBF4F2798BC; Wed, 23 Jun 2010 09:43:04 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 9266C17063; Wed, 23 Jun 2010 09:43:04 +0200 (CEST) Date: Wed, 23 Jun 2010 09:43:04 +0200 From: VANHULLEBUS Yvan To: Maciej Suszko Message-ID: <20100623074304.GA74166@zeninc.net> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100622190819.270aaa74@gda-arsenic> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 07:43:09 -0000 Hi. On Tue, Jun 22, 2010 at 07:08:19PM +0200, Maciej Suszko wrote: [....] > Set up a gif tunnel in rc.conf: > > cloned_interfaces="gif0" > ifconfig_gif0="tunnel 78.x.x.x 95.x.x.x" > ifconfig_gif0_alias0="10.20.0.1 netmask 255.255.255.255 10.10.1.90" > > 10.20.0.1 is your internal end of the tunnel, so use any address from > beyond the net 10.10.1.90 is in. Using such extra encapsulation generates different kind of IPsec tunnels, which are sometimes used by some commercial devices (I guess at least juniper will use a variant of that), but this is NOT the usual way of setting up IPsec tunnels, and, afaik, this is probably completely useless here (no extra feature provided, and I don't think cisco devices uses such extra encapsulation). Btw, his issue occurs with first phase1 exchange, so actually has NOTHING to do with that part of negociation... > in racoon.conf something like this: > > remote 95.x.x.x [500] > { > exchange_mode main,aggressive; [....] > proposal_check obey; This is a quite perfect example of what should NOT exist in a correct IPsec configuration: Once again, aggressive mode is NOT as secure as main mode, and should be avoided as most as possible. And proposal_check obey is really one of the worst idea people can have when adding things to their racoon.conf, as it just disables proposal check when we are responder !!!! Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:54:06 2010 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 CC0C5106564A for ; Wed, 23 Jun 2010 07:54:06 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE0D8FC18 for ; Wed, 23 Jun 2010 07:54:05 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 73C4022910; Wed, 23 Jun 2010 09:53:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laKZLBmkrU8T; Wed, 23 Jun 2010 09:53:56 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 34119228F9; Wed, 23 Jun 2010 09:53:56 +0200 (CEST) To: Maciej Suszko X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 09:53:56 +0200 From: In-Reply-To: <20100622204107.6c604c17@gda-arsenic> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> Message-ID: X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 07:54:06 -0000 Hi, I set everything like you wrote and I can send and receice packets but still I can't ping to host 10.10.1.90, and when I type #setkey -D there is no SAD entry What could it be? This is part of racoon log: Jun 23 09:43:57 czesio racoon: DEBUG: === Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's private. Jun 23 09:43:57 czesio racoon: DEBUG: 5b119f45 9108a35d 61341d54 ce28f645 fac5ef8d 417013a1 455ba09f 945ab1ef 81243118 8efcdc9c f6721a38 e230ab74 8302deeb c92c06c3 6324cdf0 2bc52859 032a0bcf 516c94e3 7c99eb28 1f0cde23 9afc4515 07795202 666d124d 76d74e47 8ab70799 b48d5f67 9d228ef9 1a266f0b 194b327a 15fffe6c b87cdbd0 650ee521 Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's public. Jun 23 09:43:57 czesio racoon: DEBUG: 3492c8a7 2662325a d8039260 2fc9c105 0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa 0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c 821d818a 1370a9dd b100a947 3f782a00 Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 128, next type 10 Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 16, next type 0 Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes from 78.x.x.x[500] to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: sockname 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: send packet from 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: send packet to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 1 times of 180 bytes message will be sent to 95.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 01505a49 433e1cff 8cb6b14b 5ec59b4e 04100200 00000000 000000b4 0a000084 3492c8a7 2662325a d8039260 2fc9c105 0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa 0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c 821d818a 1370a9dd b100a947 3f782a00 00000014 c75cf3fa 12f5c5dc 0b66e5a2 4e37bdf6 Jun 23 09:43:57 czesio racoon: DEBUG: resend phase1 packet 01505a49433e1cff:8cb6b14b5ec59b4e Jun 23 09:43:57 czesio racoon: DEBUG: === Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes message received from 95.x.x.x[500] to 78.x.x.x[500] Jun 23 09:43:57 czesio racoon: DEBUG: 01505a49 433e1cff 8cb6b14b 5ec59b4e 04100200 00000000 000000b4 0a000084 38b0ea0f 68a0d78e b41143b5 0b52d522 8b6a5a44 892d78fa a5ff87e5 1fdd2df8 51246c25 1743a162 0785ff3d 9e0ac5b0 39568149 8e327c35 d20459cc 44512c02 cf620450 b04a708a ae85f00d 11d58f58 c19f9b65 f8ec1cf9 160406e3 a072036c 6b2c82f2 4cc8fed5 312d4abe 75c05d7d f8f12fc9 d0cbca01 aaa62b6e 0c491a30 00000014 0fdab028 1038d6ff 32782dd2 97d9208e Jun 23 09:43:57 czesio racoon: DEBUG: begin. Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=4(ke) Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=10(nonce) Jun 23 09:43:57 czesio racoon: DEBUG: succeed. Jun 23 09:43:57 czesio racoon: DEBUG: === On Tue, 22 Jun 2010 20:41:07 +0200, Maciej Suszko wrote: > "David DeSimone" wrote: >> Maciej Suszko wrote: >> > >> > > So as you write they should set: ?? >> > > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90 >> > > (other side) >> > >> > Yes, indeed. >> > >> > > And additionaly I thing I should correct set spd policy to: >> > > >> > > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec >> > > esp/tunnel/78.x.x.x-95.x.x.x/require; >> > > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec >> > > esp/tunnel/95.x.x.x-78.x.x.x/require; >> > > >> > > Am I wrong? >> > >> > No, you're right :) >> > >> > You can set up the tunnel first - check whether both 10. are >> > accessible from both sides, then you "cover" communication between >> > them with IPSEC. >> >> Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint >> VPN equipment? In our tests we were able to use pure IPSEC tunnel >> encapsulation to interoperate with these sorts of devices, so we never >> found a need for GIF encapsulation. > > I'm not sure what's on the other side, AFAIK some hardware solution. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:59:52 2010 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 20AC1106566B for ; Wed, 23 Jun 2010 07:59:52 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id A3E618FC14 for ; Wed, 23 Jun 2010 07:59:51 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.4/8.14.4) with ESMTP id o5N7d8hR022259 for ; Wed, 23 Jun 2010 09:39:09 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 504BD5A for ; Wed, 23 Jun 2010 09:39:08 +0200 (CEST) Date: Wed, 23 Jun 2010 09:39:08 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-net@freebsd.org Message-Id: <20100623093908.e73f5327.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.6.23.73015 Subject: firewalling broadcast and multicast packets 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, 23 Jun 2010 07:59:52 -0000 Hi all, I just tried to block multicast and broadcast packets on a transparent bridge with pf by filtering on one of the physical interfaces like this: table persist {10.117.255.255/32} netbios = "netbios-ns, netbios-dgm, netbios-ssn, mdns, ipp" block quick on $ext_if proto ipv6 block quick on $ext_if proto udp from any port { $netbios } block quick on $ext_if proto udp to any port { $netbios } block quick on $ext_if inet from any to However, the packets are still passing the bridge as can be seen with tcpdump on the internal interface: 09:36:39.167995 IP newprintserver.fqdn-omitted.ipp > 10.117.255.255.ipp: UDP, length 94 Kernel settings are like this: net.link.bridge.ipfw: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 1 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 I am using a recent 8.1-prerelease. Before I start putting more time in solving this problem I just wanted to ask here if this is supposed to work at all, or if I am doing something terribly wrong from the beginning on. cu Gerrit From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:06:01 2010 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 574DF106566C for ; Wed, 23 Jun 2010 08:06:01 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5788FC15 for ; Wed, 23 Jun 2010 08:05:57 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id E164B2798BC; Wed, 23 Jun 2010 10:05:55 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id B895717063; Wed, 23 Jun 2010 10:05:55 +0200 (CEST) Date: Wed, 23 Jun 2010 10:05:55 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100623080555.GB74303@zeninc.net> References: <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:06:01 -0000 On Wed, Jun 23, 2010 at 09:53:56AM +0200, ralf@dzie-ciuch.pl wrote: > > Hi, Hi. > I set everything like you wrote and I can send and receice packets but > still I can't ping to host 10.10.1.90, > and when I type #setkey -D there is no SAD entry > > What could it be? > > This is part of racoon log: [....] Do you have a line which says: INFO: ISAKMP-SA established Until you have such line, you still have issues with your phase 1 negociation, and we'll need almost a full debug to be able to help you (be careful: there are some private informations in such debug, like public IPs, preshared-keys, etc....). Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:28:59 2010 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 90224106564A; Wed, 23 Jun 2010 08:28:59 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5E08FC18; Wed, 23 Jun 2010 08:28:59 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id BC71E2291D; Wed, 23 Jun 2010 10:28:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDEBkZ49kFZZ; Wed, 23 Jun 2010 10:28:50 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 521A822958; Wed, 23 Jun 2010 10:28:48 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 10:28:48 +0200 From: In-Reply-To: <20100623080555.GB74303@zeninc.net> References: <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> Message-ID: <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:28:59 -0000 Ok I found that my psk.txt has got wrong permissions Now I can get SAD keys! ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] spi:8a8881ee5182cbfb:53dab6ad5a65629d But one thing - why can't I ping 10.10.1.90? Regards Ralf On Wed, 23 Jun 2010 10:05:55 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 09:53:56AM +0200, ralf@dzie-ciuch.pl wrote: >> >> Hi, > > Hi. > > >> I set everything like you wrote and I can send and receice packets but >> still I can't ping to host 10.10.1.90, >> and when I type #setkey -D there is no SAD entry >> >> What could it be? >> >> This is part of racoon log: > [....] > Do you have a line which says: > > INFO: ISAKMP-SA established > > > Until you have such line, you still have issues with your phase 1 > negociation, and we'll need almost a full debug to be able to help you > (be careful: there are some private informations in such debug, like > public IPs, preshared-keys, etc....). > > > Yvan. > _______________________________________________ > 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 Jun 23 08:32:30 2010 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 BE1FC106564A for ; Wed, 23 Jun 2010 08:32:30 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7523B8FC28 for ; Wed, 23 Jun 2010 08:32:30 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 455CD2798BC; Wed, 23 Jun 2010 10:32:29 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 2640C17063; Wed, 23 Jun 2010 10:32:29 +0200 (CEST) Date: Wed, 23 Jun 2010 10:32:29 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100623083228.GA74453@zeninc.net> References: <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:32:30 -0000 On Wed, Jun 23, 2010 at 10:28:48AM +0200, ralf@dzie-ciuch.pl wrote: > Ok I found that my psk.txt has got wrong permissions Yes, we'll have to set up a more explicit error message when psk file has wrong permissions..... > Now I can get SAD keys! > > ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] > spi:8a8881ee5182cbfb:53dab6ad5a65629d According to that log, you coud establish an IsakmpSA, so only the phase1 is ok.... Do you also have later some logs like: : INFO : IPsec-SA established: ESP/Tunnel Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:37:29 2010 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 8B7AE1065672; Wed, 23 Jun 2010 08:37:29 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 498E48FC0C; Wed, 23 Jun 2010 08:37:29 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id C0BEA22930; Wed, 23 Jun 2010 10:37:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdjN5T-UGjmo; Wed, 23 Jun 2010 10:37:19 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id DD91B2291D; Wed, 23 Jun 2010 10:37:18 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 10:37:18 +0200 From: In-Reply-To: <20100623083228.GA74453@zeninc.net> References: <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> Message-ID: X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:37:29 -0000 On Wed, 23 Jun 2010 10:32:29 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 10:28:48AM +0200, ralf@dzie-ciuch.pl wrote: >> Ok I found that my psk.txt has got wrong permissions > > Yes, we'll have to set up a more explicit error message when psk file > has wrong permissions..... Ok. I fix it using chmod 0600 psk.txt > > >> Now I can get SAD keys! >> >> ISAKMP-SA established 78.x.x.x[500]-95.x.x.x[500] >> spi:8a8881ee5182cbfb:53dab6ad5a65629d > > According to that log, you coud establish an IsakmpSA, so only the > phase1 is ok.... > > Do you also have later some logs like: > : INFO : IPsec-SA established: ESP/Tunnel > Yes I got: 2010-06-23 10:18:06: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel 78.x.x.x[0]->95.x.x.x[0] spi=3926551409(0xea0a6b71) 2010-06-23 10:25:30: DEBUG: (proto_id=ESP spisize=4 spi=00000000 spi_p=00000000 encmode=Tunnel reqid=0:0) 2010-06-23 10:25:30: DEBUG: pfkey GETSPI sent: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] 2010-06-23 10:25:30: DEBUG: pfkey GETSPI succeeded: ESP/Tunnel 95.x.x.x[0]->78.x.x.x[0] spi=126966409(0x7915a89) Is it good? Ralf From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:45:23 2010 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 10062106566B for ; Wed, 23 Jun 2010 08:45:23 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id B8F288FC24 for ; Wed, 23 Jun 2010 08:45:22 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 914112798BC; Wed, 23 Jun 2010 10:45:19 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 78D4F17063; Wed, 23 Jun 2010 10:45:19 +0200 (CEST) Date: Wed, 23 Jun 2010 10:45:19 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100623084519.GA74491@zeninc.net> References: <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:45:23 -0000 On Wed, Jun 23, 2010 at 10:37:18AM +0200, ralf@dzie-ciuch.pl wrote: [...] > > Do you also have later some logs like: > > : INFO : IPsec-SA established: ESP/Tunnel > > > > Yes I got: > > 2010-06-23 10:18:06: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) > 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=224712000(0xd64d540) > 2010-06-23 10:18:06: INFO: IPsec-SA established: ESP/Tunnel > 78.x.x.x[0]->95.x.x.x[0] spi=3926551409(0xea0a6b71) > 2010-06-23 10:25:30: DEBUG: (proto_id=ESP spisize=4 spi=00000000 > spi_p=00000000 encmode=Tunnel reqid=0:0) > 2010-06-23 10:25:30: DEBUG: pfkey GETSPI sent: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] > 2010-06-23 10:25:30: DEBUG: pfkey GETSPI succeeded: ESP/Tunnel > 95.x.x.x[0]->78.x.x.x[0] spi=126966409(0x7915a89) > > Is it good? Looks like, but if you still can't ping, you still have an issue somewhere :-) First, check that you now have ESP packets going out from your IPsec gate when you try to ping. Then, usual issues at that step are: - something on the way blocks ESP packets. Solution may be to force NAT-T (add "nat_traversal force;" line in remote section). - IPsec peers has some filtering rules/ACLs which blocks your traffic after IPsec. - Peer does not have a default route, or somethinng like that which prevents it to reply to you. Anyways, the best tool now to see what happens is tcpdump.... on peer's side !!!! Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:53:10 2010 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 90CF51065675; Wed, 23 Jun 2010 08:53:10 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5898FC1B; Wed, 23 Jun 2010 08:53:10 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id B917A22919; Wed, 23 Jun 2010 10:53:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtNootq9N1Vh; Wed, 23 Jun 2010 10:53:01 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 10B092299D; Wed, 23 Jun 2010 10:52:19 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 10:52:19 +0200 From: In-Reply-To: <20100623084519.GA74491@zeninc.net> References: <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> <20100623084519.GA74491@zeninc.net> Message-ID: X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:53:10 -0000 > > Looks like, but if you still can't ping, you still have an issue > somewhere :-) > > First, check that you now have ESP packets going out from your IPsec > gate when you try to ping. > > > Then, usual issues at that step are: > > - something on the way blocks ESP packets. Solution may be to force > NAT-T (add "nat_traversal force;" line in remote section). > > - IPsec peers has some filtering rules/ACLs which blocks your traffic > after IPsec. > > - Peer does not have a default route, or somethinng like that which > prevents it to reply to you. > > Anyways, the best tool now to see what happens is tcpdump.... on > peer's side !!!! > When on one console i type tcpdump -i gif0 I don't receive any values! So I thing I should set route do it right? Can you tell me how to do it? netstat -rn print something like this: Destination Gateway Flags Refs Use Netif Expire default 78.x.x.x UGS 3 49544466 bce1 10.10.1.90 10.20.0.1 UH 2238 13439 gif0 Is it ok? or I do something wrong? Ralf From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:58:34 2010 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 F35D01065678 for ; Wed, 23 Jun 2010 08:58:34 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id DA58E8FC26 for ; Wed, 23 Jun 2010 08:58:33 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id BAAA42798BC; Wed, 23 Jun 2010 10:58:31 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id A4E5617063; Wed, 23 Jun 2010 10:58:31 +0200 (CEST) Date: Wed, 23 Jun 2010 10:58:31 +0200 From: VANHULLEBUS Yvan To: ralf@dzie-ciuch.pl Message-ID: <20100623085831.GA74559@zeninc.net> References: <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> <20100623084519.GA74491@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 08:58:35 -0000 On Wed, Jun 23, 2010 at 10:52:19AM +0200, ralf@dzie-ciuch.pl wrote: [....] > When on one console i type tcpdump -i gif0 I don't receive any values! > So I thing I should set route do it right? > > Can you tell me how to do it? > > netstat -rn print something like this: > Destination Gateway Flags Refs Use Netif Expire > default 78.x.x.x UGS 3 49544466 bce1 > 10.10.1.90 10.20.0.1 UH 2238 13439 gif0 > > Is it ok? or I do something wrong? Check with your peer's configuration, but using such extra IP-IP encapsulation (via gif interfaces on FreeBSD) is NOT the usual way of setting up IPsec tunnels.... If your peer expects usual IPsec setups, you should just have SPD entries as specified in your very first mails. Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 09:07:10 2010 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 EC5301065675; Wed, 23 Jun 2010 09:07:10 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id A98098FC29; Wed, 23 Jun 2010 09:07:10 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id 2260122910; Wed, 23 Jun 2010 11:07:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNdv8ZHBZ1HG; Wed, 23 Jun 2010 11:07:01 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id 260BC228F9; Wed, 23 Jun 2010 11:07:01 +0200 (CEST) To: VANHULLEBUS Yvan X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 11:07:01 +0200 From: In-Reply-To: <20100623085831.GA74559@zeninc.net> References: <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> <20100623084519.GA74491@zeninc.net> <20100623085831.GA74559@zeninc.net> Message-ID: <292cf4e1f2be5823aaef46907565f9c6@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 09:07:11 -0000 Hmmm, Maybe I do some error using gateway 10.20.0.1? Maybe I have to set something in route to network 10.10.1.x go throught gif0 interface? Ralf On Wed, 23 Jun 2010 10:58:31 +0200, VANHULLEBUS Yvan wrote: > On Wed, Jun 23, 2010 at 10:52:19AM +0200, ralf@dzie-ciuch.pl wrote: > [....] >> When on one console i type tcpdump -i gif0 I don't receive any values! >> So I thing I should set route do it right? >> >> Can you tell me how to do it? >> >> netstat -rn print something like this: >> Destination Gateway Flags Refs Use Netif >> Expire >> default 78.x.x.x UGS 3 49544466 bce1 >> 10.10.1.90 10.20.0.1 UH 2238 13439 gif0 >> >> Is it ok? or I do something wrong? > > Check with your peer's configuration, but using such extra IP-IP > encapsulation (via gif interfaces on FreeBSD) is NOT the usual way of > setting up IPsec tunnels.... > > > If your peer expects usual IPsec setups, you should just have SPD > entries as specified in your very first mails. > > > Yvan. > _______________________________________________ > 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 Jun 23 11:34:57 2010 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 7EBAB106564A for ; Wed, 23 Jun 2010 11:34:57 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from mail.suszko.eu (suszko.eu [174.136.96.226]) by mx1.freebsd.org (Postfix) with ESMTP id 64B238FC12 for ; Wed, 23 Jun 2010 11:34:57 +0000 (UTC) Received: from oxygen.suszko.eu (localhost [127.0.0.1]) by mail.suszko.eu (Postfix) with ESMTP id 017873F486; Wed, 23 Jun 2010 11:27:03 +0000 (UTC) X-Virus-Scanned: amavisd-new using ClamaAV Received: from helium (biuro.easygo.pl [81.95.206.139]) by mail.suszko.eu (Postfix) with ESMTPSA id D36603F474; Wed, 23 Jun 2010 11:27:01 +0000 (UTC) Date: Wed, 23 Jun 2010 13:34:52 +0200 From: Maciej Suszko To: freebsd-net@freebsd.org Message-ID: <20100623133452.6103f223@helium> In-Reply-To: <292cf4e1f2be5823aaef46907565f9c6@ewipo.pl> References: <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> <20100623084519.GA74491@zeninc.net> <20100623085831.GA74559@zeninc.net> <292cf4e1f2be5823aaef46907565f9c6@ewipo.pl> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: vpn trouble 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, 23 Jun 2010 11:34:57 -0000 wrote: > > Hmmm, > > Maybe I do some error using gateway 10.20.0.1? > Maybe I have to set something in route to network 10.10.1.x go > throught gif0 interface? First of all, find out what the other side configuration is. My configuration was only proposal. -- regards, Maciej Suszko. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 11:35:09 2010 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 04FB1106564A for ; Wed, 23 Jun 2010 11:35:09 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA6F8FC1B for ; Wed, 23 Jun 2010 11:35:08 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id C162022910; Wed, 23 Jun 2010 13:35:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfRahyr59nOW; Wed, 23 Jun 2010 13:34:58 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id AC24F228F9; Wed, 23 Jun 2010 13:34:58 +0200 (CEST) To: Maciej Suszko X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 13:34:58 +0200 From: In-Reply-To: <20100622202636.714bced5@gda-arsenic> References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622171944.GQ2620@verio.net> <7255fc10973166ff686d074fba3fc0f6@ewipo.pl> <20100622202636.714bced5@gda-arsenic> Message-ID: <6bcf71f4d76ae431c2c614eeed6dbd64@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 11:35:09 -0000 Thanks guys it's working. I couldn't ping 10.10.1.90 (external network) but they could ping me. I got another question: How to set another tunnel to me host like: 10.20.0.1 (my gif0) --> 78.x.x.x (my bce1) <---> 78.y.y.y <--> 10.20.1.1 I copy 2 lines (with changing ip's) so now i got 4 lines and I opy block remote and sainfo in racoon.conf. I restart racoon and now I could only connect to 95.x.x.x (like last time) but to 78.y.y.y I counldn't Is it possible to do not create interface gif1 or should I do it? Have I change someting in route table? Regards Ralf On Tue, 22 Jun 2010 20:26:36 +0200, Maciej Suszko wrote: > wrote: >> >> Hi, >> >> I try to set VPN like I wrote earlier. >> 78.x is server and this is not NAT. He dont forward anything. >> >> >> I try to configure VPN over my server and my client >> >> >> >> Sheme is like this >> >> 78.x.x.x <--> 95.x.x.x <--> 10.10.1.90 >> > >> > Are you trying to set up IPSEC tunneling of networks behind these >> > gateways, or are you only trying to secure traffic between the peers >> > themselves? >> >> I try to set tunnel behing my server 78.x and gateway 95.x translating >> packets to 10.x. I can only set 78.x side. >> >> > >> > The fact that you don't receive any reply to your IKE packets would >> > indicate something basic, like something is blocking traffic. >> >> But how to check it? Telnet to port 500 wont work. But when I set SSH >> to listen on port 500 I can login, port is not blocked > > Telnet host 500 uses proto tcp, isakmp - udp. > >> >> # setkey -DP >> >> 10.10.1.90[any] 78.x.x.x[any] any >> >> in ipsec >> >> esp/tunnel/95.x.x.x-78.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:39:25 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16461 seq=1 pid=83142 >> >> refcnt=1 >> >> 78.x.x.x[any] 10.10.1.90[any] any >> >> out ipsec >> >> esp/tunnel/78.x.x.x-95.x.x.x/require >> >> created: Jun 22 15:39:25 2010 lastused: Jun 22 15:40:50 >> >> 2010 lifetime: 0(s) validtime: 0(s) >> >> spid=16460 seq=0 pid=83142 >> >> refcnt=1 >> > >> > Your IPSEC policy specifies "esp/tunnel" mode, but if you are not >> > actually encapsulating traffic originating from somewhere else, you >> > might do better to just use "transport" mode to encrypt without >> > encapsulation. >> >> Hmmm, I don't understand it? I set policy only for there IP's and >> connection for it is ESP encrypced >> >> > >> >> And tcpdump >> >> #tcpdump -i bce1 host 95.x.x.x >> >> >> >> >> >> 15:53:47.355130 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:54:07.003371 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> >> 15:57:39.067765 IP 78.x.x.x.isakmp > 95.x.x.x.isakmp: isakmp: >> >> phase 1 I ident >> > >> > My first thought was that your IPSEC policy attempts to encrypt all >> > traffic between you and your peers, but the IKE traffic is also >> > traffic between you and your peers, so doesn't it lead to a policy >> > loop of some sort? Will the IPSEC layer attempt to capture and >> > encrypt the IKE packets? >> >> Can you explain how can I check it? I new on it and I don't understand >> some things. > > I've got such tunnels up and working - tunnel mode, encryption between > peers, without using any internal networks - strange, but working :) - > policy looks like that: > spdadd 195.x.x.x 213.x.x.x any -P out ipsec > esp/tunnel/195.x.x.x-213.x.x.x/require; > spdadd 213.x.x.x 195.x.x.x any -P in ipsec > esp/tunnel/213.x.x.x-195.x.x.x/require; From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 11:36:38 2010 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 60B1B1065674 for ; Wed, 23 Jun 2010 11:36:38 +0000 (UTC) (envelope-from ralf@dzie-ciuch.pl) Received: from mail.ewipo.pl (mail.ewipo.pl [94.23.240.128]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6848FC16 for ; Wed, 23 Jun 2010 11:36:38 +0000 (UTC) Received: from mail.ewipo.pl (localhost [127.0.0.1]) by mail.ewipo.pl (Postfix) with ESMTP id A712922902; Wed, 23 Jun 2010 13:36:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at wrealizacji.pl Received: from mail.ewipo.pl ([127.0.0.1]) by mail.ewipo.pl (mail.ewipo.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UQHhNq3JtTb; Wed, 23 Jun 2010 13:36:28 +0200 (CEST) Received: by mail.ewipo.pl (Postfix, from userid 80) id ECBC322915; Wed, 23 Jun 2010 13:36:28 +0200 (CEST) To: Maciej Suszko X-PHP-Script: poczta.wrealizacji.pl/index.php for 89.171.191.50 MIME-Version: 1.0 Date: Wed, 23 Jun 2010 13:36:28 +0200 From: In-Reply-To: <20100623133452.6103f223@helium> References: <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <20100622204107.6c604c17@gda-arsenic> <20100623080555.GB74303@zeninc.net> <5e8d1141ecf3d922c00114e41585a67f@ewipo.pl> <20100623083228.GA74453@zeninc.net> <20100623084519.GA74491@zeninc.net> <20100623085831.GA74559@zeninc.net> <292cf4e1f2be5823aaef46907565f9c6@ewipo.pl> <20100623133452.6103f223@helium> Message-ID: <362efa2fc1af905d2132edf656f5602e@ewipo.pl> X-Sender: ralf@dzie-ciuch.pl User-Agent: EWIPO Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 11:36:38 -0000 But its working!! Ralf On Wed, 23 Jun 2010 13:34:52 +0200, Maciej Suszko wrote: > wrote: >> >> Hmmm, >> >> Maybe I do some error using gateway 10.20.0.1? >> Maybe I have to set something in route to network 10.10.1.x go >> throught gif0 interface? > > First of all, find out what the other side configuration is. My > configuration was only proposal. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 13:33:32 2010 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 C5CC3106564A for ; Wed, 23 Jun 2010 13:33:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3098FC0A for ; Wed, 23 Jun 2010 13:33:31 +0000 (UTC) Received: from c122-106-145-229.carlnfd1.nsw.optusnet.com.au (c122-106-145-229.carlnfd1.nsw.optusnet.com.au [122.106.145.229]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5NDXPdg006808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jun 2010 23:33:28 +1000 Date: Wed, 23 Jun 2010 23:33:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Luigi Rizzo In-Reply-To: <20100622221228.GA93249@onelab2.iet.unipi.it> Message-ID: <20100623232402.X45536@delplex.bde.org> References: <20100622221228.GA93249@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 13:33:32 -0000 On Wed, 23 Jun 2010, Luigi Rizzo wrote: > On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: >> Hi all: >> >> I have had some fun in my day job playing with exchanging 64bit >> numbers. Unfortunately >> there is no ntohll() OR htonll() which would be the logical thing (for >> us old farts) to use. >> >> Yes, I have found htobe64() and friends.. and that would work.. but I >> still cannot >> help but feeling we should have the ntohll() and htonll().. for >> consistency if nothing >> else. >> >> Any objections to this showing up in a head near you soon (speak soon >> or I will commit >> the patches to add these ;-D) > > strong objection! > We should instead use names with exact sizes (16,32,64). Yes, long long should not exist, and there are few places where exact sizes should be used, but networking code is one place where they should be used. ntohs() will break semantically or actually on machines with shorts with more than 16 bits. ntohl() is already broken semantically on machines with longs with more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually handle longs on such arches. Networking code handles a few cases related to this with n_long. This is not quite as bad, but its name is nonsense -- n_long is very far from being a long -- it is unsigned 32 bits exactly, unlike long which is signed >= 32 bits. ntohll() would break similarly on machines with long longs with more or less than 64 bits. In practice this and other misuses of long long may prevent the size of long long being changed, like it prevented the size of long being changed on some systems with historical abuses of long. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 16:50:44 2010 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 63A49106564A for ; Wed, 23 Jun 2010 16:50:44 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 16D138FC21 for ; Wed, 23 Jun 2010 16:50:43 +0000 (UTC) Received: from mobile-166-187-091-069.mycingular.net (mobile-166-187-091-069.mycingular.net [166.187.91.69] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5NGoYtM003718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jun 2010 12:50:41 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277311843; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=HB7DLhrgkbOysExXbTn2gg1wr/jUZz2CGr6oNX76Mx2KodxIt3/RFpX y2kbFY7brcOyYCwtJmIT8OCuKdVSmIw== Message-Id: <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> From: Randall Stewart To: Bruce Evans In-Reply-To: <20100623232402.X45536@delplex.bde.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Jun 2010 09:50:26 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> X-Mailer: Apple Mail (2.936) Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 16:50:44 -0000 Bruce: Comments (and questions in-line)... (you too Luigi) On Jun 23, 2010, at 6:33 AM, Bruce Evans wrote: > On Wed, 23 Jun 2010, Luigi Rizzo wrote: > >> On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote: >>> Hi all: >>> >>> I have had some fun in my day job playing with exchanging 64bit >>> numbers. Unfortunately >>> there is no ntohll() OR htonll() which would be the logical thing >>> (for >>> us old farts) to use. >>> >>> Yes, I have found htobe64() and friends.. and that would work.. >>> but I >>> still cannot >>> help but feeling we should have the ntohll() and htonll().. for >>> consistency if nothing >>> else. >>> >>> Any objections to this showing up in a head near you soon (speak >>> soon >>> or I will commit >>> the patches to add these ;-D) >> >> strong objection! >> We should instead use names with exact sizes (16,32,64). So please tell me why you object so strongly? We have the 16/32/64 bit names which are nice but are not expected so folks seem to not use them. I have received a few private comments to the effect that "Gee, we would like that, we rolled our own versions of ntohll() and if you did it we could remove our version". This tells me that although a nicer name, folks are rolling their own due to the name. Having a #define that maps ntohll -> be64toh will make it so that people can actually find the function. Name changes are a good thing for clarity but if no one will use your changed name and roll their own.. thats a bad thing. By having such a define you might encourage folks (over time) to transition off to the more clear naming versions.. > > Yes, long long should not exist, and there are few places where exact > sizes should be used, but networking code is one place where they > should be used. > > ntohs() will break semantically or actually on machines with shorts > with > more than 16 bits. So two questions here: a) What machines that we do support currently have a short larger than 16bits? b) Does anyone that use networking code really expect ntohs() to do anything different than a 16 bit byte swap? The man page is pretty clear on it i.e. uint16_t is the input and its a "network short" which if I remember right is defined to be 16 bits... At least most RFC's are pretty clear and the same is true for UNP Vol 1 ;-) > > ntohl() is already broken semantically on machines with longs with > more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually > handle longs on such arches. Networking code handles a few cases > related > to this with n_long. This is not quite as bad, but its name is > nonsense -- > n_long is very far from being a long -- it is unsigned 32 bits > exactly, > unlike long which is signed >= 32 bits. again same two questions only change them to say 32 bits? > > ntohll() would break similarly on machines with long longs with more > or less than 64 bits. In practice this and other misuses of long long > may prevent the size of long long being changed, like it prevented the > size of long being changed on some systems with historical abuses of > long. Again same first question... the second one I would ask too except the function does NOT exist (except where folks go out and roll it themselves). Basically I don't agree with your assessment since these functions are designed to operate on network code which I think defines a short = 16, a long = 32 (at least all RFC's I have read do that anyway). And it appears from feedback I have received that ntohll would be defined as a 64bit network quantity in most folks minds since that what a lot of folks have implemented... R > > Bruce > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 17:02:02 2010 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 C8F63106564A for ; Wed, 23 Jun 2010 17:02:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8D87B8FC08 for ; Wed, 23 Jun 2010 17:02:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A87EF73098; Wed, 23 Jun 2010 19:12:22 +0200 (CEST) Date: Wed, 23 Jun 2010 19:12:22 +0200 From: Luigi Rizzo To: Randall Stewart Message-ID: <20100623171222.GA7981@onelab2.iet.unipi.it> References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> User-Agent: Mutt/1.4.2.3i Cc: net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 17:02:02 -0000 On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: ... > >>strong objection! > >>We should instead use names with exact sizes (16,32,64). > > So please tell me why you object so strongly? We have the 16/32/64 bit > names which > are nice but are not expected so folks seem to not use them. I have people's ignorance is not an excuse for not doing things right. We'd still be using BYTE, WORD and DWORD otherwise. I think there is no doubt that we should use the 16/32/64 bit names if we could start from scratch, and the only reason for not doing so is avoiding gratuitous changes to existing/stable code. The case of *to*ll does not apply, in that there is no actual legacy to adapt to. And btw there is tons of places which use the 16/32/64 bit names in the filesystem, usb and generic device drivers. In fact, many more than ntohl/htonl > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 1438 6397 145174 > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc 2203 10269 210989 > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc 854 4009 84855 > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc 738 3604 72970 cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 19:43:25 2010 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 CA745106564A for ; Wed, 23 Jun 2010 19:43:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-23.mx.aerioconnect.net [216.240.47.83]) by mx1.freebsd.org (Postfix) with ESMTP id A91568FC13 for ; Wed, 23 Jun 2010 19:43:25 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o5NJgqO5025085; Wed, 23 Jun 2010 12:42:55 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 409272D6012; Wed, 23 Jun 2010 12:40:44 -0700 (PDT) Message-ID: <4C226354.80601@elischer.org> Date: Wed, 23 Jun 2010 12:41:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Luigi Rizzo References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> In-Reply-To: <20100623171222.GA7981@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Randall Stewart , net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 19:43:25 -0000 On 6/23/10 10:12 AM, Luigi Rizzo wrote: > On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: > ... >>>> strong objection! >>>> We should instead use names with exact sizes (16,32,64). >> >> So please tell me why you object so strongly? We have the 16/32/64 bit >> names which >> are nice but are not expected so folks seem to not use them. I have > > people's ignorance is not an excuse for not doing things right. > We'd still be using BYTE, WORD and DWORD otherwise. > > I think there is no doubt that we should use the 16/32/64 bit names > if we could start from scratch, and the only reason for not doing > so is avoiding gratuitous changes to existing/stable code. > > The case of *to*ll does not apply, in that there is no actual legacy > to adapt to. And btw there is tons of places which use the 16/32/64 bit > names in the filesystem, usb and generic device drivers. In fact, > many more than ntohl/htonl > > > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > 1438 6397 145174 > > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > 2203 10269 210989 > > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc > 854 4009 84855 > > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc > 738 3604 72970 what he said.. if you want to have ntohll in SCTP then that is your choice, but I think it should be a local define to be64toh or ntoh64 I do prefer the ntoh64 version but beXXtoh or whatever it looks like others are using is ok to me too since 'net' is a pretty wide definition and not ALL protocols are big endian. From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 19:57:17 2010 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 DA8AA106564A for ; Wed, 23 Jun 2010 19:57:17 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 798138FC0C for ; Wed, 23 Jun 2010 19:57:17 +0000 (UTC) Received: from mobile-166-187-091-069.mycingular.net (mobile-166-187-091-069.mycingular.net [166.187.91.69] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5NJv4c9012600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Jun 2010 15:57:11 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277323033; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=HVBmkIt1rOH2aHsNIX0utzPI7TKRrNbwGEm/nJ/g4ReDylJKU9DE265 9SStyECot4YHfQMXuXb0bOnPSUq1Hwg== Message-Id: From: Randall Stewart To: Julian Elischer In-Reply-To: <4C226354.80601@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Jun 2010 12:56:58 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> X-Mailer: Apple Mail (2.936) Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 23 Jun 2010 19:57:18 -0000 On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote: > On 6/23/10 10:12 AM, Luigi Rizzo wrote: >> On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: >> ... >>>>> strong objection! >>>>> We should instead use names with exact sizes (16,32,64). >>> >>> So please tell me why you object so strongly? We have the 16/32/64 >>> bit >>> names which >>> are nice but are not expected so folks seem to not use them. I have >> >> people's ignorance is not an excuse for not doing things right. >> We'd still be using BYTE, WORD and DWORD otherwise. >> >> I think there is no doubt that we should use the 16/32/64 bit names >> if we could start from scratch, and the only reason for not doing >> so is avoiding gratuitous changes to existing/stable code. >> >> The case of *to*ll does not apply, in that there is no actual legacy >> to adapt to. And btw there is tons of places which use the 16/32/64 >> bit >> names in the filesystem, usb and generic device drivers. In fact, >> many more than ntohl/htonl >> >> > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 1438 6397 145174 >> > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 2203 10269 210989 >> > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 854 4009 84855 >> > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc >> 738 3604 72970 > > > what he said.. > > if you want to have ntohll in SCTP then that is your choice, SCTP does not have a case for sending 64 bit things... This is my day job and other folks looking for nothll() and friends... > but I think it > should be a local define to be64toh or ntoh64 > I do prefer the ntoh64 version but beXXtoh or whatever it looks like > others are using is ok to me too since 'net' is a pretty wide > definition and not ALL protocols are big endian. Well thats fine, we can let folks continue rolling there own if thats what y'all want. I really don't care actually... I already have the ifdef's in place in my day-job app code.. so its no big deal ;-) I will make this last comment.. directed at Luigi in response to: >> people's ignorance is not an excuse for not doing things right Then I would strongly suggest you go fix the manual page for ntohl/ ntohs and point people to the be64toh() functions... then people would NOT be ignorant. The problem is there is NO clue in the system... R ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 23:19:16 2010 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 3B7DC106566B for ; Wed, 23 Jun 2010 23:19:16 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id CA2B18FC15 for ; Wed, 23 Jun 2010 23:19:15 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id Zapn1e0010vyq2s55bKFzw; Wed, 23 Jun 2010 23:19:15 +0000 Received: from smtp.ericx.net ([76.24.209.147]) by omta05.westchester.pa.mail.comcast.net with comcast id ZbKF1e0023BMG6c3RbKFev; Wed, 23 Jun 2010 23:19:15 +0000 Received: from smtp.ericx.net (localhost.ericx.net [127.0.0.1]) by smtp.ericx.net (Postfix) with ESMTP id E688A129F04D; Wed, 23 Jun 2010 19:19:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ericx.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=selector1; bh=Y/9VDeQ nP2N+SjMhk2pnbJMp68s=; b=UptvbNBp8WDcHCaOH9KPh7sNim4m/oBj/Cgrefx F+KTLBjHHmXjrD1xJgXCgfU1w7eCjoyrLLgoDrWHM4BxFXyDkjs8+KUtFAoJmI0w oaSkj2UXLcLPB1pzzu/vI28dZvKnzcuCk+ieGCFzKZSnl/PRNa3YpQ/povcy75ci fn+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ericx.net; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=selector1; b=u XvlocjylJVc/s1yB8n8M/7YHu3fO8PO6HNo2oY5EB3oebBS+hSmloThSOhj+N4pk SDl459msSMkmz8KvrR641wxgDees9zeBa+WKu1+Q5HSOixegim3R1zr6ifYk9Qna kpek9y3n5j8i/p6vS15R26lQVMg7SCqV4TE7vN2dD4= Received: from [10.0.0.54] (unknown [75.150.112.177]) by smtp.ericx.net (Postfix) with ESMTPSA id ACF68129F045; Wed, 23 Jun 2010 19:19:38 -0400 (EDT) Message-ID: <4C229595.20902@ericx.net> Date: Wed, 23 Jun 2010 19:15:33 -0400 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ralf@dzie-ciuch.pl References: <87260c422232fa7409a4b374341dd106@ewipo.pl> <20100622143543.GA72020@zeninc.net> <20100622153541.GA72211@zeninc.net> <6caa9895ae1710b9f48a227116a4340c@ewipo.pl> <20100622190819.270aaa74@gda-arsenic> <4f378cfb416582c3081377ba714e508a@ewipo.pl> <20100622201130.5824d585@gda-arsenic> <20100622182242.GU2620@verio.net> <4C210B0F.6060203@ericx.net> <655d7279cefc01b3fbe0016c598fcd72@ewipo.pl> In-Reply-To: <655d7279cefc01b3fbe0016c598fcd72@ewipo.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vpn trouble 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, 23 Jun 2010 23:19:16 -0000 On 6/22/2010 3:55 PM, ralf@dzie-ciuch.pl wrote: >> >> I managed to do an IP in IP tunnel with IPsec encryption between a >> FreeBSD and a cisco router running 12.1(mumble) several years ago. >> >> It is a desirable option if you want to use routing (e.g. ospf). You >> can't route an IPSec tunnel (actually, is this now possible with enc0 >> interfaces?) but you can route to the gif interfaces. >> > > Can you tell me how to use route command to use it like above? I have to admit that I no longer have access to that client's machines. However, I can describe in broad strokes. In our case the need was to provide a backup route for a dedicated T1. Occasionally the T1 would fail; so we wanted an alternate route thru the internet. The internet path had to be encrypted; but it was much slower; so we wanted the T1 to have priority. The router terminating the T1 was separate from the router providing general internet access. This was between a hospital and a service provider. A lot of this could be simplified except that the vendor HAD to provide the server, the circuit, and the router (those of you who support banks or hospitals know what I'm talking about.) There is already a static route in place for the provider via the T1 router. We first built a simple IPencap tunnel between our FreeBSD box and their cisco. The FreeBSD side used a gif and the cisco side used a tunnel interface. We confirmed that we could ping end-points. Then we added the ospf to the mix in order to detect when the T1 dropped. We weighted the ospf so that the T1 was prioritized. Once that was working we added the IPSec as transport between the endpoints of the IpinIP tunnel rather than encapsulation. That was the only time I've built an IPSec tunnel with that method. Folks with better understanding than I can perhaps explain the pros and cons. In our case, it was a simple expedient to support ospf. I have noticed since then that OS X's GUI only supports this method of IPSec tunneling; so I'm going to have to do it again to support some other customers. Some parts on the cisco side might appear thusly (I'm doing this from memory so ymmv): interface FastEthernet0.2 description VLAN 500 to Comcast router encapsulation dot1Q 500 ip address x.x.x.x 255.255.255.252 The encryption part: crypto isakmp policy 10 encr 3des hash sha1 authentication pre-share group 2 crypto isakmp key foobar-key address 0.0.0.0 0.0.0.0 crypto ipsec transform-set PROVIDER-SET esp-3des esp-sha-hmac ! crypto ipsec profile PROVIDER-PROF set transform-set PROVIDER-SET The tunnel part: interface tunnel0 description IPnIP tunnel thru comcast to PROVIDER ip address 192.168.254.3 255.255.255.252 ip ospf mtu-ignore tunnel source x.x.x.25 tunnel destination y.y.y.y tunnel mode ipsec ipv4 tunnel protection ipsec profile PROVIDER-PROF The OSPF part: router ospf 10101 log-adjacency-changes redistribute connected subnets redistribute static subnets passive interface FastEthernet0/0 passive interface FastEthernet0/0.1 passive interface FastEthernet0/0.2 network 128.1.0.0 0.0.255.255 area 0 network 192.168.8.0 0.0.3.255 area 0 network 192.168.254.0 0.0.0.3 area 0 The static route part: ip classless ip route 0.0.0.0 0.0.0.0 Serial0 ip route 192.168.8.0 255.255.252.0 10.21.1.2 ip route 192.168.20.0 255.255.255.0 10.21.1.2 ip route y.y.y.y 255.255.255.255 x.x.x.26 ! the last route is just to make sure the tunnel uses Comcast From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 01:09:21 2010 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 1087B106564A for ; Thu, 24 Jun 2010 01:09:21 +0000 (UTC) (envelope-from pta1@fastmail.us) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id D85E98FC14 for ; Thu, 24 Jun 2010 01:09:20 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 91343105601 for ; Wed, 23 Jun 2010 20:49:53 -0400 (EDT) Received: from web7.messagingengine.com ([10.202.2.216]) by compute1.internal (MEProxy); Wed, 23 Jun 2010 20:49:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:mime-version:content-transfer-encoding:content-type:subject:reply-to:date; s=smtpout; bh=eYcHQ4Q2YXIezPiDLIhq3UyCVNE=; b=GVWni69Kenvo42b/0hQfL5cvcvVhNo7LGGN4UVhhBiThoRMlrJNS4fV/QQjESqOnyDXM6/J91zKBoi24Q0LVZho77qRsNnVKbMaT0oKLGODEzwd/dbWNIFQW9XsgxxTlZIy6XO336WrpcezzU2kOTm/MwNnj6n2I3+2LejTjDv0= Received: by web7.messagingengine.com (Postfix, from userid 99) id 671B0183C3E; Wed, 23 Jun 2010 20:49:53 -0400 (EDT) Message-Id: <1277340593.17629.1381616693@webmail.messagingengine.com> X-Sasl-Enc: HUd2JDItFd8BMGPMQqjSfvyn3qoGI9jpQeJq3G6VgoD4 1277340593 From: "Paul Ammann" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface Date: Wed, 23 Jun 2010 20:49:53 -0400 Subject: IPv6 and Anycast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pta1@fastmail.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 01:09:21 -0000 Hi I was wondering if someon knew if FreeBSD supports the creation of anycast addresses and groups. Thanks, Paul From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 02:21:26 2010 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 82E6D10656C2 for ; Thu, 24 Jun 2010 02:21:26 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 6976C8FC16 for ; Thu, 24 Jun 2010 02:21:26 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ORc4D-000MKm-Hd for freebsd-net@FreeBSD.org; Thu, 24 Jun 2010 02:21:25 +0000 Date: Thu, 24 Jun 2010 11:21:24 +0900 Message-ID: From: Randy Bush To: freebsd-net References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: IPv4 address: .* is not on the network 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, 24 Jun 2010 02:21:26 -0000 a host sees these kinds of messages Jun 7 00:20:41 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 03:38:00 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 04:32:08 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 06:55:12 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 08:52:23 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 10:02:38 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 13:19:43 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 13:32:25 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 16:32:27 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 17:46:24 r2 kernel: IPv4 address: "98.128.0.1" is not on the network Jun 7 20:59:29 r2 kernel: IPv4 address: "98.128.0.2" is not on the network Jun 7 21:54:26 r2 kernel: IPv4 address: "98.128.0.1" is not on the network yet r2# ifconfig em0: flags=8843 metric 0 mtu 9600 options=9b ether 00:1b:21:28:e2:44 inet 147.28.1.2 netmask 0xfffffffc broadcast 147.28.1.3 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8843 metric 0 mtu 9600 options=9b ether 00:1b:21:28:e2:45 inet 147.28.1.6 netmask 0xfffffffc broadcast 147.28.1.7 media: Ethernet autoselect (100baseTX ) status: active em2: flags=8802 metric 0 mtu 1500 options=19b ether 00:30:48:d4:a3:0a media: Ethernet autoselect status: no carrier em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d4:a3:0b inet 147.28.0.5 netmask 0xffffff00 broadcast 147.28.0.255 inet 192.83.230.252 netmask 0xffffff00 broadcast 192.83.230.255 inet 198.133.206.252 netmask 0xffffff00 broadcast 198.133.206.255 inet 198.180.153.252 netmask 0xffffff00 broadcast 198.180.153.255 inet 98.128.0.3 netmask 0xffff0000 broadcast 98.128.255.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet 147.28.7.3 netmask 0xffffffff and r2# ping -c 3 98.128.0.1 PING 98.128.0.1 (98.128.0.1): 56 data bytes 64 bytes from 98.128.0.1: icmp_seq=0 ttl=255 time=0.993 ms 64 bytes from 98.128.0.1: icmp_seq=1 ttl=255 time=144.373 ms 64 bytes from 98.128.0.1: icmp_seq=2 ttl=255 time=0.308 ms --- 98.128.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.308/48.558/144.373/67.752 ms r2# ping -c 3 98.128.0.2 PING 98.128.0.2 (98.128.0.2): 56 data bytes 64 bytes from 98.128.0.2: icmp_seq=0 ttl=64 time=1.224 ms 64 bytes from 98.128.0.2: icmp_seq=1 ttl=64 time=0.934 ms 64 bytes from 98.128.0.2: icmp_seq=2 ttl=64 time=0.776 ms --- 98.128.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.776/0.978/1.224/0.186 ms what is the issue here? randy From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 04:06:50 2010 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 D9CD3106566C for ; Thu, 24 Jun 2010 04:06:50 +0000 (UTC) (envelope-from fbsdlists@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 8D19F8FC1D for ; Thu, 24 Jun 2010 04:06:50 +0000 (UTC) Received: by vws13 with SMTP id 13so1727513vws.13 for ; Wed, 23 Jun 2010 21:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=car/6NgOy7gdk2IBAnaLeRuaqtP0onpTR9A+Y1svRG4=; b=WtdooV9iRL0LtYzViS8jGNioaB1L/ggZkt5jagcrGoLQfl0Dg1l11Fd4Sw+G2mEXOe zgNIIPckk5m073Mye730No21nkWRpoiywKWkusHoUrnwzNPjDtvSNeKV8rkbCOmLG0kt ZhbftGAy/PZARPPlry7Lmmlu7c3W5mXkKB6Zg= 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 :content-type; b=jbP/b7EFbaH72bMGDwTnAkh/SG6eG8vTulR3R3AKMYRHDEKVqa1TUeV9oF5imYo8oo 8O7BA6WcqSaE9+aWHjkFuu8E69QkLIiS/falCXZfrB4eLOmqMVIItUizv7nsSF5qb8r/ PqG0ylffXqaCy/1scNlvuuU4S9J0doSX9z8BY= MIME-Version: 1.0 Received: by 10.224.96.28 with SMTP id f28mr5626632qan.169.1277350577865; Wed, 23 Jun 2010 20:36:17 -0700 (PDT) Received: by 10.224.54.137 with HTTP; Wed, 23 Jun 2010 20:36:17 -0700 (PDT) In-Reply-To: References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> Date: Wed, 23 Jun 2010 23:36:17 -0400 Message-ID: From: Bob Johnson To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 04:06:50 -0000 On 6/23/10, Randall Stewart wrote: > Then I would strongly suggest you go fix the manual page for ntohl/ > ntohs and > point people to the be64toh() functions... then people would NOT be > ignorant. > > The problem is there is NO clue in the system... Already done, at least in 7.2. But it refers you to them under the alias byteorder(9). - Bob -- -- Bob Johnson fbsdlists@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 12:19:39 2010 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 C013C1065670 for ; Thu, 24 Jun 2010 12:19:39 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4CF8FC19 for ; Thu, 24 Jun 2010 12:19:39 +0000 (UTC) Received: from [192.168.2.184] (pool-96-238-218-232.snfcca.dsl-w.verizon.net [96.238.218.232]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5OCJYup052083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jun 2010 08:19:37 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277381978; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=rreO0ZSWG7q8KW7SChUOUuwvnr1MXiM+I1ulfq53Nke7cyLnkZZQgtd Moi49Lw0zDgiKE2/scORfUWpxN67+jw== Message-Id: <465EA76D-C86C-47B2-8F6E-B60CFDBB087A@lakerest.net> From: Randall Stewart To: Bob Johnson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 05:19:29 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> X-Mailer: Apple Mail (2.936) Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 12:19:39 -0000 Bob: Thats strange... when I do man byteorder (on my FreeBSD 8.0 system upgraded to head .. buildworld/installworld/ et.al) I get the same man age showing for both man ntohl and man byteorder This may just be a problem with my system.. I will check the other 8.0 installed systems at work when I get in this AM. I think what's needed here is some hint inside the man ntohl that for 64 bit quantities should use be64toh/htobe64 and a reference to that man page.. R On Jun 23, 2010, at 8:36 PM, Bob Johnson wrote: > On 6/23/10, Randall Stewart wrote: > >> Then I would strongly suggest you go fix the manual page for ntohl/ >> ntohs and >> point people to the be64toh() functions... then people would NOT be >> ignorant. >> >> The problem is there is NO clue in the system... > > Already done, at least in 7.2. But it refers you to them under the > alias byteorder(9). > > - Bob > > -- > -- Bob Johnson > fbsdlists@gmail.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" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 12:24:15 2010 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 3A9B11065672 for ; Thu, 24 Jun 2010 12:24:15 +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 B15848FC19 for ; Thu, 24 Jun 2010 12:24:14 +0000 (UTC) Received: from birdie.meganet.ru (birdie.ipv6.meganet.ru [IPv6:2a02:978::1008]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 462812A9A57; Thu, 24 Jun 2010 12:23:43 +0000 (UTC) Message-ID: <4C234E60.2060502@ipfw.ru> Date: Thu, 24 Jun 2010 16:24:00 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100511) MIME-Version: 1.0 To: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?= References: <50a120641003190539n7d60348ev85416f2777d6c82c@mail.gmail.com> <50a120641003241158t15806da9g5993cfc3c7099bc0@mail.gmail.com> <57156839.20100623092257@gmail.com> In-Reply-To: <57156839.20100623092257@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, dimm404@gmail.com Subject: Re: [patch] ng_netflow 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, 24 Jun 2010 12:24:15 -0000 Дмитрий Замураев wrote: > If you can, add information abount AS numbers too. > ASN patch for 16-bit ASN's for V5 protocol: > http://www.stasyan.com/devel/ng_netflow/patch_asnum_1 > Proto V5 can't handle 32-bit ASN unlike V9. > > But I can't understand why it's not working for me, > AS numbers exists for first time after I was load AS information to node, > but after some minutes I have't see any AS information in netflow > datagrams. > > >> Hello. >> I saw patches for ng_netflow to make netflow v9 there >> http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022911.html >> What's state of this patches? Is this code included in freebsd? Or will be >> include in future release? >> There are several major bugs in this patch. I'm planning to make updated patch in several weeks. At the moment it's a very bad idea to use current version in production > > > _______________________________________________ > 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 Jun 24 12:43:46 2010 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 E2948106566C for ; Thu, 24 Jun 2010 12:43:46 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 7C54C8FC14 for ; Thu, 24 Jun 2010 12:43:46 +0000 (UTC) Received: from [192.168.2.184] (pool-96-238-218-232.snfcca.dsl-w.verizon.net [96.238.218.232]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5OChfxw053136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jun 2010 08:43:44 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277383425; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=if3RSQXQjZvlWF7YfnRHpX7InXIRXE05iIsRiJX/j0e79zQZsz8Zbps LloHIiFBe2hJ86K13g8Iw+xN95bRJVw== Message-Id: <3A61E8D1-94A2-43D4-BD08-E4701A7A429D@lakerest.net> From: Randall Stewart To: Luigi Rizzo In-Reply-To: <20100623171222.GA7981@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 05:43:36 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 12:43:47 -0000 Lugi: One other comment I want to make about your numbers... well maybe three ;-) On Jun 23, 2010, at 10:12 AM, Luigi Rizzo wrote: > On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote: > ... >>>> strong objection! >>>> We should instead use names with exact sizes (16,32,64). >> >> So please tell me why you object so strongly? We have the 16/32/64 >> bit >> names which >> are nice but are not expected so folks seem to not use them. I have > > people's ignorance is not an excuse for not doing things right. > We'd still be using BYTE, WORD and DWORD otherwise. > > I think there is no doubt that we should use the 16/32/64 bit names > if we could start from scratch, and the only reason for not doing > so is avoiding gratuitous changes to existing/stable code. > > The case of *to*ll does not apply, in that there is no actual legacy > to adapt to. And btw there is tons of places which use the 16/32/64 > bit > names in the filesystem, usb and generic device drivers. In fact, > many more than ntohl/htonl > > > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > 1438 6397 145174 > > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > 2203 10269 210989 > > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc > 854 4009 84855 > > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc > 738 3604 72970 1) The grep for le32 is really not something you would do. You never convert network byte order to le32 for sending things on the wire since network byte order is be. I would imagine the 2203 occurrences are where you are dealing with buses (pci comes to mind) that want le. 2) When you grep be32 you are getting both conversions so you are comparing 1438 against 1592 (854+738). So it seems to me be32 is not used yet as much for network conversions.. and even more so one might want to delve in kernel wise to where the be32 is being used.. I would bet it is also in the same vein.. i.e. machines doing things with the bus... and very little network transmission code.. and that leads me to my final comment, which I think proves my point. 3) A much fairer comparison is looking in the head NOT including sys. I did a simple script along these lines by doing: cd ~head ls | grep -n sys > list grep -r be32 `cat list` | grep -v .svn | wc -l 215 grep -r ntohl `cat list` | grep -v .svn | wc -l 888 grep -r htonl `cat list` | grep -v .svn | wc -l 913 So adding that up its 1801 uses of the h/n macros and 215 of the be. Thats almost 10 to 1. Now I am not disagreeing with you that the be32 is clearer.. but my point is still valid... networking application developers do think in terms of the ntohl/htonl macros. Until we get more information out to them (assuming that the bexx and friends are available on linux and windows) you will not see an uptake in the use of them unless we educate folks. In this case ignorance is a good excuse until all networking manuals have be* and friends... looking in Fenner's update to UNP (3rd edition) I find only the ntohl/htonl macros mentioned ;-( A good start for documentation would be the man page for ntohl pointing directly at the be64 macros man page for 64 bit conversions.. I would suggest more than a reference and an explicit statement. Do that and people will not flounder around and roll their own.. well then again maybe they still will .. since folks are so conditioned for ntohx().. Hmm maybe I will take Julian's suggestion and make it easier for SCTP folks ;-) R > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 12:45:30 2010 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 B7CA0106566C for ; Thu, 24 Jun 2010 12:45:30 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6D42E8FC08 for ; Thu, 24 Jun 2010 12:45:30 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:44170 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1ORlYQ-0008Hw-Al for net@freebsd.org; Thu, 24 Jun 2010 14:29:16 +0200 Received: (qmail 31314 invoked from network); 24 Jun 2010 14:29:13 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 24 Jun 2010 14:29:13 +0200 Received: (qmail 95452 invoked by uid 1001); 24 Jun 2010 14:29:13 +0200 Date: Thu, 24 Jun 2010 14:29:13 +0200 From: Erik Trulsson To: Randall Stewart Message-ID: <20100624122913.GA95400@owl.midgard.homeip.net> References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> <465EA76D-C86C-47B2-8F6E-B60CFDBB087A@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465EA76D-C86C-47B2-8F6E-B60CFDBB087A@lakerest.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1ORlYQ-0008Hw-Al. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1ORlYQ-0008Hw-Al e686221b9ff128cd1783067457581e8e Cc: Bob Johnson , net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 12:45:30 -0000 On Thu, Jun 24, 2010 at 05:19:29AM -0700, Randall Stewart wrote: > Bob: > > Thats strange... when I do > > man byteorder > > (on my FreeBSD 8.0 system upgraded to head .. buildworld/installworld/ > et.al) > > I get the same man age showing for both > > man ntohl > > and > > man byteorder But if you do 'man 9 byteorder' you will get a different manpage. (byteorder(3) and byteorder(9) are different manpages, and even reference each other in the SEE ALSO sections.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 12:49:07 2010 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 656A31065678 for ; Thu, 24 Jun 2010 12:49:07 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id DB5958FC19 for ; Thu, 24 Jun 2010 12:49:06 +0000 (UTC) Received: from [192.168.2.184] (pool-96-238-218-232.snfcca.dsl-w.verizon.net [96.238.218.232]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5OCn2tb053366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jun 2010 08:49:05 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277383746; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=pAJMDfIUyrP0Hdl8WrpAXObU7tU8UFrD1/egR1bdjThnpb1s+b81lIN VccnsTPwYhOEFyA1fCGhFfV6tA3+ZBQ== Message-Id: <58016669-3751-4E24-A84D-6C9418E78717@lakerest.net> From: Randall Stewart To: Erik Trulsson In-Reply-To: <20100624122913.GA95400@owl.midgard.homeip.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 05:48:57 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> <465EA76D-C86C-47B2-8F6E-B60CFDBB087A@lakerest.net> <20100624122913.GA95400@owl.midgard.homeip.net> X-Mailer: Apple Mail (2.936) Cc: Bob Johnson , net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 12:49:07 -0000 On Jun 24, 2010, at 5:29 AM, Erik Trulsson wrote: > On Thu, Jun 24, 2010 at 05:19:29AM -0700, Randall Stewart wrote: >> Bob: >> >> Thats strange... when I do >> >> man byteorder >> >> (on my FreeBSD 8.0 system upgraded to head .. buildworld/ >> installworld/ >> et.al) >> >> I get the same man age showing for both >> >> man ntohl >> >> and >> >> man byteorder > > But if you do 'man 9 byteorder' you will get a different manpage. > (byteorder(3) and byteorder(9) are different manpages, and even > reference > each other in the SEE ALSO sections.) Now if thats not confusing I don't know what is.. Back to my last statement to Lugi.. We need something more explicit IMO.. something that says in ntohl man page (if we want folks to find an use be64): "Byte order conversions for 64 bit quantities should use the be64toh() macros." And also even more distressing I am talking about things as a application writer here.. not kernel developer... section 9 is from "FreeBSD Kernel Developer's Manual" Which gives one the impression (however untrue) that its for a kernel developer and not for user land.. R > > > > -- > > Erik Trulsson > ertr1013@student.uu.se > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 12:59:44 2010 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 1A692106566B for ; Thu, 24 Jun 2010 12:59:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BA3BC8FC13 for ; Thu, 24 Jun 2010 12:59:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B821873098; Thu, 24 Jun 2010 15:10:04 +0200 (CEST) Date: Thu, 24 Jun 2010 15:10:04 +0200 From: Luigi Rizzo To: Randall Stewart Message-ID: <20100624131004.GA39128@onelab2.iet.unipi.it> References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <3A61E8D1-94A2-43D4-BD08-E4701A7A429D@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A61E8D1-94A2-43D4-BD08-E4701A7A429D@lakerest.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 12:59:44 -0000 On Thu, Jun 24, 2010 at 05:43:36AM -0700, Randall Stewart wrote: > Lugi: > > One other comment I want to make about your numbers... well maybe > three ;-) ... Randall, my numbers may well be affected by large errors, but the point was just to show that the *16/32/64 functions are already widely used across the board. Since we all agree that these names are more clear than the old naming conventions, it's time for old timers and net-centric people (i am 47 and doing this stuff for over 20 years so i do qualify) to adapt to what everyone else is doing, rather than perpetrating some confusing naming conventions. Fine, let's not change the existing ntohl() for no reason (though, at some point in time there was a sweep of changes from the macro NTOHL() to the function form), but at least let's not introduce new functions with a poorly chosen name. Then sure, documentation is not up to date because no one has time to fix it, old books and old code still show mostly old APIs, and so on... cheers luigi > >The case of *to*ll does not apply, in that there is no actual legacy > >to adapt to. And btw there is tons of places which use the 16/32/64 > >bit > >names in the filesystem, usb and generic device drivers. In fact, > >many more than ntohl/htonl > > > > > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > > 1438 6397 145174 > > > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc > > 2203 10269 210989 > > > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc > > 854 4009 84855 > > > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc > > 738 3604 72970 > > 1) The grep for le32 is really not something you would do. You never > convert network byte order to le32 for sending things on the wire > since > network byte order is be. I would imagine the 2203 occurrences are > where > you are dealing with buses (pci comes to mind) that want le. > > 2) When you grep be32 you are getting both conversions so you are > comparing > 1438 against 1592 (854+738). So it seems to me be32 is not used > yet as > much for network conversions.. and even more so one might want to > delve > in kernel wise to where the be32 is being used.. I would bet it is > also > in the same vein.. i.e. machines doing things with the bus... and > very little network transmission code.. and that leads me to my > final comment, which > I think proves my point. > > 3) A much fairer comparison is looking in the head NOT including sys. > I did a simple > script along these lines by doing: > cd ~head > ls | grep -n sys > list > grep -r be32 `cat list` | grep -v .svn | wc -l > 215 > grep -r ntohl `cat list` | grep -v .svn | wc -l > 888 > grep -r htonl `cat list` | grep -v .svn | wc -l > 913 > > So adding that up its 1801 uses of the h/n macros and 215 of the > be. Thats almost 10 to 1. > > > Now I am not disagreeing with you that the be32 is clearer.. but my > point is still valid... networking > application developers do think in terms of the ntohl/htonl macros. > Until we get more information > out to them (assuming that the bexx and friends are available on linux > and windows) you will not > see an uptake in the use of them unless we educate folks. In this case > ignorance is a good > excuse until all networking manuals have be* and friends... looking in > Fenner's update to > UNP (3rd edition) I find only the ntohl/htonl macros mentioned ;-( > > A good start for documentation would be the man page for ntohl > pointing directly at the be64 macros man > page for 64 bit conversions.. I would suggest more than a reference > and an explicit statement. > Do that and people will not flounder around and roll their own.. well > then again maybe they > still will .. since folks are so conditioned for ntohx().. > > Hmm maybe I will take Julian's suggestion and make it easier for SCTP > folks ;-) > > R > > > > > > >cheers > >luigi > >_______________________________________________ > >freebsd-net@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-net > >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 14:42:35 2010 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 C8BCA106564A; Thu, 24 Jun 2010 14:42:35 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 805B28FC1C; Thu, 24 Jun 2010 14:42:35 +0000 (UTC) Received: by gwb11 with SMTP id 11so1793640gwb.13 for ; Thu, 24 Jun 2010 07:42:34 -0700 (PDT) Received: by 10.229.250.78 with SMTP id mn14mr5282283qcb.16.1277388782814; Thu, 24 Jun 2010 07:13:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.16 with HTTP; Thu, 24 Jun 2010 07:12:42 -0700 (PDT) From: Rafael Henrique Faria Date: Thu, 24 Jun 2010 11:12:42 -0300 Message-ID: To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 14:42:35 -0000 Hi. I'm working on a Brige between a router Cisco 7200, and a 3Com 7900 switch. I have several subnetworks, and I need to balance the bandwidth between the= n. The Brigde is running: "FreeBSD dell05 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Tue Jun 22 13:59:17 BRT 2010 rafaelhfaria@dell05:/usr/obj/usr/src/sys/BRIDGE amd64" I have the following lines in /boot/loader.conf: --- net.graph.maxalloc=3D512 net.graph.maxdgram=3D45000 net.graph.recvspace=3D45000 bridgestp_load=3D"YES" if_vlan_load=3D"YES" --- And my kernel is compiled with: device if_bridge device pf device pflog options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ options ALTQ_NOPCC options DEVICE_POLLING options HZ=3D1000 options SHMSEG=3D16 options SHMMNI=3D32 options SHMMAX=3D2097152 options SHMALL=3D4096 options MAXFILES=3D8192 And the bridge configuration: cloned_interfaces=3D"bridge0 vlan1" ifconfig_bridge0=3D"addm bce0 stp bce0 addm bce1 stp bce1 up" ifconfig_bce0=3D"polling up" ifconfig_bce1=3D"polling up" ifconfig_vlan1=3D"inet 200.x.x.x netmask 0xFFFFFF00 broadcast 200.x.x.255 vlan 1 vlandev bce1" bce0 is connected to the Cisco 7200 ($wan_if in pf) bce1 is conencted to the 3Com 7900 ($lan_if in pf) And my sysctl for bridge: dell05# sysctl net.link.bridge net.link.bridge.ipfw: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 1 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 0 dell05# Ok... Now, the problem. With the following queue: altq on $lan_if bandwidth 33Mb hfsc queue { down_sub1, down_sub2, down_sub3, down_sub4, down_def } queue down_sub1 bandwidth 8Mb priority 1 qlimit 300 hfsc ( realtime 3.20Mb upperlimit 22.40Mb ) queue down_sub2 bandwidth 8Mb priority 1 qlimit 300 hfsc ( realtime 3.20Mb upperlimit 22.40Mb ) queue down_sub3 bandwidth 8Mb priority 1 qlimit 300 hfsc ( realtime 3.20Mb upperlimit 22.40Mb ) queue down_sub4 bandwidth 8Mb priority 1 qlimit 300 hfsc ( realtime 3.20Mb upperlimit 22.40Mb ) queue down_def bandwidth 128Kb hfsc ( default ) And with the following rules: pass in log quick on $lan_if from to any keep state queue ( down_su= b1 ) pass out log quick on $wan_if from to any keep state queue ( up_sub1= ) pass in log quick on $wan_if from any to keep state queue ( up_sub1= ) pass out log quick on $lan_if from any to keep state queue ( down_su= b1 ) (..) for each I have the pass rules like those. With the full use of the link, only a small part of the traffic gets into the correct queue. queue root_bce1 on bce1 bandwidth 33Mb priority 0 {down_sub1, down_sub2, down_sub3, down_sub4, down_def} [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 ] [ measured: 0.0 packets/s, 0 b/s ] queue down_sub1 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime 3.20Mb upperlimit 22.40Mb ) [ pkts: 53177 bytes: 50082785 dropped pkts: 0 bytes: 0= ] [ qlength: 0/300 ] [ measured: 364.5 packets/s, 2.81Mb/s ] queue down_sub2 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime 3.20Mb upperlimit 22.40Mb ) [ pkts: 90724 bytes: 79670459 dropped pkts: 0 bytes: 0= ] [ qlength: 0/300 ] [ measured: 744.6 packets/s, 5.20Mb/s ] queue down_sub3 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime 3.20Mb upperlimit 22.40Mb ) [ pkts: 38333 bytes: 37384626 dropped pkts: 0 bytes: 0= ] [ qlength: 0/300 ] [ measured: 285.2 packets/s, 2.35Mb/s ] queue down_sub4 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime 3.20Mb upperlimit 22.40Mb ) [ pkts: 80385 bytes: 69021129 dropped pkts: 0 bytes: 0= ] [ qlength: 0/300 ] [ measured: 585.1 packets/s, 3.92Mb/s ] queue down_def on bce1 bandwidth 128Kb hfsc( default ) [ pkts: 268756 bytes: 336423531 dropped pkts: 121 bytes: 81921= ] [ qlength: 0/ 50 ] [ measured: 1615.4 packets/s, 16.49Mb/s ] watching the pflog interface, I can see that the pass rules are working, no traffic is getting out of one of the rules (I have put an "pass log all" to check this). All the rules are working... but they aren't sending the traffic to the specified queue. If someone have a glue for this... Any suggestion are welcome. Thank's in advance. --=20 Rafael Henrique da Silva Faria Grupo de Sistemas e Redes Servi=E7o T=E9cnico de Inform=E1tica Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 15:47:58 2010 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 77B7A1065674 for ; Thu, 24 Jun 2010 15:47:58 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 413668FC15 for ; Thu, 24 Jun 2010 15:47:57 +0000 (UTC) Received: (qmail 31835 invoked from network); 24 Jun 2010 15:47:57 -0000 Received: from unknown (HELO ?10.0.0.174?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 24 Jun 2010 15:47:57 -0000 Message-ID: <4C237E2C.3080103@acm.poly.edu> Date: Thu, 24 Jun 2010 11:47:56 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100530) MIME-Version: 1.0 To: Sam Leffler References: <4A8C3557.20002@acm.poly.edu> <4AA03A41.1080200@acm.poly.edu> <4AB1A086.4090303@acm.poly.edu> <4AB1D7C2.5010403@freebsd.org> In-Reply-To: <4AB1D7C2.5010403@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, stef@memberwebs.com Subject: Re: kmem_map too small panics with Soekris/Atheros access point [ath rate control] 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, 24 Jun 2010 15:47:58 -0000 Sam Leffler wrote: > Boris Kochergin wrote: > >> Stef Walter wrote: >> >>> Boris Kochergin wrote: >>> >>> >> I, too, recall the days when you had multiple rate-control algorithms to >> choose from, but that doesn't appear to be the case anymore. As a >> workaround, I wrote a little script that checks if that part of the >> driver is using more than 200 KiB of memory and run it every minute via >> cron. It seems to be doing its job so far: >> > > You can still select the ath rate control module. Static kernel config > is unchanged; for modules you must export ATH_RATE=onoe or similar > (check modules/ath/Makefile). Please file a PR if this does not work. > > Sam > (I had to go do some other stuff, but better late than never?) Thanks. That does indeed work, but the problem persists with other rate-control algorithms (I've upgraded most of the access points to 8.0-R, where the problem does not appear to exist, and upgraded one to 7.3-R for continued testing--this is where it still happens). I've instrumented the memory-allocation bits in the ath and net80211 code where MALLOC/malloc was called with a type of M_80211_NODE. I've tracked the leak down to one of two allocations never being freed: Line 595 of /usr/src/sys/net80211/ieee80211_node.c: MALLOC(ni, struct ieee80211_node *, sizeof(struct ieee80211_node), M_80211_NODE, M_NOWAIT | M_ZERO); Line 3164 of /usr/src/sys/dev/ath/if_ath.c: an = malloc(space, M_80211_NODE, M_NOWAIT|M_ZERO); It looks like both are supposed to be freed by node_free() in /usr/src/sys/net80211/ieee80211_node.c, but there is some code path where that doesn't happen, and should. Hopefully, this helps someone familiar with the code track it down. I may try it at some point, but it intimidates me somewhat. -Boris From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 15:50:05 2010 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 D1745106566B for ; Thu, 24 Jun 2010 15:50:05 +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 A6CEA8FC14 for ; Thu, 24 Jun 2010 15:50:05 +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 o5OFo5KR061816 for ; Thu, 24 Jun 2010 15:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5OFo5qG061815; Thu, 24 Jun 2010 15:50:05 GMT (envelope-from gnats) Date: Thu, 24 Jun 2010 15:50:05 GMT Message-Id: <201006241550.o5OFo5qG061815@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexander V. Chernikov" Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 15:50:05 -0000 The following reply was made to PR kern/127057; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-followup@FreeBSD.org, saper@SYSTEM.PL Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Date: Thu, 24 Jun 2010 19:44:25 +0400 1) Problem can be more easily reproduced with nc: echo | ktrace nc -nu6 ::ffff:127.0.0.1 53 ; kdump | grep socket -A 15 1682 nc CALL socket(PF_INET6,SOCK_DGRAM,IPPROTO_UDP) 1682 nc RET socket 3 1682 nc CALL connect(0x3,0x800a050e0,0x1c) 1682 nc STRU struct sockaddr { AF_INET6, [::ffff:127.0.0.1]:53 } 1682 nc RET connect 0 1682 nc CALL poll(0x7fffffffa6b0,0x2,0xffffffff) 1682 nc RET poll 1 1682 nc CALL read(0,0x7fffffffa6c0,0x400) 1682 nc GIO fd 0 read 1 byte " " 1682 nc RET read 1 1682 nc CALL write(0x3,0x7fffffffa6c0,0x1) 1682 nc RET write -1 errno 22 Invalid argument Problem is related with [implicit] IPv4 bind done by in_pcbconnect (or in_pcbbind_setup in case of explicit bind()) Selected IPv4 IP address is written into inpcb -> inp_inc.inc_ie.ie_dependladdr.ie46_local According to struct in_addr_4in6 interpreting written value as IPv6 address results in ::127.0.0.1, which is not correct v4-mapped address (it is actually deprecated ipv4-compatible address), so IN6_IS_ADDR_V4MAPPED() address check in udp6_send failes with EINVAL. Proposed solution is to add required ffff immediately after v4 protocol layer connection succeeded, e.g. --- sys/netinet6/udp6_usrreq.c.orig 2010-06-24 12:32:10.813316692 +0000 +++ sys/netinet6/udp6_usrreq.c 2010-06-24 12:33:02.977455989 +0000 @@ -923,6 +923,8 @@ if (error == 0) { inp->inp_vflag |= INP_IPV4; inp->inp_vflag &= ~INP_IPV6; + /* Make v6 addr v4-mapped */ + inp->inp_inc.inc_ie.ie_dependladdr.ie46_local.ia46_pad32[2] = IPV6_ADDR_INT32_SMP; soisconnected(so); } goto out; This tiny patch fixes an issue with java DNS resolution (at least for me) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 16:00:14 2010 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 A1AA81065670 for ; Thu, 24 Jun 2010 16:00:14 +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 773028FC12 for ; Thu, 24 Jun 2010 16:00:14 +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 o5OG0Emo069965 for ; Thu, 24 Jun 2010 16:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5OG0E3X069964; Thu, 24 Jun 2010 16:00:14 GMT (envelope-from gnats) Date: Thu, 24 Jun 2010 16:00:14 GMT Message-Id: <201006241600.o5OG0E3X069964@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexander V. Chernikov" Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:00:14 -0000 The following reply was made to PR kern/127057; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-followup@FreeBSD.org, saper@SYSTEM.PL Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Date: Thu, 24 Jun 2010 19:54:02 +0400 Problem can be more easily reproduced with nc: echo | ktrace nc -nu6 ::ffff:127.0.0.1 53 ; kdump | grep socket -A 15 1682 nc CALL socket(PF_INET6,SOCK_DGRAM,IPPROTO_UDP) 1682 nc RET socket 3 1682 nc CALL connect(0x3,0x800a050e0,0x1c) 1682 nc STRU struct sockaddr { AF_INET6, [::ffff:127.0.0.1]:53 } 1682 nc RET connect 0 1682 nc CALL poll(0x7fffffffa6b0,0x2,0xffffffff) 1682 nc RET poll 1 1682 nc CALL read(0,0x7fffffffa6c0,0x400) 1682 nc GIO fd 0 read 1 byte " " 1682 nc RET read 1 1682 nc CALL write(0x3,0x7fffffffa6c0,0x1) 1682 nc RET write -1 errno 22 Invalid argument 1682 nc CALL close(0x3) 1682 nc RET close 0 1682 nc CALL sigprocmask(SIG_BLOCK,0x80063e140,0x7fffffffc640) Problem is related with an [implicit] IPv4 bind() done in in_pcbconnect (or in_pcbbind_setup for explicit bind ). bind results in selected IPv4 address written in inp_inc.inc_ie.ie_dependladdr.ie46_local.ia46_addr4 According to struct in_addr_4in6, interpreting witten value as IPv6 address results in ::127.0.0.1 v6 address for 127.0.0.1 which is not IPv4-mapped address (it is deprecated IPv4-compatible adddress, actually). This address causes udp6_send() returning EINVAL (immediately after IN6_IS_ADDR_V4MAPPED(&inp->in6p_laddr) check) Proposed solution is to add missing :ffff: immediately after successful v4 layer connect, e.g. --- sys/netinet6/udp6_usrreq.c.orig 2010-06-24 12:32:10.813316692 +0000 +++ sys/netinet6/udp6_usrreq.c 2010-06-24 12:33:02.977455989 +0000 @@ -923,6 +923,8 @@ if (error == 0) { inp->inp_vflag |= INP_IPV4; inp->inp_vflag &= ~INP_IPV6; + /* Make v6 addr v4-mapped */ + inp->inp_inc.inc_ie.ie_dependladdr.ie46_local.ia46_pad32[2] = IPV6_ADDR_INT32_SMP; soisconnected(so); } goto out; This tiny patch fixes java DNS resolution for me From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 16:25:17 2010 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 01930106566C for ; Thu, 24 Jun 2010 16:25:17 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 948DC8FC14 for ; Thu, 24 Jun 2010 16:25:16 +0000 (UTC) Received: from mobile-166-129-250-066.mycingular.net (mobile-166-129-250-066.mycingular.net [166.129.250.66] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5OGP44a062681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jun 2010 12:25:09 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277396715; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=MWvF7QZbRj8Mv83HbHTZUZ6l/YfQUr3dDrHYZguM0EKjO3wuPreAF/W wRZ8gW+U1tuc4qK+yLIz0TKkXU1o29A== Message-Id: <3CF072B5-2DE3-45F4-B2B3-6C7DA89F09EE@lakerest.net> From: Randall Stewart To: Luigi Rizzo In-Reply-To: <20100624131004.GA39128@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 09:24:59 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <3A61E8D1-94A2-43D4-BD08-E4701A7A429D@lakerest.net> <20100624131004.GA39128@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 24 Jun 2010 16:25:17 -0000 On Jun 24, 2010, at 6:10 AM, Luigi Rizzo wrote: > On Thu, Jun 24, 2010 at 05:43:36AM -0700, Randall Stewart wrote: >> Lugi: >> >> One other comment I want to make about your numbers... well maybe >> three ;-) > ... > > Randall, > my numbers may well be affected by large errors, but the point was > just to show that the *16/32/64 functions are already widely used > across the board. > Since we all agree that these names are more clear than the old > naming conventions, it's time for old timers and net-centric > people (i am 47 and doing this stuff for over 20 years so i do > qualify) > to adapt to what everyone else is doing, rather than perpetrating > some confusing naming conventions. > > Fine, let's not change the existing ntohl() for no reason > (though, at some point in time there was a sweep of changes > from the macro NTOHL() to the function form), but at least > let's not introduce new functions with a poorly chosen name. Well, I don't know about poorly chosen names. Like you I have been in this business a long time now (over 30 years) ... and you know.. names are the only thing I have found that gets wild debate... ask a technical important point on an IETF mailing list when you are the lead document editor/author and you get dead silence.. ask what you should name this field... and you will get 1,000 email reply's with heated debate ;-) And the "preferred" name changes over time. Thats fine when the documentation keeps up of course... but in this case it just has not. I am of course assuming that the be64to* functions exist in linux at least and hopefully windoz... otherwise you have another problem... i.e. portability.. But like I said the preferred name will change.. as one private contact wrote me: " I too have used {hton,hton}{s,l} for many years but I hadn't heard of htobe64 until now. I bet 10 years from now someone will think *that* is too cryptic a name and will insist on using host_to_big_endian_64bit. " And I think thats a valid point.. what we "think" is a good name now will be thought of in the future as not so good. ntohs/ntohl made sense when they were introduced and due to propagation and years of use.. they exist most all places... and folks guess from that where to go for 64 bit.. hey if I do %lld in printf .. it must be ntohll() ... R > > Then sure, documentation is not up to date because no one has time > to fix it, old books and old code still show mostly old APIs, and > so on... > > cheers > luigi > >>> The case of *to*ll does not apply, in that there is no actual legacy >>> to adapt to. And btw there is tons of places which use the 16/32/64 >>> bit >>> names in the filesystem, usb and generic device drivers. In fact, >>> many more than ntohl/htonl >>> >>> > grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >>> 1438 6397 145174 >>> > grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc >>> 2203 10269 210989 >>> > grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc >>> 854 4009 84855 >>> > grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc >>> 738 3604 72970 >> >> 1) The grep for le32 is really not something you would do. You never >> convert network byte order to le32 for sending things on the wire >> since >> network byte order is be. I would imagine the 2203 occurrences are >> where >> you are dealing with buses (pci comes to mind) that want le. >> >> 2) When you grep be32 you are getting both conversions so you are >> comparing >> 1438 against 1592 (854+738). So it seems to me be32 is not used >> yet as >> much for network conversions.. and even more so one might want to >> delve >> in kernel wise to where the be32 is being used.. I would bet it is >> also >> in the same vein.. i.e. machines doing things with the bus... and >> very little network transmission code.. and that leads me to my >> final comment, which >> I think proves my point. >> >> 3) A much fairer comparison is looking in the head NOT including sys. >> I did a simple >> script along these lines by doing: >> cd ~head >> ls | grep -n sys > list >> grep -r be32 `cat list` | grep -v .svn | wc -l >> 215 >> grep -r ntohl `cat list` | grep -v .svn | wc -l >> 888 >> grep -r htonl `cat list` | grep -v .svn | wc -l >> 913 >> >> So adding that up its 1801 uses of the h/n macros and 215 of the >> be. Thats almost 10 to 1. >> >> >> Now I am not disagreeing with you that the be32 is clearer.. but my >> point is still valid... networking >> application developers do think in terms of the ntohl/htonl macros. >> Until we get more information >> out to them (assuming that the bexx and friends are available on >> linux >> and windows) you will not >> see an uptake in the use of them unless we educate folks. In this >> case >> ignorance is a good >> excuse until all networking manuals have be* and friends... looking >> in >> Fenner's update to >> UNP (3rd edition) I find only the ntohl/htonl macros mentioned ;-( >> >> A good start for documentation would be the man page for ntohl >> pointing directly at the be64 macros man >> page for 64 bit conversions.. I would suggest more than a reference >> and an explicit statement. >> Do that and people will not flounder around and roll their own.. >> well >> then again maybe they >> still will .. since folks are so conditioned for ntohx().. >> >> Hmm maybe I will take Julian's suggestion and make it easier for SCTP >> folks ;-) >> >> R >> >> >> >>> >>> cheers >>> luigi >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >>> " >>> >> >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 16:39:48 2010 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 8BD9C1065679 for ; Thu, 24 Jun 2010 16:39:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 461038FC19 for ; Thu, 24 Jun 2010 16:39:47 +0000 (UTC) Received: by gwb11 with SMTP id 11so1905974gwb.13 for ; Thu, 24 Jun 2010 09:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2ZYOhQKDTGyxYHrvMoEem2PXHG4syvBzhkISDqjW8eg=; b=mMCPoTcT5VcKfXwY+6bZsR7e/VSO4HZh4pnnNeNgaj86QHMPrMxa/Cx4VBb1R5cE+l wdoDiO8nrqym0dFmD0hKYoLlUgkscE03Y3J5oAPXWSLJ67Ri3ueTNij0ZYPy5vazBVl4 kUe/nhTNXjFIU8Yjlu9gP7fi23XJizJQoA9RM= 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=wr7JNPWt5PAYIS4lPovNgS0OqMc3F+4OtviikYiexMB9w/Ufm+3umIu+F91uev16/y tLdPmyS+TZgvACKMOFw0McToGY/FNOfeUBjgmvIkPB9QOIsne953+3+inIhjHqU7xVOj ST++9qRDcCPzXMFUMH8n2RPuW71dqOYiw2yto= MIME-Version: 1.0 Received: by 10.224.85.196 with SMTP id p4mr6370022qal.6.1277397587292; Thu, 24 Jun 2010 09:39:47 -0700 (PDT) Received: by 10.229.225.9 with HTTP; Thu, 24 Jun 2010 09:39:47 -0700 (PDT) In-Reply-To: <4C234E60.2060502@ipfw.ru> References: <50a120641003190539n7d60348ev85416f2777d6c82c@mail.gmail.com> <50a120641003241158t15806da9g5993cfc3c7099bc0@mail.gmail.com> <57156839.20100623092257@gmail.com> <4C234E60.2060502@ipfw.ru> Date: Thu, 24 Jun 2010 11:39:47 -0500 Message-ID: From: "Sam Fourman Jr." To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, dimm404@gmail.com, =?KOI8-R?B?5M3J1NLJyiD6wc3V0sHF1w==?= Subject: Re: [patch] ng_netflow 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, 24 Jun 2010 16:39:48 -0000 > > There are several major bugs in this patch. I'm planning to make updated > patch in several weeks. > At the moment it's a very bad idea to use current version in production >> I would be willing to test the new patch, I could use it. Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 17:04:40 2010 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 42A0A106566C for ; Thu, 24 Jun 2010 17:04:40 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84D1D8FC1D for ; Thu, 24 Jun 2010 17:04:39 +0000 (UTC) Received: by wyf22 with SMTP id 22so569260wyf.13 for ; Thu, 24 Jun 2010 10:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=7IEXZQX6/kbh2ydcewecYjAXzf3XxuivbgHFVzrrRDk=; b=ZzV62MVMoeuBJZzMGmbdGGTwKQ+3jVCNLfY6xxQhEj/dUm3lRjm6KbcBgfCZKOUf3H rKSezwrLHlVAXOEKr+MqOLuZ6GoQtUX20cd5D11teWK5QlRdxUxZH7R7eHXh+jxhndyZ IHH1G2FN7g73d83mQjk0Qe/kDy+Jnu+pgZBTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=H49lE+Z96s7fWNOny1rCdBUFRItuUoLFbpw6U9k5vt4a/YnNzJLIFqTcsab4+WJv3z eVqrHYhOScpdnFI+JAMjqXNT6NqTkuoyI8yQwk732frj9x90CpeuifeJ5daZAXzuuTHn QnZyAANKk/X9xpOiG0Bx6SWCsvU4IglHb8vns= Received: by 10.216.184.136 with SMTP id s8mr4086298wem.4.1277399077171; Thu, 24 Jun 2010 10:04:37 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.216.25.4 with HTTP; Thu, 24 Jun 2010 10:04:17 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Thu, 24 Jun 2010 18:04:17 +0100 X-Google-Sender-Auth: SECe-ttfJw7wmjfgE53OsNGaHWM Message-ID: To: Rafael Henrique Faria Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 17:04:40 -0000 On Thu, Jun 24, 2010 at 3:12 PM, Rafael Henrique Faria wrote: > Hi. > > I'm working on a Brige between a router Cisco 7200, and a 3Com 7900 switc= h. > I have several subnetworks, and I need to balance the bandwidth between t= hen. > > The Brigde is running: "FreeBSD dell05 8.1-PRERELEASE FreeBSD > 8.1-PRERELEASE #0: Tue Jun 22 13:59:17 BRT 2010 > rafaelhfaria@dell05:/usr/obj/usr/src/sys/BRIDGE =A0amd64" > > I have the following lines in /boot/loader.conf: > --- > net.graph.maxalloc=3D512 > net.graph.maxdgram=3D45000 > net.graph.recvspace=3D45000 > bridgestp_load=3D"YES" > if_vlan_load=3D"YES" > --- > > And my kernel is compiled with: > device =A0 =A0 =A0 =A0 =A0if_bridge > device =A0 =A0 =A0 =A0 =A0pf > device =A0 =A0 =A0 =A0 =A0pflog > options =A0 =A0 =A0 =A0 ALTQ > options =A0 =A0 =A0 =A0 ALTQ_CBQ > options =A0 =A0 =A0 =A0 ALTQ_RED > options =A0 =A0 =A0 =A0 ALTQ_RIO > options =A0 =A0 =A0 =A0 ALTQ_HFSC > options =A0 =A0 =A0 =A0 ALTQ_PRIQ > options =A0 =A0 =A0 =A0 ALTQ_NOPCC > options =A0 =A0 =A0 =A0 DEVICE_POLLING > options =A0 =A0 =A0 =A0 HZ=3D1000 > options =A0 =A0 =A0 =A0 SHMSEG=3D16 > options =A0 =A0 =A0 =A0 SHMMNI=3D32 > options =A0 =A0 =A0 =A0 SHMMAX=3D2097152 > options =A0 =A0 =A0 =A0 SHMALL=3D4096 > options =A0 =A0 =A0 =A0 MAXFILES=3D8192 > > And the bridge configuration: > cloned_interfaces=3D"bridge0 vlan1" > ifconfig_bridge0=3D"addm bce0 stp bce0 addm bce1 stp bce1 up" > ifconfig_bce0=3D"polling up" > ifconfig_bce1=3D"polling up" > ifconfig_vlan1=3D"inet 200.x.x.x netmask 0xFFFFFF00 broadcast > 200.x.x.255 vlan 1 vlandev bce1" > > bce0 is connected to the Cisco 7200 ($wan_if in pf) > bce1 is conencted to the 3Com 7900 ($lan_if in pf) > > And my sysctl for bridge: > dell05# sysctl net.link.bridge > net.link.bridge.ipfw: 0 > net.link.bridge.inherit_mac: 0 > net.link.bridge.log_stp: 0 > net.link.bridge.pfil_local_phys: 1 > net.link.bridge.pfil_member: 1 > net.link.bridge.pfil_bridge: 0 > net.link.bridge.ipfw_arp: 0 > net.link.bridge.pfil_onlyip: 0 > dell05# > > Ok... > > Now, the problem. > > With the following queue: > altq on $lan_if bandwidth 33Mb hfsc queue { down_sub1, down_sub2, > down_sub3, down_sub4, down_def } > =A0 queue down_sub1 =A0 bandwidth 8Mb priority 1 qlimit 300 hfsc ( > realtime 3.20Mb upperlimit 22.40Mb ) > =A0 queue down_sub2 =A0 bandwidth 8Mb priority 1 qlimit 300 hfsc ( > realtime 3.20Mb upperlimit 22.40Mb ) > =A0 queue down_sub3 =A0bandwidth 8Mb priority 1 qlimit 300 hfsc ( > realtime 3.20Mb upperlimit 22.40Mb ) > =A0 queue down_sub4 =A0bandwidth 8Mb priority 1 qlimit 300 hfsc ( > realtime 3.20Mb upperlimit 22.40Mb ) > =A0 queue down_def =A0 =A0 bandwidth 128Kb hfsc ( default ) > > And with the following rules: > pass in =A0log quick on $lan_if from to any keep state queue ( dow= n_sub1 ) > pass out log quick on $wan_if from to any keep state queue ( up_su= b1 ) > pass in =A0log quick on $wan_if from any to keep state queue ( up_= sub1 ) > pass out log quick on $lan_if from any to keep state queue ( down_= sub1 ) > > (..) for each I have the pass rules like those. > > > With the full use of the link, only a small part of the traffic gets > into the correct queue. > > queue root_bce1 on bce1 bandwidth 33Mb priority 0 {down_sub1, > down_sub2, down_sub3, down_sub4, down_def} > =A0[ pkts: =A0 =A0 =A0 =A0 =A00 =A0bytes: =A0 =A0 =A0 =A0 =A00 =A0dropped= pkts: =A0 =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/ 50 ] > =A0[ measured: =A0 =A0 0.0 packets/s, 0 b/s ] > queue =A0down_sub1 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime > 3.20Mb upperlimit 22.40Mb ) > =A0[ pkts: =A0 =A0 =A053177 =A0bytes: =A0 50082785 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/300 ] > =A0[ measured: =A0 364.5 packets/s, 2.81Mb/s ] > queue =A0down_sub2 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime > 3.20Mb upperlimit 22.40Mb ) > =A0[ pkts: =A0 =A0 =A090724 =A0bytes: =A0 79670459 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/300 ] > =A0[ measured: =A0 744.6 packets/s, 5.20Mb/s ] > queue =A0down_sub3 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime > 3.20Mb upperlimit 22.40Mb ) > =A0[ pkts: =A0 =A0 =A038333 =A0bytes: =A0 37384626 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/300 ] > =A0[ measured: =A0 285.2 packets/s, 2.35Mb/s ] > queue =A0down_sub4 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime > 3.20Mb upperlimit 22.40Mb ) > =A0[ pkts: =A0 =A0 =A080385 =A0bytes: =A0 69021129 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/300 ] > =A0[ measured: =A0 585.1 packets/s, 3.92Mb/s ] > queue =A0down_def on bce1 bandwidth 128Kb hfsc( default ) > =A0[ pkts: =A0 =A0 268756 =A0bytes: =A0336423531 =A0dropped pkts: =A0 =A0= 121 bytes: =A081921 ] > =A0[ qlength: =A0 0/ 50 ] > =A0[ measured: =A01615.4 packets/s, 16.49Mb/s ] > > watching the pflog interface, I can see that the pass rules are > working, no traffic is getting out of one of the rules (I have put an > "pass log all" to check this). > > All the rules are working... but they aren't sending the traffic to > the specified queue. > > If someone have a glue for this... > Any suggestion are welcome. > > Thank's in advance. Sorry but i do not see any evidence that what you claim is true! --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 17:18:31 2010 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 98C831065672; Thu, 24 Jun 2010 17:18:31 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6907A8FC18; Thu, 24 Jun 2010 17:18:31 +0000 (UTC) Received: by pwj1 with SMTP id 1so2250809pwj.13 for ; Thu, 24 Jun 2010 10:18:27 -0700 (PDT) Received: by 10.114.164.37 with SMTP id m37mr9901230wae.39.1277399907488; Thu, 24 Jun 2010 10:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.16 with HTTP; Thu, 24 Jun 2010 10:18:07 -0700 (PDT) In-Reply-To: References: From: Rafael Henrique Faria Date: Thu, 24 Jun 2010 14:18:07 -0300 Message-ID: To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 17:18:31 -0000 On Thu, Jun 24, 2010 at 14:04, Ermal Lu=E7i wrote: > On Thu, Jun 24, 2010 at 3:12 PM, Rafael Henrique Faria > wrote: >> Hi. >> >> I'm working on a Brige between a router Cisco 7200, and a 3Com 7900 swit= ch. >> I have several subnetworks, and I need to balance the bandwidth between = then. >> >> The Brigde is running: "FreeBSD dell05 8.1-PRERELEASE FreeBSD >> 8.1-PRERELEASE #0: Tue Jun 22 13:59:17 BRT 2010 >> rafaelhfaria@dell05:/usr/obj/usr/src/sys/BRIDGE =A0amd64" >> >> I have the following lines in /boot/loader.conf: >> --- >> net.graph.maxalloc=3D512 >> net.graph.maxdgram=3D45000 >> net.graph.recvspace=3D45000 >> bridgestp_load=3D"YES" >> if_vlan_load=3D"YES" >> --- >> >> And my kernel is compiled with: >> device =A0 =A0 =A0 =A0 =A0if_bridge >> device =A0 =A0 =A0 =A0 =A0pf >> device =A0 =A0 =A0 =A0 =A0pflog >> options =A0 =A0 =A0 =A0 ALTQ >> options =A0 =A0 =A0 =A0 ALTQ_CBQ >> options =A0 =A0 =A0 =A0 ALTQ_RED >> options =A0 =A0 =A0 =A0 ALTQ_RIO >> options =A0 =A0 =A0 =A0 ALTQ_HFSC >> options =A0 =A0 =A0 =A0 ALTQ_PRIQ >> options =A0 =A0 =A0 =A0 ALTQ_NOPCC >> options =A0 =A0 =A0 =A0 DEVICE_POLLING >> options =A0 =A0 =A0 =A0 HZ=3D1000 >> options =A0 =A0 =A0 =A0 SHMSEG=3D16 >> options =A0 =A0 =A0 =A0 SHMMNI=3D32 >> options =A0 =A0 =A0 =A0 SHMMAX=3D2097152 >> options =A0 =A0 =A0 =A0 SHMALL=3D4096 >> options =A0 =A0 =A0 =A0 MAXFILES=3D8192 >> >> And the bridge configuration: >> cloned_interfaces=3D"bridge0 vlan1" >> ifconfig_bridge0=3D"addm bce0 stp bce0 addm bce1 stp bce1 up" >> ifconfig_bce0=3D"polling up" >> ifconfig_bce1=3D"polling up" >> ifconfig_vlan1=3D"inet 200.x.x.x netmask 0xFFFFFF00 broadcast >> 200.x.x.255 vlan 1 vlandev bce1" >> >> bce0 is connected to the Cisco 7200 ($wan_if in pf) >> bce1 is conencted to the 3Com 7900 ($lan_if in pf) >> >> And my sysctl for bridge: >> dell05# sysctl net.link.bridge >> net.link.bridge.ipfw: 0 >> net.link.bridge.inherit_mac: 0 >> net.link.bridge.log_stp: 0 >> net.link.bridge.pfil_local_phys: 1 >> net.link.bridge.pfil_member: 1 >> net.link.bridge.pfil_bridge: 0 >> net.link.bridge.ipfw_arp: 0 >> net.link.bridge.pfil_onlyip: 0 >> dell05# >> >> Ok... >> >> Now, the problem. >> >> With the following queue: >> altq on $lan_if bandwidth 33Mb hfsc queue { down_sub1, down_sub2, >> down_sub3, down_sub4, down_def } >> =A0 queue down_sub1 =A0 bandwidth 8Mb priority 1 qlimit 300 hfsc ( >> realtime 3.20Mb upperlimit 22.40Mb ) >> =A0 queue down_sub2 =A0 bandwidth 8Mb priority 1 qlimit 300 hfsc ( >> realtime 3.20Mb upperlimit 22.40Mb ) >> =A0 queue down_sub3 =A0bandwidth 8Mb priority 1 qlimit 300 hfsc ( >> realtime 3.20Mb upperlimit 22.40Mb ) >> =A0 queue down_sub4 =A0bandwidth 8Mb priority 1 qlimit 300 hfsc ( >> realtime 3.20Mb upperlimit 22.40Mb ) >> =A0 queue down_def =A0 =A0 bandwidth 128Kb hfsc ( default ) >> >> And with the following rules: >> pass in =A0log quick on $lan_if from to any keep state queue ( do= wn_sub1 ) >> pass out log quick on $wan_if from to any keep state queue ( up_s= ub1 ) >> pass in =A0log quick on $wan_if from any to keep state queue ( up= _sub1 ) >> pass out log quick on $lan_if from any to keep state queue ( down= _sub1 ) >> >> (..) for each I have the pass rules like those. >> >> >> With the full use of the link, only a small part of the traffic gets >> into the correct queue. >> >> queue root_bce1 on bce1 bandwidth 33Mb priority 0 {down_sub1, >> down_sub2, down_sub3, down_sub4, down_def} >> =A0[ pkts: =A0 =A0 =A0 =A0 =A00 =A0bytes: =A0 =A0 =A0 =A0 =A00 =A0droppe= d pkts: =A0 =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/ 50 ] >> =A0[ measured: =A0 =A0 0.0 packets/s, 0 b/s ] >> queue =A0down_sub1 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime >> 3.20Mb upperlimit 22.40Mb ) >> =A0[ pkts: =A0 =A0 =A053177 =A0bytes: =A0 50082785 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/300 ] >> =A0[ measured: =A0 364.5 packets/s, 2.81Mb/s ] >> queue =A0down_sub2 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime >> 3.20Mb upperlimit 22.40Mb ) >> =A0[ pkts: =A0 =A0 =A090724 =A0bytes: =A0 79670459 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/300 ] >> =A0[ measured: =A0 744.6 packets/s, 5.20Mb/s ] >> queue =A0down_sub3 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime >> 3.20Mb upperlimit 22.40Mb ) >> =A0[ pkts: =A0 =A0 =A038333 =A0bytes: =A0 37384626 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/300 ] >> =A0[ measured: =A0 285.2 packets/s, 2.35Mb/s ] >> queue =A0down_sub4 on bce1 bandwidth 8Mb qlimit 300 hfsc( realtime >> 3.20Mb upperlimit 22.40Mb ) >> =A0[ pkts: =A0 =A0 =A080385 =A0bytes: =A0 69021129 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/300 ] >> =A0[ measured: =A0 585.1 packets/s, 3.92Mb/s ] >> queue =A0down_def on bce1 bandwidth 128Kb hfsc( default ) >> =A0[ pkts: =A0 =A0 268756 =A0bytes: =A0336423531 =A0dropped pkts: =A0 = =A0121 bytes: =A081921 ] >> =A0[ qlength: =A0 0/ 50 ] >> =A0[ measured: =A01615.4 packets/s, 16.49Mb/s ] >> >> watching the pflog interface, I can see that the pass rules are >> working, no traffic is getting out of one of the rules (I have put an >> "pass log all" to check this). >> >> All the rules are working... but they aren't sending the traffic to >> the specified queue. >> >> If someone have a glue for this... >> Any suggestion are welcome. >> >> Thank's in advance. > > Sorry but i do not see any evidence that what you claim is true! > > -- > Ermal > My subnets are all /24, so table const { 200.x.1.0/24 } table const { 200.x.2.0/24 } table const { 200.x.3.0/24 } table const { 200.x.4.0/24 } In my network, I only have thoses subnets. With: pass all from to any queue sub1 pass all from any to queue sub1 pass all from to any queue sub2 pass all from any to queue sub2 pass all from to any queue sub3 pass all from any to queue sub3 pass all from to any queue sub4 pass all from any to queue sub4 pass all (sent to default queue) The queues have to get all the traffic from my network. But it don't. If I put an log option to the last pass all rule, and do a tcpdump to pflog0, no packet is showed. So, the rules are working OK. But with "pfctl -vvs queue", it shows: sub1: 2.81Mb/s sub2: 5.20Mb/s sub3: 2.35Mb/s sub4: 3.92Mb/s default: 16.49Mb/s As I can understand, with the pass rules, all the traffic from that subnets, need to get into that queue. So... with the pass rule of the , all the traffic data from that subnet, need to get into the queue sub1, the same with sub2, sub3, and sub4. But, Why, I have a high traffic in the default queue? There is no packet at the last pass all rule. So, no packet is missing the other rules. What I want, it to get all the traffic from 200.x.1.0/24, into the sub1 queue, and get limited by this queue, not the default queue. And again, the same with sub2-4. I'm using HFSC, but I'll try with CBQ. --=20 Rafael Henrique da Silva Faria Grupo de Sistemas e Redes Servi=E7o T=E9cnico de Inform=E1tica Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 19:42:36 2010 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 87B5D1065674; Thu, 24 Jun 2010 19:42:36 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 30F878FC16; Thu, 24 Jun 2010 19:42:36 +0000 (UTC) Received: by gwb11 with SMTP id 11so2055799gwb.13 for ; Thu, 24 Jun 2010 12:42:35 -0700 (PDT) Received: by 10.229.181.16 with SMTP id bw16mr5610708qcb.223.1277408555371; Thu, 24 Jun 2010 12:42:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.201.16 with HTTP; Thu, 24 Jun 2010 12:42:15 -0700 (PDT) In-Reply-To: References: From: Rafael Henrique Faria Date: Thu, 24 Jun 2010 16:42:15 -0300 Message-ID: To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?M=E1rcio_Luciano_Donada?= Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 19:42:36 -0000 Just to be more clean: My pf.conf: ---- wan_if=3D"bce0" set limit { states 100000, frags 20000 } set loginterface $wan_if set optimization normal set block-policy drop set fingerprints "/etc/pf.os" set skip on lo altq on $wan_if cbq bandwidth 100% queue { out_bal, out_std } queue out_bal bandwidth 50% priority 0 cbq queue out_std bandwidth 50% priority 0 cbq (default borrow) pass out on $wan_if queue (out_bal) ---- The "pfctl -vvs queue" show: ---- queue root_bce0 on bce0 bandwidth 1Gb priority 0 cbq( wrr root ) {out_bal, out_std} [ pkts: 50117 bytes: 13947411 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 3869.4 packets/s, 8.31Mb/s ] queue out_bal on bce0 bandwidth 500Mb priority 0 [ pkts: 33198 bytes: 7175985 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 2591.3 packets/s, 4.36Mb/s ] queue out_std on bce0 bandwidth 500Mb priority 0 cbq( borrow default ) [ pkts: 16919 bytes: 6771426 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 1278.1 packets/s, 3.95Mb/s ] ---- So, my question is: why the default queue is being used, If I have a rule to use the out_bal queue to all outgoing traffic on that interface? I need to redirect all the traffic from a subnet (/24) to one queue (incoming and outgoing traffic)... so what I can understand is that, this is not possible with PF+ALTQ. Am I wrong? --=20 Rafael Henrique da Silva Faria Grupo de Sistemas e Redes Servi=E7o T=E9cnico de Inform=E1tica Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 20:47:21 2010 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 AC85C106564A for ; Thu, 24 Jun 2010 20:47:21 +0000 (UTC) (envelope-from buchtajz@borsice.net) Received: from mx.sitkom.cz (mx.sitkom.cz [109.164.0.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7F98FC1A for ; Thu, 24 Jun 2010 20:47:21 +0000 (UTC) Received: from spamd.mail.sitkom.cz (mail.mx.sitkom.cz [10.13.126.5]) by mx.mail.sitkom.cz (Postfix) with ESMTP id 549E21C66F2 for ; Thu, 24 Jun 2010 22:47:18 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.mx.sitkom.cz X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from avscan.mail.sitkom.cz (mx.sitkom.cz [109.164.0.132]) by spamd.mail.sitkom.cz (Postfix) with ESMTP id 36D8A1C6680 for ; Thu, 24 Jun 2010 22:47:18 +0200 (CEST) Received: from [10.10.0.12] (manwe.buchtikov.borsice.sfn [10.10.0.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.sitkom.cz (Postfix) with ESMTPSA id 179881C6417 for ; Thu, 24 Jun 2010 22:47:18 +0200 (CEST) Message-ID: <4C23C442.6030501@borsice.net> Date: Thu, 24 Jun 2010 22:46:58 +0200 From: Michal Buchtik User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100622 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 20:47:21 -0000 Hi, On 2010/06/24 21:42, Rafael Henrique Faria wrote: > So, my question is: why the default queue is being used, If I have a > rule to use the out_bal queue to all outgoing traffic on that > interface? > > I need to redirect all the traffic from a subnet (/24) to one queue > (incoming and outgoing traffic)... so what I can understand is that, > this is not possible with PF+ALTQ. Am I wrong? > > I never try pf on bridge, but on router. You must create queues on every interface (only outgoing packets are queued) and pass rules on every interface too. States created then directs packets to right queue. Try something like: pass in log quick on $lan_if from to any tag SUB1_UP keep state queue ( down_sub1 ) pass out log quick on $wan_if tagged SUB1_UP keep state queue (up_sub1) pass in log quick on $wan_if from any to tag SUB1_DOWN keep state queue ( up_sub1 ) pass out log quick on $lan_if tagged SUB1_DOWN keep state queue ( down_sub1 ) or try "no state", but with performance decrease. This is only working solution I found (on router). From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 21:56:44 2010 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 6E2BC1065672; Thu, 24 Jun 2010 21:56:44 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB22E8FC27; Thu, 24 Jun 2010 21:56:43 +0000 (UTC) Received: by wwb24 with SMTP id 24so2186449wwb.13 for ; Thu, 24 Jun 2010 14:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wD1oRSZfP1a5y7IaM9wR/7WCxuEBtU2HdNn21x1vmYg=; b=tCj7GlODijDxEbllFU0GZfic5Ny884w98wp7Q5q5Tq4NwFp2Q2/+slNtTiV1FJIetH ImyPJ5rd41E02BhTkS9IiorS04l+tV0z/Hjb9V6moIdv4g08b8IVcdrDx8R6PajVrYlx 0eipnpV+LtRo12XqhX3sw71+vhTXYE7HfJknk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=xSWGe6WJFjUcuL+YmwBaEaLg2xg3qLr6NiM9Qf4ztS34yl4/kJmqzixaUQoytEX3ol v0uTYF1QaM+b+H7duCMYg5Po2zA6JlSxkvKiBK2Oa7dkjaLGhSrgNPQXOnaSjqEDntWR s5enggk0AKRsvisiczRviv4lq2FA4pEfljBmU= Received: by 10.216.85.17 with SMTP id t17mr7919192wee.30.1277416602262; Thu, 24 Jun 2010 14:56:42 -0700 (PDT) MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.216.25.4 with HTTP; Thu, 24 Jun 2010 14:56:22 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Thu, 24 Jun 2010 23:56:22 +0200 X-Google-Sender-Auth: nqNfi4jPfnO-9VH1x9VpbNs8Fcc Message-ID: To: Rafael Henrique Faria Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?M=E1rcio_Luciano_Donada?= , freebsd-pf@freebsd.org Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 21:56:44 -0000 2010/6/24 Rafael Henrique Faria : > Just to be more clean: > > My pf.conf: > ---- > wan_if=3D"bce0" > > set limit { states 100000, frags 20000 } > set loginterface $wan_if > set optimization normal > set block-policy drop > set fingerprints "/etc/pf.os" > set skip on lo > > altq on $wan_if cbq bandwidth 100% queue { out_bal, out_std } > =A0 queue out_bal bandwidth 50% priority 0 cbq > =A0 queue out_std bandwidth 50% priority 0 cbq (default borrow) > > pass out on $wan_if queue (out_bal) > ---- > The problem is that this rule will not match any traffic that initiated as incoming on $wan_if. Try this instead: pass out all queue (out_bal) It will do the magic. > > The "pfctl -vvs queue" show: > > ---- > queue root_bce0 on bce0 bandwidth 1Gb priority 0 cbq( wrr root ) > {out_bal, out_std} > =A0[ pkts: =A0 =A0 =A050117 =A0bytes: =A0 13947411 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 =A0= 0 ] > =A0[ measured: =A03869.4 packets/s, 8.31Mb/s ] > queue =A0out_bal on bce0 bandwidth 500Mb priority 0 > =A0[ pkts: =A0 =A0 =A033198 =A0bytes: =A0 =A07175985 =A0dropped pkts: =A0= =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 =A0= 0 ] > =A0[ measured: =A02591.3 packets/s, 4.36Mb/s ] > queue =A0out_std on bce0 bandwidth 500Mb priority 0 cbq( borrow default ) > =A0[ pkts: =A0 =A0 =A016919 =A0bytes: =A0 =A06771426 =A0dropped pkts: =A0= =A0 =A00 bytes: =A0 =A0 =A00 ] > =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 =A0= 0 ] > =A0[ measured: =A01278.1 packets/s, 3.95Mb/s ] > ---- > > So, my question is: why the default queue is being used, If I have a > rule to use the out_bal queue to all outgoing traffic on that > interface? > > I need to redirect all the traffic from a subnet (/24) to one queue > (incoming and outgoing traffic)... so what I can understand is that, > this is not possible with PF+ALTQ. Am I wrong? > > -- > Rafael Henrique da Silva Faria > Grupo de Sistemas e Redes > > Servi=E7o T=E9cnico de Inform=E1tica > Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 23:01:38 2010 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 AEBDD106564A; Thu, 24 Jun 2010 23:01:38 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 388208FC0A; Thu, 24 Jun 2010 23:01:37 +0000 (UTC) Received: by vws13 with SMTP id 13so3121321vws.13 for ; Thu, 24 Jun 2010 16:01:37 -0700 (PDT) Received: by 10.220.127.79 with SMTP id f15mr5419326vcs.271.1277420497267; Thu, 24 Jun 2010 16:01:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.87.85 with HTTP; Thu, 24 Jun 2010 16:01:17 -0700 (PDT) In-Reply-To: References: From: Rafael Henrique Faria Date: Thu, 24 Jun 2010 20:01:17 -0300 Message-ID: To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Unknown Behavior of PF+ALTQ on a 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: Thu, 24 Jun 2010 23:01:38 -0000 On Thu, Jun 24, 2010 at 18:56, Ermal Lu=E7i wrote: > 2010/6/24 Rafael Henrique Faria : >> Just to be more clean: >> >> My pf.conf: >> ---- >> wan_if=3D"bce0" >> >> set limit { states 100000, frags 20000 } >> set loginterface $wan_if >> set optimization normal >> set block-policy drop >> set fingerprints "/etc/pf.os" >> set skip on lo >> >> altq on $wan_if cbq bandwidth 100% queue { out_bal, out_std } >> =A0 queue out_bal bandwidth 50% priority 0 cbq >> =A0 queue out_std bandwidth 50% priority 0 cbq (default borrow) >> >> pass out on $wan_if queue (out_bal) >> ---- >> > The problem is that this rule will not match any traffic that > initiated as incoming on $wan_if. > > Try this instead: > =A0pass out all queue (out_bal) > > It will do the magic. I tried it... but nothing changes... the same behavior. queue root_bce0 on bce0 bandwidth 1Gb priority 0 cbq( wrr root ) {out_bal, out_std} [ pkts: 76573 bytes: 14784373 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 2774.1 packets/s, 4.15Mb/s ] queue out_bal on bce0 bandwidth 500Mb priority 0 [ pkts: 27413 bytes: 8197630 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 1040.4 packets/s, 2.34Mb/s ] queue out_std on bce0 bandwidth 500Mb priority 0 cbq( borrow default ) [ pkts: 49160 bytes: 6586743 dropped pkts: 0 bytes: 0= ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 1733.7 packets/s, 1.81Mb/s ] I have tried a lot of rules... including: pass all queue out_bal But without success... If this is not the regular behavior of PF+ALTQ, my suspect is on the Bridge itself... >> >> The "pfctl -vvs queue" show: >> >> ---- >> queue root_bce0 on bce0 bandwidth 1Gb priority 0 cbq( wrr root ) >> {out_bal, out_std} >> =A0[ pkts: =A0 =A0 =A050117 =A0bytes: =A0 13947411 =A0dropped pkts: =A0 = =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 = =A00 ] >> =A0[ measured: =A03869.4 packets/s, 8.31Mb/s ] >> queue =A0out_bal on bce0 bandwidth 500Mb priority 0 >> =A0[ pkts: =A0 =A0 =A033198 =A0bytes: =A0 =A07175985 =A0dropped pkts: = =A0 =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 = =A00 ] >> =A0[ measured: =A02591.3 packets/s, 4.36Mb/s ] >> queue =A0out_std on bce0 bandwidth 500Mb priority 0 cbq( borrow default = ) >> =A0[ pkts: =A0 =A0 =A016919 =A0bytes: =A0 =A06771426 =A0dropped pkts: = =A0 =A0 =A00 bytes: =A0 =A0 =A00 ] >> =A0[ qlength: =A0 0/ 50 =A0borrows: =A0 =A0 =A00 =A0suspends: =A0 =A0 = =A00 ] >> =A0[ measured: =A01278.1 packets/s, 3.95Mb/s ] >> ---- >> >> So, my question is: why the default queue is being used, If I have a >> rule to use the out_bal queue to all outgoing traffic on that >> interface? >> >> I need to redirect all the traffic from a subnet (/24) to one queue >> (incoming and outgoing traffic)... so what I can understand is that, >> this is not possible with PF+ALTQ. Am I wrong? >> >> -- >> Rafael Henrique da Silva Faria >> Grupo de Sistemas e Redes >> >> Servi=E7o T=E9cnico de Inform=E1tica >> Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Ermal > --=20 Rafael Henrique da Silva Faria Grupo de Sistemas e Redes Servi=E7o T=E9cnico de Inform=E1tica Faculdade de Ci=EAncias e Letras do Campus de Araraquara - UNESP From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 03:32:20 2010 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 B8515106564A for ; Fri, 25 Jun 2010 03:32:20 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4A38FC18 for ; Fri, 25 Jun 2010 03:32:19 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so44671fga.13 for ; Thu, 24 Jun 2010 20:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=98bnQRJmpPVxEiNAOLcI/ipzKCHUoCMHbMiPjxUjcO8=; b=w9QSJolY6r8AUvJDDqZtawclc0WIcBQ4Zl3FsMLyJeGXRLU7ZTdufXGBFY3TZctH09 D8KGcUXCM5RfYFTG/bxwhkgJPsftENyQOlHHELIcEYP/Sd0k5BhQty3AhngR3oCD/ctM hqpsQrIw4v+hvRiVQpO+b3hmlSq5qtBH620KA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=JBS8WQCZl2pdwKOiCFxZfMJqzIj2VKii+KBCH77AjA9Zocv9hdpA/rrHqaFWYpe4v2 tWeztJPFK1gUK8eTQuTOuebd0KNDlnxcqFoZnB/W9OjChv2FnWpqJ6mEUDgv6e9hc43N J6ngXoQWAw7RCzIAGRI8mRKROaMYto7IMQRKg= Received: by 10.86.124.8 with SMTP id w8mr145113fgc.8.1277436739067; Thu, 24 Jun 2010 20:32:19 -0700 (PDT) Received: from 244.dynamic-n38.in72.ru ([91.203.38.244]) by mx.google.com with ESMTPS id 4sm285291fgg.7.2010.06.24.20.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Jun 2010 20:32:18 -0700 (PDT) Date: Fri, 25 Jun 2010 09:29:30 +0600 From: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?= X-Priority: 3 (Normal) Message-ID: <1405071838.20100625092930@gmail.com> To: "Sam Fourman Jr." In-Reply-To: References: <50a120641003190539n7d60348ev85416f2777d6c82c@mail.gmail.com> <50a120641003241158t15806da9g5993cfc3c7099bc0@mail.gmail.com> <57156839.20100623092257@gmail.com> <4C234E60.2060502@ipfw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, dimm404@gmail.com, "Alexander V. Chernikov" Subject: Re: [patch] ng_netflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 03:32:20 -0000 >> >> There are several major bugs in this patch. I'm planning to make updated >> patch in several weeks. >> At the moment it's a very bad idea to use current version in production >>> I noticed :) I have many kernel panic's on heavy load (300+300Mbit on GE channel) in function GetAsNumber. Can't tell, where exactly fails, because i rewriting you code and have't sources for compiled module. > I would be willing to test the new patch, I could use it. I will too. From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 13:10:02 2010 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 B0DAE1065672 for ; Fri, 25 Jun 2010 13:10:02 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 670268FC1C for ; Fri, 25 Jun 2010 13:10:02 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o5PDB0TE063872; Fri, 25 Jun 2010 06:11:01 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C24AAA9.7090309@mahan.org> Date: Fri, 25 Jun 2010 06:10:01 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Pierre Lamy References: <4C21A3C2.9050002@mahan.org> <4C227D9C.60701@userid.org> In-Reply-To: <4C227D9C.60701@userid.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multicast under FBSD 8.0 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, 25 Jun 2010 13:10:02 -0000 Pierre, The RIP source is all the BSD boxes in the current broadcast domain that run our product. The app does pick which interface to send the message out on and sets that using the appropriate MULTICAST setsockoptions. It is built for 8.0 (Or rather it is built using the 8.0 toolchain :-)) However, I believe this was something that was automatically configured for each box under 6.2 as part of the normal configuration. We have since removed it and the app is now working fine. I was being asked why the change occurred, and since multicast is not something I am familiar with, I turned to this list. Thanks, Patrick Pierre Lamy wrote: > Multicast traffic doesn't get routed in a traditional sense, it sort of > gets repackaged for delivery to requesting recipients. > > And 224/24 should never get retransmitted, it's for within a broadcast > domain only. > > Is the RIP source the BSD box itself? If so, the app should determine > what interfaces to send on, and then use that. Can you recompile the > daemon for 8? > > Pierre > > Patrick Mahan wrote: >> All, >> >> Hoping for a little insight as I am not a user of multicast nor >> do I know much about the servers that use them. >> >> In my day job, I am helping with the moving of my company's product >> from FreeBSD 6.2 (i386) to FreeBSD 8.0 (amd64). One of the daemons >> wants to use 224.0.0.9 (routed? rip?) multicast group. >> >> The problem is this worked fine on 6.2 but when we moved to 8.0 >> the daemon started reporting "Network unreachable" errors when >> it was trying to send a packet out to the multicast group. >> >> I tracked it down to the following in the routing table: >> >> % netstat -nr >> >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif >> Expire >> default 10.10.1.1 UG 0 0 bce0 >> 10.10.0.0/16 link#5 U 3 1253 bce0 >> ... >> 224.0.0.2 127.0.0.1 UH 0 0 lo0 >> 224.0.0.9 127.0.0.1 UH 0 0 lo0 >> >> Notice that 224.0.0.9 has a route pointing to the loopback interface, >> even though the code uses the IP_MULTICAST_IF socket option to specify >> the interface. If this entry does not exist or points to a true physical >> interface, then there is no issue. >> >> I did some research on this and found this code all changed in in_pcb.c >> as part of revision 105629 for FreeBSD 7.2. But I don't understand why >> he change and why the loopback was no longer allowed. I get asked >> daily by the developers of this daemon for the reason, so I was hoping >> to get some enlightment here. >> >> Thanks for listening, >> >> Patrick >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 17:29:31 2010 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 B7B27106564A for ; Fri, 25 Jun 2010 17:29:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7238FC1E for ; Fri, 25 Jun 2010 17:29:30 +0000 (UTC) Received: from c122-107-125-7.carlnfd1.nsw.optusnet.com.au (c122-107-125-7.carlnfd1.nsw.optusnet.com.au [122.107.125.7]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5PHTP9Y004881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jun 2010 03:29:27 +1000 Date: Sat, 26 Jun 2010 03:29:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> Message-ID: <20100626022258.Y47182@delplex.bde.org> References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 25 Jun 2010 17:29:31 -0000 On Wed, 23 Jun 2010, Randall Stewart wrote: > Bruce: > > Comments (and questions in-line)... (you too Luigi) See Luigi's reply for most details.. > On Jun 23, 2010, at 6:33 AM, Bruce Evans wrote: > >> On Wed, 23 Jun 2010, Luigi Rizzo wrote: >>> strong objection! >>> We should instead use names with exact sizes (16,32,64). > > So please tell me why you object so strongly? We have the 16/32/64 bit names > which > are nice but are not expected so folks seem to not use them. I have > received a few private comments to the effect that "Gee, we would like > that, we rolled our own versions of ntohll() and if you did it we could > remove our version". This tells me that although a nicer name, folks > are rolling their own due to the name. Having a #define that maps > ntohll -> be64toh will make it so that people can actually find > the function. Not really. Such a define would be an obfuscation, and might make it fairly hard to find the actual function. See the corresponding #define for ntohl(). It is far from what is documented and it takes searching through 3-4 layers of include files and/or nested macros (with at least the lowest layer differing across arches) to see what it is: on i386: - man page: no mention of whether it is a function or a macro or both, except for the non-i386 case where it is "null" where it is misdocumented as being null (but it is never null). I think it is actually both a (extern) function and a macro. POSIX may require both, and doesn't prohibit the function, so we implement the function. - sys/param.h: htonl() may be defined at a lower level. It isn't on i386. When it isn't defined at a lower level, it is defined here as __htonl(x). Before this, if it isn't prototyped at a lower level, it is prototyped here, so that #undefing it works right. - i386/include/endian.h: - __htonl(x) is defined as __bswap32(x) - __bswap32(x) is a static inline function taking a uint32_t arg and returns a uint32_t after calling __byte_swap_int(x). The typed arg causes a converion of the 'x' arg in ntohl(x) in cases where it is not already uint32_t. I think this conversion is required by POSIX. On big-endian arches where ntohl(x) is "null", this conversion should be done too, so the macro cannot be null (really the null filter). It is done at the level of endian.h on at least sparc64. - __byte_swap_int(x) is a macro that expands in various ways: - if __OPTIMIZE__ is defined (i.e., for compiling with -O1 or higher), then it expands to the macro __byte_swap_int_var(x) if x is a variable and to the macro __byte_swap_int_const(x) if x is a constant. Otherwise, it always expands to the macro __byte_swap_int_const(x). - __byte_swap_int_var(x) expands to a Gnu C statement-expression with inline asm - __byte_swap_int_const(x) expands to a C expression with shifts and masks. It is expected that this expression is evaluated at compile time iff it is used. Some of this layering is bogus, but fixing it will gives slightly more complicated layering to reduce duplication: - __byte_swap_int_const(x) is MI so it should be defined in a MI file and not duplicated ad nauseum like it is now. Especially since it is only to support a tiny optimization. - __byte_swap_int_const(x) works for the non-constant case too, so its name is bogus. Some arches use it for the non-constant case, and for swapping uint64_t's on i386 there is nothing better than a similar expression. This expression should work on i386, but none of the versions versions of gcc used in FreeBSD optimize it well (to bswap). Someday when they do, ntohl() can be simply this version in all cases. - the ifdef's involving __OPTIMIZE__ can probably be improved. However, just having them gets in the way of letting gcc do the optimization. You don't want even more convoluted __OPTIMIZE__ ifdefs to "fix" thus. > Name changes are a good thing for clarity but if no > one will use your changed name and roll their own.. thats a bad thing. The hand rolled version is as unlikely to be as sophisticated as ntohl() :-). The be/le family is intentionally unsophisticated sinc its speed is believed to be unimportant. Probably the speed of the ntohl() family is similarly unimportant. > By having such a define you might encourage folks (over time) to transition > off to the more clear naming versions.. Nah, that will encourage them to keep using the macro that hides the newer versions. >> Yes, long long should not exist, and there are few places where exact >> sizes should be used, but networking code is one place where they >> should be used. >> >> ntohs() will break semantically or actually on machines with shorts with >> more than 16 bits. > > So two questions here: > > a) What machines that we do support currently have a short larger than > 16bits? None. Even if there were, then this would be moot because ntohs() was fixed some time ago to not take a signed short arg. It takes an unsigned 16-bit arg. (Signed 16-bit shorts would also break on 1's complement and maybe on signed-magnitude machines: 0xFFFF in bits has value -0 on 1's. complement, so ntohs(0xFFFF) might become ntohs(-0) = ntohs(0) = 0). > b) Does anyone that use networking code really expect ntohs() to do anything > different than a 16 bit byte swap? No. It cannot, since it is required to work on 16-bit unsigned values. > The man page is pretty clear on > it i.e. uint16_t is the input and its a "network short" which > if I remember right is defined to be 16 bits... At least most RFC's > are pretty clear and the same is true for UNP Vol 1 ;-) Since ntohs() is now (and maybe always has been) specified specifically enough. But this specification makes the function name bogus -- it never takes a short arg. A similar case that is still broken is fls(). POSIX only standardized historical malpractice for it, so it is still specified to take an int arg, without even any details of what happens when the value is negative. >> ntohl() is already broken semantically on machines with longs with >> more than 32 bits (all 64-bit arches in FreeBSD). It doesn't actually >> handle longs on such arches. Networking code handles a few cases related >> to this with n_long. This is not quite as bad, but its name is nonsense -- >> n_long is very far from being a long -- it is unsigned 32 bits exactly, >> unlike long which is signed >= 32 bits. > > again same two questions only change them to say 32 bits? Like ntohs(), it is specified correcly but doesn't match its name. Renaming it to ntoh32() would break historical practice. >> ntohll() would break similarly on machines with long longs with more >> or less than 64 bits. In practice this and other misuses of long long >> may prevent the size of long long being changed, like it prevented the >> size of long being changed on some systems with historical abuses of >> long. > > Again same first question... the second one I would ask too except the > function > does NOT exist (except where folks go out and roll it themselves). No need to break it from the start. > Basically I don't agree with your assessment since these functions are > designed > to operate on network code which I think defines a short = 16, a long = 32 > (at least > all RFC's I have read do that anyway). shorts and longs are defined by the C standard and the C compiler. Network code cannot change this. > And it appears from feedback I have > received > that ntohll would be defined as a 64bit network quantity in most folks minds > since > that what a lot of folks have implemented... Wouldn't they expect it to have a long long type if it were named ntohll()? Another error (mentioned in a later reply) would be expecting to print a 64 bit network type using %lld. That is as unportable as expecting to print a 32-bit type using %ld. On of the main type errors in practice for 64-bit arches under FreeBSD was printing the result of ntohl() using %ld. When there is a standard for a 64-bit network type, it will necessarily specify the type to be uint64_t (or perhaps a typedefed alias of this, like in_addr_t for uint32_t). Printing of this type will have the usual problems for a typedefed type. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 17:51:00 2010 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 3FF24106566B for ; Fri, 25 Jun 2010 17:51:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id C8EE98FC19 for ; Fri, 25 Jun 2010 17:50:57 +0000 (UTC) Received: from c122-107-125-7.carlnfd1.nsw.optusnet.com.au (c122-107-125-7.carlnfd1.nsw.optusnet.com.au [122.107.125.7]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5PHop6D019953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jun 2010 03:50:52 +1000 Date: Sat, 26 Jun 2010 03:50:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: Message-ID: <20100626032941.U47182@delplex.bde.org> References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <4C226354.80601@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , Julian Elischer , net@FreeBSD.org Subject: Re: Observations from an old timer playing with 64 bit numbers... 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, 25 Jun 2010 17:51:00 -0000 On Wed, 23 Jun 2010, Randall Stewart wrote: > On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote: >> but I think it >> should be a local define to be64toh or ntoh64 >> I do prefer the ntoh64 version but beXXtoh or whatever it looks like others >> are using is ok to me too since 'net' is a pretty wide definition and not >> ALL protocols are big endian. A global define for ntoh64 would be reasonable. It wouldn't be OK if 'net' were so wide, but I think it basically requires big endian (there must be an endianness and there shouldn't be 2). > I will make this last comment.. directed at Luigi in response to: > >>> people's ignorance is not an excuse for not doing things right > > Then I would strongly suggest you go fix the manual page for ntohl/ntohs and > point people to the be64toh() functions... then people would NOT be ignorant. > > The problem is there is NO clue in the system... The man page is indeed not good. It is too general, and I noticed the following errors in its details: % BYTEORDER(3) FreeBSD Library Functions Manual BYTEORDER(3) It is far from being about general byte order macros (those are mainly the be/le ones in byteorder(9)... % % NAME % htonl, htons, ntohl, ntohs -- convert values between host and network % byte order ... it is only about these network functions. % DESCRIPTION % These routines convert 16 and 32 bit quantities between network byte % order and host byte order. On machines which have a byte order which is % the same as the network order, routines are defined as null macros. s/routines/these routines/ s/null/null filter/ [but needs more work:] Saying that the routines are defined as null macros gives too much detail, and the detail is wrong. The "routines" are actually defined as deeply nested macros in all cases (but are backed up by real routines, i.e., extern functions) for when the macros are #undefed). Then, on machines which have a byte order which is the same as the network order, the macros end up expanding to the non-quite null filter of (type)(arg), where `type' is the relevant type. But this is too much detail. % SEE ALSO % gethostbyname(3), getservent(3), byteorder(9) I find cross references like this worse than useless. The relevant functions should be mentioned in the description, with specific cross references there, and there should be no generic cross references in the SEE ALSO section. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 13:11:40 2010 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 686A4106566B for ; Sat, 26 Jun 2010 13:11:40 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.freebsd.org (Postfix) with ESMTP id D05798FC1B for ; Sat, 26 Jun 2010 13:11:39 +0000 (UTC) Received: from segfault.kiev.ua (localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.14.4/8.14.4/8.Who.Cares) with ESMTP id o5QD0ITw002154; Sat, 26 Jun 2010 16:00:18 +0300 (EEST) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.14.4/8.14.4/Submit) id o5QD0DWt002151; Sat, 26 Jun 2010 16:00:13 +0300 (EEST) (envelope-from netch) Date: Sat, 26 Jun 2010 16:00:13 +0300 From: Valentin Nechayev To: tuexen@freebsd.org, rrs@freebsd.org Message-ID: <20100626130013.GA1502@netch.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-42: On Cc: net@freebsd.org Subject: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 13:11:40 -0000 Hi, FreeBSD 7.3-RELEASE i386 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05955ca stack pointer = 0x28:0xe783bb94 frame pointer = 0x28:0xe783bc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7751 (spc) trap number = 12 panic: page fault Uptime: 20d6h25m18s Physical memory: 1910 MB Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc053a730 in boot (howto=260) at /usr/BSD/src/sys/kern/kern_shutdown.c:418 #2 0xc053a931 in panic (fmt=Variable "fmt" is not available. ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 #3 0xc0762e4c in trap_fatal (frame=0xe783bb54, eva=0) at /usr/BSD/src/sys/i386/i386/trap.c:950 #4 0xc07630b0 in trap_pfault (frame=0xe783bb54, usermode=0, eva=0) at /usr/BSD/src/sys/i386/i386/trap.c:863 #5 0xc0763a92 in trap (frame=0xe783bb54) at /usr/BSD/src/sys/i386/i386/trap.c:541 #6 0xc074f81b in calltrap () at /usr/BSD/src/sys/i386/i386/exception.s:166 #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 #8 0xc0763405 in syscall (frame=0xe783bd38) at /usr/BSD/src/sys/i386/i386/trap.c:1101 #9 0xc074f880 in Xint0x80_syscall () at /usr/BSD/src/sys/i386/i386/exception.s:262 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 7 #7 0xc05955ca in sctp_generic_sendmsg (td=0xcafb7d80, uap=0xe783bcfc) at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 2386 ktrsockaddr(to); (kgdb) p to $1 = (struct sockaddr *) 0x0 (kgdb) l 2381 error = getsock(td->td_proc->p_fd, uap->sd, &fp, NULL); 2382 if (error) 2383 goto sctp_bad; 2384 #ifdef KTRACE 2385 if (KTRPOINT(td, KTR_STRUCT)) 2386 ktrsockaddr(to); 2387 #endif 2388 2389 iov[0].iov_base = uap->msg; 2390 iov[0].iov_len = uap->mlen; As seen from code, if uap->tolen is zero, `to' isn't initialized and remains NULL. This error is identical to -CURRENT. Seems this zero originates from libc code for sctp_send(): === #ifdef SYS_sctp_generic_sendmsg struct sockaddr *to = NULL; return (syscall(SYS_sctp_generic_sendmsg, sd, data, len, to, 0, sinfo, flags)); #else === why after `to'? -netch- From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 15:10:07 2010 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 DE1B31065672; Sat, 26 Jun 2010 15:10:06 +0000 (UTC) (envelope-from tuexen@freebsd.org) 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 4923E8FC0C; Sat, 26 Jun 2010 15:10:06 +0000 (UTC) Received: from [192.168.1.190] (p508FC3F8.dip.t-dialin.net [80.143.195.248]) by mail-n.franken.de (Postfix) with ESMTP id 39B081C0C0BCC; Sat, 26 Jun 2010 17:10:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20100626130013.GA1502@netch.kiev.ua> Date: Sat, 26 Jun 2010 17:11:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B01BACA-B0A6-4D89-8BE4-437002D7CE8E@freebsd.org> References: <20100626130013.GA1502@netch.kiev.ua> To: netch@netch.kiev.ua X-Mailer: Apple Mail (2.1081) Cc: rrs@freebsd.org, net@freebsd.org Subject: Re: SCTP panic with sctp_send() 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, 26 Jun 2010 15:10:07 -0000 On Jun 26, 2010, at 3:00 PM, Valentin Nechayev wrote: > Hi, >=20 > FreeBSD 7.3-RELEASE i386 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x0 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc05955ca > stack pointer =3D 0x28:0xe783bb94 > frame pointer =3D 0x28:0xe783bc80 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 7751 (spc) > trap number =3D 12 > panic: page fault > Uptime: 20d6h25m18s > Physical memory: 1910 MB > Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 = 10 >=20 > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc053a730 in boot (howto=3D260) at = /usr/BSD/src/sys/kern/kern_shutdown.c:418 > #2 0xc053a931 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 > #3 0xc0762e4c in trap_fatal (frame=3D0xe783bb54, eva=3D0) > at /usr/BSD/src/sys/i386/i386/trap.c:950 > #4 0xc07630b0 in trap_pfault (frame=3D0xe783bb54, usermode=3D0, = eva=3D0) > at /usr/BSD/src/sys/i386/i386/trap.c:863 > #5 0xc0763a92 in trap (frame=3D0xe783bb54) > at /usr/BSD/src/sys/i386/i386/trap.c:541 > #6 0xc074f81b in calltrap () at = /usr/BSD/src/sys/i386/i386/exception.s:166 > #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > #8 0xc0763405 in syscall (frame=3D0xe783bd38) > at /usr/BSD/src/sys/i386/i386/trap.c:1101 > #9 0xc074f880 in Xint0x80_syscall () > at /usr/BSD/src/sys/i386/i386/exception.s:262 > #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > (kgdb) f 7 > #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > 2386 ktrsockaddr(to); > (kgdb) p to > $1 =3D (struct sockaddr *) 0x0 > (kgdb) l > 2381 error =3D getsock(td->td_proc->p_fd, uap->sd, &fp, = NULL); > 2382 if (error) > 2383 goto sctp_bad; > 2384 #ifdef KTRACE > 2385 if (KTRPOINT(td, KTR_STRUCT)) > 2386 ktrsockaddr(to); > 2387 #endif > 2388 > 2389 iov[0].iov_base =3D uap->msg; > 2390 iov[0].iov_len =3D uap->mlen; >=20 > As seen from code, if uap->tolen is zero, `to' isn't initialized and = remains > NULL. This error is identical to -CURRENT. How can the crash be reproduced? Can you provide a small test program? Best regards Michael >=20 > Seems this zero originates from libc code for sctp_send(): >=20 > =3D=3D=3D > #ifdef SYS_sctp_generic_sendmsg > struct sockaddr *to =3D NULL; >=20 > return (syscall(SYS_sctp_generic_sendmsg, sd, > data, len, to, 0, sinfo, flags)); > #else > =3D=3D=3D >=20 > why after `to'? >=20 >=20 > -netch- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 15:39:12 2010 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 6DFA8106566B; Sat, 26 Jun 2010 15:39:12 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.freebsd.org (Postfix) with ESMTP id EC83C8FC1B; Sat, 26 Jun 2010 15:39:11 +0000 (UTC) Received: from segfault.kiev.ua (localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.14.4/8.14.4/8.Who.Cares) with ESMTP id o5QFd5n3012120; Sat, 26 Jun 2010 18:39:05 +0300 (EEST) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.14.4/8.14.4/Submit) id o5QFcxjw012116; Sat, 26 Jun 2010 18:38:59 +0300 (EEST) (envelope-from netch) Date: Sat, 26 Jun 2010 18:38:59 +0300 From: Valentin Nechayev To: Michael Tuexen Message-ID: <20100626153859.GB1502@netch.kiev.ua> References: <20100626130013.GA1502@netch.kiev.ua> <9B01BACA-B0A6-4D89-8BE4-437002D7CE8E@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B01BACA-B0A6-4D89-8BE4-437002D7CE8E@freebsd.org> X-42: On Cc: rrs@freebsd.org, net@freebsd.org Subject: Re: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 15:39:12 -0000 Hi, Sat, Jun 26, 2010 at 17:11:13, tuexen wrote about "Re: SCTP panic with sctp_send()": > > As seen from code, if uap->tolen is zero, `to' isn't initialized and remains > > NULL. This error is identical to -CURRENT. > How can the crash be reproduced? Any code with sctp_send() under ktrace. > Can you provide a small test program? http://segfault.kiev.ua/~netch/20100626.2/ sps.c - server, spc.c - client run server in one terminal and client under ktrace in another one. > > why after `to'? shall be written as "why 0 after `to'?" -netch- From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 19:29:03 2010 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 3FEDD106564A; Sat, 26 Jun 2010 19:29:03 +0000 (UTC) (envelope-from tuexen@freebsd.org) 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 CD0B48FC21; Sat, 26 Jun 2010 19:29:02 +0000 (UTC) Received: from [192.168.1.190] (p508FC3F8.dip.t-dialin.net [80.143.195.248]) by mail-n.franken.de (Postfix) with ESMTP id B659D1C0C0BCC; Sat, 26 Jun 2010 21:29:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20100626130013.GA1502@netch.kiev.ua> Date: Sat, 26 Jun 2010 21:30:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> References: <20100626130013.GA1502@netch.kiev.ua> To: netch@netch.kiev.ua X-Mailer: Apple Mail (2.1081) Cc: rrs@freebsd.org, net@freebsd.org Subject: Re: SCTP panic with sctp_send() 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, 26 Jun 2010 19:29:03 -0000 On Jun 26, 2010, at 3:00 PM, Valentin Nechayev wrote: > Hi, >=20 > FreeBSD 7.3-RELEASE i386 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x0 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc05955ca > stack pointer =3D 0x28:0xe783bb94 > frame pointer =3D 0x28:0xe783bc80 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 7751 (spc) > trap number =3D 12 > panic: page fault > Uptime: 20d6h25m18s > Physical memory: 1910 MB > Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 = 10 >=20 > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc053a730 in boot (howto=3D260) at = /usr/BSD/src/sys/kern/kern_shutdown.c:418 > #2 0xc053a931 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/BSD/src/sys/kern/kern_shutdown.c:574 > #3 0xc0762e4c in trap_fatal (frame=3D0xe783bb54, eva=3D0) > at /usr/BSD/src/sys/i386/i386/trap.c:950 > #4 0xc07630b0 in trap_pfault (frame=3D0xe783bb54, usermode=3D0, = eva=3D0) > at /usr/BSD/src/sys/i386/i386/trap.c:863 > #5 0xc0763a92 in trap (frame=3D0xe783bb54) > at /usr/BSD/src/sys/i386/i386/trap.c:541 > #6 0xc074f81b in calltrap () at = /usr/BSD/src/sys/i386/i386/exception.s:166 > #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > #8 0xc0763405 in syscall (frame=3D0xe783bd38) > at /usr/BSD/src/sys/i386/i386/trap.c:1101 > #9 0xc074f880 in Xint0x80_syscall () > at /usr/BSD/src/sys/i386/i386/exception.s:262 > #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > (kgdb) f 7 > #7 0xc05955ca in sctp_generic_sendmsg (td=3D0xcafb7d80, = uap=3D0xe783bcfc) > at /usr/BSD/src/sys/kern/uipc_syscalls.c:2386 > 2386 ktrsockaddr(to); > (kgdb) p to > $1 =3D (struct sockaddr *) 0x0 > (kgdb) l > 2381 error =3D getsock(td->td_proc->p_fd, uap->sd, &fp, = NULL); > 2382 if (error) > 2383 goto sctp_bad; > 2384 #ifdef KTRACE > 2385 if (KTRPOINT(td, KTR_STRUCT)) > 2386 ktrsockaddr(to); > 2387 #endif > 2388 > 2389 iov[0].iov_base =3D uap->msg; > 2390 iov[0].iov_len =3D uap->mlen; >=20 > As seen from code, if uap->tolen is zero, `to' isn't initialized and = remains > NULL. This error is identical to -CURRENT. Thanks for reporting it. It is fixed in r209540 for current. Best regards Michael >=20 > Seems this zero originates from libc code for sctp_send(): >=20 > =3D=3D=3D > #ifdef SYS_sctp_generic_sendmsg > struct sockaddr *to =3D NULL; >=20 > return (syscall(SYS_sctp_generic_sendmsg, sd, > data, len, to, 0, sinfo, flags)); > #else > =3D=3D=3D >=20 > why after `to'? >=20 >=20 > -netch- >=20 From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 21:00:15 2010 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 A6500106566B for ; Sat, 26 Jun 2010 21:00:15 +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 4EC6C8FC15 for ; Sat, 26 Jun 2010 21:00:15 +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 o5QL0FHQ078886 for ; Sat, 26 Jun 2010 21:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5QL0F2v078885; Sat, 26 Jun 2010 21:00:15 GMT (envelope-from gnats) Date: Sat, 26 Jun 2010 21:00:15 GMT Message-Id: <201006262100.o5QL0F2v078885@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:00:15 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Rui Paulo To: Alex Kozlov Cc: bug-followup@FreeBSD.org, vince@unsane.co.uk Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Sat, 26 Jun 2010 21:52:11 +0100 On 22 Jun 2010, at 14:35, Alex Kozlov wrote: > On Mon, Jun 21, 2010 at 05:30:30PM +0100, Rui Paulo wrote: >> On 21 Jun 2010, at 15:38, Alex Kozlov wrote: >>> On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: >>>>> I confirm this. Atheros 9280, work fine with 8.0R usb stick, >>>>> timeout after few pings with 8.1-BETA1. >>>>> I can try to find a particular commit, that causes this >>>>> regression, if its help. >>>> Yes, please. >>> Sorry for the delay. I think that the culprit is r203959. >> Please try this patch. > Patch does not help, but if I change line in AR_SREV_MERLIN_20 from > AH_PRIVATE((_ah))->ah_macRev == AR_XSREV_REVISION_MERLIN_20 > to > AH_PRIVATE((_ah))->ah_macRev >= AR_XSREV_REVISION_MERLIN_20 > net works again. I think this is the correct version. Can you try? Index: ar5416/ar5416reg.h =================================================================== --- ar5416/ar5416reg.h (revision 209522) +++ ar5416/ar5416reg.h (working copy) @@ -611,8 +611,8 @@ (AR_SREV_MERLIN(_ah) && \ AH_PRIVATE((_ah))->ah_macRev == AR_XSREV_REVISION_MERLIN_20) #define AR_SREV_MERLIN_20_OR_LATER(_ah) \ - (AR_SREV_MERLIN_20(_ah) || \ - AH_PRIVATE((_ah))->ah_macVersion > AR_XSREV_VERSION_MERLIN) + (AR_SREV_MERLIN(_ah) || \ + AH_PRIVATE((_ah))->ah_macVersion >= AR_XSREV_VERSION_MERLIN_20) #define AR_SREV_KITE(_ah) \ (AH_PRIVATE((_ah))->ah_macVersion == AR_XSREV_VERSION_KITE) Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 21:00:17 2010 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 30133106567D for ; Sat, 26 Jun 2010 21:00:17 +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 E40D18FC16 for ; Sat, 26 Jun 2010 21:00:16 +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 o5QL0Gio078893 for ; Sat, 26 Jun 2010 21:00:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5QL0GNO078892; Sat, 26 Jun 2010 21:00:16 GMT (envelope-from gnats) Date: Sat, 26 Jun 2010 21:00:16 GMT Message-Id: <201006262100.o5QL0GNO078892@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:00:17 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Rui Paulo To: Rui Paulo Cc: Alex Kozlov , bug-followup@FreeBSD.org, vince@unsane.co.uk Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Sat, 26 Jun 2010 21:58:03 +0100 On 26 Jun 2010, at 21:52, Rui Paulo wrote: > > On 22 Jun 2010, at 14:35, Alex Kozlov wrote: > >> On Mon, Jun 21, 2010 at 05:30:30PM +0100, Rui Paulo wrote: >>> On 21 Jun 2010, at 15:38, Alex Kozlov wrote: >>>> On Mon, May 31, 2010 at 07:30:04PM +0000, Rui Paulo wrote: >>>>>> I confirm this. Atheros 9280, work fine with 8.0R usb stick, >>>>>> timeout after few pings with 8.1-BETA1. >>>>>> I can try to find a particular commit, that causes this >>>>>> regression, if its help. >>>>> Yes, please. >>>> Sorry for the delay. I think that the culprit is r203959. >>> Please try this patch. >> Patch does not help, but if I change line in AR_SREV_MERLIN_20 from >> AH_PRIVATE((_ah))->ah_macRev == AR_XSREV_REVISION_MERLIN_20 >> to >> AH_PRIVATE((_ah))->ah_macRev >= AR_XSREV_REVISION_MERLIN_20 >> net works again. > > I think this is the correct version. Can you try? > > Index: ar5416/ar5416reg.h > =================================================================== > --- ar5416/ar5416reg.h (revision 209522) > +++ ar5416/ar5416reg.h (working copy) > @@ -611,8 +611,8 @@ > (AR_SREV_MERLIN(_ah) && \ > AH_PRIVATE((_ah))->ah_macRev == AR_XSREV_REVISION_MERLIN_20) > #define AR_SREV_MERLIN_20_OR_LATER(_ah) \ > - (AR_SREV_MERLIN_20(_ah) || \ > - AH_PRIVATE((_ah))->ah_macVersion > AR_XSREV_VERSION_MERLIN) > + (AR_SREV_MERLIN(_ah) || \ > + AH_PRIVATE((_ah))->ah_macVersion >= AR_XSREV_VERSION_MERLIN_20) > > #define AR_SREV_KITE(_ah) \ > (AH_PRIVATE((_ah))->ah_macVersion == AR_XSREV_VERSION_KITE) Actually, forget this. You were right. I'll commit your fix. Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 21:34:26 2010 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 C5B4D106566C; Sat, 26 Jun 2010 21:34:26 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.freebsd.org (Postfix) with ESMTP id 377948FC15; Sat, 26 Jun 2010 21:34:25 +0000 (UTC) Received: from segfault.kiev.ua (localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.14.4/8.14.4/8.Who.Cares) with ESMTP id o5QLYIEp031629; Sun, 27 Jun 2010 00:34:18 +0300 (EEST) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.14.4/8.14.4/Submit) id o5QLYDkB031626; Sun, 27 Jun 2010 00:34:13 +0300 (EEST) (envelope-from netch) Date: Sun, 27 Jun 2010 00:34:13 +0300 From: Valentin Nechayev To: Michael Tuexen Message-ID: <20100626213413.GC1502@netch.kiev.ua> References: <20100626130013.GA1502@netch.kiev.ua> <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A9143A2-28A7-447A-AF65-A22CC49C6034@freebsd.org> X-42: On Cc: net@freebsd.org Subject: Re: SCTP panic with sctp_send() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:34:26 -0000 Hi, Sat, Jun 26, 2010 at 21:30:12, tuexen wrote about "Re: SCTP panic with sctp_send()": > > As seen from code, if uap->tolen is zero, `to' isn't initialized and remains > > NULL. This error is identical to -CURRENT. > Thanks for reporting it. It is fixed in r209540 for current. Thanks! (for second fix too) -netch-