From owner-freebsd-net@FreeBSD.ORG Sun Nov 24 18:50:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9878976C for ; Sun, 24 Nov 2013 18:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CC872F05 for ; Sun, 24 Nov 2013 18:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAOIo1Ho058480 for ; Sun, 24 Nov 2013 18:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAOIo1OE058464; Sun, 24 Nov 2013 18:50:01 GMT (envelope-from gnats) Date: Sun, 24 Nov 2013 18:50:01 GMT Message-Id: <201311241850.rAOIo1OE058464@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Sergey Kandaurov Subject: Re: kern/177366: [ieee80211] negative malloc(9) statistics for 80211node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Sergey Kandaurov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 18:50:01 -0000 The following reply was made to PR kern/177366; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, pluknet@gmail.com Cc: Subject: Re: kern/177366: [ieee80211] negative malloc(9) statistics for 80211node Date: Sun, 24 Nov 2013 22:45:23 +0400 Still true on HEAD (11-CURRENT). 80211node 18446744073709551603 18014398509481785K - 294 1024 18446744073709551603-2^64 -13 The point of counter leaking is still to be investigated. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Nov 25 11:06:53 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48C70598 for ; Mon, 25 Nov 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC4E2F4E for ; Mon, 25 Nov 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAPB6rxS089932 for ; Mon, 25 Nov 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAPB6qoM089930 for freebsd-net@FreeBSD.org; Mon, 25 Nov 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Nov 2013 11:06:52 GMT Message-Id: <201311251106.rAPB6qoM089930@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 11:06:53 -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/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 471 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 25 17:30:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CE1C8EF for ; Mon, 25 Nov 2013 17:30:53 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id C06512A83 for ; Mon, 25 Nov 2013 17:30:52 +0000 (UTC) Received: from [192.168.1.98] (unknown [194.190.78.9]) by mail.euro-comm.net (Postfix) with ESMTPSA id 687816BD5DF for ; Sun, 24 Nov 2013 01:06:04 +0400 (MSK) From: Victor Gamov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Netgraph ng_patch and ng_input: where to find packets? Date: Sun, 24 Nov 2013 01:05:58 +0400 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 17:30:53 -0000 Hi All I want to get 2 or 3 copies of input packet at my system to resend it to = new destinations. So I prepare following configuration: # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 in = via vlan999 # ngctl mkpeer ipfw: hub 100 hub-in # ngctl name ipfw:100 hub100 # ngctl mkpeer hub100: patch hub100-out1 in # ngctl name hub100:hub100-out1 patch100 # ngctl msg patch100: setconfig '{ count=3D1 csum_flags=3D1 ops=3D[ { = value=3D0xc0a8e680 offset=3D16 length=3D4 mode=3D1 } ] }' Now when I connect to patch:out as=20 # nghook -a patch100: out then I see packets with new IP: 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a Now I want to put this packets back into IP processing to send it to new = destination 192.168.230.128 (0xc0a8e680): # ngctl mkpeer patch100: ip_input out new100_to_dst_1 But packets not shown on outgoing interface: # ifconfig vlan333 vlan333: flags=3D8843 metric 0 = mtu 1500 options=3D103 ether 00:1b:21:5b:7e:e9 inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 # arp 192.168.230.128 ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 = seconds [vlan] Can somebody explain me where I was wrong? Thanks! -- CU, Victor Gamov From owner-freebsd-net@FreeBSD.ORG Mon Nov 25 23:57:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39056CE4 for ; Mon, 25 Nov 2013 23:57:46 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA3ED233D for ; Mon, 25 Nov 2013 23:57:45 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAPNvVkq024047 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 15:57:35 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5293E3E7.6090604@freebsd.org> Date: Tue, 26 Nov 2013 07:57:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Victor Gamov , freebsd-net@freebsd.org Subject: Re: Netgraph ng_patch and ng_input: where to find packets? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 23:57:46 -0000 On 11/24/13, 5:05 AM, Victor Gamov wrote: > Hi All > > I want to get 2 or 3 copies of input packet at my system to resend it to new destinations. So I prepare following configuration: > > # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 in via vlan999 > > # ngctl mkpeer ipfw: hub 100 hub-in > # ngctl name ipfw:100 hub100 > > # ngctl mkpeer hub100: patch hub100-out1 in > # ngctl name hub100:hub100-out1 patch100 > # ngctl msg patch100: setconfig '{ count=1 csum_flags=1 ops=[ { value=0xc0a8e680 offset=16 length=4 mode=1 } ] }' > > Now when I connect to patch:out as > # nghook -a patch100: out > > then I see packets with new IP: > > 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 > 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a > > Now I want to put this packets back into IP processing to send it to new destination 192.168.230.128 (0xc0a8e680): > > # ngctl mkpeer patch100: ip_input out new100_to_dst_1 > > But packets not shown on outgoing interface: > > # ifconfig vlan333 > vlan333: flags=8843 metric 0 mtu 1500 > options=103 > ether 00:1b:21:5b:7e:e9 > inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 > > # arp 192.168.230.128 > ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 seconds I would looking at giving the packet back to the firewall as suggested.. netgraph cookie Divert packet into netgraph with given cookie. The search termi- nates. If packet is later returned from netgraph it is either accepted or continues with the next rule, depending on net.inet.ip.fw.one_pass sysctl variable. see ng_ipfw for more details.. > > > Can somebody explain me where I was wrong? > > Thanks! > > -- > CU, > Victor Gamov > > > > > _______________________________________________ > 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 Nov 26 09:44:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4C1F65C for ; Tue, 26 Nov 2013 09:44:33 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id 63AA52F68 for ; Tue, 26 Nov 2013 09:44:33 +0000 (UTC) Received: from [192.168.0.4] (unknown [195.91.216.248]) by mail.euro-comm.net (Postfix) with ESMTPSA id 7D7686BD5E3 for ; Tue, 26 Nov 2013 13:44:25 +0400 (MSK) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Victor Gamov In-Reply-To: <5293E3E7.6090604@freebsd.org> Date: Tue, 26 Nov 2013 13:44:25 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5293E3E7.6090604@freebsd.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 09:44:33 -0000 On 26Nov, 2013, at 03:57, Julian Elischer wrote: > On 11/24/13, 5:05 AM, Victor Gamov wrote: >> Hi All >>=20 >> I want to get 2 or 3 copies of input packet at my system to resend it = to new destinations. So I prepare following configuration: >>=20 >> # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 = in via vlan999 >>=20 >> # ngctl mkpeer ipfw: hub 100 hub-in >> # ngctl name ipfw:100 hub100 >>=20 >> # ngctl mkpeer hub100: patch hub100-out1 in >> # ngctl name hub100:hub100-out1 patch100 >> # ngctl msg patch100: setconfig '{ count=3D1 csum_flags=3D1 ops=3D[ { = value=3D0xc0a8e680 offset=3D16 length=3D4 mode=3D1 } ] }' >>=20 >> Now when I connect to patch:out as >> # nghook -a patch100: out >>=20 >> then I see packets with new IP: >>=20 >> 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 >> 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a >>=20 >> Now I want to put this packets back into IP processing to send it to = new destination 192.168.230.128 (0xc0a8e680): >>=20 >> # ngctl mkpeer patch100: ip_input out new100_to_dst_1 >>=20 >> But packets not shown on outgoing interface: >>=20 >> # ifconfig vlan333 >> vlan333: flags=3D8843 metric = 0 mtu 1500 >> options=3D103 >> ether 00:1b:21:5b:7e:e9 >> inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 >>=20 >> # arp 192.168.230.128 >> ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 = seconds > I would looking at giving the packet back to the firewall as = suggested.. >=20 > netgraph cookie > Divert packet into netgraph with given cookie. The search = termi- > nates. If packet is later returned from netgraph it is = either > accepted or continues with the next rule, depending on > net.inet.ip.fw.one_pass sysctl variable. > see ng_ipfw for more details.. Yes I read this manuals :-) But I still can't see packets neither at = ipfw nor at outgoing interface. net.inet.ip.fw.one_pass: 0 net.inet.ip.forwarding: 1 Is my original idea is correct? -- CU, Victor Gamov From owner-freebsd-net@FreeBSD.ORG Tue Nov 26 21:21:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65FB22B5; Tue, 26 Nov 2013 21:21:49 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A2BC2EFE; Tue, 26 Nov 2013 21:21:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAQLLnnI063943; Tue, 26 Nov 2013 21:21:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAQLLnHF063942; Tue, 26 Nov 2013 21:21:49 GMT (envelope-from linimon) Date: Tue, 26 Nov 2013 21:21:49 GMT Message-Id: <201311262121.rAQLLnHF063942@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/184311: [bge] [panic] kernel panic with bge(4) on SunFire X2100 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 21:21:49 -0000 Old Synopsis: kernel panic with bge(4) on SunFire X2100 New Synopsis: [bge] [panic] kernel panic with bge(4) on SunFire X2100 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 26 21:21:23 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=184311 From owner-freebsd-net@FreeBSD.ORG Tue Nov 26 22:11:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 712C5FDB for ; Tue, 26 Nov 2013 22:11:04 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15C1B224C for ; Tue, 26 Nov 2013 22:11:04 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id rAQMB3Zt013020 for ; Tue, 26 Nov 2013 17:11:03 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <52951C5E.2090101@sentex.net> Date: Tue, 26 Nov 2013 17:10:38 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: IPCP: deflink: Oops, RCR in Initial. X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 22:11:04 -0000 Googling around this problem occasionally comes up, but I have yet to find a definitive answer. An ISP is changing out their LACs and when they are doing a hot cut, this sometimes messes up the pppoe ppp process so it gets stuck in a loop and never recovers. Killing off the ppp process and restarts it works and all is fixed. But this still on rare occasion will come up. Does anyone know the cause or work around ? I did manage to catch one and up the debug logs. None debug looks like Nov 26 15:30:01 s0332 ppp[1620]: tun1: IPCP: deflink: RecvConfigReq(10) state = Initial Nov 26 15:30:01 s0332 ppp[1620]: tun1: IPCP: IPADDR[6] xx.yy.128.14 Nov 26 15:30:01 s0332 ppp[1620]: tun1: IPCP: deflink: Oops, RCR in Initial. Nov 26 15:30:03 s0332 ppp[1620]: tun1: IPCP: deflink: RecvConfigReq(11) state = Initial Nov 26 15:30:03 s0332 ppp[1620]: tun1: IPCP: IPADDR[6] xx.yy.128.14 Nov 26 15:30:03 s0332 ppp[1620]: tun1: IPCP: deflink: Oops, RCR in Initial. Nov 26 15:30:04 s0332 ppp[1620]: tun1: LCP: deflink: RecvEchoRequest(174) state = Opened Nov 26 15:30:04 s0332 ppp[1620]: tun1: LCP: deflink: SendEchoReply(174) state = Opened Nov 26 15:30:05 s0332 ppp[1620]: tun1: IPCP: deflink: RecvConfigReq(12) state = Initial Config is simple pppoe: add 10.6.153.2 HISADDR add default HISADDR set device PPPoE:vr0 set server /var/run/spdsl-internet "" 0177 set speed sync enable echo disable ipv6cp disable vjcomp set cd 15 set dial set login set timeout 0 set lqrperiod 10 set authname s0332@realm set authkey xxxxxxxx set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 255.255.255.0 With debugging Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: Select returns 1 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Physical: read Nov 26 16:53:20 s0332 ppp[1620]: tun1: Physical: 80 21 01 97 00 0a 03 06 43 2b 80 0e .!......C+.. Nov 26 16:53:20 s0332 ppp[1620]: tun1: Debug: deflink: DescriptorRead: read 12/2048 from 1 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Sync: Read Nov 26 16:53:20 s0332 ppp[1620]: tun1: Sync: 80 21 01 97 00 0a 03 06 43 2b 80 0e .!......C+.. Nov 26 16:53:20 s0332 ppp[1620]: tun1: Debug: proto_LayerPull: unknown -> 0x8021 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Debug: link_PullPacket: Despatch proto 0x8021 Nov 26 16:53:20 s0332 ppp[1620]: tun1: IPCP: deflink: RecvConfigReq(151) state = Initial Nov 26 16:53:20 s0332 ppp[1620]: tun1: IPCP: IPADDR[6] xx.yy.128.14 Nov 26 16:53:20 s0332 ppp[1620]: tun1: IPCP: deflink: Oops, RCR in Initial. Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: tun: fdset(r) 6 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: deflink(ctrl): fdset(r) 0 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: deflink: fdset(r) 1 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: deflink: fdset(e) 1 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: server: fdset(r) 9 Nov 26 16:53:20 s0332 ppp[1620]: tun1: Timer: prompt /var/run/spdsl-internet: fdset(r) 2 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: Select returns -1 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: ---- Begin of Timer Service List--- Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: physical throughput timer[0x28411068]: freq = 1.00s, next = 0.00s, state = running Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: lqm timer[0x28413df4]: freq = 10.00s, next = 2.40s, state = running Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: hdlc timer[0x28413db0]: freq = 60.00s, next = 52.40s, state = running Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: ---- End of Timer Service List --- Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: timer_Start: Inserting physical throughput timer[0x28411068] before lqm timer[0x28413df4], delta = 10 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: tun: fdset(r) 6 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: deflink(ctrl): fdset(r) 0 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: deflink: fdset(r) 1 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: deflink: fdset(e) 1 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: server: fdset(r) 9 Nov 26 16:53:21 s0332 ppp[1620]: tun1: Timer: prompt /var/run/spdsl-internet: fdset(r) 2 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: Select returns -1 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: ---- Begin of Timer Service List--- Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: physical throughput timer[0x28411068]: freq = 1.00s, next = 0.00s, state = running Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: lqm timer[0x28413df4]: freq = 10.00s, next = 1.40s, state = running Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: hdlc timer[0x28413db0]: freq = 60.00s, next = 51.40s, state = running Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: ---- End of Timer Service List --- Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: timer_Start: Inserting physical throughput timer[0x28411068] before lqm timer[0x28413df4], delta = 10 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: tun: fdset(r) 6 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: deflink(ctrl): fdset(r) 0 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: deflink: fdset(r) 1 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: deflink: fdset(e) 1 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: server: fdset(r) 9 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: prompt /var/run/spdsl-internet: fdset(r) 2 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: Select returns 1 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Physical: read Nov 26 16:53:22 s0332 ppp[1620]: tun1: Physical: 80 21 01 98 00 0a 03 06 43 2b 80 0e .!......C+.. Nov 26 16:53:22 s0332 ppp[1620]: tun1: Debug: deflink: DescriptorRead: read 12/2048 from 1 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Sync: Read Nov 26 16:53:22 s0332 ppp[1620]: tun1: Sync: 80 21 01 98 00 0a 03 06 43 2b 80 0e .!......C+.. Nov 26 16:53:22 s0332 ppp[1620]: tun1: Debug: proto_LayerPull: unknown -> 0x8021 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Debug: link_PullPacket: Despatch proto 0x8021 Nov 26 16:53:22 s0332 ppp[1620]: tun1: IPCP: deflink: RecvConfigReq(152) state = Initial Nov 26 16:53:22 s0332 ppp[1620]: tun1: IPCP: IPADDR[6] xx.yy.128.14 Nov 26 16:53:22 s0332 ppp[1620]: tun1: IPCP: deflink: Oops, RCR in Initial. Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: tun: fdset(r) 6 Nov 26 16:53:22 s0332 ppp[1620]: tun1: Timer: deflink(ctrl): fdset(r) 0 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 26 23:41:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4E9B1EE for ; Tue, 26 Nov 2013 23:41:49 +0000 (UTC) Received: from marcos.anarc.at (marcos.orangeseeds.org [IPv6:2001:1928:1:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7FAC12750 for ; Tue, 26 Nov 2013 23:41:49 +0000 (UTC) Received: by marcos.anarc.at (Postfix, from userid 1000) id 753CB142D5E; Tue, 26 Nov 2013 18:41:43 -0500 (EST) From: Antoine =?utf-8?Q?Beaupr=C3=A9?= To: freebsd-net@freebsd.org Subject: OpenBGPd + TCP-MD5 sig fails after a few weeks User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Tue, 26 Nov 2013 18:41:40 -0500 Message-ID: <87zjoqu3wr.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: bzeeb-lists@lists.zabbadoz.net, anarcat@koumbit.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 23:41:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [please CC me I am not on the list. also cc'ing bzeeb since he was working on a patch for this two years ago] Hi, I have configured an OpenBGPd daemon to connect to another provider with a TCP-MD5 password. It used to work when I set it up 30 days ago, but somehow the session is down now. # bgpctl show Neighbor AS MsgRcvd MsgSent OutQ Up/Down State/Prf= Rcvd Cogent 174 0 0 0 Never Active I suspect this was working only because the remote server was initializing the connexion and not us.=20 What is ackward is that OpenBGPd doesn't seem to properly initialise the socket with an MD5 signature: 17:54:59.479900 IP (tos 0xc0, ttl 1, id 14983, offset 0, flags [DF], proto = TCP (6), length 60, bad cksum 0 (->c0d9)!) 38.104.152.102.16295 > 38.104.152.101.179: Flags [S], cksum 0x096d (cor= rect), seq 1556933933, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS = val 1324688 ecr 0], length 0 17:54:59.480593 IP (tos 0x0, ttl 255, id 30414, offset 0, flags [none],prot= o TCP (6), length 40) 38.104.152.101.179 > 38.104.152.102.16295: Flags [R.], cksum 0xa7df (co= rrect), seq 0, ack 1556933934, win 0, length 0 Usually, this should mention "md5valid" in the options field if it is enabled. This actually works with netcat: # nc -v -S 38.104.152.101 179 nc: connect to 38.104.152.101 port 179 (tcp) failed: Connection refused # tcpdump -M [...] -i bge0 -n -vvv port 179 tcpdump: listening on bge0, link-type EN10MB (Ethernet), capture size 65535 bytes 18:15:43.534592 IP (tos 0x0, ttl 64, id 27666, offset 0, flags [DF], proto = TCP (6), length 80, bad cksum 0 (->50fa)!) 38.104.152.102.26043 > 38.104.152.101.179: Flags [S], cksum 0xe73a (cor= rect), seq 3803575904, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS = val 2568742 ecr 0,nop,nop,md5valid], length 0 18:15:43.536592 IP (tos 0x0, ttl 255, id 30526, offset 0, flags [none], pro= to TCP (6), length 60) 38.104.152.101.179 > 38.104.152.102.26043: Flags [R.], cksum 0x1566 (co= rrect), seq 0, ack 3803575905, win 0, options [md5valid,eol], length 0 Notice, however, how the other side is still reseting our connexion, so there's something wrong there - but it could be that they simply blocked us because of too many failed attempts. The SAD association is set properly: # setkey -D 38.104.152.102 38.104.152.101 tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) A: tcp-md5 [...] seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature created: Nov 26 17:37:59 2013 current: Nov 26 17:57:40 2013 diff: 1181(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3D1 pid=3D31485 refcnt=3D1 38.104.152.101 38.104.152.102 tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) A: tcp-md5 [...] seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature created: Nov 26 17:37:59 2013 current: Nov 26 17:57:40 2013 diff: 1181(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3D0 pid=3D31485 refcnt=3D1 here's our ipsec.conf: add -n 38.104.152.101 38.104.152.102 tcp 0x1000 -A tcp-md5 "[...]"; add -n 38.104.152.102 38.104.152.101 tcp 0x1000 -A tcp-md5 "[...]"; I have tried both openbgpd-5.2.20121209 and openbgpd-5.2.20121014. I have also tried to disable TCP verification through sysctl, no luck: net.inet.tcp.signature_verify_input: 0 We have the following kernel configuration: include GENERIC ident KOUMBIT1 device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options IPSEC #IP security options TCP_SIGNATURE device crypto options DEVICE_POLLING device carp Our bgpd.conf doesn't specify a tcp password, otherwise we end up with the following error: root@rtr0:/usr/local/etc # bgpd -d startup rereading config no kernel support for PF_KEY route decision engine ready session engine ready RDE reconfigured listening on 0.0.0.0 listening on :: SE reconfigured neighbor 38.104.152.101 (Cogent): state change None -> Idle, reason: None neighbor 38.104.152.101 (Cogent): pfkey setup failed Why is it that outgoing TCP connexions do not respect setkey settings? I read a little bit of the source code, and it seems that openbgpd is stuck in a catch-22: it can't setup the SAD associations (because they are handled by setkey) so it doesn't set the MD5SIG option on the socket... One horrible solution I found was to change session_connect() as such: =2D if (peer->conf.auth.method !=3D AUTH_NONE && sysdep.no_pfkey) { + if (peer->conf.auth.method !=3D AUTH_NONE && sysdep.no_pfkey || 1) { log_peer_warnx(&peer->conf, =2D "ipsec or md5sig configured but not available"); =2D bgp_fsm(peer, EVNT_CON_OPENFAIL); =2D return (-1); + "ipsec or md5sig configured but not available, assuming= set externally"); + /* bgp_fsm(peer, EVNT_CON_OPENFAIL); */ + /* return (-1); */ + if (setsockopt(peer->fd, IPPROTO_TCP, TCP_MD5SIG, + &opt, sizeof(opt)) =3D=3D -1) { + log_peer_warn(&peer->conf, "setsockopt md5sig"); + bgp_fsm(peer, EVNT_CON_OPENFAIL); + return (-1); + } + } It's pretty nasty, but with this at least the connexion gets initialized going out with the right socket options. A. PS: this is a problem similar to what was reported here: http://lists.freebsd.org/pipermail/freebsd-net/2012-January/030921.html =2D-=20 Il faut tout un village pour =C3=A9lever un enfant. - Proverbe africain --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSlTG1AAoJEHkhUlJ7dZIeElcP/30dP2sbM5wDZk+dMsXAyMyj NrYlSc5VfYcgYL65LOK2AnS3fj21W7ov3V/LgOs4lKed7B3+hZaFTAL4jg6eq4l3 98y3W3Hv4cF7TVhUiqyJQ1G81fN2iD+GYQECDhmZE76hU0n+acoAn4pALlCq56Cn aWwhdOqJBklCjmWRgYxXy/vY0sdkF0Lgq7Qj3wlqh5OOfwNFwYX0hgcSFdOn35Bq EtiJFUlroUyMorNb7xiwCvuxS0wsQvF4RzTssxNB/921HMUMXWs0HiOuNEzdbbN7 g6BKn5fcbupWxPHC5KpWjqOQwz0b5lE6WoF3V/G58vpM9Bx4PAVVESHruZi75HCk lCDfCGE9tLLEkqiobA4/h1cN1039FG6e7dqmfq8lYixQ7sGB7eX/TyJH4x/MR7/N 698IKtjWDeh9SesiTCkysRIyriM7MHPz52B/giz8NiGsgLTcgJiW9/Iv2Icb6V7P acO8VuNbxs4VD2xqOJhrDZGNF2+R7MEIIW8WXskKwKmzdfmQ97XJPHyxR4LG7Xtr XKVWMwed8jIucMLycqK4oOuAwY4ibu8sXfA43Jbx+dkqv8trYhTUX7Y5Tte95fH8 YySV0mXndPsBhCAXlNMcQYIMhNABDP3reHosMQxZ82/b8vcVOF+9Mx/xxWKaUpnB SOWITR3dGp+ukcvBCUq+ =ZyGV -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 05:00:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 526FEC4B; Wed, 27 Nov 2013 05:00:16 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A76D326E9; Wed, 27 Nov 2013 05:00:15 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id uz6so6850904obc.37 for ; Tue, 26 Nov 2013 21:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wp8Ot4d3RPOEuzGIKE8Jz7/RDGhPDbWHY7y/6mBhm0=; b=rYdUJseyUwPHWqcQklRUoisRlU/voDrjkEVu56SE2PRXK78VJrYZJnNkvZiZBe5msk t/dLUItELVpt+dIhsjvwWuAiv1RrnF7x57H2g0TVkwJHjhGAIkHovwcqVxRzn6Zlmzzx nTVppQdatBEq0cIU1cpNvgv9YXGe9uIQiXz/LxwdV6MtBYe7lERQseDdfldx+2aRPzmz saZfxjWp5fyunamrXBxnfd/jkk6Bwv+Z9HiHdtMt5KxYvP9iKl3PWnBfPjXIV+aU9VWn KPRPzD2pjNEARv8GBunsYArF+m3CI8U59rvzEPK7m4AIu3jKYPobj07ne3ac3kXxVxiq 4eqQ== MIME-Version: 1.0 X-Received: by 10.60.145.241 with SMTP id sx17mr8276633oeb.57.1385528414314; Tue, 26 Nov 2013 21:00:14 -0800 (PST) Received: by 10.182.153.65 with HTTP; Tue, 26 Nov 2013 21:00:14 -0800 (PST) In-Reply-To: References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <528D6173.4080406@freebsd.org> Date: Tue, 26 Nov 2013 21:00:14 -0800 Message-ID: Subject: Re: svn commit: r258328 - head/sys/net From: Vijay Singh To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Adrian Chadd , "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , "George V. Neville-Neil" , "freebsd-arch@freebsd.org" , "svn-src-head@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 05:00:16 -0000 Sorry to join this late, I've been busy preparing other patches to roll out. I am OK either way. FWIW we're running with this @netapp for more than 2 years, but we do use only very few drivers. I would like to avoid the proliferation of APIs but Robert's point also does make sense. On Sat, Nov 23, 2013 at 2:57 AM, Robert Watson wrote: > On Wed, 20 Nov 2013, Julian Elischer wrote: > > After that it'd be nice to write a set of mbuf list macros for abstract >>> the whole queue, dequeue, concat, iterate, etc (like sys/queue.h, but for >>> mbufs.) >>> >>> What do people think? >>> >>> (I've been doing it for m->next chained things, but not m->m_nextpkt >>> things..) >>> >> >> I was thinking: new interfaces.. (your -multi names sound good). macros >> for handling said lists so that people don't screw them up Old drivers run >> with no change. >> > > To me, the name "multi" is ambiguous: could be multicast. If we call the > new datastructure "mbqueue" or "mqueue", then we should name the method > ether_input_mbqueue or ether_input_mqueue. > > Robert > > > > > > >> >>> >>> >>> -adrian >>> >>> >>> On 18 November 2013 14:58, George V. Neville-Neil >>> wrote: >>> >>>> Author: gnn >>>> Date: Mon Nov 18 22:58:14 2013 >>>> New Revision: 258328 >>>> URL: http://svnweb.freebsd.org/changeset/base/258328 >>>> >>>> Log: >>>> Allow ethernet drivers to pass in packets connected via the nextpkt >>>> pointer. >>>> Handling packets in this way allows drivers to amortize work during >>>> packet reception. >>>> >>>> Submitted by: Vijay Singh >>>> Sponsored by: NetApp >>>> >>>> Modified: >>>> head/sys/net/if_ethersubr.c >>>> >>>> Modified: head/sys/net/if_ethersubr.c >>>> ============================================================ >>>> ================== >>>> --- head/sys/net/if_ethersubr.c Mon Nov 18 22:55:50 2013 >>>> (r258327) >>>> +++ head/sys/net/if_ethersubr.c Mon Nov 18 22:58:14 2013 >>>> (r258328) >>>> @@ -708,13 +708,25 @@ static void >>>> ether_input(struct ifnet *ifp, struct mbuf *m) >>>> { >>>> >>>> + struct mbuf *mn; >>>> + >>>> /* >>>> - * We will rely on rcvif being set properly in the deferred >>>> context, >>>> - * so assert it is correct here. >>>> + * The drivers are allowed to pass in a chain of packets linked >>>> with >>>> + * m_nextpkt. We split them up into separate packets here and >>>> pass >>>> + * them up. This allows the drivers to amortize the receive >>>> lock. >>>> */ >>>> - KASSERT(m->m_pkthdr.rcvif == ifp, ("%s: ifnet mismatch", >>>> __func__)); >>>> + while (m) { >>>> + mn = m->m_nextpkt; >>>> + m->m_nextpkt = NULL; >>>> >>>> - netisr_dispatch(NETISR_ETHER, m); >>>> + /* >>>> + * We will rely on rcvif being set properly in the >>>> deferred context, >>>> + * so assert it is correct here. >>>> + */ >>>> + KASSERT(m->m_pkthdr.rcvif == ifp, ("%s: ifnet >>>> mismatch", __func__)); >>>> + netisr_dispatch(NETISR_ETHER, m); >>>> + m = mn; >>>> + } >>>> } >>>> >>>> /* >>>> >>> >> >> _______________________________________________ > svn-src-head@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 09:21:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E571179A; Wed, 27 Nov 2013 09:21:04 +0000 (UTC) Received: from smtp2-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599:215:17ff:fe31:fb8]) by mx1.freebsd.org (Postfix) with ESMTP id AAA1422E0; Wed, 27 Nov 2013 09:21:02 +0000 (UTC) Received: from oldfaithful.bebik.local (unknown [82.227.164.69]) by smtp2-g21.free.fr (Postfix) with ESMTP id 252CC4B016D; Wed, 27 Nov 2013 10:20:55 +0100 (CET) Received: by oldfaithful.bebik.local (Postfix, from userid 1001) id 113EC892B98; Wed, 27 Nov 2013 10:13:14 +0100 (CET) Date: Wed, 27 Nov 2013 10:13:14 +0100 From: Rodrigo Osorio To: freebsd-ports@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: install tcpdump 4.5.1 and libpcap 1.5.1 to filter in/out trafic Message-ID: <20131127091313.GB54435@oldfaithful.bebik.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 09:21:05 -0000 Hi all, In order to take advantage of the new '-P' switch in tcpdump to filter in/out trafic from an interface, I need to move from tcpdump 4.4.0 to 4.5.1. http://www.tcpdump.org/tcpdump_man.html I did a set of minimal patches to upgrade tcpdump and its companion libpcap in ports to the latest versions. In our tests (FreeBSD-i386-9.1-RELEASE and i386-10.0-BETA1) tcpdump 4.5.1 works fine and capture the desired trafic. I didn't perform any test to check if the deinstall/package works, this will come with a future PR. regards -rodrigo http://files.bebik.net/patches/tcpdump-4.5.1/tcpdump-patch http://files.bebik.net/patches/tcpdump-4.5.1/pcap-patch From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 10:10:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C7549B6 for ; Wed, 27 Nov 2013 10:10:09 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41908259C for ; Wed, 27 Nov 2013 10:10:09 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id e14so11235990iej.40 for ; Wed, 27 Nov 2013 02:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Uq9XS18GSAKYtCl29HrlOqzn0+W0btco26j6s5VxCEo=; b=GnGUQjNdNVlQBTbIWijAWxJqRUlucC3vAe0M6n6QJWUl98EXV86iaCNaNISCiztNcG Dl0HaGGHTg5de/BlQfPKilNI91Ke4naDUgcsv5/VtAUqX9Ku+b2WSI6hUVG/rkUKq5d5 dlinVUCu6Vl0vphMd7y8TuokAryNw9dL9cfxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Uq9XS18GSAKYtCl29HrlOqzn0+W0btco26j6s5VxCEo=; b=aUYeI+WXbGbKpal+HgZid7YijhqkwJnbje9OWZZQmGenjsyVJM9taaU7AnkHY7v+kr EvhvWJEArk3/mhTQQC6Ai7eI1HNWVGJ0M6M+hinnXDQldHoFY+K849SjWDt8a7Tn/zL0 OqY2+sQcRyu/Maf/24EtwqJSV24D9BxP8LuKS/cfMYXcl2e+FBmcbr4In2dVeoIJN+SQ 1/eGlgEPl6Sp/Xbsyr5EKc310cQrGMJyZONcmxCpQamY6fIleHVK5na/cVdhQQLTan3b cwVYiiOnj2uaesGWFgz185uiMzKlmr/21Yok21sUqoEKEgciXOpJHjiUS1yBQpNWj6bn 8L9w== X-Gm-Message-State: ALoCoQm2JzuIhLVicbwchEjVCab9D+Nd+mv0GxdhP1UBPuBeEx2oNXIgzJ1TfpHTskbPJCkyoH2Z X-Received: by 10.43.106.198 with SMTP id dv6mr4926579icc.51.1385547008481; Wed, 27 Nov 2013 02:10:08 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id k6sm37981010igx.8.2013.11.27.02.10.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 02:10:06 -0800 (PST) References: <20131127091313.GB54435@oldfaithful.bebik.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20131127091313.GB54435@oldfaithful.bebik.local> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1C22D1ED-1F81-46F6-92ED-BB76A7B7F781@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: install tcpdump 4.5.1 and libpcap 1.5.1 to filter in/out trafic Date: Wed, 27 Nov 2013 05:10:01 -0500 To: Rodrigo Osorio Cc: "freebsd-net@freebsd.org" , "freebsd-ports@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 10:10:09 -0000 --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Never thought if catch myself saying this butt . . . Push it in please! > On Nov 27, 2013, at 4:13, Rodrigo Osorio wrote: > > Hi all, > > In order to take advantage of the new '-P' switch in > tcpdump to filter in/out trafic from an interface, I > need to move from tcpdump 4.4.0 to 4.5.1. > > http://www.tcpdump.org/tcpdump_man.html > > I did a set of minimal patches to upgrade tcpdump and > its companion libpcap in ports to the latest versions. > > In our tests (FreeBSD-i386-9.1-RELEASE and i386-10.0-BETA1) > tcpdump 4.5.1 works fine and capture the desired trafic. > > I didn't perform any test to check if the deinstall/package > works, this will come with a future PR. > > regards > -rodrigo > > > http://files.bebik.net/patches/tcpdump-4.5.1/tcpdump-patch > http://files.bebik.net/patches/tcpdump-4.5.1/pcap-patch > > _______________________________________________ > 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" --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEyNzEwMTAwNFowIwYJKoZIhvcN AQkEMRYEFHDtT6RLRbpgr9MZfsXMIB1TKrk9MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAM4A0Yoz3zkzh0CnIp81G j+wpXvGu254e0Wdnpbv7VX/4YYmQ4ycbZr/MCr1Wy1B1Fu74WMe2p5+8vgpIar6IEx/0oVITuOfr TOHjKbdZ1+T0QB6Wl1kHCCx6v8kF9GXuj0PvBBiresmdNizEWnkUsgEH3WdZM08Vkz5i79dMWDVz hBkUWLHa5lWkHdAiERAHimKMtX/ls/YZvqFS6no3CcH3fkS+J2y1i8S7b6XwchwCCd3YBPJ8l7G6 rp+oeYQgnoujjIfWzys4t5JqIp+DiRjypFE3c5Y3CH4V85p7CdXiAL9Brvfn9ntNWr/qlTtObhnG YFgrMP2scDQZgK2UHAAAAAAAAA== --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 10:58:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FB8B7CE for ; Wed, 27 Nov 2013 10:58:13 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09470281A for ; Wed, 27 Nov 2013 10:58:13 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so9711463pdj.15 for ; Wed, 27 Nov 2013 02:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mKBTiK5+aSUldwQtgMkekKqyz+ohAThM1nhErNV1j2Y=; b=okXLZd10t2m3c/KmJm7yQ/89XqIVIqGaMuBAhOqq3AuUBa5ISlPwykRgLyyZSUBx1e wSfzXddusOzHUJJhE007tLnxgcQzwLUJMina6kmAX00Yj8g6lLMK/GM9UxxjPiwH6SIh 7Ad502eur/WQWm/WBqoAPO2I8S1a+uGX8ner2Ki2ilGIJHwmjhY7LlGs8gB49FtjMZFe bhXhkRHxrcLBXgDLQjydpKP2sc1eHgZLrQDwIQ6a4Rthoh8jM28iX+GNYaPRfcXrp/xw 8dbxTRlfiuI81Z9UEZ+tZT8B0TgNuJKf4Ou/98NvcpnLJceIAsKzoxuBp2zOz7oUze8w F5dw== MIME-Version: 1.0 X-Received: by 10.67.30.70 with SMTP id kc6mr40220461pad.32.1385549892602; Wed, 27 Nov 2013 02:58:12 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Wed, 27 Nov 2013 02:58:12 -0800 (PST) In-Reply-To: <87zjoqu3wr.fsf@marcos.anarc.at> References: <87zjoqu3wr.fsf@marcos.anarc.at> Date: Wed, 27 Nov 2013 11:58:12 +0100 X-Google-Sender-Auth: WL56F0B83arVrLyxu3VmwDmOSRw Message-ID: Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: =?ISO-8859-1?Q?Antoine_Beaupr=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 10:58:13 -0000 On Wed, Nov 27, 2013 at 12:41 AM, Antoine Beaupr=E9 wr= ote: > [please CC me I am not on the list. also cc'ing bzeeb since he was > working on a patch for this two years ago] > > Hi, > > I have configured an OpenBGPd daemon to connect to another provider with = a > TCP-MD5 password. > > It used to work when I set it up 30 days ago, but somehow the session is > down now. > > # bgpctl show > Neighbor AS MsgRcvd MsgSent OutQ Up/Down > State/PrfRcvd > Cogent 174 0 0 0 Never Active > > I suspect this was working only because the remote server was > initializing the connexion and not us. > > What is ackward is that OpenBGPd doesn't seem to properly initialise the > socket with an MD5 signature: > > 17:54:59.479900 IP (tos 0xc0, ttl 1, id 14983, offset 0, flags [DF], prot= o > TCP (6), length 60, bad cksum 0 (->c0d9)!) > 38.104.152.102.16295 > 38.104.152.101.179: Flags [S], cksum 0x096d > (correct), seq 1556933933, win 65535, options [mss 1460,nop,wscale > 6,sackOK,TS val 1324688 ecr 0], length 0 > 17:54:59.480593 IP (tos 0x0, ttl 255, id 30414, offset 0, flags > [none],proto TCP (6), length 40) > 38.104.152.101.179 > 38.104.152.102.16295: Flags [R.], cksum 0xa7df > (correct), seq 0, ack 1556933934, win 0, length 0 > > Usually, this should mention "md5valid" in the options field if it is > enabled. > > This actually works with netcat: > > # nc -v -S 38.104.152.101 179 > nc: connect to 38.104.152.101 port 179 (tcp) failed: Connection refused > > # tcpdump -M [...] -i bge0 -n -vvv port 179 > tcpdump: listening on bge0, link-type EN10MB (Ethernet), capture size > 65535 bytes > 18:15:43.534592 IP (tos 0x0, ttl 64, id 27666, offset 0, flags [DF], prot= o > TCP (6), length 80, bad cksum 0 (->50fa)!) > 38.104.152.102.26043 > 38.104.152.101.179: Flags [S], cksum 0xe73a > (correct), seq 3803575904, win 65535, options [mss 1460,nop,wscale > 6,sackOK,TS val 2568742 ecr 0,nop,nop,md5valid], length 0 > 18:15:43.536592 IP (tos 0x0, ttl 255, id 30526, offset 0, flags [none], > proto TCP (6), length 60) > 38.104.152.101.179 > 38.104.152.102.26043: Flags [R.], cksum 0x1566 > (correct), seq 0, ack 3803575905, win 0, options [md5valid,eol], length 0 > > Notice, however, how the other side is still reseting our connexion, so > there's something wrong there - but it could be that they simply blocked > us because of too many failed attempts. > > The SAD association is set properly: > > # setkey -D > 38.104.152.102 38.104.152.101 > tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) > A: tcp-md5 [...] > seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature > created: Nov 26 17:37:59 2013 current: Nov 26 17:57:40 2013 > diff: 1181(s) hard: 0(s) soft: 0(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=3D1 pid=3D31485 refcnt=3D1 > 38.104.152.101 38.104.152.102 > tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) > A: tcp-md5 [...] > seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature > created: Nov 26 17:37:59 2013 current: Nov 26 17:57:40 2013 > diff: 1181(s) hard: 0(s) soft: 0(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=3D0 pid=3D31485 refcnt=3D1 > > here's our ipsec.conf: > > add -n 38.104.152.101 38.104.152.102 tcp 0x1000 -A tcp-md5 "[...]"; > add -n 38.104.152.102 38.104.152.101 tcp 0x1000 -A tcp-md5 "[...]"; > > I have tried both openbgpd-5.2.20121209 and openbgpd-5.2.20121014. I > have also tried to disable TCP verification through sysctl, no luck: > > net.inet.tcp.signature_verify_input: 0 > > We have the following kernel configuration: > > include GENERIC > ident KOUMBIT1 > device pf > device pflog > device pfsync > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_CDNR > options ALTQ_PRIQ > options IPSEC #IP security > options TCP_SIGNATURE > device crypto > options DEVICE_POLLING > device carp > > Our bgpd.conf doesn't specify a tcp password, otherwise we end up with > the following error: > > root@rtr0:/usr/local/etc # bgpd -d > startup > rereading config > no kernel support for PF_KEY > route decision engine ready > session engine ready > RDE reconfigured > listening on 0.0.0.0 > listening on :: > SE reconfigured > neighbor 38.104.152.101 (Cogent): state change None -> Idle, reason: None > neighbor 38.104.152.101 (Cogent): pfkey setup failed > > Why is it that outgoing TCP connexions do not respect setkey settings? > > I read a little bit of the source code, and it seems that openbgpd is > stuck in a catch-22: it can't setup the SAD associations (because they > are handled by setkey) so it doesn't set the MD5SIG option on the > socket... One horrible solution I found was to change session_connect() > as such: > > - if (peer->conf.auth.method !=3D AUTH_NONE && sysdep.no_pfkey) { > + if (peer->conf.auth.method !=3D AUTH_NONE && sysdep.no_pfkey || 1= ) { > log_peer_warnx(&peer->conf, > - "ipsec or md5sig configured but not available"); > - bgp_fsm(peer, EVNT_CON_OPENFAIL); > - return (-1); > + "ipsec or md5sig configured but not available, > assuming set externally"); > + /* bgp_fsm(peer, EVNT_CON_OPENFAIL); */ > + /* return (-1); */ > + if (setsockopt(peer->fd, IPPROTO_TCP, TCP_MD5SIG, > + &opt, sizeof(opt)) =3D=3D -1) { > + log_peer_warn(&peer->conf, "setsockopt md5sig"); > + bgp_fsm(peer, EVNT_CON_OPENFAIL); > + return (-1); > + } > + > } > > It's pretty nasty, but with this at least the connexion gets initialized > going out with the right socket options. > > You can use the port here https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgpd It has integration with pfkey sockets of FreeBSD in the daemon itself and you have to specify only th espd policy through setkey. It works for pfSense. > A. > > PS: this is a problem similar to what was reported here: > > http://lists.freebsd.org/pipermail/freebsd-net/2012-January/030921.html > > -- > Il faut tout un village pour =E9lever un enfant. > - Proverbe africain > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 14:52:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF84493A; Wed, 27 Nov 2013 14:52:32 +0000 (UTC) Received: from marcos.anarc.at (marcos.orangeseeds.org [IPv6:2001:1928:1:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2D524CD; Wed, 27 Nov 2013 14:52:32 +0000 (UTC) Received: by marcos.anarc.at (Postfix, from userid 1000) id 7D6E6142D5E; Wed, 27 Nov 2013 09:52:22 -0500 (EST) From: Antoine =?utf-8?Q?Beaupr=C3=A9?= To: Ermal =?utf-8?Q?Lu=C3=A7i?= Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks In-Reply-To: References: <87zjoqu3wr.fsf@marcos.anarc.at> User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Wed, 27 Nov 2013 09:52:20 -0500 Message-ID: <87ob55ucbf.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: freebsd-net , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 14:52:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2013-11-27 05:58:12, Ermal Lu=C3=A7i wrote: > You can use the port here > https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgpd > It has integration with pfkey sockets of FreeBSD in the daemon itself and > you have to specify only th espd policy through setkey. > > It works for pfSense. Any reason why the port wasn't updated in FreeBSD? A. =2D-=20 Le pouvoir n'est pas =C3=A0 conqu=C3=A9rir, il est =C3=A0 d=C3=A9truire - Jean-Fran=C3=A7ois Brient, de la servitude moderne --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSlgckAAoJEHkhUlJ7dZIezp4P/3W0VdJLyHqzzLGfdettRpLt qdXsWzc0gvF0ltPNeArG/HkoC1m6EBGPVrz3vpD/UqAp/Hst7h7ip362r2cBHsLa 6YGBIu+jLttKq424oNlwjv1D1m+2wxuejWyqYq2yNDs/yTaZdwpEovMMz0Gid6tj FsnT+LmRBFYf029OdHcpn3vWN2u47PJP5RTwtsh5HVoeMPx0uH0vMpwDZ8Wtb0wz uc7oq4H7j1CHFEhggyffwGyw9qfcKbCpJP7TsNiHARfGzAyFaUR5jFc8j74RlQ3x VxAK2ddgv1Td4lxw8gtyV7l2EEc72feqBAlXNeZKPm+DIVqR8wTzax19oHcdmpfN HuBh5EJSSgrehtaWWrhvJaQ4XVDQ+6cmcjkc2DMnX6gMXq3ISYZsjw5+51TkMVh4 fIziJbB+Nn29v8xzh/Ld/MBxYqa98pmdS90XyZzW9PK3af5RtzNws79xGTnr1LUy JqI7kH2OmLx5rlmYFjnYEevTMMz4jzA/SfZA451WjtC1QQ7gijDhMcI733P80p4n 62dVaMGg9JWm7/kJOAcrWUFK3FWG5t+dzEQp+tTE6Ljz3ebjnHwYncgGUxFBXs37 xVojXgmS4iRqmHIBN1VUIw8ylPh96IY5qD3Bp990ojxNyAIzrEq9SK0CZdKLgQAo I++4jZnkZYf+j9/+aMDT =483J -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 17:59:12 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8651FC34; Wed, 27 Nov 2013 17:59:12 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 524F42E39; Wed, 27 Nov 2013 17:59:11 +0000 (UTC) Received: from [192.168.0.48] ([192.168.0.48]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id rARHx9kq039367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Nov 2013 10:59:10 -0700 (MST) (envelope-from gibbs@scsiguy.com) From: "Justin T. Gibbs" Content-Type: multipart/mixed; boundary="Apple-Mail=_BF798988-D40B-4431-80BE-5CDB6B3ADE57" Subject: Defaults for if_capenable and detecting user initiated changes Date: Wed, 27 Nov 2013 10:59:08 -0700 Message-Id: <0E13D481-9D6D-4B52-A5AD-B671BF3A85AF@scsiguy.com> To: net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Wed, 27 Nov 2013 10:59:10 -0700 (MST) Cc: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 17:59:12 -0000 --Apple-Mail=_BF798988-D40B-4431-80BE-5CDB6B3ADE57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi net, I=92m reviewing a patch from Roger Pau Monn=E9 for the Xen netfront = driver. The goal of the change is to avoid disturbing the user=92s = settings for the interface just because the backend device has changed = or the connection to the backend was reset. I=92ve attached the latest = version of the patch. The current patch leaves the interface settings alone if they can be = supported by the newly attached backend. What would be ideal is to = enable capabilities that default to being enabled if they were not = explicitly disabled by the user and can be supported by the new backend. = Unfortunately, I don=92t think the if_capenable and if_capabilities = fields are descriptive enough to deal with an interface whose = capabilities can change at runtime. Just as can be done with link = speed, some of these settings need to allow an =93auto/default=94 = setting in addition to on or off. This would allow the user to = explicitly disable a capability if needed, but generally allow the = system to chose the most optimal settings when they are supported. = Would this be difficult to add? Thanks, Justin --Apple-Mail=_BF798988-D40B-4431-80BE-5CDB6B3ADE57 Content-Disposition: attachment; filename=0001-xen-netfront-keep-xn-options-on-suspend-resume.patch Content-Type: application/octet-stream; name="0001-xen-netfront-keep-xn-options-on-suspend-resume.patch" Content-Transfer-Encoding: quoted-printable =46rom=20a660c9e9a3903d72c351e0fb7a890132efff6b7d=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Roger=20Pau=20Monne=20=0A= Date:=20Mon,=2021=20Oct=202013=2016:00:15=20+0100=0ASubject:=20[PATCH]=20= xen-netfront:=20keep=20xn=20options=20on=20suspend/resume=0A=0ASpecific=20= xn=20features=20should=20be=20preserved=20across=20migrations=20when=0A= possible=20(if=20the=20destination=20host=20also=20supports=20them).=20= Previously=20if=0Athe=20user=20disabled=20a=20feature,=20it=20would=20be=20= automatically=20re-enabled=0Aafter=20resume=20if=20the=20destination=20= host=20supports=20it.=0A---=0A=20sys/dev/xen/netfront/netfront.c=20|=20=20= =2032=20++++++++++++++++++++++++++------=0A=201=20files=20changed,=2026=20= insertions(+),=206=20deletions(-)=0A=0Adiff=20--git=20= a/sys/dev/xen/netfront/netfront.c=20b/sys/dev/xen/netfront/netfront.c=0A= index=20c0ad393..f5bce33=20100644=0A---=20= a/sys/dev/xen/netfront/netfront.c=0A+++=20= b/sys/dev/xen/netfront/netfront.c=0A@@=20-287,6=20+287,8=20@@=20struct=20= netfront_info=20{=0A=20=09multicall_entry_t=09= rx_mcl[NET_RX_RING_SIZE+1];=0A=20=09mmu_update_t=09=09= rx_mmu[NET_RX_RING_SIZE];=0A=20=09struct=20ifmedia=09=09sc_media;=0A+=0A= +=09bool=09=09=09xn_cold;=0A=20};=0A=20=0A=20#define=20rx_mbufs=20= xn_cdata.xn_rx_chain=0A@@=20-1963,6=20+1965,7=20@@=20= network_connect(struct=20netfront_info=20*np)=0A=20=09xn_txeof(np);=0A=20= =09XN_TX_UNLOCK(np);=0A=20=09network_alloc_rx_buffers(np);=0A+=09= np->xn_cold=20=3D=20false;=0A=20=0A=20=09return=20(0);=0A=20}=0A@@=20= -2003,13=20+2006,28=20@@=20xn_configure_features(struct=20netfront_info=20= *np)=0A=20=09int=20err;=0A=20=0A=20=09err=20=3D=200;=0A-#if=20= __FreeBSD_version=20>=3D=2070000=20&&=20(defined(INET)=20||=20= defined(INET6))=0A-=09if=20((np->xn_ifp->if_capenable=20&=20IFCAP_LRO)=20= !=3D=200)=0A-=09=09tcp_lro_free(&np->xn_lro);=0A+=0A+=09if=20= (np->xn_cold=20||=0A+=09=20=20=20=20((np->xn_ifp->if_capenable=20&=20= np->xn_ifp->if_capabilities)=0A+=09=20=20=20=20!=3D=20= np->xn_ifp->if_capenable))=20{=0A+=09=09/*=0A+=09=09=20*=20Check=20if=20= current=20enabled=20capabilities=20are=20available,=0A+=09=09=20*=20if=20= not=20switch=20to=20default=20capabilities.=0A+=09=09=20*/=0A+#if=20= __FreeBSD_version=20>=3D=20700000=20&&=20(defined(INET)=20||=20= defined(INET6))=0A+=09=09if=20((np->xn_ifp->if_capenable=20&=20= IFCAP_LRO)=20!=3D=200)=0A+=09=09=09tcp_lro_free(&np->xn_lro);=0A=20= #endif=0A-=20=20=20=20=09np->xn_ifp->if_capenable=20=3D=0A-=09=20=20=20=20= np->xn_ifp->if_capabilities=20&=20~(IFCAP_LRO|IFCAP_TSO4);=0A-=09= np->xn_ifp->if_hwassist=20&=3D=20~CSUM_TSO;=0A+=09=09= np->xn_ifp->if_capenable=20=3D=0A+=09=09=09np->xn_ifp->if_capabilities=20= &=20~(IFCAP_LRO|IFCAP_TSO4);=0A+=09=09np->xn_ifp->if_hwassist=20&=3D=20= ~CSUM_TSO;=0A+=09}=20else=20{=0A+=09=09/*=0A+=09=09=20*=20What=20we=20= have=20currently=20enabled=20is=20supported=20by=20the=0A+=09=09=20*=20= new=20host,=20no=20need=20to=20change=20anything.=0A+=09=09=20*/=0A+=09=09= return=200;=0A+=09}=0A=20#if=20__FreeBSD_version=20>=3D=20700000=20&&=20= (defined(INET)=20||=20defined(INET6))=0A=20=09if=20(xn_enable_lro=20&&=20= (np->xn_ifp->if_capabilities=20&=20IFCAP_LRO)=20!=3D=200)=20{=0A=20=09=09= err=20=3D=20tcp_lro_init(&np->xn_lro);=0A@@=20-2054,6=20+2072,8=20@@=20= create_netdev(device_t=20dev)=0A=20=09np->rx_min_target=20=3D=20= RX_MIN_TARGET;=0A=20=09np->rx_max_target=20=3D=20RX_MAX_TARGET;=0A=20=0A= +=09np->xn_cold=20=3D=20true;=0A+=0A=20=09/*=20Initialise=20{tx,rx}_skbs=20= to=20be=20a=20free=20chain=20containing=20every=20entry.=20*/=0A=20=09= for=20(i=20=3D=200;=20i=20<=3D=20NET_TX_RING_SIZE;=20i++)=20{=0A=20=09=09= np->tx_mbufs[i]=20=3D=20(void=20*)=20((u_long)=20i+1);=0A--=20=0A1.7.7.5=20= (Apple=20Git-26)=0A=0A= --Apple-Mail=_BF798988-D40B-4431-80BE-5CDB6B3ADE57-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 18:12:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B4A87B; Wed, 27 Nov 2013 18:12:42 +0000 (UTC) Received: from marcos.anarc.at (marcos.orangeseeds.org [IPv6:2001:1928:1:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0387A2F28; Wed, 27 Nov 2013 18:12:41 +0000 (UTC) Received: by marcos.anarc.at (Postfix, from userid 1000) id 2DE20142D5E; Wed, 27 Nov 2013 13:12:35 -0500 (EST) From: Antoine =?utf-8?Q?Beaupr=C3=A9?= To: Ermal =?utf-8?Q?Lu=C3=A7i?= Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks In-Reply-To: References: <87zjoqu3wr.fsf@marcos.anarc.at> User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Wed, 27 Nov 2013 13:12:33 -0500 Message-ID: <874n6xu31q.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 18:12:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2013-11-27 05:58:12, Ermal Lu=C3=A7i wrote: > You can use the port here > https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgpd > It has integration with pfkey sockets of FreeBSD in the daemon itself and > you have to specify only th espd policy through setkey. > > It works for pfSense. While it seems to bootstrap properly, it still fails to isntall a security association, in my bgpd.conf: tcp md5sig password "[...]" Startup log: root@rtr0:/usr/home/anarcat # bgpd -d startup rereading config route decision engine ready session engine ready RDE reconfigured listening on 0.0.0.0 listening on :: SE reconfigured neighbor 199.58.81.1 (rtr1): state change None -> Idle, reason: None neighbor 38.104.152.101 (Cogent): state change None -> Idle, reason: None neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start pfkey: Invalid argument neighbor 38.104.152.101 (Cogent): pfkey setup failed neighbor 199.58.81.1 (rtr1): state change Connect -> Active, reason: Connection open failed ^Cneighbor 199.58.81.1 (rtr1): state change Active -> Idle, reason: Stop kernel routing table 0 (Loc-RIB) decoupled pfkey: Invalid argument route decision engine exiting session engine exiting Terminating What do I need to set with setkey? It seems to send the wrong password to the other side: 13:06:33.455309 IP (tos 0x0, ttl 255, id 18405, offset 0, flags [DF], proto= TCP (6), length 68, bad cksum 0 (->b632)!) 38.104.152.102.179 > 38.104.152.101.44659: Flags [S.], cksum 0xe57b (co= rrect), seq 2310073167, ack 669413589, win 65535, options [mss 1436,nop,wsc= ale 6,nop,nop,md5invalid], length 0 After removing the tcpsig from my config, things work again because the other side is initiating the connexion... But connexions initiated from our side are not properly signed. also, I have another bgpd that i want to setup an iBGP session with, and this one loops to death: neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: Conn= ection opened neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason: = OPEN message received neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, reaso= n: KEEPALIVE message received neighbor 199.58.81.1 (rtr1): graceful restart of IPv4 unicast, keeping rout= es neighbor 199.58.81.1 (rtr1): state change Established -> Idle, reason: Conn= ection closed neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: Conn= ection opened neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason: = OPEN message received neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, reaso= n: KEEPALIVE message received neighbor 199.58.81.1 (rtr1): graceful restart of IPv4 unicast, keeping rout= es neighbor 199.58.81.1 (rtr1): state change Established -> Idle, reason: Conn= ection closed ... etc. After restarting the other daemon, it seems to work properly, but that was really scary... neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: Conn= ection opened neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason: = OPEN message received neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, reaso= n: KEEPALIVE message received a. =2D-=20 Freedom is being able to make decisions that affect mainly you. Power is being able to make decisions that affect others more than you. If we confuse power with freedom, we will fail to uphold real freedom. - Richard Stallman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSljYRAAoJEHkhUlJ7dZIeNcYP/0fmgxYjjGcohFuQZOOZkVs7 kQYW6i3GIIPUYXKAkBU5YBcd6YlVrId82J1+OklFZofZG/rjpPo1c9nc88hBrnVS lLqkjnf4jHTqGVbDNx9JE4kEgrwoZF3TAm6G4J6JxM7HVjsjQJLrVQhPUS1D8n8/ xYeLHntmIIeXjNIvqAX5GDUfhMJ8W8FpHr06sTbfIx6HigwW0SVfJDjmUX2untZ/ 4nb+D8C39D0ciIu3rOdn0WcY60UwQOuKnnMwy8Cj0f709//N/mYLMRJOdsd5X07u MlijDvwkFtn8OX65wvkgLj4nXeGchAkTi6ZfrikWSkeH58nrOOAS1R7RQpIPNZMM 5SI6NAPmSyMFK9I4XOyQJiYPIxHsWAcX+/bn0ue89ZrP04Nf6L/9EtIM3J9N3Bkq tlNnz/fTHhWixbsQu5fRELeafOTovjY1PPU+9YuZoZcAEfF1x6E3bw4gEIxDdlyz MXSXaplJDG0Bp0JQGMvd9/ZDipglDECsxCiuLDVu0aAUHob4bL30sUXE6FKEK9v8 TfS4OVQlPybiKnkpAkUwfku0x8q+pHyLdz/tQ7taS/DIsUvWG1DF2L/1GoZ3uYej oMvgW3YPKdhDucKsYRfGx0NTPFw9X6/+xky63pt3duWRwz8w00CnK66cwRQAmWlt 0A80jvu2jbcJ2Ehn8B93 =8KC6 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 27 19:53:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EB4343A for ; Wed, 27 Nov 2013 19:53:36 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3DE2474 for ; Wed, 27 Nov 2013 19:53:35 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id e14so12479020iej.40 for ; Wed, 27 Nov 2013 11:53:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HrtAy81ZfrEa8Bk89zhjeJfjpDNTe5oQ8vm57zP+90s=; b=UBMOKL+dNX69KcfKa06bIl1OlM3VW5Jhw3EwQ39283rJoxiWZ94w21/QSZoNVpKzIn Aax1YXY8QB+raYTWWTE1qPNX1wuhAqPnECJJq1JHtBmv9+dgWnLur2yAP89qbTReX7x6 w9DHAffnGvJvdwgoJud6qW1CBWeaINRh/Dn8TnzopdWn7bvgidW2DIy0iC2vrSxjtLN0 m37MSmdLhc0C+TvJ9i2a14x+DuDZ53Eq8+vKRGCnN8u1V070sRdMx9eOGV8ReHsWxoCa Wm3V8BkYyBGtTft432wjXbzVCBUyttgYydoFgbBdDSwwEcE+3LXyNvv5nIx9uHLKc0bC 2EiA== X-Gm-Message-State: ALoCoQkBZIV8WXJDBDyO+srX2a6pE8tr+WueUKTDKjvDlWbR8/jj7oMTkHaxgpwnnHouj0N0bMjf X-Received: by 10.50.119.161 with SMTP id kv1mr22826579igb.51.1385582009685; Wed, 27 Nov 2013 11:53:29 -0800 (PST) Received: from [10.181.146.40] ([63.92.245.153]) by mx.google.com with ESMTPSA id v9sm30666538igh.7.2013.11.27.11.53.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 11:53:28 -0800 (PST) References: <87zjoqu3wr.fsf@marcos.anarc.at> <87ob55ucbf.fsf@marcos.anarc.at> Mime-Version: 1.0 (1.0) In-Reply-To: <87ob55ucbf.fsf@marcos.anarc.at> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jim Thompson Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks Date: Wed, 27 Nov 2013 13:53:26 -0600 To: =?utf-8?Q?Antoine_Beaupr=C3=A9?= Cc: =?utf-8?Q?Ermal_Lu=C3=A7i?= , freebsd-net , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 19:53:36 -0000 > On Nov 27, 2013, at 8:52, Antoine Beaupr=C3=A9 wrote= : >=20 > Any reason why the port wasn't updated in FreeBSD? No, though historically the community has been stoic about taking patches ba= ck from pfSense.=20= From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 01:40:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B81F52AD for ; Thu, 28 Nov 2013 01:40:04 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D256B8C for ; Thu, 28 Nov 2013 01:40:04 +0000 (UTC) Received: from [206.217.92.186] (port=25529 helo=[192.168.134.134]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VlqaJ-0006Ot-1h for freebsd-net@freebsd.org; Wed, 27 Nov 2013 20:40:03 -0500 From: George Neville-Neil Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: If you work on a driver that supports pluggable optics or cables... Message-Id: Date: Wed, 27 Nov 2013 20:40:07 -0500 To: FreeBSD Net Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 01:40:04 -0000 Howdy, I just added sff8472.h to sys/net which allows driver writers to get = information on SFF/SFP+ optics and cables across i2c more easily. Navdeep (np@) has added the relevant = code to tools/tools/cxgbetool to show how to use these values to get information from cables plugged = into NICs. Can those of you who work on the various drivers that have an I2C interface to the = cabling please look at that include file and the cxgbetool program and start adding your own code to = handle this in a similar way? It=92s a great help to those working with hardware in large data centers = when they can see things like this: trantor:~# cxgbetool t5nex0 modinfo 1 ID: SFP Vendor FINISAR CORP. SN AJ10JQR PN FTLX8571D3BCL Rev A Temp: +35C Vcc 3.225600V TX Bias 2.176000uA TX Power 0.588800mW RX Power 0.486400mW Best, George From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 12:46:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 874C86AD for ; Thu, 28 Nov 2013 12:46:34 +0000 (UTC) Received: from eu1sys200aog104.obsmtp.com (eu1sys200aog104.obsmtp.com [207.126.144.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C56021BDD for ; Thu, 28 Nov 2013 12:46:33 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP ID DSNKUpc7It5c2TQ1QYgXO2UIPKleC1VUfnTU@postini.com; Thu, 28 Nov 2013 12:46:33 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 14:43:44 +0200 From: Meny Yossefi To: "freebsd-net@freebsd.org" Subject: UDP traffic, msg size exceeds 9215 Bytes Thread-Topic: UDP traffic, msg size exceeds 9215 Bytes Thread-Index: Ac7sB0a0MvWgPAi+SpCpDDit3uPaqA== Date: Thu, 28 Nov 2013 12:43:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Oded Shanoon , Meny Yossefi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 12:46:34 -0000 Hi all, We've been running some benchmarks (Netperf, Iperf) on our driver (Mellanox= ), and witnessed an odd behavior. We saw that when running UDP traffic with msg size larger than 9215 bytes, = it gets dropped for some reason. MTU is 1500. We've spotted the same behavior on different vendors which lead us to belie= ve there's some kernel issue that we are missing here. Please advise, Meny Yossefi | SW Engineer Mellanox Technologies Ltd Work: +972-74-7129121, Cell: +972-52-8379557 From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 12:57:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D56479DB for ; Thu, 28 Nov 2013 12:57:26 +0000 (UTC) Received: from mzh.zlo.nu (ns0.zlo.nu [85.17.141.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECB11C64 for ; Thu, 28 Nov 2013 12:57:25 +0000 (UTC) Received: by mzh.zlo.nu (Postfix, from userid 1000) id C5442140CB; Thu, 28 Nov 2013 13:49:44 +0100 (CET) Date: Thu, 28 Nov 2013 13:49:44 +0100 From: Marc Olzheim To: Meny Yossefi Subject: Re: UDP traffic, msg size exceeds 9215 Bytes Message-ID: <20131128124944.GA15691@zlo.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , Oded Shanoon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 12:57:26 -0000 On Thu, Nov 28, 2013 at 12:43:43PM +0000, Meny Yossefi wrote: > Hi all, > > We've been running some benchmarks (Netperf, Iperf) on our driver (Mellanox), and witnessed an odd behavior. > We saw that when running UDP traffic with msg size larger than 9215 bytes, it gets dropped for some reason. MTU is 1500. > > We've spotted the same behavior on different vendors which lead us to believe there's some kernel issue that we are missing here. Did you meddle with sysctl net.inet.udp.maxdgram yet ? The default value is 6 * 1536 = 9216 bytes... Marc From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 13:00:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F370B4F for ; Thu, 28 Nov 2013 13:00:39 +0000 (UTC) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86DA31CC4 for ; Thu, 28 Nov 2013 13:00:38 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKUpc+dLbRu39AKP/90vBSh8EJeu1e8zwl@postini.com; Thu, 28 Nov 2013 13:00:38 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 14:54:02 +0200 From: Meny Yossefi To: Marc Olzheim , "freebsd-net@freebsd.org" Subject: RE: UDP traffic, msg size exceeds 9215 Bytes Thread-Topic: UDP traffic, msg size exceeds 9215 Bytes Thread-Index: Ac7sB0a0MvWgPAi+SpCpDDit3uPaqAAIEV4AAARP5CA= Date: Thu, 28 Nov 2013 12:53:59 +0000 Message-ID: References: <20131128124944.GA15691@zlo.nu> In-Reply-To: <20131128124944.GA15691@zlo.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oded Shanoon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 13:00:39 -0000 Nope, I wasn't aware of it. It works now. Thanks! -Meny -----Original Message----- From: Marc Olzheim [mailto:marcolz@stack.nl]=20 Sent: Thursday, November 28, 2013 2:50 PM To: Meny Yossefi Cc: freebsd-net@freebsd.org; Oded Shanoon Subject: Re: UDP traffic, msg size exceeds 9215 Bytes On Thu, Nov 28, 2013 at 12:43:43PM +0000, Meny Yossefi wrote: > Hi all, >=20 > We've been running some benchmarks (Netperf, Iperf) on our driver (Mellan= ox), and witnessed an odd behavior. > We saw that when running UDP traffic with msg size larger than 9215 bytes= , it gets dropped for some reason. MTU is 1500. >=20 > We've spotted the same behavior on different vendors which lead us to bel= ieve there's some kernel issue that we are missing here. Did you meddle with sysctl net.inet.udp.maxdgram yet ? The default value is 6 * 1536 =3D 9216 bytes... Marc From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 15:05:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A88FCB8C for ; Thu, 28 Nov 2013 15:05:56 +0000 (UTC) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 795AF1303 for ; Thu, 28 Nov 2013 15:05:56 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id jt11so12854704pbb.28 for ; Thu, 28 Nov 2013 07:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZybPseI3wpKgaxFVSSA6eVw5BdD37BZHVHkBbutSNts=; b=HZnu/SrOeAzH7q4kHD+jn11E8Cw69osMfjsKaL7D0r2XiWvfk2HpYWglGU9i8J8l8A ozr2/ngAfz91Fp/w2yqGoBuCDquLTRoRTcMA9Iu6luH8aw+JA5c+VnHN71bl7w8giBPo n9OOJMymj6MDOZMiMcPThRLOl/N8Fez6rqpasnMBC4TgbP96POl3TEXH5lhBGZGRU7a5 F3Bghs9zSbmG6oBprF0afEf2gFsVTFOaAPLYfTRMusFGoBon66UFRoteE/jQEqNAAJt2 eoKKnWfg2M7Vdfqb3RzNW44mIwhJ6R59W4KYvgV7GaFsLjxdsLwwN5gJtzf/wnjVDc6G 9J8Q== MIME-Version: 1.0 X-Received: by 10.68.129.130 with SMTP id nw2mr11303524pbb.88.1385651155532; Thu, 28 Nov 2013 07:05:55 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Thu, 28 Nov 2013 07:05:55 -0800 (PST) In-Reply-To: <874n6xu31q.fsf@marcos.anarc.at> References: <87zjoqu3wr.fsf@marcos.anarc.at> <874n6xu31q.fsf@marcos.anarc.at> Date: Thu, 28 Nov 2013 16:05:55 +0100 X-Google-Sender-Auth: Ibmz40ysgcbI1DUxU4ZopRXi6CA Message-ID: Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: =?ISO-8859-1?Q?Antoine_Beaupr=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 15:05:56 -0000 On Wed, Nov 27, 2013 at 7:12 PM, Antoine Beaupr=E9 wro= te: > On 2013-11-27 05:58:12, Ermal Lu=E7i wrote: > > You can use the port here > > https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgpd > > It has integration with pfkey sockets of FreeBSD in the daemon itself a= nd > > you have to specify only th espd policy through setkey. > > > > It works for pfSense. > > While it seems to bootstrap properly, it still fails to isntall a > security association, in my bgpd.conf: > > tcp md5sig password "[...]" > Probably because you are putting "(quotes) on the password and that is wrong. That means password on the connection is wrong since it has " in it. Think its an issue of the bgpd parser on this. > Startup log: > > root@rtr0:/usr/home/anarcat # bgpd -d > startup > rereading config > route decision engine ready > session engine ready > RDE reconfigured > listening on 0.0.0.0 > listening on :: > SE reconfigured > neighbor 199.58.81.1 (rtr1): state change None -> Idle, reason: None > neighbor 38.104.152.101 (Cogent): state change None -> Idle, reason: > None > neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start > pfkey: Invalid argument > neighbor 38.104.152.101 (Cogent): pfkey setup failed > neighbor 199.58.81.1 (rtr1): state change Connect -> Active, reason: > Connection open failed > ^Cneighbor 199.58.81.1 (rtr1): state change Active -> Idle, reason: Stop > kernel routing table 0 (Loc-RIB) decoupled > pfkey: Invalid argument > route decision engine exiting > session engine exiting > Terminating > > What do I need to set with setkey? > > It seems to send the wrong password to the other side: > > 13:06:33.455309 IP (tos 0x0, ttl 255, id 18405, offset 0, flags [DF], > proto TCP (6), length 68, bad cksum 0 (->b632)!) > 38.104.152.102.179 > 38.104.152.101.44659: Flags [S.], cksum 0xe57b > (correct), seq 2310073167, ack 669413589, win 65535, options [mss > 1436,nop,wscale 6,nop,nop,md5invalid], length 0 > > After removing the tcpsig from my config, things work again because the > other side is initiating the connexion... But connexions initiated from > our side are not properly signed. > > also, I have another bgpd that i want to setup an iBGP session with, and > this one loops to death: > > neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start > neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: > Connection opened > neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason= : > OPEN message received > neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, > reason: KEEPALIVE message received > neighbor 199.58.81.1 (rtr1): graceful restart of IPv4 unicast, keeping > routes > neighbor 199.58.81.1 (rtr1): state change Established -> Idle, reason: > Connection closed > neighbor 199.58.81.1 (rtr1): state change Idle -> Connect, reason: Start > neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: > Connection opened > neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason= : > OPEN message received > neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, > reason: KEEPALIVE message received > neighbor 199.58.81.1 (rtr1): graceful restart of IPv4 unicast, keeping > routes > neighbor 199.58.81.1 (rtr1): state change Established -> Idle, reason: > Connection closed > > ... etc. After restarting the other daemon, it seems to work properly, > but that was really scary... > > neighbor 199.58.81.1 (rtr1): state change Connect -> OpenSent, reason: > Connection opened > neighbor 199.58.81.1 (rtr1): state change OpenSent -> OpenConfirm, reason= : > OPEN message received > neighbor 199.58.81.1 (rtr1): state change OpenConfirm -> Established, > reason: KEEPALIVE message received > > a. > > -- > Freedom is being able to make decisions that affect mainly you. Power > is being able to make decisions that affect others more than you. If > we confuse power with freedom, we will fail to uphold real freedom. > - Richard Stallman > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 15:17:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA1EDF7D; Thu, 28 Nov 2013 15:17:00 +0000 (UTC) Received: from marcos.anarc.at (mail.orangeseeds.org [72.0.72.144]) by mx1.freebsd.org (Postfix) with ESMTP id 975E81394; Thu, 28 Nov 2013 15:16:59 +0000 (UTC) Received: by marcos.anarc.at (Postfix, from userid 1000) id DCEB9142D5E; Thu, 28 Nov 2013 10:16:48 -0500 (EST) From: Antoine =?utf-8?Q?Beaupr=C3=A9?= To: Ermal =?utf-8?Q?Lu=C3=A7i?= Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks In-Reply-To: References: <87zjoqu3wr.fsf@marcos.anarc.at> <874n6xu31q.fsf@marcos.anarc.at> User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Thu, 28 Nov 2013 10:16:43 -0500 Message-ID: <87ob54pndw.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 15:17:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2013-11-28 10:05:55, Ermal Lu=C3=A7i wrote: > On Wed, Nov 27, 2013 at 7:12 PM, Antoine Beaupr=C3=A9 wrote: > >> On 2013-11-27 05:58:12, Ermal Lu=C3=A7i wrote: >> > You can use the port here >> > https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgpd >> > It has integration with pfkey sockets of FreeBSD in the daemon itself = and >> > you have to specify only th espd policy through setkey. >> > >> > It works for pfSense. >> >> While it seems to bootstrap properly, it still fails to isntall a >> security association, in my bgpd.conf: >> >> tcp md5sig password "[...]" >> > > Probably because you are putting "(quotes) on the password and that is > wrong. > That means password on the connection is wrong since it has " in it. > Think its an issue of the bgpd parser on this. I also tried without the quotes, same effect. A. =2D-=20 Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. - Andrew S. Tanenbaum, "Computer Networks" --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSl15cAAoJEHkhUlJ7dZIe4XgP/je0BlR/2MC6OWXHN7gJlvFl ZEl7LU7ZHE8HG+4X4aOZtragDqtauQ7RCNMRN8dCACkf3I9imyK0zT41v8sicF6k vVU5mM8KFM6PnYXSAB49c9WOMdRBJcf1f6ejBS9uNuk0KttPW6H9ruXUe/SwsUee nOa2LDZiyTpLZdH8vcSuU+iwxiqe8g5s1gMLscVilW/qhtmFJPyCMtydpDfqGP6g Gg9VcT9Ua3urM8uW5i/qA4hfUsgpPohYvIklOdlgXq/zFbYSFE73555va3CYIVIz i54it/Yyn8TSnkixF1JzcDIoegTgxTz2YBHKIc0z2Vl04gluqJU8F4vLFNvsFkdc ZpEO0s0pbakM2liMy5v08xjvh3d+b1B7pcPiV99spUBDJtTnWCNJ0Swu2Cw7FeIz 3yMYwvO5hgHNWaAkeiyHZeky5sElOX3n2cdkVtxwWD2TjIr1tJgjfaI4qV0cJBAW E8MEajTIQ/wx25CWeFZkhwbJFiM9ZwzLXuDpupZEAf2roj7b+YcS/FsbOOMlrmY5 dqv8pzQ29/obIh7IYzxYo9QUyGGM436Ag4txUljXiYhWE2CrcN2c+acmJfcbTbPx O8VVgIwIfuMAmg+rBiy0Ia2qyCaAIqZWfdC2Ik3e2fUtXyNo/uyZ6c3/TbbVXJqM jHDNf+cLRcsUbuBg+ZDq =2F19 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 16:02:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67C4BD18 for ; Thu, 28 Nov 2013 16:02:14 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0331E166D for ; Thu, 28 Nov 2013 16:02:13 +0000 (UTC) Received: from r2d2 ([82.69.179.241]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006862913.msg for ; Thu, 28 Nov 2013 16:02:09 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 28 Nov 2013 16:02:09 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.179.241 X-Return-Path: prvs=1044cd13f0=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <0F2B39164CA846AFBBE0EF697EFE3407@multiplay.co.uk> From: "Steven Hartland" To: "Marc Olzheim" , "Meny Yossefi" References: <20131128124944.GA15691@zlo.nu> Subject: Re: UDP traffic, msg size exceeds 9215 Bytes Date: Thu, 28 Nov 2013 16:02:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-net@freebsd.org, Oded Shanoon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 16:02:14 -0000 You really shouldnt allow the application to send packets that big as you'll end up with fragmentation and due to UDP protocol issues and hackers abusing them (the port for fragemented packets isn't set) you'll often find fragmented udp packets are simply blocked. Regards Steve ----- Original Message ----- From: "Marc Olzheim" To: "Meny Yossefi" Cc: ; "Oded Shanoon" Sent: Thursday, November 28, 2013 12:49 PM Subject: Re: UDP traffic, msg size exceeds 9215 Bytes > On Thu, Nov 28, 2013 at 12:43:43PM +0000, Meny Yossefi wrote: >> Hi all, >> >> We've been running some benchmarks (Netperf, Iperf) on our driver (Mellanox), and witnessed an odd behavior. >> We saw that when running UDP traffic with msg size larger than 9215 bytes, it gets dropped for some reason. MTU is 1500. >> >> We've spotted the same behavior on different vendors which lead us to believe there's some kernel issue that we are missing >> here. > > Did you meddle with sysctl net.inet.udp.maxdgram yet ? The default value is > 6 * 1536 = 9216 bytes... > > Marc > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 18:14:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 636ADA75 for ; Thu, 28 Nov 2013 18:14:20 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34D991D19 for ; Thu, 28 Nov 2013 18:14:20 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id r10so12400585pdi.38 for ; Thu, 28 Nov 2013 10:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YiEGus+phsDydT7FKBOWHAoZMyBCDU76c7N8GZ9qHzo=; b=0w7dsmUmK9uCCOK8wHl8iZkTANfFssNmpZPN4JSd32e8qqxCJMOvdv6AUXiStj6cgq ozu6fnGKy9ZxRXAa2bns4InclwLt6UVCbuLIivLdAgU2scQ7V1VNcZVj/qU9Ow1vgvTq Z+QtHIg2DlW6u9EGcqcaKg1O+Vsa3CSVIpP7tr77vUsRPukSFy5rjU3zVYFstO87+XVZ fnkgPT/LJHjYoHe76b/O1Wv09veL7ReqE//WB5f8vnSdlZ5PE83w+J1UIOAG+05/jhdt f1kbxR+OV/yVSGg6EzmYK2jgXehzn+/mqiqh6V7O5IbpBy8EdMBPCa3NpwDwEVpyj/Vj SB8g== MIME-Version: 1.0 X-Received: by 10.66.4.130 with SMTP id k2mr47586500pak.95.1385662458999; Thu, 28 Nov 2013 10:14:18 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Thu, 28 Nov 2013 10:14:18 -0800 (PST) In-Reply-To: <87ob54pndw.fsf@marcos.anarc.at> References: <87zjoqu3wr.fsf@marcos.anarc.at> <874n6xu31q.fsf@marcos.anarc.at> <87ob54pndw.fsf@marcos.anarc.at> Date: Thu, 28 Nov 2013 19:14:18 +0100 X-Google-Sender-Auth: beog3UZ7omkCwEUcsX7jXTHs1Vc Message-ID: Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: =?ISO-8859-1?Q?Antoine_Beaupr=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 18:14:20 -0000 On Thu, Nov 28, 2013 at 4:16 PM, Antoine Beaupr=E9 wro= te: > On 2013-11-28 10:05:55, Ermal Lu=E7i wrote: > > On Wed, Nov 27, 2013 at 7:12 PM, Antoine Beaupr=E9 >wrote: > > > >> On 2013-11-27 05:58:12, Ermal Lu=E7i wrote: > >> > You can use the port here > >> > https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/openbgp= d > >> > It has integration with pfkey sockets of FreeBSD in the daemon itsel= f > and > >> > you have to specify only th espd policy through setkey. > >> > > >> > It works for pfSense. > >> > >> While it seems to bootstrap properly, it still fails to isntall a > >> security association, in my bgpd.conf: > >> > >> tcp md5sig password "[...]" > >> > > > > Probably because you are putting "(quotes) on the password and that is > > wrong. > > That means password on the connection is wrong since it has " in it. > > Think its an issue of the bgpd parser on this. > > I also tried without the quotes, same effect. > Can you show your related config to this! The only other thing i can think of is that since the daemon is inserting policies you have to define local-address $your-local-ip So the SPD policy is generated correctly. You can verify the generated policy using setkey utility. > > A. > -- > Never underestimate the bandwidth of a station wagon full of tapes > hurtling down the highway. > - Andrew S. Tanenbaum, "Computer Networks" > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 19:31:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D8359D4; Thu, 28 Nov 2013 19:31:18 +0000 (UTC) Received: from marcos.anarc.at (marcos.orangeseeds.org [IPv6:2001:1928:1:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id BE84A1095; Thu, 28 Nov 2013 19:31:17 +0000 (UTC) Received: by marcos.anarc.at (Postfix, from userid 1000) id D5FBC142D5E; Thu, 28 Nov 2013 14:31:13 -0500 (EST) From: Antoine =?utf-8?Q?Beaupr=C3=A9?= To: Ermal =?utf-8?Q?Lu=C3=A7i?= Subject: Re: OpenBGPd + TCP-MD5 sig fails after a few weeks In-Reply-To: References: <87zjoqu3wr.fsf@marcos.anarc.at> <874n6xu31q.fsf@marcos.anarc.at> <87ob54pndw.fsf@marcos.anarc.at> User-Agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Thu, 28 Nov 2013 14:31:11 -0500 Message-ID: <87bo14pbls.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 19:31:18 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2013-11-28 13:14:18, Ermal Lu=C3=A7i wrote: > Can you show your related config to this! > The only other thing i can think of is that since the daemon is inserting > policies you have to define > local-address $your-local-ip > > So the SPD policy is generated correctly. Ah! That was it!!! Without local-address, I get this: pfkey: Invalid argument neighbor 38.104.152.101 (Cogent): pfkey setup failed With local-address, it just works! > You can verify the generated policy using setkey utility. I confirm the policy is properly installed by the pfsense port, if and only if local-address is specified. Next step would be to file a PR to update the port! I have tried to factor in a patch that merges the pfsense port in the FreeBSD port with minimal changes, would you mind reviewing it before I send it? Here's the patch to the FreeBSD port: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=fbsd-openbgpd-port-setkey.patch Content-Transfer-Encoding: quoted-printable diff --git a/Makefile b/Makefile old mode 100644 new mode 100755 index d39d87d..5c0513a =2D-- a/Makefile +++ b/Makefile @@ -1,4 +1,5 @@ =2D# $FreeBSD: net/openbgpd/Makefile 330656 2013-10-17 16:47:58Z ohauer $ +# Created by: Florent Thoumie +# $FreeBSD: ports/net/openbgpd/Makefile,v 1.35 2012/12/24 12:56:29 svnexp = Exp $ =20 PORTNAME=3D openbgpd PORTVERSION=3D 5.2.20121209 @@ -8,6 +9,7 @@ MASTER_SITE_SUBDIR=3D OpenBGPD DISTNAME=3D ${PORTNAME}-4.6 EXTRACT_SUFX=3D .tgz DIST_SUBDIR=3D ${PORTNAME} +NO_STAGE=3D yes =20 MAINTAINER=3D hrs@FreeBSD.org COMMENT=3D Free implementation of the Border Gateway Protocol, Version 4 @@ -15,13 +17,16 @@ COMMENT=3D Free implementation of the Border Gateway Pr= otocol, Version 4 CONFLICTS=3D zebra-[0-9]* quagga-[0-9]* =20 WRKSRC=3D ${WRKDIR} +MANCOMPRESSED=3D yes USE_RC_SUBR=3D ${PORTNAME} =2DPLIST_FILES=3D sbin/bgpctl sbin/bgpd man/man5/bgpd.conf.5.gz \ =2D man/man8/bgpctl.8.gz man/man8/bgpd.8.gz +PLIST_FILES=3D sbin/bgpctl sbin/bgpd SUB_FILES=3D pkg-message USERS=3D _bgpd GROUPS=3D _bgpd =20 +MAN5=3D bgpd.conf.5 +MAN8=3D bgpctl.8 bgpd.8 + OPTIONS_DEFINE=3D IPV6LLPEER OPTIONS_DEFAULT=3DIPV6LLPEER IPV6LLPEER_DESC=3DSupport nexthop using IPv6 link-local address diff --git a/files/openbgpd.in b/files/openbgpd.in index f1b904e..fc6642e 100644 =2D-- a/files/openbgpd.in +++ b/files/openbgpd.in @@ -1,6 +1,6 @@ #!/bin/sh # =2D# $FreeBSD: net/openbgpd/files/openbgpd.in 302141 2012-08-05 23:19:36Z d= ougb $ +# $FreeBSD: ports/net/openbgpd/files/openbgpd.in,v 1.2 2012/11/17 06:00:08= svnexp Exp $ # =20 # PROVIDE: bgpd diff --git a/files/patch-bgpd_Makefile b/files/patch-bgpd_Makefile index f946c92..fc27014 100644 =2D-- a/files/patch-bgpd_Makefile +++ b/files/patch-bgpd_Makefile @@ -1,11 +1,5 @@ =2DIndex: bgpd/Makefile =2D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2DRCS file: /home/cvs/private/hrs/openbgpd/bgpd/Makefile,v =2Dretrieving revision 1.1.1.2 =2Dretrieving revision 1.9 =2Ddiff -u -p -r1.1.1.2 -r1.9 =2D--- bgpd/Makefile 9 Jul 2009 16:49:54 -0000 1.1.1.2 =2D+++ bgpd/Makefile 13 Oct 2012 18:36:00 -0000 1.9 +--- bgpd/Makefile.orig 2013-02-21 19:20:05.000000000 +0000 ++++ bgpd/Makefile 2013-02-21 19:20:54.000000000 +0000 @@ -1,15 +1,25 @@ # $OpenBSD: Makefile,v 1.28 2009/06/25 14:14:54 deraadt Exp $ =20=20 @@ -17,9 +11,8 @@ diff -u -p -r1.1.1.2 -r1.9 -SRCS=3D bgpd.c buffer.c session.c log.c parse.y config.c imsg.c \ +SRCS=3D bgpd.c session.c log.c parse.y config.c \ rde.c rde_rib.c rde_decide.c rde_prefix.c mrt.c kroute.c \ =2D- control.c pfkey.c rde_update.c rde_attr.c printconf.c \ + control.c pfkey.c rde_update.c rde_attr.c printconf.c \ - rde_filter.c pftable.c name2id.c util.c carp.c timer.c =2D+ control.c pfkey_compat.c rde_update.c rde_attr.c printconf.c \ + rde_filter.c pftable.c name2id.c util.c carp.c timer.c \ + imsg.c imsg-buffer.c CFLAGS+=3D -Wall -I${.CURDIR} diff --git a/files/patch-bgpd_pfkey.c b/files/patch-bgpd_pfkey.c index 7ad7548..224298f 100644 =2D-- a/files/patch-bgpd_pfkey.c +++ b/files/patch-bgpd_pfkey.c @@ -1,26 +1,41 @@ =2DIndex: bgpd/pfkey.c =2D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2DRCS file: /home/cvs/private/hrs/openbgpd/bgpd/pfkey.c,v =2Dretrieving revision 1.1.1.6 =2Dretrieving revision 1.1.1.9 =2Ddiff -u -p -r1.1.1.6 -r1.1.1.9 =2D--- bgpd/pfkey.c 14 Feb 2010 20:19:57 -0000 1.1.1.6 =2D+++ bgpd/pfkey.c 13 Oct 2012 18:22:44 -0000 1.1.1.9 +diff -ur bgpd.orig/pfkey.c bgpd/pfkey.c +--- bgpd.orig/pfkey.c 2013-03-15 12:07:16.000000000 +0000 ++++ bgpd/pfkey.c 2013-03-15 12:07:47.000000000 +0000 @@ -1,4 +1,4 @@ -/* $OpenBSD: pfkey.c,v 1.37 2009/04/21 15:25:52 henning Exp $ */ +/* $OpenBSD: pfkey.c,v 1.40 2009/12/14 17:38:18 claudio Exp $ */ =20=20 /* * Copyright (c) 2003, 2004 Henning Brauer =2D@@ -74,6 +74,7 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -21,7 +21,7 @@ + #include + #include + #include +-#include ++//#include + #include + #include + #include +@@ -65,15 +65,15 @@ + { + struct sadb_msg smsg; + struct sadb_sa sa; +- struct sadb_address sa_src, sa_dst, sa_peer, sa_smask, sa_dmask; ++ struct sadb_address sa_src, sa_dst; + struct sadb_key sa_akey, sa_ekey; + struct sadb_spirange sa_spirange; +- struct sadb_protocol sa_flowtype, sa_protocol; + struct iovec iov[IOV_CNT]; + ssize_t n; int len =3D 0; int iov_cnt; =2D struct sockaddr_storage ssrc, sdst, speer, smask, dmask; +- struct sockaddr_storage ssrc, sdst, speer, smask, dmask; ++ struct sockaddr_storage ssrc, sdst, smask, dmask; + struct sockaddr *saptr; =20=20 if (!pid) pid =3D getpid(); =2D@@ -81,22 +82,17 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -81,22 +81,17 @@ /* we need clean sockaddr... no ports set */ bzero(&ssrc, sizeof(ssrc)); bzero(&smask, sizeof(smask)); @@ -49,7 +64,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 ssrc.ss_len =3D sizeof(struct sockaddr); break; default: =2D@@ -107,22 +103,17 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -107,22 +102,17 @@ =20=20 bzero(&sdst, sizeof(sdst)); bzero(&dmask, sizeof(dmask)); @@ -78,7 +93,84 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 sdst.ss_len =3D sizeof(struct sockaddr); break; default: =2D@@ -220,8 +211,8 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -135,7 +125,7 @@ + smsg.sadb_msg_version =3D PF_KEY_V2; + smsg.sadb_msg_seq =3D ++sadb_msg_seq; + smsg.sadb_msg_pid =3D pid; +- smsg.sadb_msg_len =3D sizeof(smsg) / 8; ++ smsg.sadb_msg_len =3D PFKEY_UNIT64(sizeof(smsg)); + smsg.sadb_msg_type =3D mtype; + smsg.sadb_msg_satype =3D satype; +=20 +@@ -143,7 +133,7 @@ + case SADB_GETSPI: + bzero(&sa_spirange, sizeof(sa_spirange)); + sa_spirange.sadb_spirange_exttype =3D SADB_EXT_SPIRANGE; +- sa_spirange.sadb_spirange_len =3D sizeof(sa_spirange) / 8; ++ sa_spirange.sadb_spirange_len =3D PFKEY_UNIT64(sizeof(sa_spirange)); + sa_spirange.sadb_spirange_min =3D 0x100; + sa_spirange.sadb_spirange_max =3D 0xffffffff; + sa_spirange.sadb_spirange_reserved =3D 0; +@@ -153,11 +143,12 @@ + case SADB_DELETE: + bzero(&sa, sizeof(sa)); + sa.sadb_sa_exttype =3D SADB_EXT_SA; +- sa.sadb_sa_len =3D sizeof(sa) / 8; ++ sa.sadb_sa_len =3D PFKEY_UNIT64(sizeof(sa)); + sa.sadb_sa_replay =3D 0; + sa.sadb_sa_spi =3D spi; + sa.sadb_sa_state =3D SADB_SASTATE_MATURE; + break; ++#if 0 + case SADB_X_ADDFLOW: + case SADB_X_DELFLOW: + bzero(&sa_flowtype, sizeof(sa_flowtype)); +@@ -172,35 +163,37 @@ + sa_protocol.sadb_protocol_direction =3D 0; + sa_protocol.sadb_protocol_proto =3D 6; + break; ++#endif + } +=20 + bzero(&sa_src, sizeof(sa_src)); + sa_src.sadb_address_exttype =3D SADB_EXT_ADDRESS_SRC; +- sa_src.sadb_address_len =3D (sizeof(sa_src) + ROUNDUP(ssrc.ss_len)) / 8; ++ sa_src.sadb_address_len =3D PFKEY_UNIT64(sizeof(sa_src) + ROUNDUP(ssrc.s= s_len)); +=20 + bzero(&sa_dst, sizeof(sa_dst)); + sa_dst.sadb_address_exttype =3D SADB_EXT_ADDRESS_DST; +- sa_dst.sadb_address_len =3D (sizeof(sa_dst) + ROUNDUP(sdst.ss_len)) / 8; ++ sa_dst.sadb_address_len =3D PFKEY_UNIT64(sizeof(sa_dst) + ROUNDUP(sdst.s= s_len)); +=20 + sa.sadb_sa_auth =3D aalg; +- sa.sadb_sa_encrypt =3D SADB_X_EALG_AES; /* XXX */ ++ sa.sadb_sa_encrypt =3D ealg; /* XXX */ +=20 + switch (mtype) { + case SADB_ADD: + case SADB_UPDATE: + bzero(&sa_akey, sizeof(sa_akey)); + sa_akey.sadb_key_exttype =3D SADB_EXT_KEY_AUTH; +- sa_akey.sadb_key_len =3D (sizeof(sa_akey) + +- ((alen + 7) / 8) * 8) / 8; ++ sa_akey.sadb_key_len =3D PFKEY_UNIT64(sizeof(sa_akey) + ++ (PFKEY_ALIGN8(alen))); + sa_akey.sadb_key_bits =3D 8 * alen; +=20 + bzero(&sa_ekey, sizeof(sa_ekey)); + sa_ekey.sadb_key_exttype =3D SADB_EXT_KEY_ENCRYPT; +- sa_ekey.sadb_key_len =3D (sizeof(sa_ekey) + +- ((elen + 7) / 8) * 8) / 8; ++ sa_ekey.sadb_key_len =3D PFKEY_UNIT64(sizeof(sa_ekey) + ++ (PFKEY_ALIGN8(elen))); + sa_ekey.sadb_key_bits =3D 8 * elen; +=20 + break; ++#if 0 + case SADB_X_ADDFLOW: + case SADB_X_DELFLOW: + /* sa_peer always points to the remote machine */ +@@ -220,8 +213,8 @@ sa_dst.sadb_address_exttype =3D SADB_X_EXT_DST_FLOW; =20=20 bzero(&smask, sizeof(smask)); @@ -89,7 +181,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 smask.ss_len =3D sizeof(struct sockaddr_in); smask.ss_family =3D AF_INET; memset(&((struct sockaddr_in *)&smask)->sin_addr, =2D@@ -233,7 +224,7 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -233,7 +226,7 @@ htons(0xffff); } break; @@ -98,7 +190,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 smask.ss_len =3D sizeof(struct sockaddr_in6); smask.ss_family =3D AF_INET6; memset(&((struct sockaddr_in6 *)&smask)->sin6_addr, =2D@@ -247,8 +238,8 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -247,8 +240,8 @@ break; } bzero(&dmask, sizeof(dmask)); @@ -109,7 +201,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 dmask.ss_len =3D sizeof(struct sockaddr_in); dmask.ss_family =3D AF_INET; memset(&((struct sockaddr_in *)&dmask)->sin_addr, =2D@@ -260,7 +251,7 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -260,7 +253,7 @@ htons(0xffff); } break; @@ -118,7 +210,57 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 dmask.ss_len =3D sizeof(struct sockaddr_in6); dmask.ss_family =3D AF_INET6; memset(&((struct sockaddr_in6 *)&dmask)->sin6_addr, =2D@@ -411,6 +402,33 @@ pfkey_send(int sd, uint8_t satype, uint8 +@@ -284,6 +277,7 @@ + sa_dmask.sadb_address_len =3D + (sizeof(sa_dmask) + ROUNDUP(dmask.ss_len)) / 8; + break; ++#endif + } +=20 + iov_cnt =3D 0; +@@ -310,6 +304,7 @@ + smsg.sadb_msg_len +=3D sa_spirange.sadb_spirange_len; + iov_cnt++; + break; ++#if 0 + case SADB_X_ADDFLOW: + /* sa_peer always points to the remote machine */ + iov[iov_cnt].iov_base =3D &sa_peer; +@@ -351,6 +346,7 @@ + smsg.sadb_msg_len +=3D sa_dmask.sadb_address_len; + iov_cnt++; + break; ++#endif + } +=20 + /* dest addr */ +@@ -380,7 +376,7 @@ + iov[iov_cnt].iov_len =3D sizeof(sa_akey); + iov_cnt++; + iov[iov_cnt].iov_base =3D akey; +- iov[iov_cnt].iov_len =3D ((alen + 7) / 8) * 8; ++ iov[iov_cnt].iov_len =3D PFKEY_ALIGN8(alen); + smsg.sadb_msg_len +=3D sa_akey.sadb_key_len; + iov_cnt++; + } +@@ -390,14 +386,14 @@ + iov[iov_cnt].iov_len =3D sizeof(sa_ekey); + iov_cnt++; + iov[iov_cnt].iov_base =3D ekey; +- iov[iov_cnt].iov_len =3D ((elen + 7) / 8) * 8; ++ iov[iov_cnt].iov_len =3D PFKEY_ALIGN8(elen); + smsg.sadb_msg_len +=3D sa_ekey.sadb_key_len; + iov_cnt++; + } + break; + } +=20 +- len =3D smsg.sadb_msg_len * 8; ++ len =3D PFKEY_UNUNIT64(smsg.sadb_msg_len); + do { + n =3D writev(sd, iov, iov_cnt); + } while (n =3D=3D -1 && (errno =3D=3D EAGAIN || errno =3D=3D EINTR)); +@@ -411,6 +407,33 @@ } =20=20 int @@ -152,7 +294,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 pfkey_reply(int sd, u_int32_t *spip) { struct sadb_msg hdr, *msg; =2D@@ -418,23 +436,13 @@ pfkey_reply(int sd, u_int32_t *spip) +@@ -418,27 +441,17 @@ struct sadb_sa *sa; u_int8_t *data; ssize_t len; @@ -161,10 +303,7 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 - for (;;) { - if (recv(sd, &hdr, sizeof(hdr), MSG_PEEK) !=3D sizeof(hdr)) { - log_warn("pfkey peek"); =2D+ do { =2D+ rv =3D pfkey_read(sd, &hdr); =2D+ if (rv =3D=3D -1) =2D return (-1); +- return (-1); - } - - if (hdr.sadb_msg_seq =3D=3D sadb_msg_seq && @@ -174,14 +313,148 @@ diff -u -p -r1.1.1.6 -r1.1.1.9 - /* not ours, discard */ - if (read(sd, &hdr, sizeof(hdr)) =3D=3D -1) { - log_warn("pfkey read"); =2D- return (-1); ++ do { ++ rv =3D pfkey_read(sd, &hdr); ++ if (rv =3D=3D -1) + return (-1); - } - } + } while (rv); =20=20 if (hdr.sadb_msg_errno !=3D 0) { errno =3D hdr.sadb_msg_errno; =2D@@ -730,11 +738,9 @@ pfkey_init(struct bgpd_sysdep *sysdep) +- if (errno =3D=3D ESRCH) ++ if (errno =3D=3D ESRCH || errno =3D=3D EEXIST) + return (0); + else { + log_warn("pfkey"); +@@ -486,13 +499,8 @@ + pfkey_sa_add(struct bgpd_addr *src, struct bgpd_addr *dst, u_int8_t keyle= n, + char *key, u_int32_t *spi) + { +- if (pfkey_send(fd, SADB_X_SATYPE_TCPSIGNATURE, SADB_GETSPI, 0, +- src, dst, 0, 0, 0, NULL, 0, 0, NULL, 0, 0) < 0) +- return (-1); +- if (pfkey_reply(fd, spi) < 0) +- return (-1); +- if (pfkey_send(fd, SADB_X_SATYPE_TCPSIGNATURE, SADB_UPDATE, 0, +- src, dst, *spi, 0, keylen, key, 0, 0, NULL, 0, 0) < 0) ++ if (pfkey_send(fd, SADB_X_SATYPE_TCPSIGNATURE, SADB_ADD, 0, ++ src, dst, *spi, SADB_X_AALG_TCP_MD5, keylen, key, SADB_EALG_NONE, 0, NU= LL, 0, 0) < 0) + return (-1); + if (pfkey_reply(fd, NULL) < 0) + return (-1); +@@ -503,7 +511,7 @@ + pfkey_sa_remove(struct bgpd_addr *src, struct bgpd_addr *dst, u_int32_t *= spi) + { + if (pfkey_send(fd, SADB_X_SATYPE_TCPSIGNATURE, SADB_DELETE, 0, +- src, dst, *spi, 0, 0, NULL, 0, 0, NULL, 0, 0) < 0) ++ src, dst, *spi, SADB_X_AALG_TCP_MD5, 0, NULL, 0, 0, NULL, 0, 0) < 0) + return (-1); + if (pfkey_reply(fd, NULL) < 0) + return (-1); +@@ -511,37 +519,37 @@ + return (0); + } +=20 ++#define TCP_SIG_SPI 0x1000 + int + pfkey_md5sig_establish(struct peer *p) + { + sleep(1); +=20 +- if (!p->auth.spi_out) +- if (pfkey_sa_add(&p->auth.local_addr, &p->conf.remote_addr, +- p->conf.auth.md5key_len, p->conf.auth.md5key, +- &p->auth.spi_out) =3D=3D -1) +- return (-1); +- if (!p->auth.spi_in) +- if (pfkey_sa_add(&p->conf.remote_addr, &p->auth.local_addr, +- p->conf.auth.md5key_len, p->conf.auth.md5key, +- &p->auth.spi_in) =3D=3D -1) +- return (-1); ++ p->auth.spi_out =3D htonl(TCP_SIG_SPI); ++ if (pfkey_sa_add(&p->auth.local_addr, &p->conf.remote_addr, ++ p->conf.auth.md5key_len, p->conf.auth.md5key, ++ &p->auth.spi_out) =3D=3D -1) ++ return (-1); ++ p->auth.spi_in =3D htonl(TCP_SIG_SPI); ++ if (pfkey_sa_add(&p->conf.remote_addr, &p->auth.local_addr, ++ p->conf.auth.md5key_len, p->conf.auth.md5key, ++ &p->auth.spi_out) =3D=3D -1) ++ return (-1); +=20 + p->auth.established =3D 1; + return (0); + } ++#undef TCP_SIG_SPI +=20 + int + pfkey_md5sig_remove(struct peer *p) + { +- if (p->auth.spi_out) +- if (pfkey_sa_remove(&p->auth.local_addr, &p->conf.remote_addr, +- &p->auth.spi_out) =3D=3D -1) +- return (-1); +- if (p->auth.spi_in) +- if (pfkey_sa_remove(&p->conf.remote_addr, &p->auth.local_addr, +- &p->auth.spi_in) =3D=3D -1) +- return (-1); ++ if (pfkey_sa_remove(&p->auth.local_addr, &p->conf.remote_addr, ++ &p->auth.spi_out) =3D=3D -1) ++ return (-1); ++ if (pfkey_sa_remove(&p->conf.remote_addr, &p->auth.local_addr, ++ &p->auth.spi_in) =3D=3D -1) ++ return (-1); +=20 + p->auth.established =3D 0; + return (0); +@@ -550,6 +558,7 @@ + int + pfkey_ipsec_establish(struct peer *p) + { ++#if 0 + uint8_t satype =3D SADB_SATYPE_ESP; +=20 + switch (p->auth.method) { +@@ -621,6 +630,9 @@ +=20 + p->auth.established =3D 1; + return (0); ++#else ++ return (-1); ++#endif + } +=20 + int +@@ -660,6 +672,7 @@ + break; + } +=20 ++#if 0 + if (pfkey_flow(fd, satype, SADB_X_DELFLOW, IPSP_DIRECTION_OUT, + &p->auth.local_addr, &p->conf.remote_addr, 0, BGP_PORT) < 0) + return (-1); +@@ -681,6 +694,7 @@ + if (pfkey_flow(fd, satype, SADB_X_DELFLOW, IPSP_DIRECTION_IN, + &p->conf.remote_addr, &p->auth.local_addr, BGP_PORT, 0) < 0) + return (-1); ++#endif + if (pfkey_reply(fd, NULL) < 0) + return (-1); +=20 +@@ -715,9 +729,7 @@ + int + pfkey_remove(struct peer *p) + { +- if (!p->auth.established) +- return (0); +- else if (p->auth.method =3D=3D AUTH_MD5SIG) ++ if (p->auth.method =3D=3D AUTH_MD5SIG) + return (pfkey_md5sig_remove(p)); + else + return (pfkey_ipsec_remove(p)); +@@ -730,11 +742,9 @@ if (errno =3D=3D EPROTONOSUPPORT) { log_warnx("PF_KEY not available, disabling ipsec"); sysdep->no_pfkey =3D 1; diff --git a/files/patch-bgpd_session.c b/files/patch-bgpd_session.c index d043c44..66c05a9 100644 =2D-- a/files/patch-bgpd_session.c +++ b/files/patch-bgpd_session.c @@ -123,7 +123,7 @@ diff -u -p -r1.1.1.8 -r1.13 + int s; + + /* Check if TCP_MD5SIG is supported. */ =2D+ s =3D socket(PF_LOCAL, SOCK_STREAM, 0); ++ s =3D socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); + if (s < 0) + fatal("socket open for TCP_MD5SIG check"); + opt =3D TF_SIGNATURE; --=-=-= And here's the diff between my final version of the FreeBSD port (above) and the original pfsense port: --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=fbsd-openbgpd-port-interdiff.patch Content-Transfer-Encoding: quoted-printable commit 0683cf3740e8971be752a8b6e8d67eac5903e9c6 Author: Antoine Beaupr=C3=A9 Date: Thu Nov 28 14:24:02 2013 -0500 minimise changes with existing FreeBSD port diff --git a/Makefile b/Makefile index 205ae89..5c0513a 100755 =2D-- a/Makefile +++ b/Makefile @@ -16,16 +16,6 @@ COMMENT=3D Free implementation of the Border Gateway Pro= tocol, Version 4 =20 CONFLICTS=3D zebra-[0-9]* quagga-[0-9]* =20 =2DOPTIONS_DEFINE=3D IPV6LLPEER =2DOPTIONS_DEFAULT=3DIPV6LLPEER =2DIPV6LLPEER_DESC=3DSupport nexthop using IPv6 link-local address =2D =2D.include =2D =2D.if ${OSVERSION} < 700000 =2DBROKEN=3D does not build =2D.endif =2D WRKSRC=3D ${WRKDIR} MANCOMPRESSED=3D yes USE_RC_SUBR=3D ${PORTNAME} @@ -37,7 +27,13 @@ GROUPS=3D _bgpd MAN5=3D bgpd.conf.5 MAN8=3D bgpctl.8 bgpd.8 =20 =2D.if !defined(WITHOUT_IPV6LLPEER) +OPTIONS_DEFINE=3D IPV6LLPEER +OPTIONS_DEFAULT=3DIPV6LLPEER +IPV6LLPEER_DESC=3DSupport nexthop using IPv6 link-local address + +.include + +.if ${PORT_OPTIONS:MIPV6LLPEER} MAKE_ARGS=3D -DIPV6_LINKLOCAL_PEER .endif =20 @@ -47,7 +43,4 @@ post-patch: ${WRKSRC}/bgpd/bgpd.conf.5 \ ${WRKSRC}/bgpctl/bgpctl.8 =20 =2Dpost-install: =2D @${CAT} ${PKGMESSAGE} =2D =2D.include +.include --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This was done to avoid introducing unnecessary changes into the port. I confirm the port works with or without that patch, however, so I am not sure it is necessary. Last thoughts before I file that pr? A. =2D-=20 C'est trop facile quand les guerres sont finies D'aller gueuler que c'=C3=A9tait la derni=C3=A8re Amis bourgeois vous me faites envie Ne voyez vous pas donc point vos cimeti=C3=A8res? - Jaques Brel --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSl5n/AAoJEHkhUlJ7dZIeoBwP/3ROOOwyBMJEswUbN60js46S KM9W5vryPul8EK/YxpttBkLVEQTaTyT2+xYxVlB56YDWwBWfIjs1cQT8w8wnNvRD w006HmpH+y3UIn6nRzg+f57nYnSyE827Y9MbHYBNzLV6wBWlTzfRH28XNzAvd5jp hm/VNQtDDeyuaCyqjCO1KAps+R0tz5cVEbZIUq9qT6xqUt1fRZfogzaSKeWx2mR7 zvEm59jHUBSaRSiQQ12Xjn1KMtRWWg1N1RaJKWs9GqCO6q8MbBg/P018SOJE3eRE 73UcYKWOIYEqQzeDGppE912Y5ogUzS6BeXnmtmQodRo986faYYpWUshqr+sBoNIx jvdsXu5WRsUHbPAj7F5dMEcIkqGd3BAPvBl06jsXFG4mWGeNV1ZBLedNiY6g4Ev8 YJnSXVG/AfERlmsvRUKjYke4Of4wb2zy+QShSc3vx2TMiROniGSUGYEzPUUelFaZ A0cWYd7GoBojs9EBTUp10G9aJA7xsvrAdfVY9aOP2aP0TKOEtAKPRf0dh5Qyz9nU vyI8RWSetSK+bZvvToeZy4ko1WMkwO5rEn6rGRwwuBFHsV7PefOqOzzhXyhxZQug O4/8PWy75C1UWC71ZRGlRQLdfFvQdj+uXsesYMYTbNDJQRjU8yvlXpHjY/Uubuak 89fEEeRtmxUYOPLdiWOh =zLkC -----END PGP SIGNATURE----- --==-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 28 20:35:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2578942 for ; Thu, 28 Nov 2013 20:35:50 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B38FA1371 for ; Thu, 28 Nov 2013 20:35:50 +0000 (UTC) Received: from [192.168.1.102] (p508F1261.dip0.t-ipconnect.de [80.143.18.97]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 71B151C0C0692 for ; Thu, 28 Nov 2013 21:35:47 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ip_output()/if_output() behaviour Message-Id: Date: Thu, 28 Nov 2013 21:35:46 +0100 To: "freebsd-net@freebsd.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 20:35:51 -0000 Dear all, I'm investigating a problem and need to understand the behaviour of ip_output(). Is it correct that if ip_output() returns an non-zero error, the corresponding packet was never sent? In the SCTP stack we assume this, but it seems that at least the em and the igb driver might return an error from igb_mq_start_locked(), for example, but have accepted the packet. Before digging further, I would like to know what the intended behaviour of ip_output() is. Thanks in advance Michael From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 02:54:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FE347FC for ; Fri, 29 Nov 2013 02:54:07 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C39C316B4 for ; Fri, 29 Nov 2013 02:54:06 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so9956961qen.33 for ; Thu, 28 Nov 2013 18:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l7bXGn4RWCL9aJDBclDTsVV5YTeEqUzatdpYX93lqVU=; b=IjKKIdDf+8u+15GcsQ1QqKgRgQii2T46wpp/50e7HMZmrIY6atOaidn5X1v0KlvN5B V/pd298Lg2hQJNceulS0ljPyPUvnMc8fK7GO987CCWrwJY8PIL1bgQCOWOloJKNW2W5U dyW5oGf3rZAD9jjrG1vTaIc17xrdWhFEroRhK2MhjCkqTD7Zj/Szl8ezE9O5Jw+XJTXw g1ilKLR8W+sjtBxi95RnjgHEvqzgK9+VcYqa6mYHvXMN/txP4mp+YRxSnV9WrTUZUK5o bEbUmWcuNsjEI34kXtPS5XpB0pNjyXNNlLegtgD6SDsyjffNNJurZSDDdsnuvRTQn0cl kSUw== MIME-Version: 1.0 X-Received: by 10.224.64.196 with SMTP id f4mr46775344qai.55.1385693645882; Thu, 28 Nov 2013 18:54:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 28 Nov 2013 18:54:05 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Nov 2013 18:54:05 -0800 X-Google-Sender-Auth: NMQInoVflg0HIHYQkEjTSakV1aM Message-ID: Subject: Re: ip_output()/if_output() behaviour From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 02:54:07 -0000 On 28 November 2013 12:35, Michael Tuexen wrote: > Dear all, > > I'm investigating a problem and need to understand the behaviour > of ip_output(). Is it correct that if ip_output() returns an > non-zero error, the corresponding packet was never sent? > In the SCTP stack we assume this, but it seems that at least > the em and the igb driver might return an error from > igb_mq_start_locked(), for example, but have accepted the packet. Which error(s) ? > Before digging further, I would like to know what the intended > behaviour of ip_output() is. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 09:42:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56F3DCFD; Fri, 29 Nov 2013 09:42:42 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E110A1A38; Fri, 29 Nov 2013 09:42:41 +0000 (UTC) Received: from [192.168.1.102] (p508F32E7.dip0.t-ipconnect.de [80.143.50.231]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 826DE1C0C0692; Fri, 29 Nov 2013 10:42:39 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ip_output()/if_output() behaviour From: Michael Tuexen In-Reply-To: Date: Fri, 29 Nov 2013 10:42:38 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 09:42:42 -0000 On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: > On 28 November 2013 12:35, Michael Tuexen > wrote: >> Dear all, >> >> I'm investigating a problem and need to understand the behaviour >> of ip_output(). Is it correct that if ip_output() returns an >> non-zero error, the corresponding packet was never sent? >> In the SCTP stack we assume this, but it seems that at least >> the em and the igb driver might return an error from >> igb_mq_start_locked(), for example, but have accepted the packet. > > Which error(s) ? ENOBUFS, but does it matter? What is the correct reaction to ip_output() returning an error? The SCTP stack assumes that the packet was not put on the wire. With the current version of the igb driver we are wrong. igb_mq_start() might return an error, even if the packets was enqueued successfully (in case igb_mq_start_locked() fails). But the SCTP stacks assumes in general that if ip_output() returns an error, the packet didn't make it out. Best regards Michael > >> Before digging further, I would like to know what the intended >> behaviour of ip_output() is. > > > -adrian > From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 11:44:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52C2088B; Fri, 29 Nov 2013 11:44:58 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08B4010B1; Fri, 29 Nov 2013 11:44:57 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATBikv0039170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 03:44:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52987E27.10503@freebsd.org> Date: Fri, 29 Nov 2013 19:44:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Tuexen , Adrian Chadd Subject: Re: ip_output()/if_output() behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 11:44:58 -0000 On 11/29/13, 5:42 PM, Michael Tuexen wrote: > On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: > >> On 28 November 2013 12:35, Michael Tuexen >> wrote: >>> Dear all, >>> >>> I'm investigating a problem and need to understand the behaviour >>> of ip_output(). Is it correct that if ip_output() returns an >>> non-zero error, the corresponding packet was never sent? >>> In the SCTP stack we assume this, but it seems that at least >>> the em and the igb driver might return an error from >>> igb_mq_start_locked(), for example, but have accepted the packet. >> Which error(s) ? > ENOBUFS, but does it matter? What is the correct reaction to > ip_output() returning an error? The SCTP stack assumes that the > packet was not put on the wire. With the current version of the > igb driver we are wrong. igb_mq_start() might return an error, > even if the packets was enqueued successfully (in case > igb_mq_start_locked() fails). > > But the SCTP stacks assumes in general that if ip_output() returns > an error, the packet didn't make it out. From my memory it's always been the case that you really have little idea if the packet makes it out onto the wire or not. In the past it's been the case that an error indicates that it probably DIDN'T make it out, but the converse is not true.. NO error is not an indication of success. I'm surprised that you could get an error when it was broadcast however.. that is counter to the last 30 years of behaviour. > > Best regards > Michael >>> Before digging further, I would like to know what the intended >>> behaviour of ip_output() is. >> >> -adrian >> > _______________________________________________ > 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 Nov 29 12:04:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB95B2A0; Fri, 29 Nov 2013 12:04:17 +0000 (UTC) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E20A11E8; Fri, 29 Nov 2013 12:04:17 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id ma3so14259713pbc.26 for ; Fri, 29 Nov 2013 04:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=CPiWwDJfXaT9X6k4gc9+XeP9XZ7FCUEwK9RI9ulEeHo=; b=f+i94GeALnOCU/24hHWiuYggijU6nnh0+rpYqWzykfeCqmYpS1sIhFko/48vlznuuh 8joAmvFqn9jRKg3vFnFI49JETnwEEl4mwguHJ/f6jiAMo2Vh2JeCcEw0EhM9AFponIKy SxcGGg12+tjpz1qu+oLgjk+HptPeCNq+Z+hQO0HvAhfO4dJGUMgBi5HZWl56m9dm8d8+ A8izEiFIOTi06/xeD0MaPx9l6mb29S9tJ35qunskP+msBPVzKj2NL/uBFOYgilJWfVII uJFEjLefMMg2+aOOuCRBGuCbxdUsS1FpWPOcTizAD5BfU1Sqi27cRgKwBLo2VrXdZjLx /DNg== MIME-Version: 1.0 X-Received: by 10.66.235.106 with SMTP id ul10mr51271947pac.19.1385726648578; Fri, 29 Nov 2013 04:04:08 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 04:04:08 -0800 (PST) Date: Fri, 29 Nov 2013 13:04:08 +0100 X-Google-Sender-Auth: G_-4mzBOTmt4WcmGtCWd4q2Li_I Message-ID: Subject: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net , "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 12:04:17 -0000 Hello, since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to share the same port and possibly listening ip, you would expect if you bind two daemon with such options to same port to see the same traffic on both! This is not the case today. Only multicast sockets seem to have the behaviour of broadcasting the data to all sockets sharing the same properties through these options! The patch at [1] implements/corrects the behaviour for UDP sockets. Is there anything to be corrected in that patch? Why it has not been provided there before? Can it be committed to the tree? Any extra security checks for jails needed there? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 12:19:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94C4269E; Fri, 29 Nov 2013 12:19:50 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF41C12A9; Fri, 29 Nov 2013 12:19:49 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ec20so6846952lab.10 for ; Fri, 29 Nov 2013 04:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=77XKm/7UVD72Kg0lAy4x0DO+xI0mfk3HqREjClEYdCY=; b=SCAeg4K92n6prQh4mlVZdUoGNPrYUC6mn33AfaG6YwiYLoaUKHUPm/uI3P7BDAsxS6 WkQxbo49Xfn02D94BdBsna39NNeDFcYb+SP2PkR9zVZ1XCu16pFj+/45ykE30C6Gqdjn WktD5SJ/VCnu/gt3nFPiAwdG8ZoygE5FTpk+zVobNu0XVi9EAI+tUXO2hZr/39YP7pM6 EmL5Wg5o4o0StNzGBtLmUjSll+iBBWe8ADSe+iDgKxPpS39O0A5UUazC2wNKe00ICCuA VO9bquHet+nqrLc9RkLYuUipG/ZSxSNqSU55itBEZqlMIhhTMexF571YS9anMar20Awk ZM6Q== MIME-Version: 1.0 X-Received: by 10.112.52.33 with SMTP id q1mr1463243lbo.30.1385727587656; Fri, 29 Nov 2013 04:19:47 -0800 (PST) Received: by 10.112.140.132 with HTTP; Fri, 29 Nov 2013 04:19:47 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Nov 2013 13:19:47 +0100 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Daniel Nebdal To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 12:19:50 -0000 On Fri, Nov 29, 2013 at 1:04 PM, Ermal Lu=E7i wrote: > Hello, > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > share the same port and possibly listening ip, you would expect if you bi= nd > two daemon with such options to same port to see the same traffic on both= ! > > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the dat= a > to all sockets sharing the same properties through these options! > > The patch at [1] implements/corrects the behaviour for UDP sockets. > Is there anything to be corrected in that patch? > Why it has not been provided there before? > Can it be committed to the tree? > Any extra security checks for jails needed there? > > > [1] > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/= udp_SO_REUSEADDR%2BPORT.diff > > -- > Ermal I understood it as working sort of like for TCP, where packages from a given remote host+port all end up at exactly one of the local sockets? If the idea is to split the workload over multiple threads holding their own sockets listening to the same interface+port, wouldn't sending all packets to all sockets all the time be kind of counterproductive? Of course, I haven't actually used it much; I might be wrong. --=20 Daniel Nebdal From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 12:31:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68D14B04 for ; Fri, 29 Nov 2013 12:31:33 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6731398 for ; Fri, 29 Nov 2013 12:31:32 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3dWFLG62h3z7rH8 for ; Fri, 29 Nov 2013 12:25:42 +0000 (UTC) Message-ID: <529887EF.8090009@rewt.org.uk> Date: Fri, 29 Nov 2013 12:26:23 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 12:31:33 -0000 On 29/11/2013 12:04, Ermal Luįi wrote: > Hello, > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > share the same port and possibly listening ip, you would expect if you bind > two daemon with such options to same port to see the same traffic on both! > > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the data > to all sockets sharing the same properties through these options! > > The patch at [1] implements/corrects the behaviour for UDP sockets. > Is there anything to be corrected in that patch? > Why it has not been provided there before? > Can it be committed to the tree? > Any extra security checks for jails needed there? > > > [1] > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff > Have you added support for TCP as well? IMO the correct behaviour is the functioning of the Linux support added in 3.9 (https://lwn.net/Articles/542629/) - TCP would be much more useful than UDP (think high load web servers etc) I'm not sure what the correct handling would be for UDP though, is it not inefficient to send copies of the same data to all listeners? Would round-robin distribution be usable? TCP I guess doesn't matter as the listener can just accept(). From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 13:11:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B1E46B0; Fri, 29 Nov 2013 13:11:27 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3005161A; Fri, 29 Nov 2013 13:11:26 +0000 (UTC) Received: from [192.168.1.102] (p508F32E7.dip0.t-ipconnect.de [80.143.50.231]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 36DFF1C0C0692; Fri, 29 Nov 2013 14:11:24 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ip_output()/if_output() behaviour From: Michael Tuexen In-Reply-To: <52987E27.10503@freebsd.org> Date: Fri, 29 Nov 2013 14:11:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B948FD5-0597-4F7E-93CD-D37F409F3FA1@lurchi.franken.de> References: <52987E27.10503@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1510) Cc: "freebsd-net@freebsd.org list" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 13:11:27 -0000 On Nov 29, 2013, at 12:44 PM, Julian Elischer = wrote: > On 11/29/13, 5:42 PM, Michael Tuexen wrote: >> On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: >>=20 >>> On 28 November 2013 12:35, Michael Tuexen >>> wrote: >>>> Dear all, >>>>=20 >>>> I'm investigating a problem and need to understand the behaviour >>>> of ip_output(). Is it correct that if ip_output() returns an >>>> non-zero error, the corresponding packet was never sent? >>>> In the SCTP stack we assume this, but it seems that at least >>>> the em and the igb driver might return an error from >>>> igb_mq_start_locked(), for example, but have accepted the packet. >>> Which error(s) ? >> ENOBUFS, but does it matter? What is the correct reaction to >> ip_output() returning an error? The SCTP stack assumes that the >> packet was not put on the wire. With the current version of the >> igb driver we are wrong. igb_mq_start() might return an error, >> even if the packets was enqueued successfully (in case >> igb_mq_start_locked() fails). >>=20 >> But the SCTP stacks assumes in general that if ip_output() returns >> an error, the packet didn't make it out. > =46rom my memory it's always been the case that you really have little > idea if the packet makes it out onto the wire or not. > In the past it's been the case that an error indicates that it = probably DIDN'T make it out, but > the converse is not true.. NO error is not an indication of success. I understand that if the call is successful, I don't know if it makes it out. I'm only thinking about the case an error is indicated. I have * either remove the functionality from SCTP to take the return code of ip_output() into account. * or fix the drivers to not return an error if the packet was queued. I looked at the IP layer code and it seems that an error is only indicated if the packet is dropped by the stack. So basically it seems to be a question of if_output()... > I'm surprised that you could get an error when it was broadcast = however.. that is counter > to the last 30 years of behaviour. This sounds more like changing the driver... Do we have specified how if_transmit() behaves? Best regards Michael >=20 >=20 >>=20 >> Best regards >> Michael >>>> Before digging further, I would like to know what the intended >>>> behaviour of ip_output() is. >>>=20 >>> -adrian >>>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >>=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 14:06:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 219C4204; Fri, 29 Nov 2013 14:06:11 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9EC718A8; Fri, 29 Nov 2013 14:06:10 +0000 (UTC) Received: from [192.168.1.102] (p508F32E7.dip0.t-ipconnect.de [80.143.50.231]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8F54C1C0C0695; Fri, 29 Nov 2013 15:06:08 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ip_output()/if_output() behaviour From: Michael Tuexen In-Reply-To: <52987E27.10503@freebsd.org> Date: Fri, 29 Nov 2013 15:06:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> References: <52987E27.10503@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1510) Cc: "freebsd-net@freebsd.org list" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 14:06:11 -0000 On Nov 29, 2013, at 12:44 PM, Julian Elischer = wrote: > On 11/29/13, 5:42 PM, Michael Tuexen wrote: >> On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: >>=20 >>> On 28 November 2013 12:35, Michael Tuexen >>> wrote: >>>> Dear all, >>>>=20 >>>> I'm investigating a problem and need to understand the behaviour >>>> of ip_output(). Is it correct that if ip_output() returns an >>>> non-zero error, the corresponding packet was never sent? >>>> In the SCTP stack we assume this, but it seems that at least >>>> the em and the igb driver might return an error from >>>> igb_mq_start_locked(), for example, but have accepted the packet. >>> Which error(s) ? >> ENOBUFS, but does it matter? What is the correct reaction to >> ip_output() returning an error? The SCTP stack assumes that the >> packet was not put on the wire. With the current version of the >> igb driver we are wrong. igb_mq_start() might return an error, >> even if the packets was enqueued successfully (in case >> igb_mq_start_locked() fails). >>=20 >> But the SCTP stacks assumes in general that if ip_output() returns >> an error, the packet didn't make it out. > =46rom my memory it's always been the case that you really have little > idea if the packet makes it out onto the wire or not. > In the past it's been the case that an error indicates that it = probably DIDN'T make it out, but > the converse is not true.. NO error is not an indication of success. > I'm surprised that you could get an error when it was broadcast = however.. that is counter > to the last 30 years of behaviour. ifnet(9) says: if_transmit() Transmit a packet on an interface or queue it if the = interface is in use. This function will return ENOBUFS if the devices = software and hardware queues are both full. ... So I guess returning ENOBUFS when the packet was queued is wrong... Any comments? Best regards Michael >=20 >=20 >>=20 >> Best regards >> Michael >>>> Before digging further, I would like to know what the intended >>>> behaviour of ip_output() is. >>>=20 >>> -adrian >>>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >>=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 16:14:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08B5797F; Fri, 29 Nov 2013 16:14:35 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1C651F40; Fri, 29 Nov 2013 16:14:34 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATGESWN039922 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 08:14:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5298BD5D.3020203@freebsd.org> Date: Sat, 30 Nov 2013 00:14:21 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ip_output()/if_output() behaviour References: <52987E27.10503@freebsd.org> <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> In-Reply-To: <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org list" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 16:14:35 -0000 On 11/29/13, 10:06 PM, Michael Tuexen wrote: > On Nov 29, 2013, at 12:44 PM, Julian Elischer wrote: > >> On 11/29/13, 5:42 PM, Michael Tuexen wrote: >>> On Nov 29, 2013, at 3:54 AM, Adrian Chadd wrote: >>> >>>> On 28 November 2013 12:35, Michael Tuexen >>>> wrote: >>>>> Dear all, >>>>> >>>>> I'm investigating a problem and need to understand the behaviour >>>>> of ip_output(). Is it correct that if ip_output() returns an >>>>> non-zero error, the corresponding packet was never sent? >>>>> In the SCTP stack we assume this, but it seems that at least >>>>> the em and the igb driver might return an error from >>>>> igb_mq_start_locked(), for example, but have accepted the packet. >>>> Which error(s) ? >>> ENOBUFS, but does it matter? What is the correct reaction to >>> ip_output() returning an error? The SCTP stack assumes that the >>> packet was not put on the wire. With the current version of the >>> igb driver we are wrong. igb_mq_start() might return an error, >>> even if the packets was enqueued successfully (in case >>> igb_mq_start_locked() fails). >>> >>> But the SCTP stacks assumes in general that if ip_output() returns >>> an error, the packet didn't make it out. >> From my memory it's always been the case that you really have little >> idea if the packet makes it out onto the wire or not. >> In the past it's been the case that an error indicates that it probably DIDN'T make it out, but >> the converse is not true.. NO error is not an indication of success. >> I'm surprised that you could get an error when it was broadcast however.. that is counter >> to the last 30 years of behaviour. > ifnet(9) says: > > if_transmit() > Transmit a packet on an interface or queue it if the interface is > in use. This function will return ENOBUFS if the devices software > and hardware queues are both full. ... > > So I guess returning ENOBUFS when the packet was queued is wrong... I think it is. ENOBUFS means "I couldn't proceed due to no buffers" not "I used up the last one on this operation". From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 16:15:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 922E8A3F; Fri, 29 Nov 2013 16:15:10 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6144D1F4D; Fri, 29 Nov 2013 16:15:10 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rATGF6LR039929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 08:15:08 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5298BD83.2090601@freebsd.org> Date: Sat, 30 Nov 2013 00:14:59 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , "freebsd-current@freebsd.org" Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 16:15:10 -0000 On 11/29/13, 8:04 PM, Ermal Luįi wrote: > Hello, > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to > share the same port and possibly listening ip, you would expect if you bind > two daemon with such options to same port to see the same traffic on both! this is not how I interpret it.. I presume it is is to allow two OUTGOING sessions from the same source. > > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the data > to all sockets sharing the same properties through these options! > > The patch at [1] implements/corrects the behaviour for UDP sockets. > Is there anything to be corrected in that patch? > Why it has not been provided there before? > Can it be committed to the tree? > Any extra security checks for jails needed there? > > > [1] > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff > From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 16:31:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D33BE79 for ; Fri, 29 Nov 2013 16:31:16 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id C7282103E for ; Fri, 29 Nov 2013 16:31:15 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3dWLmn1fcnz7rH8 for ; Fri, 29 Nov 2013 16:30:33 +0000 (UTC) Message-ID: <5298C152.4030209@rewt.org.uk> Date: Fri, 29 Nov 2013 16:31:14 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour References: <5298BD83.2090601@freebsd.org> In-Reply-To: <5298BD83.2090601@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 16:31:16 -0000 On 29/11/2013 16:14, Julian Elischer wrote: > On 11/29/13, 8:04 PM, Ermal Luįi wrote: >> Hello, >> >> since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to >> share the same port and possibly listening ip, you would expect if you >> bind >> two daemon with such options to same port to see the same traffic on >> both! > this is not how I interpret it.. I presume it is is to allow two > OUTGOING sessions from the same source. >> No, it is to allow multiple listeners bound to the same ip:port. This already works in FreeBSD but the kernel does not distribute incoming connections to the different threads, rather just the last one that called listen(). See the article in my previous post for how it should be implemented... >> This is not the case today. >> Only multicast sockets seem to have the behaviour of broadcasting the >> data >> to all sockets sharing the same properties through these options! >> >> The patch at [1] implements/corrects the behaviour for UDP sockets. >> Is there anything to be corrected in that patch? >> Why it has not been provided there before? >> Can it be committed to the tree? >> Any extra security checks for jails needed there? >> >> >> [1] >> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff >> >> > > _______________________________________________ > 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 Nov 29 17:18:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EDA2B77 for ; Fri, 29 Nov 2013 17:18:37 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32A3512A2 for ; Fri, 29 Nov 2013 17:18:37 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id w10so14134058pde.35 for ; Fri, 29 Nov 2013 09:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Ka6ifvySYjEuUyGR7ROx44fNG14SfurkPH6NAisZE8=; b=iyXwCznWUW76dPHjKiPjhT6mnzuMFvLzUP5o2SQtLXAz9ZeBnm36iwQO9el+Kh0SYf fySYoHNwFXI5+y5nCSQ/v+tsxsCXd2tpGEMwIFheW2z+qGoHeFqggm59kGH5xbLFEK4Y d+iKHxEBdE6OTpDcOTmyUlowe7Xp9a14APz3v3UvKGrG6ghHKn9Ig7rnJjajAGidvVnW xpjJF/WChFaocQ3WQB6eFylfNz1krc7cNWglUBZ6JNxwz9EGfxWrWPbuV48hfmQ3QnP6 e6nJ2gO+Qn9OYsCHNJvZXSdFRUPqfp+jer/21jtwlbJokX5PT96OJX5TEnezVADEptcd ElqQ== MIME-Version: 1.0 X-Received: by 10.68.196.227 with SMTP id ip3mr17143467pbc.163.1385745516791; Fri, 29 Nov 2013 09:18:36 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 29 Nov 2013 09:18:36 -0800 (PST) In-Reply-To: <5298C152.4030209@rewt.org.uk> References: <5298BD83.2090601@freebsd.org> <5298C152.4030209@rewt.org.uk> Date: Fri, 29 Nov 2013 09:18:36 -0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Oleg Moskalenko To: Joe Holden Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 17:18:37 -0000 Joe is right. I've been watching this feature. It is very important for high-performance media gateways - they use mostly UDP protocol. Linux now has it. I hope FreeBSD will include it, too. One thing that makes it especially useful is that the kernel remembers the networks path (from which remote address to which listening UDP socket) the packets are being delivered. That allows very efficient and simple UDP servers. Currently several sockets can listen on the same local address, but the packets are delivered only to one socket of them. Oleg On Fri, Nov 29, 2013 at 8:31 AM, Joe Holden wrote: > On 29/11/2013 16:14, Julian Elischer wrote: > >> On 11/29/13, 8:04 PM, Ermal Lu=E7i wrote: >> >>> Hello, >>> >>> since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons t= o >>> share the same port and possibly listening ip, you would expect if you >>> bind >>> two daemon with such options to same port to see the same traffic on >>> both! >>> >> this is not how I interpret it.. I presume it is is to allow two >> OUTGOING sessions from the same source. >> >>> >>> No, it is to allow multiple listeners bound to the same ip:port. This > already works in FreeBSD but the kernel does not distribute incoming > connections to the different threads, rather just the last one that calle= d > listen(). > > See the article in my previous post for how it should be implemented... > > > > This is not the case today. >>> Only multicast sockets seem to have the behaviour of broadcasting the >>> data >>> to all sockets sharing the same properties through these options! >>> >>> The patch at [1] implements/corrects the behaviour for UDP sockets. >>> Is there anything to be corrected in that patch? >>> Why it has not been provided there before? >>> Can it be committed to the tree? >>> Any extra security checks for jails needed there? >>> >>> >>> [1] >>> https://github.com/pfsense/pfsense-tools/blob/master/ >>> patches/RELENG_10_0/udp_SO_REUSEADDR%2BPORT.diff >>> >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 17:24:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6474DE4; Fri, 29 Nov 2013 17:24:16 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 357C212F2; Fri, 29 Nov 2013 17:24:15 +0000 (UTC) Received: from [192.168.1.102] (p508F32E7.dip0.t-ipconnect.de [80.143.50.231]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E91891C0C0692; Fri, 29 Nov 2013 18:24:12 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: A small fix for if_em.c, if_igb.c, if_ixgbe.c Date: Fri, 29 Nov 2013 18:24:12 +0100 Message-Id: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> To: "freebsd-net@freebsd.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 17:24:16 -0000 Dear all, ifnet(9) says regarding if_transmit(): Transmit a packet on an interface or queue it if the interface is in use. This function will return ENOBUFS if the devices software and hardware queues are both full. The drivers for em, igb and ixgbe might also return an error even in the case the packet was enqueued. The attached patches fix this issue. Any comments? Jack: What do you think? Would you prefer to commit the fix if you think it is acceptable? Best regards Michael [bsd5:~/head/sys/dev] tuexen% svn diff -x -p Index: e1000/if_em.c =================================================================== --- e1000/if_em.c (revision 258746) +++ e1000/if_em.c (working copy) @@ -930,7 +930,7 @@ em_mq_start_locked(struct ifnet *ifp, struct tx_ri /* Process the queue */ while ((next = drbr_peek(ifp, txr->br)) != NULL) { - if ((err = em_xmit(txr, &next)) != 0) { + if (em_xmit(txr, &next) != 0) { if (next == NULL) drbr_advance(ifp, txr->br); else @@ -957,7 +957,7 @@ em_mq_start_locked(struct ifnet *ifp, struct tx_ri em_txeof(txr); if (txr->tx_avail < EM_MAX_SCATTER) ifp->if_drv_flags |= IFF_DRV_OACTIVE; - return (err); + return (0); } /* Index: e1000/if_igb.c =================================================================== --- e1000/if_igb.c (revision 258746) +++ e1000/if_igb.c (working copy) @@ -192,7 +192,7 @@ static int igb_suspend(device_t); static int igb_resume(device_t); #ifndef IGB_LEGACY_TX static int igb_mq_start(struct ifnet *, struct mbuf *); -static int igb_mq_start_locked(struct ifnet *, struct tx_ring *); +static void igb_mq_start_locked(struct ifnet *, struct tx_ring *); static void igb_qflush(struct ifnet *); static void igb_deferred_mq_start(void *, int); #else @@ -989,31 +989,31 @@ igb_mq_start(struct ifnet *ifp, struct mbuf *m) if (err) return (err); if (IGB_TX_TRYLOCK(txr)) { - err = igb_mq_start_locked(ifp, txr); + igb_mq_start_locked(ifp, txr); IGB_TX_UNLOCK(txr); } else taskqueue_enqueue(que->tq, &txr->txq_task); - return (err); + return (0); } -static int +static void igb_mq_start_locked(struct ifnet *ifp, struct tx_ring *txr) { struct adapter *adapter = txr->adapter; struct mbuf *next; - int err = 0, enq = 0; + int enq = 0; IGB_TX_LOCK_ASSERT(txr); if (((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) || adapter->link_active == 0) - return (ENETDOWN); + return; /* Process the queue */ while ((next = drbr_peek(ifp, txr->br)) != NULL) { - if ((err = igb_xmit(txr, &next)) != 0) { + if (igb_xmit(txr, &next) != 0) { if (next == NULL) { /* It was freed, move forward */ drbr_advance(ifp, txr->br); @@ -1045,7 +1045,7 @@ igb_mq_start_locked(struct ifnet *ifp, struct tx_r igb_txeof(txr); if (txr->tx_avail <= IGB_MAX_SCATTER) txr->queue_status |= IGB_QUEUE_DEPLETED; - return (err); + return; } /* Index: ixgbe/ixgbe.c =================================================================== --- ixgbe/ixgbe.c (revision 258746) +++ ixgbe/ixgbe.c (working copy) @@ -107,7 +107,7 @@ static void ixgbe_start(struct ifnet *); static void ixgbe_start_locked(struct tx_ring *, struct ifnet *); #else /* ! IXGBE_LEGACY_TX */ static int ixgbe_mq_start(struct ifnet *, struct mbuf *); -static int ixgbe_mq_start_locked(struct ifnet *, struct tx_ring *); +static void ixgbe_mq_start_locked(struct ifnet *, struct tx_ring *); static void ixgbe_qflush(struct ifnet *); static void ixgbe_deferred_mq_start(void *, int); #endif /* IXGBE_LEGACY_TX */ @@ -831,35 +831,35 @@ ixgbe_mq_start(struct ifnet *ifp, struct mbuf *m) if (err) return (err); if (IXGBE_TX_TRYLOCK(txr)) { - err = ixgbe_mq_start_locked(ifp, txr); + ixgbe_mq_start_locked(ifp, txr); IXGBE_TX_UNLOCK(txr); } else taskqueue_enqueue(que->tq, &txr->txq_task); - return (err); + return (0); } -static int +static void ixgbe_mq_start_locked(struct ifnet *ifp, struct tx_ring *txr) { struct adapter *adapter = txr->adapter; struct mbuf *next; - int enqueued = 0, err = 0; + int enqueued = 0; if (((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) || adapter->link_active == 0) - return (ENETDOWN); + return; /* Process the queue */ #if __FreeBSD_version < 901504 next = drbr_dequeue(ifp, txr->br); while (next != NULL) { - if ((err = ixgbe_xmit(txr, &next)) != 0) { + if (ixgbe_xmit(txr, &next) != 0) { if (next != NULL) - err = drbr_enqueue(ifp, txr->br, next); + drbr_enqueue(ifp, txr->br, next); #else while ((next = drbr_peek(ifp, txr->br)) != NULL) { - if ((err = ixgbe_xmit(txr, &next)) != 0) { + if (ixgbe_xmit(txr, &next) != 0) { if (next == NULL) { drbr_advance(ifp, txr->br); } else { @@ -890,7 +890,7 @@ ixgbe_mq_start_locked(struct ifnet *ifp, struct tx if (txr->tx_avail < IXGBE_TX_CLEANUP_THRESHOLD) ixgbe_txeof(txr); - return (err); + return; } /* From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 17:28:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C26D1FD9 for ; Fri, 29 Nov 2013 17:28:16 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3621318 for ; Fri, 29 Nov 2013 17:28:16 +0000 (UTC) Received: from [192.168.0.4] (unknown [195.91.216.248]) by mail.euro-comm.net (Postfix) with ESMTPSA id 87A8E6BD5E3 for ; Fri, 29 Nov 2013 21:28:08 +0400 (MSK) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Victor Gamov In-Reply-To: Date: Fri, 29 Nov 2013 21:27:59 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5293E3E7.6090604@freebsd.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 17:28:16 -0000 ipfw allow log udp from 192.168.230.9 to 192.168.230.128 dst-port 1234 this rule added to ipfw before ngtee action and I see patched packets at = ipfw now -- its marked as received via vlan999 still. Yes, it's OK. Also, I make 3 actions at ng_patch now: set TTL=3D3 set src_ip=3D192.168.230.9 (vlan333) set dst_ip=3D192.168.230.128 now. But packets still does not exists on vlan333 as outgoing. Any suggestions? Is it possible patched packets silently drops by kernel ? On 26Nov, 2013, at 13:44, Victor Gamov wrote: >=20 > On 26Nov, 2013, at 03:57, Julian Elischer wrote: >=20 >> On 11/24/13, 5:05 AM, Victor Gamov wrote: >>> Hi All >>>=20 >>> I want to get 2 or 3 copies of input packet at my system to resend = it to new destinations. So I prepare following configuration: >>>=20 >>> # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 = in via vlan999 >>>=20 >>> # ngctl mkpeer ipfw: hub 100 hub-in >>> # ngctl name ipfw:100 hub100 >>>=20 >>> # ngctl mkpeer hub100: patch hub100-out1 in >>> # ngctl name hub100:hub100-out1 patch100 >>> # ngctl msg patch100: setconfig '{ count=3D1 csum_flags=3D1 ops=3D[ = { value=3D0xc0a8e680 offset=3D16 length=3D4 mode=3D1 } ] }' >>>=20 >>> Now when I connect to patch:out as >>> # nghook -a patch100: out >>>=20 >>> then I see packets with new IP: >>>=20 >>> 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 >>> 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a >>>=20 >>> Now I want to put this packets back into IP processing to send it to = new destination 192.168.230.128 (0xc0a8e680): >>>=20 >>> # ngctl mkpeer patch100: ip_input out new100_to_dst_1 >>>=20 >>> But packets not shown on outgoing interface: >>>=20 >>> # ifconfig vlan333 >>> vlan333: flags=3D8843 metric = 0 mtu 1500 >>> options=3D103 >>> ether 00:1b:21:5b:7e:e9 >>> inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 >>>=20 >>> # arp 192.168.230.128 >>> ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 = seconds >> I would looking at giving the packet back to the firewall as = suggested.. >>=20 >> netgraph cookie >> Divert packet into netgraph with given cookie. The search = termi- >> nates. If packet is later returned from netgraph it is = either >> accepted or continues with the next rule, depending on >> net.inet.ip.fw.one_pass sysctl variable. >> see ng_ipfw for more details.. >=20 > Yes I read this manuals :-) But I still can't see packets neither at = ipfw nor at outgoing interface. >=20 > net.inet.ip.fw.one_pass: 0 > net.inet.ip.forwarding: 1 >=20 > Is my original idea is correct? -- CU, Victor Gamov From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 17:59:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 490E799C for ; Fri, 29 Nov 2013 17:59:59 +0000 (UTC) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18DDD14CA for ; Fri, 29 Nov 2013 17:59:58 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id um1so14885786pbc.34 for ; Fri, 29 Nov 2013 09:59:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pKqVVysBn4l+j9NkqDgRFfJPrlhXdFJquzctqtecpDA=; b=aecvzXKghpTSYVopeGlqMY52rSNrR0mcp6l/1A7zJD3K50mlZ8k4O5SWlIgvPVIdLc k/gNWr8rUyLV3UUw5smCtsQa1xcFm662tdW+8YXNRHKfI6i5BZCpYaJe64We8bogA1Cv FSTHvZR6R+/THBLRBP6ZMcqhZYzkaKPr9FN+Plvlokr2g5WFdesezeFIC8H9JUrW7xHi aURUiSX8nGXZMiC9NFIgxnLl36ZKaQeFNTM4SWMRpL//CKfonvCDcVSWkXVD+iQsvhv1 p0oHSI3vQO2B64RUm1vG0mBNt4OceCgoWx11stccva4ezOzqrNnXHqSfhf/xz4T6eY6h SOzA== X-Gm-Message-State: ALoCoQmotFV4aP6uxdKVybUTWnuTaxEYXXErag+H+3x3m+0VQgT29MMqChhOl6BxXJUCu91SMct0 X-Received: by 10.68.191.3 with SMTP id gu3mr17101147pbc.142.1385747992101; Fri, 29 Nov 2013 09:59:52 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id pu5sm117393195pac.21.2013.11.29.09.59.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 09:59:51 -0800 (PST) Sender: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Tim Kientzle In-Reply-To: Date: Fri, 29 Nov 2013 09:59:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> References: To: =?windows-1252?Q?Ermal_Lu=E7i?= X-Mailer: Apple Mail (2.1822) Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 17:59:59 -0000 On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > Hello, >=20 > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons = to > share the same port and possibly listening ip =85 These flags are used with TCP-based servers. I=92ve used them to make software upgrades go more smoothly. Without them, the following often happens: * Old server stops. In the process, all of its TCP connections are = closed. * Connections to old server remain in the TCP connection table until the = remote end can acknowledge. * New server starts. * New server tries to open port but fails because that port is =93still = in use=94 by connections in the TCP connection table. With these flags, the new server can open the port even though it is =93still in use=94 by existing connections. > This is not the case today. > Only multicast sockets seem to have the behaviour of broadcasting the = data > to all sockets sharing the same properties through these options! That is what multicast is for. If you want the same data sent to all listeners, then that is multicast behavior and you should be using a multicast socket. > The patch at [1] implements/corrects the behaviour for UDP sockets. You=92re trying to turn all UDP sockets with those options into multicast sockets. If you want a multicast socket, you should ask for one. Tim From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 18:03:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBCFCBC0; Fri, 29 Nov 2013 18:03:20 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE5B1152F; Fri, 29 Nov 2013 18:03:20 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id g10so14184735pdj.17 for ; Fri, 29 Nov 2013 10:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BhNmunVCSddq8mAZO1KhluFZ5x5bdW8igmq/Thl3QqA=; b=budZvJZKK6+pwHXF6TZ7rRu5yVtX3GA0870RoHP6RCSN/zdjWawBWjsPGZX2g8FOUc 3Hm4A/byBEiQZ5r7VhrtfaYn6ZhxUFFftybmZdsx02F4RqjWxb73VRSYocRpepwR2S2z 9qBc6DnuphQ1W+hXt6RmYhwq7tiItEiHv81KwerRCL2HFzZW5WxsSxzPqgg0/9Lx0npU 4jXF9YUPyAzCKExfETq9NjFtAT2tJH51wMjHNhW98NU6maih3xpWa7NOUaigAfxThXXF PGag+safbi6YzYXB2S9L51Qk+13MQnFbD4+ZnGqwrem1PfNw16+20w2adihSn/5B0iaX 3ksA== MIME-Version: 1.0 X-Received: by 10.68.130.72 with SMTP id oc8mr3279709pbb.200.1385748200369; Fri, 29 Nov 2013 10:03:20 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 29 Nov 2013 10:03:20 -0800 (PST) In-Reply-To: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 10:03:20 -0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Oleg Moskalenko To: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:03:21 -0000 Tim, you are wrong. Read what is "multicast" definition, and read how UDP and TCP sockets work in Linux 3.9+ kernels. Oleg . On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote: > > On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > > > Hello, > > > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons t= o > > share the same port and possibly listening ip =85 > > These flags are used with TCP-based servers. > > I=92ve used them to make software upgrades go more smoothly. > Without them, the following often happens: > > * Old server stops. In the process, all of its TCP connections are close= d. > > * Connections to old server remain in the TCP connection table until the > remote end can acknowledge. > > * New server starts. > > * New server tries to open port but fails because that port is =93still i= n > use=94 by connections in the TCP connection table. > > With these flags, the new server can open the port even though > it is =93still in use=94 by existing connections. > > > > This is not the case today. > > Only multicast sockets seem to have the behaviour of broadcasting the > data > > to all sockets sharing the same properties through these options! > > That is what multicast is for. > > If you want the same data sent to all listeners, then > that is multicast behavior and you should be using > a multicast socket. > > > The patch at [1] implements/corrects the behaviour for UDP sockets. > > You=92re trying to turn all UDP sockets with those options > into multicast sockets. > > If you want a multicast socket, you should ask for one. > > Tim > > _______________________________________________ > 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 Nov 29 18:42:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C351A1F; Fri, 29 Nov 2013 18:42:33 +0000 (UTC) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3212F188F; Fri, 29 Nov 2013 18:42:33 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id un15so14942157pbc.13 for ; Fri, 29 Nov 2013 10:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E7rVOHXlcDEbgJykq07xE2JRIgEjpGh4AMC0W1PB8pc=; b=qTeId4+c5RgZhnyQC5UN6ut6WIE94WDdXJF7VcZkp6K548xeEWCmgTfTh27h0waDpp RJiiSFWK7uSg+vJ1l42OXviSxtue5A6bOP4+1tdvWBAT0zTZFcC94Bv7I7FTl6MM97Xm 5h0nh9MqPqYpPRvLpoCBL5KG5R6/TyQHLlOqZJsnvgLQVOiSdnmasWujPO2tu2MVM2+3 VuIOQKZAYuZ0UHymoWHiQmfivCyzyveMrG0Z4oUEAPWRgPuTNi9AZg08wu4woUx2tEOv sTGb7FxlY6Nmqu9H87LQ36iJ/xPvFUC0Q6iRDHjOqr+NPXzWJWHpxz1eunq8mIUSiBY8 NuCQ== MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr7745610pbb.7.1385750552031; Fri, 29 Nov 2013 10:42:32 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:42:31 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:42:31 +0100 X-Google-Sender-Auth: mE1J7-6v6SDPyXbAcvu5LrCfWoY Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:42:33 -0000 Well seems Dragonfly has some version of it already from commit [1]. In FreeBSD there is the framework for this with by defining PCBGROUP. Also the explanation of it at [2] and [3]. It can achieve approximately the same features of SO_RESUSEPORT of linux. The only thing missing is the marketing behind it and i think and better RSS support. By looking at dates the support is there before linux so all you guys looking for it can experiment with it. What i was trying to accomplish was something else from performance improvement and maybe put a sysctl behind it to make it more acceptable.. [1] http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c02= 1abb8197718d7a2d441c9 [2] http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#L51 [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wrote= : > Tim, you are wrong. Read what is "multicast" definition, and read how UDP > and TCP sockets work in Linux 3.9+ kernels. > > Oleg . > > > On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrote= : > >> >> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >> >> > Hello, >> > >> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons = to >> > share the same port and possibly listening ip =85 >> >> These flags are used with TCP-based servers. >> >> I=92ve used them to make software upgrades go more smoothly. >> Without them, the following often happens: >> >> * Old server stops. In the process, all of its TCP connections are >> closed. >> >> * Connections to old server remain in the TCP connection table until the >> remote end can acknowledge. >> >> * New server starts. >> >> * New server tries to open port but fails because that port is =93still = in >> use=94 by connections in the TCP connection table. >> >> With these flags, the new server can open the port even though >> it is =93still in use=94 by existing connections. >> >> >> > This is not the case today. >> > Only multicast sockets seem to have the behaviour of broadcasting the >> data >> > to all sockets sharing the same properties through these options! >> >> That is what multicast is for. >> >> If you want the same data sent to all listeners, then >> that is multicast behavior and you should be using >> a multicast socket. >> >> > The patch at [1] implements/corrects the behaviour for UDP sockets. >> >> You=92re trying to turn all UDP sockets with those options >> into multicast sockets. >> >> If you want a multicast socket, you should ask for one. >> >> Tim >> >> _______________________________________________ >> 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 Fri Nov 29 18:46:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6536CBF0; Fri, 29 Nov 2013 18:46:01 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFF218B3; Fri, 29 Nov 2013 18:46:01 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p10so14223167pdj.4 for ; Fri, 29 Nov 2013 10:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x3/7S+1KdZ4OGCpWIWM1/e7YTV63go6/l/1MGZ+63sk=; b=B/B2pq9DaUPU5dshnxkFLxYgRVlUJ+JXxd+JSLfwjy2hO48Dn/Fyhln5u3std+6kzT LcWzqmpzuoLVtoW6rMqfyrXugu0GdIlsfraZGXqeSKsKll3mGvIUW2Q9eMftcNwpWf1P GNUgXDOKEyvTBoXPvqov2v15rAxgKj8E0aDXGMnDJBsBj4v0HH0YLvy5APILCu9gldAF /D5hEYU5G4uvQinJoryJmH/AW+tTZNpgU3JlLFKDhsNzLV/LuXn0szb8Ty5wleABCjP3 bMPg8O8DFITeN809ZGz+UCirlSkugEJZ7jDIfVPJgfvXnHEfx8xCBeb8Ge0nGAuqroCD c0tQ== MIME-Version: 1.0 X-Received: by 10.66.149.135 with SMTP id ua7mr34022802pab.124.1385750760544; Fri, 29 Nov 2013 10:46:00 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:46:00 -0800 (PST) In-Reply-To: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:46:00 +0100 X-Google-Sender-Auth: siq9dmpzJT8OkeHeH0-FBkIlW1w Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:46:01 -0000 On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle wrote: > > On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > > > Hello, > > > > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons t= o > > share the same port and possibly listening ip =85 > > These flags are used with TCP-based servers. > Every one has its own use-case! > > I=92ve used them to make software upgrades go more smoothly. > Without them, the following often happens: > > * Old server stops. In the process, all of its TCP connections are close= d. > > * Connections to old server remain in the TCP connection table until the > remote end can acknowledge. > > * New server starts. > > * New server tries to open port but fails because that port is =93still i= n > use=94 by connections in the TCP connection table. > > With these flags, the new server can open the port even though > it is =93still in use=94 by existing connections. > > > > This is not the case today. > > Only multicast sockets seem to have the behaviour of broadcasting the > data > > to all sockets sharing the same properties through these options! > > That is what multicast is for. > > Multicast has its defined scope and its applications though i think its interpreting the same socket options and respecting the options for what they should do and how they should behave. > If you want the same data sent to all listeners, then > that is multicast behavior and you should be using > a multicast socket. > > > The patch at [1] implements/corrects the behaviour for UDP sockets. > > You=92re trying to turn all UDP sockets with those options > into multicast sockets. > Not really the idea is how you do support the use case of having two daemons using the same port numbers but speaking different protocols. The best would be to merge these daemons but in the case you cannot there should be some support on it. At the very end there are only 65k ports :). Probably a sysctl for the feature might be a further compromise on it? > > If you want a multicast socket, you should ask for one. > > Tim > > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 18:55:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 022D824F; Fri, 29 Nov 2013 18:55:33 +0000 (UTC) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BADCF193F; Fri, 29 Nov 2013 18:55:32 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id un15so14957353pbc.13 for ; Fri, 29 Nov 2013 10:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HnYU9wbKF43dOnvnPzXcTN3/pwiKZrFFJ7h3JNRL/RM=; b=UY+ppfIe0zsLCwwBaMw19qzGHm7f++ox64n2mleygKZunNjuDmLPFLG02GdsXjh2rD S6e3GykseQNPDtG4co3ox3ZffpmFVwdsS9+4jGVcjDf/IklZcAzLPL9r9HtqDG0XheBw fdsQkbK6kKHgvvFOkv2YyoXuNqE6Q9yonhRlOqV7DLemlNpKT0qp9nrwk013Cwayq74f 3Sndk+XvJd8QWM3AXA2PYZCeYGAF/zmOcU50dK+TE56wtBEjBElyE0u5km9+tmYJ2ZcW 4SwLtBsAV66O/souwna0yzRr6OOxeWrtimCZpSK8W2Bp2ZX4T38dDWVvVkOrgwm09jKW 11Yw== MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr7787198pbb.7.1385751332368; Fri, 29 Nov 2013 10:55:32 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 10:55:32 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 19:55:32 +0100 X-Google-Sender-Auth: t-IdTvNBjHGHoGdxnJt1Fb1cqFc Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:55:33 -0000 Also some discussions and improvements to it. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: > Well seems Dragonfly has some version of it already from commit [1]. > > In FreeBSD there is the framework for this with by defining PCBGROUP. > Also the explanation of it at [2] and [3]. > It can achieve approximately the same features of SO_RESUSEPORT of linux. > The only thing missing is the marketing behind it and i think and better > RSS support. > By looking at dates the support is there before linux so all you guys > looking for it can experiment with it. > > What i was trying to accomplish was something else from performance > improvement and > maybe put a sysctl behind it to make it more acceptable.. > > [1] > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c= 021abb8197718d7a2d441c9 > [2] > http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#L= 51 > [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html > > > On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wro= te: > >> Tim, you are wrong. Read what is "multicast" definition, and read how UD= P >> and TCP sockets work in Linux 3.9+ kernels. >> >> Oleg . >> >> >> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wrot= e: >> >>> >>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>> >>> > Hello, >>> > >>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons >>> to >>> > share the same port and possibly listening ip =85 >>> >>> These flags are used with TCP-based servers. >>> >>> I=92ve used them to make software upgrades go more smoothly. >>> Without them, the following often happens: >>> >>> * Old server stops. In the process, all of its TCP connections are >>> closed. >>> >>> * Connections to old server remain in the TCP connection table until th= e >>> remote end can acknowledge. >>> >>> * New server starts. >>> >>> * New server tries to open port but fails because that port is =93still= in >>> use=94 by connections in the TCP connection table. >>> >>> With these flags, the new server can open the port even though >>> it is =93still in use=94 by existing connections. >>> >>> >>> > This is not the case today. >>> > Only multicast sockets seem to have the behaviour of broadcasting the >>> data >>> > to all sockets sharing the same properties through these options! >>> >>> That is what multicast is for. >>> >>> If you want the same data sent to all listeners, then >>> that is multicast behavior and you should be using >>> a multicast socket. >>> >>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>> >>> You=92re trying to turn all UDP sockets with those options >>> into multicast sockets. >>> >>> If you want a multicast socket, you should ask for one. >>> >>> Tim >>> >>> _______________________________________________ >>> 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 Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 19:01:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFCD94B7; Fri, 29 Nov 2013 19:01:26 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B30CD19A2; Fri, 29 Nov 2013 19:01:26 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id v10so14188062pde.41 for ; Fri, 29 Nov 2013 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7lSjamTqTzVkbRyBYKtnHFq3O97J7a2RyelXxvTR7oA=; b=z+wNaEYrA1hFgrLC+vAQetLZI69F9zgPo1SNXauK9y+NJfEhS3NFTgNDF96PLAHDKt +nIKRCV1nxWAi3kHKkhSp8NYBhwAzLXWprl14jPq9H5jpnd+s8ngVKaBMH6zWEqJgHey 2S9uwT/NFzQpWKbfmqK/L+MNn4t35chH22UZ2oDrToBfsNlFUShngr1TL2ob6DAEG0OC 9woYGE/cz3Pglu99oJW1jdpRrD/qE9QzG6q0J1wZ2XlvuVBqeP26BT+zsxZhQERXgECG jGLBcxLoszHqoMNWRF+KVMpHIt88fUdXSwWLBBQTLi1WpFU15Re0GMTVhCDpnWkQIxou cSKQ== MIME-Version: 1.0 X-Received: by 10.68.190.33 with SMTP id gn1mr17867037pbc.48.1385751686074; Fri, 29 Nov 2013 11:01:26 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Fri, 29 Nov 2013 11:01:26 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 20:01:26 +0100 X-Google-Sender-Auth: 9rUket6Ub6P9xoSV_z1KA3KcIp8 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 19:01:27 -0000 And some better marketing from Dragonfly about it http://forum.nginx.org/read.php?29,241283,241283 :) On Fri, Nov 29, 2013 at 7:55 PM, Ermal Lu=E7i wrote: > Also some discussions and improvements to it. > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html > > > On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: > >> Well seems Dragonfly has some version of it already from commit [1]. >> >> In FreeBSD there is the framework for this with by defining PCBGROUP. >> Also the explanation of it at [2] and [3]. >> It can achieve approximately the same features of SO_RESUSEPORT of linux= . >> The only thing missing is the marketing behind it and i think and better >> RSS support. >> By looking at dates the support is there before linux so all you guys >> looking for it can experiment with it. >> >> What i was trying to accomplish was something else from performance >> improvement and >> maybe put a sysctl behind it to make it more acceptable.. >> >> [1] >> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9= c021abb8197718d7a2d441c9 >> [2] >> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#= L51 >> [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.htm= l >> >> >> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko wr= ote: >> >>> Tim, you are wrong. Read what is "multicast" definition, and read how >>> UDP and TCP sockets work in Linux 3.9+ kernels. >>> >>> Oleg . >>> >>> >>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wro= te: >>> >>>> >>>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>>> >>>> > Hello, >>>> > >>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemon= s >>>> to >>>> > share the same port and possibly listening ip =85 >>>> >>>> These flags are used with TCP-based servers. >>>> >>>> I=92ve used them to make software upgrades go more smoothly. >>>> Without them, the following often happens: >>>> >>>> * Old server stops. In the process, all of its TCP connections are >>>> closed. >>>> >>>> * Connections to old server remain in the TCP connection table until >>>> the remote end can acknowledge. >>>> >>>> * New server starts. >>>> >>>> * New server tries to open port but fails because that port is =93stil= l >>>> in use=94 by connections in the TCP connection table. >>>> >>>> With these flags, the new server can open the port even though >>>> it is =93still in use=94 by existing connections. >>>> >>>> >>>> > This is not the case today. >>>> > Only multicast sockets seem to have the behaviour of broadcasting th= e >>>> data >>>> > to all sockets sharing the same properties through these options! >>>> >>>> That is what multicast is for. >>>> >>>> If you want the same data sent to all listeners, then >>>> that is multicast behavior and you should be using >>>> a multicast socket. >>>> >>>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>>> >>>> You=92re trying to turn all UDP sockets with those options >>>> into multicast sockets. >>>> >>>> If you want a multicast socket, you should ask for one. >>>> >>>> Tim >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Ermal > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 19:28:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91F60FDD; Fri, 29 Nov 2013 19:28:41 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 05D2D1AE0; Fri, 29 Nov 2013 19:28:40 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id y10so14256004pdj.37 for ; Fri, 29 Nov 2013 11:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=44ks8XXdj/fivY7M3h5HQ9O14DpxNcjibpDe19EbheU=; b=UqMeinS0XNMCUO+DOhkC0jlGGcQ/BcX5TXD1rUhIMRyik7G0F8ne/3v5UHg7IwMxpi ecB9KjTqoLL9a8bJ6UX25iL9UP306snl/JlY2k0fl2FtfEfAKjbPGZ9e8WtMnBcZXq6L g9BnKwSTwPGeyIqP/Mq8J1iuF1Lm9e+Ey9GJcC4Mb2/2egCNR5QzUs33/iDqg5Vq0zE3 c3ImjSVog0BeSdB7qjZGdaUnDHhr2lEt6dtIisEEC013ui6HpyAzwz634EuxRExXFFTK 2jU6bguPwm2T9+hvuwBipkBSjmBXLxyYDxF+SZCOIaBjHwAfZIR4kdrZqBP5Wg02iBpd d+Bg== MIME-Version: 1.0 X-Received: by 10.68.196.227 with SMTP id ip3mr17598930pbc.163.1385753320381; Fri, 29 Nov 2013 11:28:40 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 29 Nov 2013 11:28:40 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 11:28:40 -0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Oleg Moskalenko To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 19:28:41 -0000 It would be nice to have this feature compiled and supported in FreeBSD kernel by default. Thanks Oleg On Fri, Nov 29, 2013 at 11:01 AM, Ermal Lu=E7i wrote: > And some better marketing from Dragonfly about it > http://forum.nginx.org/read.php?29,241283,241283 :) > > > On Fri, Nov 29, 2013 at 7:55 PM, Ermal Lu=E7i wrote: > >> Also some discussions and improvements to it. >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.htm= l >> >> >> On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: >> >>> Well seems Dragonfly has some version of it already from commit [1]. >>> >>> In FreeBSD there is the framework for this with by defining PCBGROUP. >>> Also the explanation of it at [2] and [3]. >>> It can achieve approximately the same features of SO_RESUSEPORT of linu= x. >>> The only thing missing is the marketing behind it and i think and bette= r >>> RSS support. >>> By looking at dates the support is there before linux so all you guys >>> looking for it can experiment with it. >>> >>> What i was trying to accomplish was something else from performance >>> improvement and >>> maybe put a sysctl behind it to make it more acceptable.. >>> >>> [1] >>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c= 9c021abb8197718d7a2d441c9 >>> [2] >>> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts= #L51 >>> [3] >>> http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html >>> >>> >>> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko w= rote: >>> >>>> Tim, you are wrong. Read what is "multicast" definition, and read how >>>> UDP and TCP sockets work in Linux 3.9+ kernels. >>>> >>>> Oleg . >>>> >>>> >>>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle wr= ote: >>>> >>>>> >>>>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>>>> >>>>> > Hello, >>>>> > >>>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two >>>>> daemons to >>>>> > share the same port and possibly listening ip =85 >>>>> >>>>> These flags are used with TCP-based servers. >>>>> >>>>> I=92ve used them to make software upgrades go more smoothly. >>>>> Without them, the following often happens: >>>>> >>>>> * Old server stops. In the process, all of its TCP connections are >>>>> closed. >>>>> >>>>> * Connections to old server remain in the TCP connection table until >>>>> the remote end can acknowledge. >>>>> >>>>> * New server starts. >>>>> >>>>> * New server tries to open port but fails because that port is =93sti= ll >>>>> in use=94 by connections in the TCP connection table. >>>>> >>>>> With these flags, the new server can open the port even though >>>>> it is =93still in use=94 by existing connections. >>>>> >>>>> >>>>> > This is not the case today. >>>>> > Only multicast sockets seem to have the behaviour of broadcasting >>>>> the data >>>>> > to all sockets sharing the same properties through these options! >>>>> >>>>> That is what multicast is for. >>>>> >>>>> If you want the same data sent to all listeners, then >>>>> that is multicast behavior and you should be using >>>>> a multicast socket. >>>>> >>>>> > The patch at [1] implements/corrects the behaviour for UDP sockets. >>>>> >>>>> You=92re trying to turn all UDP sockets with those options >>>>> into multicast sockets. >>>>> >>>>> If you want a multicast socket, you should ask for one. >>>>> >>>>> Tim >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Ermal >> > > > > -- > Ermal > From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 19:30:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B751134; Fri, 29 Nov 2013 19:30:03 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D275B1AFB; Fri, 29 Nov 2013 19:30:02 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so2174433qaq.15 for ; Fri, 29 Nov 2013 11:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5EVsvFt8BXDMy6fHbQ+UGB+UcTX1Lgack40jddvYHjQ=; b=ZaQin9mepc8SYXmle4KOR2sGE4doXhOz8xxIk8jJu626r7eHTnm+PdY5OlmNPwI/d9 1n5k7pW4Yvmzcc7JouYee5Owu5xx5flR0T4TcVo6ztyuNvrLC5x4aY8ndby60OdtJwob 0SjUxBBcDcezHrRycvZLA3YSPBBiOitb9h/w2yfNZh9UhWfva3r84FDWEdY3XsOty4WY xBNgOAIoK7XpLL1gZj/10ao+Y8v6TN7obPES60RN4e1OhbXmUuALvLXO7iRwdZ/rnctE /znmGTbyjbp+g2b0jIlKlz9pdKXvYJj2EmXG24PO3v3n2J3ifY3gijbRFGf487riJLXe r2/g== MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr89637851qej.35.1385753402048; Fri, 29 Nov 2013 11:30:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 29 Nov 2013 11:30:01 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 29 Nov 2013 11:30:01 -0800 X-Google-Sender-Auth: bw5zAjZQER44f0HmpPx0l8u5Gjk Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Adrian Chadd To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 19:30:03 -0000 Sure, is there a TCP version of this patch floating around? How's it doing load balancing to multiple listeners? -a On 29 November 2013 11:28, Oleg Moskalenko wrote: > It would be nice to have this feature compiled and supported in FreeBSD > kernel by default. > > Thanks > Oleg > > > On Fri, Nov 29, 2013 at 11:01 AM, Ermal Lu=E7i wrote: > >> And some better marketing from Dragonfly about it >> http://forum.nginx.org/read.php?29,241283,241283 :) >> >> >> On Fri, Nov 29, 2013 at 7:55 PM, Ermal Lu=E7i wrote: >> >>> Also some discussions and improvements to it. >>> >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.ht= ml >>> >>> >>> On Fri, Nov 29, 2013 at 7:42 PM, Ermal Lu=E7i wrote: >>> >>>> Well seems Dragonfly has some version of it already from commit [1]. >>>> >>>> In FreeBSD there is the framework for this with by defining PCBGROUP. >>>> Also the explanation of it at [2] and [3]. >>>> It can achieve approximately the same features of SO_RESUSEPORT of lin= ux. >>>> The only thing missing is the marketing behind it and i think and bett= er >>>> RSS support. >>>> By looking at dates the support is there before linux so all you guys >>>> looking for it can experiment with it. >>>> >>>> What i was trying to accomplish was something else from performance >>>> improvement and >>>> maybe put a sysctl behind it to make it more acceptable.. >>>> >>>> [1] >>>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9= c9c021abb8197718d7a2d441c9 >>>> [2] >>>> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpt= s#L51 >>>> [3] >>>> http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html >>>> >>>> >>>> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko = wrote: >>>> >>>>> Tim, you are wrong. Read what is "multicast" definition, and read how >>>>> UDP and TCP sockets work in Linux 3.9+ kernels. >>>>> >>>>> Oleg . >>>>> >>>>> >>>>> On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle w= rote: >>>>> >>>>>> >>>>>> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>>>>> >>>>>> > Hello, >>>>>> > >>>>>> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two >>>>>> daemons to >>>>>> > share the same port and possibly listening ip =85 >>>>>> >>>>>> These flags are used with TCP-based servers. >>>>>> >>>>>> I=92ve used them to make software upgrades go more smoothly. >>>>>> Without them, the following often happens: >>>>>> >>>>>> * Old server stops. In the process, all of its TCP connections are >>>>>> closed. >>>>>> >>>>>> * Connections to old server remain in the TCP connection table until >>>>>> the remote end can acknowledge. >>>>>> >>>>>> * New server starts. >>>>>> >>>>>> * New server tries to open port but fails because that port is =93st= ill >>>>>> in use=94 by connections in the TCP connection table. >>>>>> >>>>>> With these flags, the new server can open the port even though >>>>>> it is =93still in use=94 by existing connections. >>>>>> >>>>>> >>>>>> > This is not the case today. >>>>>> > Only multicast sockets seem to have the behaviour of broadcasting >>>>>> the data >>>>>> > to all sockets sharing the same properties through these options! >>>>>> >>>>>> That is what multicast is for. >>>>>> >>>>>> If you want the same data sent to all listeners, then >>>>>> that is multicast behavior and you should be using >>>>>> a multicast socket. >>>>>> >>>>>> > The patch at [1] implements/corrects the behaviour for UDP sockets= . >>>>>> >>>>>> You=92re trying to turn all UDP sockets with those options >>>>>> into multicast sockets. >>>>>> >>>>>> If you want a multicast socket, you should ask for one. >>>>>> >>>>>> Tim >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g" >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ermal >>>> >>> >>> >>> >>> -- >>> Ermal >>> >> >> >> >> -- >> Ermal >> > _______________________________________________ > 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 Nov 29 22:39:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D588FDAB; Fri, 29 Nov 2013 22:39:52 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F89F1365; Fri, 29 Nov 2013 22:39:52 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f11so2313989qae.5 for ; Fri, 29 Nov 2013 14:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=84NIxTfuhGB4btq0kBeGXo+LC7eDQtDDKB6GtaKDVl4=; b=PdJWXRduwI4BfSR33Bf/O7KZM5ZcOV2mgWP5ApgcB0buSOzORmA1hGd9n6mgmjocVw RVcEjBCSLUldT9/CS+vEuGaM59Koci21vXEzzuQ+sjwwHtQr9EJxciXCmn46I2mfQAs+ NpIo2uen4NPjcBI4FoEjeJzKbXjGD/PRK1YIcbm8Nwj7CNrfeARo7BkvQCdXZ6wUJ/EL Tf3U0buLUs+27XWCnlPZbApK1bqOf80+tzt36u0eqX7Rolnd6Blyhhl/ZFJrLKkUoOcU mzBmjR7nfPW4VcwD4+HmloW50mWMlKKKPqKSQLtCzyzlt9r7LGhTzHpmTmb4ahbbByBo ZOrA== MIME-Version: 1.0 X-Received: by 10.49.24.163 with SMTP id v3mr29869210qef.78.1385764791636; Fri, 29 Nov 2013 14:39:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Fri, 29 Nov 2013 14:39:51 -0800 (PST) In-Reply-To: <5298BD5D.3020203@freebsd.org> References: <52987E27.10503@freebsd.org> <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> <5298BD5D.3020203@freebsd.org> Date: Fri, 29 Nov 2013 14:39:51 -0800 X-Google-Sender-Auth: hOVeW7_8KQ2fUvFcGxwubfNJPSw Message-ID: Subject: Re: ip_output()/if_output() behaviour From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael Tuexen , "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 22:39:52 -0000 +1 On 29 November 2013 08:14, Julian Elischer wrote: >> ifnet(9) says: >> >> if_transmit() >> Transmit a packet on an interface or queue it if the interface >> is >> in use. This function will return ENOBUFS if the devices >> software >> and hardware queues are both full. ... >> >> So I guess returning ENOBUFS when the packet was queued is wrong... > > I think it is. > > ENOBUFS means "I couldn't proceed due to no buffers" > not "I used up the last one on this operation". Yes, it's wrong. ENOBUFS means "couldn't queue; no buffers." Please provide a diff against igb and I'll make sure Jack/Intel get it into (his, freebsd) tree. Thanks! -adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 23:05:08 2013 Return-Path: Delivered-To: net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2585C8B8 for ; Fri, 29 Nov 2013 23:05:08 +0000 (UTC) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.freebsd.org (Postfix) with ESMTP id D553314FB for ; Fri, 29 Nov 2013 23:05:07 +0000 (UTC) Received: from [216.36.114.10] (helo=legal-monitor) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VmWus-00050l-Sl for net@FreeBSD.ORG; Fri, 29 Nov 2013 17:52:07 -0500 From: "EarthLink Customer Support" Subject: Please Update Your Account To: net@FreeBSD.ORG MIME-Version: 1.0 Date: Fri, 29 Nov 2013 14:52:07 -0800 Message-ID: X-ELNK-Trace: bac4167d992cc5d6b79ee3e1e00473249ef193a6bfc3dd485b37cc0cd2b0bc1fcdda512f5960e2dce925a8e63659b694350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.36.114.10 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 23:05:08 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Dear member, Your EarthLink account has been regarded as inactive and disabled in=20 compliance with EarthLink a Terms of Use. You have 24hours to restore the account, just follow the link below: www.earthlink.net/restoreaccount.aspx Otherwise your account will be completely removed on the expiry of the mentioned period. Thank you, EarthLink Customer Support This email has been sent as a courtesy to you by EarthLink=20 You may change your email settings by signing into EarthLink , and goi= ng to http://www.earthlink.net/account/preference.aspx From owner-freebsd-net@FreeBSD.ORG Sat Nov 30 08:50:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38696AA5; Sat, 30 Nov 2013 08:50:58 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDE2813BC; Sat, 30 Nov 2013 08:50:57 +0000 (UTC) Received: from [192.168.1.102] (p508F1AF6.dip0.t-ipconnect.de [80.143.26.246]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EDC081C0C0692; Sat, 30 Nov 2013 09:50:54 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ip_output()/if_output() behaviour From: Michael Tuexen In-Reply-To: Date: Sat, 30 Nov 2013 09:50:55 +0100 Content-Transfer-Encoding: 7bit Message-Id: <41906339-8AE7-4444-8B84-6FC19D48B132@lurchi.franken.de> References: <52987E27.10503@freebsd.org> <8C291076-5F03-4406-B689-A3185E6DD313@lurchi.franken.de> <5298BD5D.3020203@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: "freebsd-net@freebsd.org list" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 30 Nov 2013 08:50:58 -0000 On Nov 29, 2013, at 11:39 PM, Adrian Chadd wrote: > +1 > > > On 29 November 2013 08:14, Julian Elischer wrote: > >>> ifnet(9) says: >>> >>> if_transmit() >>> Transmit a packet on an interface or queue it if the interface >>> is >>> in use. This function will return ENOBUFS if the devices >>> software >>> and hardware queues are both full. ... >>> >>> So I guess returning ENOBUFS when the packet was queued is wrong... >> >> I think it is. >> >> ENOBUFS means "I couldn't proceed due to no buffers" >> not "I used up the last one on this operation". > > Yes, it's wrong. ENOBUFS means "couldn't queue; no buffers." Please > provide a diff against igb and I'll make sure Jack/Intel get it into > (his, freebsd) tree. I sent the patch already yesterday to the list and Jack. It covers em, igb and ixgbe. Best regards Michael > > Thanks! > > > > -adrian >