From owner-freebsd-net@FreeBSD.ORG Sun Dec 13 02:04:43 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CDD106566C; Sun, 13 Dec 2009 02:04:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 098338FC12; Sun, 13 Dec 2009 02:04:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBD24gBQ070820; Sun, 13 Dec 2009 02:04:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBD24gGm070816; Sun, 13 Dec 2009 02:04:42 GMT (envelope-from linimon) Date: Sun, 13 Dec 2009 02:04:42 GMT Message-Id: <200912130204.nBD24gGm070816@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141414: [vge] vge(4) problem on 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 02:04:43 -0000 Synopsis: [vge] vge(4) problem on 8.0-RELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Dec 13 02:04:19 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141414 From owner-freebsd-net@FreeBSD.ORG Sun Dec 13 16:38:25 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CBC1065670; Sun, 13 Dec 2009 16:38:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE7B18FC08; Sun, 13 Dec 2009 16:38:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBDGcONe069308; Sun, 13 Dec 2009 16:38:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBDGcOFa069304; Sun, 13 Dec 2009 16:38:24 GMT (envelope-from linimon) Date: Sun, 13 Dec 2009 16:38:24 GMT Message-Id: <200912131638.nBDGcOFa069304@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/139079: [wpi] Failure to attach wpi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 16:38:25 -0000 Old Synopsis: Failure to attach wpi(4) New Synopsis: [wpi] Failure to attach wpi(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Dec 13 16:37:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139079 From owner-freebsd-net@FreeBSD.ORG Sun Dec 13 19:22:22 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C913B1065692; Sun, 13 Dec 2009 19:22:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A0BD08FC2C; Sun, 13 Dec 2009 19:22:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBDJMMNt014627; Sun, 13 Dec 2009 19:22:22 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBDJMMSM014623; Sun, 13 Dec 2009 19:22:22 GMT (envelope-from gavin) Date: Sun, 13 Dec 2009 19:22:22 GMT Message-Id: <200912131922.nBDJMMSM014623@freefall.freebsd.org> To: dirk.meyer@dinoex.sub.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: bin/140571: [patch] ifconfig(8) does not set country DE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 19:22:22 -0000 Synopsis: [patch] ifconfig(8) does not set country DE State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Sun Dec 13 19:22:06 UTC 2009 State-Changed-Why: Feedback was received http://www.freebsd.org/cgi/query-pr.cgi?pr=140571 From owner-freebsd-net@FreeBSD.ORG Sun Dec 13 23:02:54 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9B61065670 for ; Sun, 13 Dec 2009 23:02:54 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id EFC808FC19 for ; Sun, 13 Dec 2009 23:02:53 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBDLwfic083416 for ; Sun, 13 Dec 2009 14:58:41 -0700 (MST) (envelope-from freebsd@penx.com) Date: Sun, 13 Dec 2009 14:58:41 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 23:02:54 -0000 I am having a problem diagnosing a multiple IPv6 interfaces problem. Any hint is appreciated. OS: Elmer# uname -a FreeBSD Elmer 8.0-STABLE FreeBSD 8.0-STABLE #94: Fri Dec 11 17:24:09 MST 2009 root@Elmer:/usr/src/sys/amd64/compile/ELMER amd64 I have two interfaces on the same switch fabric. They both reside within the same prefix. One is IPv4/IPv6 and the other strictly IPv6. The purpose of these two interfaces is the "normal" stuff and a "bulk data net." The bulk data net is merely an Ethernet intreface with a larger MTU to aid back-up (incoming data) and otehr tasks. The interfaces are defiend as follows: Elmer# ifconfig -a bce0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:13:72:60:ac:52 inet 172.19.10.10 netmask 0xffffff00 broadcast 172.19.10.255 inet6 fe80::213:72ff:fe60:ac52%bce0 prefixlen 64 scopeid 0x1 inet6 fd7c:3f2b:e791:1::ac13:a0a prefixlen 64 nd6 options=3 media: Ethernet 1000baseT status: active bce1: flags=8843 metric 0 mtu 8192 options=1bb ether 00:13:72:60:ac:50 inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a prefixlen 64 inet6 fe80::213:72ff:fe60:ac50%bce1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 nd6 options=3 Bce1 is the bulk data net. I can ping6 a host out the bce0 interface and get a response. However, though I can send ping6 packets out bce1 to the same host, that host cannot discover the MAC for bce1. For example: Elmer# ping6 -S fd7c:3f2b:e791:1::ac13:a0a docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1::ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=0 hlim=64 time=0.301 ms 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=1 hlim=64 time=0.224 ms Elmer# ping6 -S fd7c:3f2b:e791:1:0:1:ac13:a0a docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 (nothing returned). Docs# tcpdump -n -q ip6 and not tcp and not udp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes 13:11:05.557252 IP6 fd7c:3f2b:e791:1:0:1:ac13:a0a > fd7c:3f2b:e791:1::ac13:a15: ICMP6, echo request, seq 55, length 16 13:11:05.557275 IP6 fd7c:3f2b:e791:1::ac13:a15 > ff02::1:ff13:a0a: ICMP6, neighbor solicitation, who has fd7c:3f2b:e791:1:0:1:ac13:a0a, length 32 (and so on) Note: Docs: bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:85:ee:02:54 inet 172.19.10.21 netmask 0xffffff00 broadcast 172.19.10.255 inet6 fe80::211:85ff:feee:254%bge0 prefixlen 64 scopeid 0x1 inet6 fd7c:3f2b:e791:1::ac13:a15 prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active If I watch the bce1 interface on Elmer using TCPdump in another window session, it is seeing the solicitation, at least via tcpdump; but no response as to who has fd7c:3f2b:e791:1:0:1:ac13:a0a. I've included other data below. I am at a loss to understand why the bce1 interface isn't being advertised on the fabric. I am an IPv6 newbie. I have a router on the network. Elmer# ndp -an Neighbor Linklayer Address Netif Expire S Flags fe80::213:72ff:fe60:ac50%bce1 0:13:72:60:ac:50 bce1 permanent R fd7c:3f2b:e791:1:0:1:ac13:a0a 0:13:72:60:ac:50 bce1 permanent R fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bce0 12s R fe80::213:72ff:fe60:ac52%bce0 0:13:72:60:ac:52 bce0 permanent R fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bce0 23h58m20s S R fe80::217:95ff:fe25:5c90%bce0 0:17:95:25:5c:90 bce0 23h59m22s S R fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bce0 permanent R Docs# ndp -an Neighbor Linklayer Address Netif Expire S Flags fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bge0 permanent R fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bge0 2s D R fe80::211:85ff:feee:254%bge0 0:11:85:ee:2:54 bge0 permanent R fe80::217:95ff:fe25:5c90%bge0 0:17:95:25:5c:90 bge0 23h58m30s S R fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bge0 23h59m46s S Elmer# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.19.10.1 UGS 152 3711257 bce0 127.0.0.1 link#3 UH 0 442332 lo0 172.19.10.0/24 link#1 U 0 10116355 bce0 172.19.10.10 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fd7c:3f2b:e791:1::1 UGS bce0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 U bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64 link#1 U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS lo0 fe80::%bce1/64 link#2 U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff01:3::/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U bce1 ff02::%lo0/32 ::1 U lo0 Elmer's rc.config: ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu 8192" ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" The router (cisco): interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) Elmer# tcpdump -nq ip6 and not tcp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes 13:21:52.819632 IP6 fe80::217:95ff:fe25:5c90 > ff02::1: ICMP6, router advertisement, length 64 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 00:08:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5EE106566B for ; Mon, 14 Dec 2009 00:08:08 +0000 (UTC) (envelope-from fjo-lists@ogris.de) Received: from ns1.ogris.net (ns1.ogris.net [212.62.68.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9398FC0C for ; Mon, 14 Dec 2009 00:08:07 +0000 (UTC) Received: from [192.168.0.14] (p54875767.dip.t-dialin.net [84.135.87.103]) by ns1.ogris.net (Postfix) with ESMTPA id 2C3B11211A3 for ; Mon, 14 Dec 2009 00:53:48 +0100 (CET) User-Agent: Microsoft-Entourage/13.3.0.091002 Date: Mon, 14 Dec 2009 00:53:22 +0100 From: "Felix J. Ogris" To: Message-ID: Thread-Topic: tcp keepalive after fin+ack from client and server Thread-Index: Acp8T3PEW34co3FYMkyvX8dmC028ug== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: tcp keepalive after fin+ack from client and server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 00:08:08 -0000 Hi, I am experiencing some strange problem where FreeBSD sometimes starts sending tcp keepalives after client and server have sent and ack'ed FINs. The server runs 7.1-RELEASE/amd64 with open-vm-tools-nox11-148847 in a VMware ESXi 4.0. The client runs a CentOS Linux 2.6.18-164.6.1.el5PAE SMP on a bare metal machine. FreeBSD houses a Apache installation with sendfile and mmap enabled. The Linux machine runs a homemade monitoring system and starts a Perl script every 5 minutes to check if Apache is still alive. I have put a tcpdump output on http://ogris.de/keepalive.txt for readability and can provide the raw tcpdump file, if needed. Client and server keep sending those keepalives for about 2 hours (yielding 300kB/s constantly) if not stopped manually by an ipfw rule. lsof shows that no user process has open the corresponding sockets anymore, whereas netstat shows established connections. FreeBSD has loaded ipfw with some keep-state rules, the Linux box has iptables disabled. kldstat: Id Refs Address Size Name 1 7 0xffffffff80100000 b4be40 kernel 2 1 0xffffffff80c4c000 7d0 accf_data.ko 3 1 0xffffffff80c4d000 14d8 accf_http.ko 4 1 0xffffffffae531000 175a vmmemctl.ko 5 1 0xffffffffae543000 1e2e vmxnet.ko 6 1 0xffffffffae548000 9dd2 ipfw.ko netstat -s -p tcp: tcp: 952726388 packets sent 9941686 data packets (12846102403 bytes) 27667 data packets (37621159 bytes) retransmitted 844 data packets unnecessarily retransmitted 10 resends initiated by MTU discovery 942517629 ack-only packets (125912 delayed) 0 URG only packets 632 window probe packets 61151 window update packets 177623 control packets 949354853 packets received 6393724 acks (for 12784848708 bytes) 217997 duplicate acks 941774559 acks for unsent data 677499 packets (448005826 bytes) received in-sequence 179120 completely duplicate packets (1862276 bytes) 178 old duplicate packets 12 packets with some dup. data (6813 bytes duped) 4934 out-of-order packets (6499234 bytes) 0 packets (0 bytes) of data after window 0 window probes 92981 window update packets 1848 packets received after close 19 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 81 discarded due to memory problems 24262 connection requests 152765 connection accepts 0 bad connection attempts 0 listen queue overflows 21854 ignored RSTs in the windows 176860 connections established (including accepts) 179292 connections closed (including 23036 drops) 111998 connections updated cached RTT on close 112122 connections updated cached RTT variance on close 43123 connections updated cached ssthresh on close 58 embryonic connections dropped 5513567 segments updated rtt (of 3368553 attempts) 17054 retransmit timeouts 751 connections dropped by rexmit timeout 803 persist timeouts 3 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 2008 keepalive timeouts 1786 keepalive probes sent 222 connections dropped by keepalive 1234887 correct ACK header predictions 434353 correct data packet header predictions 152809 syncache entries added 738 retransmitted 506 dupsyn 0 dropped 152765 completed 0 bucket overflow 0 cache overflow 144 reset 165 stale 0 aborted 0 badack 0 unreach 0 zone failures 152809 cookies sent 265 cookies received 6416 SACK recovery episodes 12522 segment rexmits in SACK recovery episodes 17837785 byte rexmits in SACK recovery episodes 62528 SACK options (SACK blocks) received 3807 SACK options (SACK blocks) sent 0 SACK scoreboard overflow sysctl net: net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.recycled: 0 net.local.taskcount: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 1024 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 22 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 1038 net.inet.ip.fw.curr_dyn_buckets: 1024 net.inet.ip.fw.dyn_buckets: 1024 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 116 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 81 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 2048 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 168 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 6553 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.soreceive_dgram_enabled: 0 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.early_fast_retran_msec: 250 net.inet.sctp.early_fast_retran: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_pf: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 4096 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 0 net.inet.sctp.ecn_nonce: 0 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 233016 net.inet.sctp.sendspace: 233016 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 net.inet.accf.http.parsehttpversion: 1 net.link.generic.system.ifcount: 3 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 8192 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 0 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 8192 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.fw.enable: 1 net.inet6.ip6.fw.deny_unknown_exthdrs: 1 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 751963064 net.isr.drop: 0 net.isr.queued: 952769795 net.isr.deferred: 0 net.isr.directed: 952250693 net.isr.count: 952250693 net.isr.direct: 1 net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.route.netisr_maxqlen: 256 net.wlan.recv_bar: 1 net.wlan.debug: 0 sysctl kern.ipc: kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 4096 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 100 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 32768 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 147456 kern.ipc.maxpipekva: 20971520 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 512 kern.ipc.semmns: 1024 kern.ipc.semmni: 512 kern.ipc.semmap: 256 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 32768 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 134217728 kern.ipc.maxsockets: 32768 kern.ipc.numopensockets: 188 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 TIA, Felix From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 02:34:34 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9CB1065670; Mon, 14 Dec 2009 02:34:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96C128FC12; Mon, 14 Dec 2009 02:34:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBE2YYIp089499; Mon, 14 Dec 2009 02:34:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBE2YYfM089495; Mon, 14 Dec 2009 02:34:34 GMT (envelope-from linimon) Date: Mon, 14 Dec 2009 02:34:34 GMT Message-Id: <200912140234.nBE2YYfM089495@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:34:34 -0000 Old Synopsis: Strange behavior with vge gigabit ethernet adapter New Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 14 02:34:13 UTC 2009 Responsible-Changed-Why: This may not be i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 02:35:06 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 649C5106568D; Mon, 14 Dec 2009 02:35:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAD78FC0C; Mon, 14 Dec 2009 02:35:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBE2Z6Jj089552; Mon, 14 Dec 2009 02:35:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBE2Z6aK089548; Mon, 14 Dec 2009 02:35:06 GMT (envelope-from linimon) Date: Mon, 14 Dec 2009 02:35:06 GMT Message-Id: <200912140235.nBE2Z6aK089548@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141314: Network Performance has decreased by 30% [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:35:06 -0000 Old Synopsis: Network Performance has decreased by 30% New Synopsis: Network Performance has decreased by 30% [regression] Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 14 02:34:39 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=141314 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 04:32:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F322106566B for ; Mon, 14 Dec 2009 04:32:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 23CE88FC14 for ; Mon, 14 Dec 2009 04:32:39 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C386527861; Sun, 13 Dec 2009 20:33:12 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C52E42D6013; Sun, 13 Dec 2009 20:32:37 -0800 (PST) Message-ID: <4B25BFF3.4060103@elischer.org> Date: Sun, 13 Dec 2009 20:32:51 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Felix J. Ogris" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: tcp keepalive after fin+ack from client and server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 04:32:39 -0000 Felix J. Ogris wrote: > Hi, > > I am experiencing some strange problem where FreeBSD sometimes starts > sending tcp keepalives after client and server have sent and ack'ed FINs. > The server runs 7.1-RELEASE/amd64 with open-vm-tools-nox11-148847 in a > VMware ESXi 4.0. The client runs a CentOS Linux 2.6.18-164.6.1.el5PAE SMP on > a bare metal machine. FreeBSD houses a Apache installation with sendfile and > mmap enabled. The Linux machine runs a homemade monitoring system and starts > a Perl script every 5 minutes to check if Apache is still alive. I have put > a tcpdump output on http://ogris.de/keepalive.txt for readability and can > provide the raw tcpdump file, if needed. Client and server keep sending > those keepalives for about 2 hours (yielding 300kB/s constantly) if not > stopped manually by an ipfw rule. lsof shows that no user process has open > the corresponding sockets anymore, whereas netstat shows established > connections. > FreeBSD has loaded ipfw with some keep-state rules, the Linux box has > iptables disabled. are you sure it isn't the firewall (ipfw) sending keepalives? it is one of the options with kept state to inject keepalives. if it didint' see all the FINs for some reason, it may think the session is still alive. > > kldstat: > Id Refs Address Size Name > 1 7 0xffffffff80100000 b4be40 kernel > 2 1 0xffffffff80c4c000 7d0 accf_data.ko > 3 1 0xffffffff80c4d000 14d8 accf_http.ko > 4 1 0xffffffffae531000 175a vmmemctl.ko > 5 1 0xffffffffae543000 1e2e vmxnet.ko > 6 1 0xffffffffae548000 9dd2 ipfw.ko > > netstat -s -p tcp: > tcp: > 952726388 packets sent > 9941686 data packets (12846102403 bytes) > 27667 data packets (37621159 bytes) retransmitted > 844 data packets unnecessarily retransmitted > 10 resends initiated by MTU discovery > 942517629 ack-only packets (125912 delayed) > 0 URG only packets > 632 window probe packets > 61151 window update packets > 177623 control packets > 949354853 packets received > 6393724 acks (for 12784848708 bytes) > 217997 duplicate acks > 941774559 acks for unsent data > 677499 packets (448005826 bytes) received in-sequence > 179120 completely duplicate packets (1862276 bytes) > 178 old duplicate packets > 12 packets with some dup. data (6813 bytes duped) > 4934 out-of-order packets (6499234 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 92981 window update packets > 1848 packets received after close > 19 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 81 discarded due to memory problems > 24262 connection requests > 152765 connection accepts > 0 bad connection attempts > 0 listen queue overflows > 21854 ignored RSTs in the windows > 176860 connections established (including accepts) > 179292 connections closed (including 23036 drops) > 111998 connections updated cached RTT on close > 112122 connections updated cached RTT variance on close > 43123 connections updated cached ssthresh on close > 58 embryonic connections dropped > 5513567 segments updated rtt (of 3368553 attempts) > 17054 retransmit timeouts > 751 connections dropped by rexmit timeout > 803 persist timeouts > 3 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 2008 keepalive timeouts > 1786 keepalive probes sent > 222 connections dropped by keepalive > 1234887 correct ACK header predictions > 434353 correct data packet header predictions > 152809 syncache entries added > 738 retransmitted > 506 dupsyn > 0 dropped > 152765 completed > 0 bucket overflow > 0 cache overflow > 144 reset > 165 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > 152809 cookies sent > 265 cookies received > 6416 SACK recovery episodes > 12522 segment rexmits in SACK recovery episodes > 17837785 byte rexmits in SACK recovery episodes > 62528 SACK options (SACK blocks) received > 3807 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > > sysctl net: > net.local.stream.recvspace: 8192 > net.local.stream.sendspace: 8192 > net.local.dgram.recvspace: 4096 > net.local.dgram.maxdgram: 2048 > net.local.recycled: 0 > net.local.taskcount: 0 > net.local.inflight: 0 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.portrange.reservedlow: 0 > net.inet.ip.portrange.reservedhigh: 1023 > net.inet.ip.portrange.hilast: 65535 > net.inet.ip.portrange.hifirst: 49152 > net.inet.ip.portrange.last: 65535 > net.inet.ip.portrange.first: 49152 > net.inet.ip.portrange.lowlast: 600 > net.inet.ip.portrange.lowfirst: 1023 > net.inet.ip.forwarding: 0 > net.inet.ip.redirect: 1 > net.inet.ip.ttl: 64 > net.inet.ip.rtexpire: 3600 > net.inet.ip.rtminexpire: 10 > net.inet.ip.rtmaxcache: 128 > net.inet.ip.sourceroute: 0 > net.inet.ip.intr_queue_maxlen: 50 > net.inet.ip.intr_queue_drops: 0 > net.inet.ip.accept_sourceroute: 0 > net.inet.ip.keepfaith: 0 > net.inet.ip.gifttl: 30 > net.inet.ip.same_prefix_carp_only: 0 > net.inet.ip.subnets_are_local: 0 > net.inet.ip.fastforwarding: 0 > net.inet.ip.maxfragpackets: 1024 > net.inet.ip.maxfragsperpacket: 16 > net.inet.ip.fragpackets: 0 > net.inet.ip.check_interface: 0 > net.inet.ip.random_id: 0 > net.inet.ip.sendsourcequench: 0 > net.inet.ip.process_options: 1 > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 22 > net.inet.ip.fw.dyn_max: 4096 > net.inet.ip.fw.dyn_count: 1038 > net.inet.ip.fw.curr_dyn_buckets: 1024 > net.inet.ip.fw.dyn_buckets: 1024 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 0 > net.inet.ip.fw.debug: 1 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.inet.icmp.maskrepl: 0 > net.inet.icmp.icmplim: 200 > net.inet.icmp.bmcastecho: 0 > net.inet.icmp.quotelen: 8 > net.inet.icmp.reply_from_interface: 0 > net.inet.icmp.reply_src: > net.inet.icmp.icmplim_output: 1 > net.inet.icmp.log_redirect: 0 > net.inet.icmp.drop_redirect: 0 > net.inet.icmp.maskfake: 0 > net.inet.tcp.rfc1323: 1 > net.inet.tcp.mssdflt: 512 > net.inet.tcp.keepidle: 7200000 > net.inet.tcp.keepintvl: 75000 > net.inet.tcp.sendspace: 65536 > net.inet.tcp.recvspace: 65536 > net.inet.tcp.keepinit: 75000 > net.inet.tcp.delacktime: 100 > net.inet.tcp.v6mssdflt: 1024 > net.inet.tcp.hostcache.purge: 0 > net.inet.tcp.hostcache.prune: 300 > net.inet.tcp.hostcache.expire: 3600 > net.inet.tcp.hostcache.count: 116 > net.inet.tcp.hostcache.bucketlimit: 30 > net.inet.tcp.hostcache.hashsize: 512 > net.inet.tcp.hostcache.cachelimit: 15360 > net.inet.tcp.recvbuf_max: 262144 > net.inet.tcp.recvbuf_inc: 16384 > net.inet.tcp.recvbuf_auto: 1 > net.inet.tcp.insecure_rst: 0 > net.inet.tcp.rfc3390: 1 > net.inet.tcp.rfc3042: 1 > net.inet.tcp.drop_synfin: 0 > net.inet.tcp.delayed_ack: 1 > net.inet.tcp.blackhole: 0 > net.inet.tcp.log_in_vain: 0 > net.inet.tcp.sendbuf_max: 262144 > net.inet.tcp.sendbuf_inc: 8192 > net.inet.tcp.sendbuf_auto: 1 > net.inet.tcp.tso: 1 > net.inet.tcp.newreno: 1 > net.inet.tcp.local_slowstart_flightsize: 4 > net.inet.tcp.slowstart_flightsize: 1 > net.inet.tcp.path_mtu_discovery: 1 > net.inet.tcp.reass.overflows: 81 > net.inet.tcp.reass.maxqlen: 48 > net.inet.tcp.reass.cursegments: 0 > net.inet.tcp.reass.maxsegments: 2048 > net.inet.tcp.sack.globalholes: 0 > net.inet.tcp.sack.globalmaxholes: 65536 > net.inet.tcp.sack.maxholes: 128 > net.inet.tcp.sack.enable: 1 > net.inet.tcp.inflight.stab: 20 > net.inet.tcp.inflight.max: 1073725440 > net.inet.tcp.inflight.min: 6144 > net.inet.tcp.inflight.rttthresh: 10 > net.inet.tcp.inflight.debug: 0 > net.inet.tcp.inflight.enable: 1 > net.inet.tcp.isn_reseed_interval: 0 > net.inet.tcp.icmp_may_rst: 1 > net.inet.tcp.pcbcount: 168 > net.inet.tcp.do_tcpdrain: 1 > net.inet.tcp.tcbhashsize: 512 > net.inet.tcp.log_debug: 0 > net.inet.tcp.minmss: 216 > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > net.inet.tcp.syncookies_only: 0 > net.inet.tcp.syncookies: 1 > net.inet.tcp.timer_race: 0 > net.inet.tcp.finwait2_timeout: 60000 > net.inet.tcp.fast_finwait2_recycle: 0 > net.inet.tcp.always_keepalive: 1 > net.inet.tcp.rexmit_slop: 200 > net.inet.tcp.rexmit_min: 30 > net.inet.tcp.msl: 30000 > net.inet.tcp.nolocaltimewait: 0 > net.inet.tcp.maxtcptw: 6553 > net.inet.udp.checksum: 1 > net.inet.udp.maxdgram: 9216 > net.inet.udp.recvspace: 42080 > net.inet.udp.soreceive_dgram_enabled: 0 > net.inet.udp.blackhole: 0 > net.inet.udp.log_in_vain: 0 > net.inet.sctp.enable_sack_immediately: 0 > net.inet.sctp.udp_tunneling_port: 0 > net.inet.sctp.udp_tunneling_for_client_enable: 0 > net.inet.sctp.mobility_fasthandoff: 0 > net.inet.sctp.mobility_base: 0 > net.inet.sctp.default_frag_interleave: 1 > net.inet.sctp.default_cc_module: 0 > net.inet.sctp.log_level: 0 > net.inet.sctp.max_retran_chunk: 30 > net.inet.sctp.min_residual: 1452 > net.inet.sctp.strict_data_order: 0 > net.inet.sctp.abort_at_limit: 0 > net.inet.sctp.hb_max_burst: 4 > net.inet.sctp.do_sctp_drain: 1 > net.inet.sctp.max_chained_mbufs: 5 > net.inet.sctp.abc_l_var: 1 > net.inet.sctp.nat_friendly: 1 > net.inet.sctp.auth_disable: 0 > net.inet.sctp.asconf_auth_nochk: 0 > net.inet.sctp.early_fast_retran_msec: 250 > net.inet.sctp.early_fast_retran: 0 > net.inet.sctp.cwnd_maxburst: 1 > net.inet.sctp.cmt_pf: 0 > net.inet.sctp.cmt_use_dac: 0 > net.inet.sctp.cmt_on_off: 0 > net.inet.sctp.outgoing_streams: 10 > net.inet.sctp.add_more_on_output: 1452 > net.inet.sctp.path_rtx_max: 5 > net.inet.sctp.assoc_rtx_max: 10 > net.inet.sctp.init_rtx_max: 8 > net.inet.sctp.valid_cookie_life: 60000 > net.inet.sctp.init_rto_max: 60000 > net.inet.sctp.rto_initial: 3000 > net.inet.sctp.rto_min: 1000 > net.inet.sctp.rto_max: 60000 > net.inet.sctp.secret_lifetime: 3600 > net.inet.sctp.shutdown_guard_time: 180 > net.inet.sctp.pmtu_raise_time: 600 > net.inet.sctp.heartbeat_interval: 30000 > net.inet.sctp.asoc_resource: 10 > net.inet.sctp.sys_resource: 1000 > net.inet.sctp.sack_freq: 2 > net.inet.sctp.delayed_sack_time: 200 > net.inet.sctp.chunkscale: 10 > net.inet.sctp.min_split_point: 2904 > net.inet.sctp.pcbhashsize: 256 > net.inet.sctp.tcbhashsize: 1024 > net.inet.sctp.maxchunks: 4096 > net.inet.sctp.maxburst: 4 > net.inet.sctp.peer_chkoh: 256 > net.inet.sctp.strict_init: 1 > net.inet.sctp.loopback_nocsum: 1 > net.inet.sctp.strict_sacks: 0 > net.inet.sctp.ecn_nonce: 0 > net.inet.sctp.ecn_enable: 1 > net.inet.sctp.auto_asconf: 1 > net.inet.sctp.recvspace: 233016 > net.inet.sctp.sendspace: 233016 > net.inet.raw.recvspace: 9216 > net.inet.raw.maxdgram: 9216 > net.inet.accf.unloadable: 0 > net.inet.accf.http.parsehttpversion: 1 > net.link.generic.system.ifcount: 3 > net.link.ether.inet.log_arp_permanent_modify: 1 > net.link.ether.inet.log_arp_movements: 1 > net.link.ether.inet.log_arp_wrong_iface: 1 > net.link.ether.inet.proxyall: 0 > net.link.ether.inet.useloopback: 1 > net.link.ether.inet.maxtries: 5 > net.link.ether.inet.max_age: 1200 > net.link.ether.ipfw: 0 > net.link.gif.parallel_tunnels: 0 > net.link.gif.max_nesting: 1 > net.link.log_link_state_change: 1 > net.link.tun.devfs_cloning: 1 > net.inet6.ip6.forwarding: 0 > net.inet6.ip6.redirect: 1 > net.inet6.ip6.hlim: 64 > net.inet6.ip6.maxfragpackets: 8192 > net.inet6.ip6.accept_rtadv: 0 > net.inet6.ip6.keepfaith: 0 > net.inet6.ip6.log_interval: 5 > net.inet6.ip6.hdrnestlimit: 15 > net.inet6.ip6.dad_count: 1 > net.inet6.ip6.auto_flowlabel: 1 > net.inet6.ip6.defmcasthlim: 1 > net.inet6.ip6.gifhlim: 30 > net.inet6.ip6.kame_version: FreeBSD > net.inet6.ip6.use_deprecated: 1 > net.inet6.ip6.rr_prune: 5 > net.inet6.ip6.v6only: 1 > net.inet6.ip6.rtexpire: 3600 > net.inet6.ip6.rtminexpire: 10 > net.inet6.ip6.rtmaxcache: 128 > net.inet6.ip6.use_tempaddr: 0 > net.inet6.ip6.temppltime: 86400 > net.inet6.ip6.tempvltime: 604800 > net.inet6.ip6.auto_linklocal: 0 > net.inet6.ip6.prefer_tempaddr: 0 > net.inet6.ip6.use_defaultzone: 0 > net.inet6.ip6.maxfrags: 8192 > net.inet6.ip6.mcast_pmtu: 0 > net.inet6.ip6.fw.enable: 1 > net.inet6.ip6.fw.deny_unknown_exthdrs: 1 > net.inet6.icmp6.rediraccept: 1 > net.inet6.icmp6.redirtimeout: 600 > net.inet6.icmp6.nd6_prune: 1 > net.inet6.icmp6.nd6_delay: 5 > net.inet6.icmp6.nd6_umaxtries: 3 > net.inet6.icmp6.nd6_mmaxtries: 3 > net.inet6.icmp6.nd6_useloopback: 1 > net.inet6.icmp6.nodeinfo: 3 > net.inet6.icmp6.errppslimit: 100 > net.inet6.icmp6.nd6_maxnudhint: 0 > net.inet6.icmp6.nd6_debug: 0 > net.inet6.icmp6.nd6_maxqueuelen: 1 > net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 > net.bpf.maxinsns: 512 > net.bpf.maxbufsize: 524288 > net.bpf.bufsize: 4096 > net.isr.swi_count: 751963064 > net.isr.drop: 0 > net.isr.queued: 952769795 > net.isr.deferred: 0 > net.isr.directed: 952250693 > net.isr.count: 952250693 > net.isr.direct: 1 > net.raw.recvspace: 8192 > net.raw.sendspace: 8192 > net.my_fibnum: 0 > net.add_addr_allfibs: 1 > net.fibs: 1 > net.route.netisr_maxqlen: 256 > net.wlan.recv_bar: 1 > net.wlan.debug: 0 > > sysctl kern.ipc: > kern.ipc.maxsockbuf: 262144 > kern.ipc.sockbuf_waste_factor: 8 > kern.ipc.somaxconn: 4096 > kern.ipc.max_linkhdr: 16 > kern.ipc.max_protohdr: 60 > kern.ipc.max_hdr: 76 > kern.ipc.max_datalen: 100 > kern.ipc.nmbjumbo16: 3200 > kern.ipc.nmbjumbo9: 6400 > kern.ipc.nmbjumbop: 12800 > kern.ipc.nmbclusters: 32768 > kern.ipc.piperesizeallowed: 1 > kern.ipc.piperesizefail: 0 > kern.ipc.pipeallocfail: 0 > kern.ipc.pipefragretry: 0 > kern.ipc.pipekva: 147456 > kern.ipc.maxpipekva: 20971520 > kern.ipc.msgseg: 2048 > kern.ipc.msgssz: 8 > kern.ipc.msgtql: 40 > kern.ipc.msgmnb: 2048 > kern.ipc.msgmni: 40 > kern.ipc.msgmax: 16384 > kern.ipc.semaem: 16384 > kern.ipc.semvmx: 32767 > kern.ipc.semusz: 104 > kern.ipc.semume: 10 > kern.ipc.semopm: 100 > kern.ipc.semmsl: 60 > kern.ipc.semmnu: 512 > kern.ipc.semmns: 1024 > kern.ipc.semmni: 512 > kern.ipc.semmap: 256 > kern.ipc.shm_allow_removed: 0 > kern.ipc.shm_use_phys: 0 > kern.ipc.shmall: 32768 > kern.ipc.shmseg: 128 > kern.ipc.shmmni: 192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 134217728 > kern.ipc.maxsockets: 32768 > kern.ipc.numopensockets: 188 > kern.ipc.nsfbufsused: 0 > kern.ipc.nsfbufspeak: 0 > kern.ipc.nsfbufs: 0 > > > TIA, > Felix > > > _______________________________________________ > 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 Mon Dec 14 09:11:50 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B86106566C for ; Mon, 14 Dec 2009 09:11:50 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from mail.esigetel.fr (venus.esigetel.fr [192.134.106.8]) by mx1.freebsd.org (Postfix) with ESMTP id DB71B8FC20 for ; Mon, 14 Dec 2009 09:11:49 +0000 (UTC) Received: by mail.esigetel.fr (Postfix, from userid 65534) id 762A9102E6; Mon, 14 Dec 2009 10:11:48 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on venus.esigetel.avon X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from localhost (localhost [127.0.0.1]) by mail.esigetel.fr (Postfix) with ESMTP id D380D102E5; Mon, 14 Dec 2009 10:11:47 +0100 (CET) X-Virus-Scanned: amavisd-new at esigetel.fr Received: from mail.esigetel.fr ([127.0.0.1]) by localhost (venus.esigetel.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3hVYrsTFbbv; Mon, 14 Dec 2009 10:11:42 +0100 (CET) Received: from webmail.esigetel.fr (neo.ecampus.avon [192.168.106.14]) by mail.esigetel.fr (Postfix) with ESMTP id 28169102DB; Mon, 14 Dec 2009 10:11:42 +0100 (CET) Received: from 83.206.131.26 (proxying for unknown) by webmail.esigetel.fr with HTTP; Mon, 14 Dec 2009 10:11:42 +0100 (CET) Message-ID: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> In-Reply-To: References: Date: Mon, 14 Dec 2009 10:11:42 +0100 (CET) From: "JASSAL Aman" To: "Dennis Glatting" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:11:50 -0000 Hello Mr.Glatting, Not that I'm an IPv6 genius, but at first sight your problem seems to be a route-related. I've put comments in-line. Le Dim 13 décembre 2009 22:58, Dennis Glatting a écrit : > > > Elmer# netstat -rn > Routing tables > > > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 => default fd7c:3f2b:e791:1::1 > UGS bce0 > ::1 ::1 UH > lo0 ::ffff:0.0.0.0/96 ::1 UGRS > lo0 fd7c:3f2b:e791:1::/64 link#1 U > bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 UHS > lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS > lo0 fe80::/10 ::1 UGRS > lo0 fe80::%bce0/64 link#1 U > bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS > lo0 fe80::%bce1/64 link#2 U > bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS > lo0 fe80::%lo0/64 link#3 U > lo0 fe80::1%lo0 link#3 UHS > lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U > bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 ff01:3::/32 ::1 U > lo0 ff02::/16 ::1 UGRS > lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U > bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 ff02::%lo0/32 ::1 U > lo0 > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was expecting bce1 rather than lo0, I suppose you were as well :) If I'm not mistaken, the packets emanating from bce1 go to the loopback interface, thus not really going out. You can try specifying the route manually with "route add *your parameters*" or even set it in /etc/rc.conf so that it's loaded at boot-time. There's no reason why among 2 physical interfaces sharing the same fabric, one can ship packets out and the other can't. > > Elmer's rc.config: > > > ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" > ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" > ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu > 8192" > ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used this myself so I can't really comment, and I can't say if there aren't any sort of "interferences" with what you're trying to do. > > > The router (cisco): > > > interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 > enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > Just a side-note, I'm not sure if it will be really useful to you, but you could give it a try if you want to. Have you tried using your Cisco router as a Router Advertisement Daemon ? That way, addresses would be built automatically and you could see how both interfaces react to such advertisements. I hope this helps. ------------ Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 09:48:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92F9106566C for ; Mon, 14 Dec 2009 09:48:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7DF8FC14 for ; Mon, 14 Dec 2009 09:48:42 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Gruf5nAm4nYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=_Yv7MrWqlXihvAoF5gIA:9 a=dEtFkXl7oUE3-cDj-iEpTvm7S2IA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1327417052; Mon, 14 Dec 2009 09:48:39 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Mon, 14 Dec 2009 09:50:33 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <3a142e750912120418h2e57c3c4g351d44b4a342a789@mail.gmail.com> In-Reply-To: <3a142e750912120418h2e57c3c4g351d44b4a342a789@mail.gmail.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200912140950.34624.hselasky@c2i.net> Cc: freebsd-net@freebsd.org, Paul B Mahol Subject: Re: patch: ndisusb: show device description on attach X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 09:48:42 -0000 On Saturday 12 December 2009 13:18:53 Paul B Mahol wrote: > --- /sys/dev/if_ndis/if_ndis_usb.c 2009-11-25 21:49:03.000000000 +0000 > +++ if_ndis_usb.c 2009-12-12 12:17:27.000000000 +0000 > @@ -165,6 +165,7 @@ > driver_object *drv; > int devidx = 0; > > + device_set_usb_desc(self); > db = uaa->driver_ivar; > sc = (struct ndis_softc *)dummy; > sc->ndis_dev = self; The patch looks good. Just commit it! --HPS From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 11:07:00 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD360106568B for ; Mon, 14 Dec 2009 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9848A8FC0A for ; Mon, 14 Dec 2009 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEB701l076017 for ; Mon, 14 Dec 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEB6x65076015 for freebsd-net@FreeBSD.org; Mon, 14 Dec 2009 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Dec 2009 11:06:59 GMT Message-Id: <200912141106.nBEB6x65076015@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/141414 net [vge] vge(4) problem on 8.0-RELEASE o kern/141376 net [ndis] [patch] fix broken scan by passing ies and ies_ o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141276 net [vge] Strange behavior with vge gigabit ethernet adapt o kern/141256 net [iwn] iwn(4) causes page fault on interface up o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection o bin/140571 net [patch] ifconfig(8) does not set country DE o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net [iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting 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) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [if_em] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 374 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 18:44:09 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A49A10656B1; Mon, 14 Dec 2009 18:44:09 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4174B8FC19; Mon, 14 Dec 2009 18:44:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEIi9DB080245; Mon, 14 Dec 2009 18:44:09 GMT (envelope-from rpaulo@freefall.freebsd.org) Received: (from rpaulo@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEIi9Kc080241; Mon, 14 Dec 2009 18:44:09 GMT (envelope-from rpaulo) Date: Mon, 14 Dec 2009 18:44:09 GMT Message-Id: <200912141844.nBEIi9Kc080241@freefall.freebsd.org> To: onemda@gmail.com, rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org From: rpaulo@FreeBSD.org Cc: Subject: Re: kern/141376: [ndis] [patch] fix broken scan by passing ies and ies_len pointer to net80211 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:44:09 -0000 Synopsis: [ndis] [patch] fix broken scan by passing ies and ies_len pointer to net80211 State-Changed-From-To: open->closed State-Changed-By: rpaulo State-Changed-When: Mon Dec 14 18:43:44 UTC 2009 State-Changed-Why: fixed, thanks http://www.freebsd.org/cgi/query-pr.cgi?pr=141376 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 18:50:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B89A31065676 for ; Mon, 14 Dec 2009 18:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A7B018FC1A for ; Mon, 14 Dec 2009 18:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEIo2md080342 for ; Mon, 14 Dec 2009 18:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEIo2oO080341; Mon, 14 Dec 2009 18:50:02 GMT (envelope-from gnats) Date: Mon, 14 Dec 2009 18:50:02 GMT Message-Id: <200912141850.nBEIo2oO080341@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/141376: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:50:02 -0000 The following reply was made to PR kern/141376; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/141376: commit references a PR Date: Mon, 14 Dec 2009 18:43:47 +0000 (UTC) Author: rpaulo Date: Mon Dec 14 18:43:27 2009 New Revision: 200524 URL: http://svn.freebsd.org/changeset/base/200524 Log: Pass all IEs to net80211. PR: 141376 Submitted by: Paul MFC after: 1 week Modified: head/sys/dev/if_ndis/if_ndis.c Modified: head/sys/dev/if_ndis/if_ndis.c ============================================================================== --- head/sys/dev/if_ndis/if_ndis.c Mon Dec 14 18:43:18 2009 (r200523) +++ head/sys/dev/if_ndis/if_ndis.c Mon Dec 14 18:43:27 2009 (r200524) @@ -3299,24 +3299,11 @@ ndis_scan_results(struct ndis_softc *sc) efrm = frm + wb->nwbx_ielen; if (efrm - frm < 12) goto done; - sp.tstamp = frm; - frm += 8; - sp.bintval = le16toh(*(uint16_t *)frm); - frm += 2; - sp.capinfo = le16toh(*(uint16_t *)frm); - frm += 2; - - /* Grab variable length ies */ - while (efrm - frm > 1) { - if (efrm - frm < frm[1] + 2) - break; - switch (*frm) { - case IEEE80211_ELEMID_RSN: - sp.rsn = frm; - break; - } - frm += frm[1] + 2; - } + sp.tstamp = frm; frm += 8; + sp.bintval = le16toh(*(uint16_t *)frm); frm += 2; + sp.capinfo = le16toh(*(uint16_t *)frm); frm += 2; + sp.ies = frm; + sp.ies_len = efrm - frm; } done: DPRINTF(("scan: bssid %s chan %dMHz (%d/%d) rssi %d\n", _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 18:59:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF501065692 for ; Mon, 14 Dec 2009 18:59:28 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 667EC8FC08 for ; Mon, 14 Dec 2009 18:59:28 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBEIxR4x026595; Mon, 14 Dec 2009 10:59:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 10:59:25 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thread-Index: Acp8SKAbhwxMeAtwTF63R/FlkYplbgApuV0g References: From: "Li, Qing" To: "Dennis Glatting" , Cc: Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 18:59:28 -0000 I will take a look at it later today. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Dennis Glatting > Sent: Sunday, December 13, 2009 1:59 PM > To: freebsd-net@freebsd.org > Subject: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 >=20 > I am having a problem diagnosing a multiple IPv6 interfaces problem. > Any > hint is appreciated. >=20 > OS: >=20 > Elmer# uname -a FreeBSD Elmer 8.0-STABLE FreeBSD 8.0-STABLE #94: Fri > Dec 11 > 17:24:09 MST 2009 root@Elmer:/usr/src/sys/amd64/compile/ELMER amd64 >=20 >=20 > I have two interfaces on the same switch fabric. They both reside > within > the same prefix. One is IPv4/IPv6 and the other strictly IPv6. The > purpose > of these two interfaces is the "normal" stuff and a "bulk data net." > The > bulk data net is merely an Ethernet intreface with a larger MTU to aid > back-up (incoming data) and otehr tasks. The interfaces are defiend as > follows: >=20 > Elmer# ifconfig -a > bce0: flags=3D8843 metric 0 = mtu > 1500 >=20 > options=3D1bb ,TSO4> > ether 00:13:72:60:ac:52 > inet 172.19.10.10 netmask 0xffffff00 broadcast 172.19.10.255 > inet6 fe80::213:72ff:fe60:ac52%bce0 prefixlen 64 scopeid 0x1 > inet6 fd7c:3f2b:e791:1::ac13:a0a prefixlen 64 > nd6 options=3D3 > media: Ethernet 1000baseT > status: active > bce1: flags=3D8843 metric 0 = mtu > 8192 >=20 > options=3D1bb ,TSO4> > ether 00:13:72:60:ac:50 > inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a prefixlen 64 > inet6 fe80::213:72ff:fe60:ac50%bce1 prefixlen 64 scopeid 0x2 > nd6 options=3D3 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > nd6 options=3D3 >=20 > Bce1 is the bulk data net. I can ping6 a host out the bce0 interface > and > get a response. However, though I can send ping6 packets out bce1 to > the > same host, that host cannot discover the MAC for bce1. For example: >=20 > Elmer# ping6 -S fd7c:3f2b:e791:1::ac13:a0a docs.penx.com > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1::ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=3D0 hlim=3D64 time=3D0.301 > ms > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=3D1 hlim=3D64 time=3D0.224 > ms >=20 > Elmer# ping6 -S fd7c:3f2b:e791:1:0:1:ac13:a0a docs.penx.com > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 >=20 > (nothing returned). >=20 >=20 > Docs# tcpdump -n -q ip6 and not tcp and not udp > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > 13:11:05.557252 IP6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > fd7c:3f2b:e791:1::ac13:a15: ICMP6, echo request, seq 55, length 16 > 13:11:05.557275 IP6 fd7c:3f2b:e791:1::ac13:a15 > ff02::1:ff13:a0a: > ICMP6, neighbor solicitation, who has fd7c:3f2b:e791:1:0:1:ac13:a0a, > length 32 >=20 > (and so on) >=20 > Note: Docs: > bge0: flags=3D8843 metric 0 = mtu > 1500 > = options=3D9b > ether 00:11:85:ee:02:54 > inet 172.19.10.21 netmask 0xffffff00 broadcast 172.19.10.255 > inet6 fe80::211:85ff:feee:254%bge0 prefixlen 64 scopeid 0x1 > inet6 fd7c:3f2b:e791:1::ac13:a15 prefixlen 64 > nd6 options=3D3 > media: Ethernet autoselect (1000baseT ) > status: active >=20 >=20 > If I watch the bce1 interface on Elmer using TCPdump in another window > session, it is seeing the solicitation, at least via tcpdump; but no > response as to who has fd7c:3f2b:e791:1:0:1:ac13:a0a. >=20 > I've included other data below. I am at a loss to understand why the > bce1 > interface isn't being advertised on the fabric. I am an IPv6 newbie. I > have a router on the network. >=20 >=20 > Elmer# ndp -an > Neighbor Linklayer Address Netif Expire > S Flags > fe80::213:72ff:fe60:ac50%bce1 0:13:72:60:ac:50 bce1 permanent > R > fd7c:3f2b:e791:1:0:1:ac13:a0a 0:13:72:60:ac:50 bce1 permanent > R > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bce0 12s > R > fe80::213:72ff:fe60:ac52%bce0 0:13:72:60:ac:52 bce0 permanent > R > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bce0 23h58m20s > S R > fe80::217:95ff:fe25:5c90%bce0 0:17:95:25:5c:90 bce0 23h59m22s > S R > fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bce0 permanent > R >=20 >=20 > Docs# ndp -an > Neighbor Linklayer Address Netif Expire > S Flags > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bge0 permanent > R > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bge0 2s > D R > fe80::211:85ff:feee:254%bge0 0:11:85:ee:2:54 bge0 permanent > R > fe80::217:95ff:fe25:5c90%bge0 0:17:95:25:5c:90 bge0 23h58m30s > S R > fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bge0 23h59m46s > S >=20 >=20 > Elmer# netstat -rn > Routing tables >=20 > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 172.19.10.1 UGS 152 3711257 bce0 > 127.0.0.1 link#3 UH 0 442332 lo0 > 172.19.10.0/24 link#1 U 0 10116355 bce0 > 172.19.10.10 link#1 UHS 0 0 lo0 >=20 > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 =3D> > default fd7c:3f2b:e791:1::1 UGS > bce0 > ::1 ::1 UH > lo0 > ::ffff:0.0.0.0/96 ::1 UGRS > lo0 > fd7c:3f2b:e791:1::/64 link#1 U > bce0 > fd7c:3f2b:e791:1::ac13:a0a link#1 UHS > lo0 > fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS > lo0 > fe80::/10 ::1 UGRS > lo0 > fe80::%bce0/64 link#1 U > bce0 > fe80::213:72ff:fe60:ac52%bce0 link#1 UHS > lo0 > fe80::%bce1/64 link#2 U > bce1 > fe80::213:72ff:fe60:ac50%bce1 link#2 UHS > lo0 > fe80::%lo0/64 link#3 U > lo0 > fe80::1%lo0 link#3 UHS > lo0 > ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U > bce0 > ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 > ff01:3::/32 ::1 U > lo0 > ff02::/16 ::1 UGRS > lo0 > ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U > bce0 > ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > bce1 > ff02::%lo0/32 ::1 U > lo0 >=20 >=20 > Elmer's rc.config: >=20 > ipv6_enable=3D"YES" > ipv6_network_interfaces=3D"bce0 bce1" > ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen = 64" > ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 > mtu 8192" > ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" >=20 >=20 > The router (cisco): >=20 > interface GigabitEthernet0/0 > ipv6 address FD7C:3F2B:E791:1::1/64 > ipv6 enable > ipv6 nd prefix FD7C:3F2B:E791:1::/64 > (etc) >=20 >=20 > Elmer# tcpdump -nq ip6 and not tcp > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes > 13:21:52.819632 IP6 fe80::217:95ff:fe25:5c90 > ff02::1: ICMP6, router > advertisement, length 64 >=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" From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 19:20:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0612F1065676 for ; Mon, 14 Dec 2009 19:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E9E5B8FC26 for ; Mon, 14 Dec 2009 19:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEJK2RR005937 for ; Mon, 14 Dec 2009 19:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEJK2Dc005936; Mon, 14 Dec 2009 19:20:02 GMT (envelope-from gnats) Date: Mon, 14 Dec 2009 19:20:02 GMT Message-Id: <200912141920.nBEJK2Dc005936@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/139079: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:20:03 -0000 The following reply was made to PR kern/139079; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/139079: commit references a PR Date: Mon, 14 Dec 2009 19:18:15 +0000 (UTC) Author: gavin Date: Mon Dec 14 19:18:02 2009 New Revision: 200530 URL: http://svn.freebsd.org/changeset/base/200530 Log: Don't panic on failure to attach if we fail before or during the if_alloc() of ifp. This fixes the panic reported in the PR, but not the attach failure. PR: kern/139079 Tested by: Steven Noonan Reviewed by: thompsa Approved by: ed (mentor) MFC after: 2 weeks` Modified: head/sys/dev/wpi/if_wpi.c Modified: head/sys/dev/wpi/if_wpi.c ============================================================================== --- head/sys/dev/wpi/if_wpi.c Mon Dec 14 19:08:11 2009 (r200529) +++ head/sys/dev/wpi/if_wpi.c Mon Dec 14 19:18:02 2009 (r200530) @@ -713,13 +713,14 @@ wpi_detach(device_t dev) { struct wpi_softc *sc = device_get_softc(dev); struct ifnet *ifp = sc->sc_ifp; - struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211com *ic; int ac; - ieee80211_draintask(ic, &sc->sc_restarttask); - ieee80211_draintask(ic, &sc->sc_radiotask); - if (ifp != NULL) { + ic = ifp->if_l2com; + + ieee80211_draintask(ic, &sc->sc_restarttask); + ieee80211_draintask(ic, &sc->sc_radiotask); wpi_stop(sc); callout_drain(&sc->watchdog_to); callout_drain(&sc->calib_to); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 19:29:55 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E840106568B for ; Mon, 14 Dec 2009 19:29:55 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4518FC14 for ; Mon, 14 Dec 2009 19:29:55 +0000 (UTC) Received: by iwn36 with SMTP id 36so2290504iwn.3 for ; Mon, 14 Dec 2009 11:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=FmuatbJknlWZH1lq5AGcpY8S3kQs7PDf/bkI4K01Jv4=; b=ih/ZZPO2P23FiQaVbclbKrTGYge1QCE8D4g1ikpCNtnrovUWRRH21KNuGJFmzeL201 9iUagQM7mV/6dtf+Ws0vG1qGq/Aq5DfCM05gc01Zm4RI4esJKh5mELZSpYhKT6nN5jU1 VxbJp+F9Pb973bFf8Gw2G4j8FgeP2rrGsuLXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Xznohzn6iPQzUJnZme4mFhPLS4qUKlTPxDcoq/v390OCyP4VaMP+WsTZm7Cktv4GTW SGPS6eRRaGRHEGhmg+ARJFVYIE1mq4RWCe3CFNo5n2OOekkvGnvysQUttpEvo2DimYJ0 byfnNyKfqELFv8yvWsvWQ/U1HrMUkCBR+dlZE= MIME-Version: 1.0 Received: by 10.231.146.2 with SMTP id f2mr2765349ibv.23.1260818994768; Mon, 14 Dec 2009 11:29:54 -0800 (PST) Date: Mon, 14 Dec 2009 11:29:54 -0800 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:29:55 -0000 All, I'm having a very strange problem. I'm running ntop - the unnumbered interface is not receiving any data. Running 'tcpdump -i em0' also gets no data. I am really baffled - I've tried it against a switch that I know has a correctly configured mirror port, as I have ntop running on another machine and that works fine in the same port, but it's running 7.1-RELEASE. Anyone have thoughts on this? # uname -a FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # cat /etc/rc.conf hostname="zntop.mycompany.com" ifconfig_rl0="DHCP" ntpdate_enable="YES" ntpdate_flags="-b 192.168.10.191" sshd_enable="YES" ntop_enable="YES" ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" zntop# ifconfig em0: flags=8902 metric 0 mtu 1500 options=9b ether 00:1b:21:04:2a:c5 media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0c:46:b3:43:53 inet 192.168.24.51 netmask 0xffffff00 broadcast 192.168.24.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 Kurt From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 19:35:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86416106566B for ; Mon, 14 Dec 2009 19:35:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDE98FC13 for ; Mon, 14 Dec 2009 19:35:48 +0000 (UTC) Received: by ewy26 with SMTP id 26so4027220ewy.3 for ; Mon, 14 Dec 2009 11:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mKz6z6HkLuXYoNQ2G1oUxFDZE+aVHF6V6KtCWN8ffkM=; b=On3/dz8p3dvjO79RwmFm/4Wmy4CDaVyhR80dUOVrouQWt55uVYiauks09tLQfbIB0h jtfuPKgG4hTjgcyNLhRqPSR8DvqWkqvphBK8JrqJMToV9nx1bYuApT95JNZuwi1iLYCc 5yXd8G6UQYKXouPbHHJ8BGDLsBPGpZnG6mOWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n7O4lqi+fVmTvhp186JF3i3l5zu9Jjhr+g8BsQeCa3OGPqskLzkjtrgsMnzyv6CW+q TBxZiKId4kbH6MKN2reGf+DWmm44pMmC1F1nFCYt5rmCN4g7LtVfhQyu+AVsBqeAGMVX tDYB1+//l4SZA0eDQhnxz+Zz9fetSNFsCgsbE= MIME-Version: 1.0 Received: by 10.216.88.7 with SMTP id z7mr2196305wee.19.1260819347895; Mon, 14 Dec 2009 11:35:47 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Dec 2009 11:35:47 -0800 Message-ID: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> From: Jack Vogel To: Kurt Buff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:35:49 -0000 Not familiar with ntop, but I notice below that the em interface is not UP, what if you `ifup em0` ? Jack On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: > All, > > I'm having a very strange problem. I'm running ntop - the unnumbered > interface is not receiving any data. > > Running 'tcpdump -i em0' also gets no data. I am really baffled - I've > tried it against a switch that I know has a correctly configured > mirror port, as I have ntop running on another machine and that works > fine in the same port, but it's running 7.1-RELEASE. > > Anyone have thoughts on this? > > > # uname -a > FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > Nov 21 15:48:17 UTC 2009 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > # cat /etc/rc.conf > hostname="zntop.mycompany.com" > ifconfig_rl0="DHCP" > ntpdate_enable="YES" > ntpdate_flags="-b 192.168.10.191" > sshd_enable="YES" > ntop_enable="YES" > ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" > > zntop# ifconfig > em0: flags=8902 metric 0 mtu 1500 > options=9b > ether 00:1b:21:04:2a:c5 > media: Ethernet autoselect (100baseTX ) > status: active > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0c:46:b3:43:53 > inet 192.168.24.51 netmask 0xffffff00 broadcast 192.168.24.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > > > Kurt > _______________________________________________ > 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 Mon Dec 14 19:39:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E84E106566C for ; Mon, 14 Dec 2009 19:39:22 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 452C98FC0C for ; Mon, 14 Dec 2009 19:39:22 +0000 (UTC) Received: by iwn36 with SMTP id 36so2297107iwn.3 for ; Mon, 14 Dec 2009 11:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KQpm4WQgBJs4nPmHBAI+e4P/1dU2Do57UI9nIHp7VZY=; b=xRNvTDWVLz82Q6c0Nut6fAreSru0YH+JSVa7o6OOSeMLvNzlMfLij7kYJPcqnUkQ8f S9qfByUN3WqZDFTpiPHktTlW0QAg/65UQLgUdqVc4l+BQBD/c3YGVhpsHp2XviehhZbw SgA0DfMU+Aes3Ai0zyydGH6twyTECOjuF6xTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m1+hxxD+7BeJTLTMbMTKiY7Leiyqfk5zY3PbOewczq+sCdQcZWXnTcA08Hp0P2Gp4U dgffV/vfhv7npc1917/Q8/i7s7xKp3bPTFsBSmH02D1uHqAteMfJZy5I2a3GXXu6g/0H JlCwbGWSjzjzXfHE+0CDYvDSNpWSM5vvKF/CU= MIME-Version: 1.0 Received: by 10.231.21.157 with SMTP id j29mr508115ibb.28.1260819561790; Mon, 14 Dec 2009 11:39:21 -0800 (PST) In-Reply-To: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> Date: Mon, 14 Dec 2009 11:39:21 -0800 Message-ID: From: Kurt Buff To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:39:22 -0000 Sigh. Yes, that works. So, to expose even more of my ignorance, any thoughts on why it isn't up at boot? Kurt On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > Not familiar with ntop, but I notice below that the em interface is not U= P, > what > if you `ifup em0` ? > > Jack > > > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: >> >> All, >> >> I'm having a very strange problem. I'm running ntop - the unnumbered >> interface is not receiving any data. >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >> tried it against a switch that I know has a correctly configured >> mirror port, as I have ntop running on another machine and that works >> fine in the same port, but it's running 7.1-RELEASE. >> >> Anyone have thoughts on this? >> >> >> # uname -a >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >> Nov 21 15:48:17 UTC 2009 >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =C2=A0i386 >> >> # cat /etc/rc.conf >> hostname=3D"zntop.mycompany.com" >> ifconfig_rl0=3D"DHCP" >> ntpdate_enable=3D"YES" >> ntpdate_flags=3D"-b 192.168.10.191" >> sshd_enable=3D"YES" >> ntop_enable=3D"YES" >> ntop_flags=3D"-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W= 0" >> >> zntop# ifconfig >> em0: flags=3D8902 metric 0 mtu 1500 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D9b >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:1b:21:04:2a:c5 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> rl0: flags=3D8843 metric 0 mtu 1= 500 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D8 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:0c:46:b3:43:53 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 192.168.24.51 netmask 0xffffff00 broadca= st 192.168.24.255 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> lo0: flags=3D8049 metric 0 mtu 16384 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 ::1 prefixlen 128 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 127.0.0.1 netmask 0xff000000 >> >> >> Kurt >> _______________________________________________ >> 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 Mon Dec 14 19:42:01 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DFA81065679 for ; Mon, 14 Dec 2009 19:42:01 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 36FA28FC1D for ; Mon, 14 Dec 2009 19:42:01 +0000 (UTC) Received: from supra.b1c1l1.com (netops-172.sfo1.bitgravity.com [209.131.110.172]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id A0D485C29; Mon, 14 Dec 2009 11:42:00 -0800 (PST) Message-ID: <4B269501.2080706@b1c1l1.com> Date: Mon, 14 Dec 2009 11:41:53 -0800 From: Benjamin Lee User-Agent: Thunderbird 2.0.0.23 (X11/20090829) MIME-Version: 1.0 To: Chris Cowart References: <20091211052349.0000517a@unknown> <20091211065141.GL88840@marvin.timesinks.net> In-Reply-To: <20091211065141.GL88840@marvin.timesinks.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6EFAB83EBD269B7769C12AAB" Cc: Bruce Cran , freebsd-net@freebsd.org Subject: Re: Running rtadvd or DHCPv6 server via if_bridge interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:42:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6EFAB83EBD269B7769C12AAB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/10/2009 10:51 PM, Chris Cowart wrote: > Bruce Cran wrote: >> I have a router configured using if_bridge with a 4-port NIC that's >> serving addresses over DHCP. I'd like to add in either rtadvd or >> DHCPv6, but neither work because the bridge interface doesn't have an >> IPv6 link-local address. Is there a way around this, or is it not >> possible to serve IPv6 addresses over if_bridge interfaces? >=20 > It's totally doable; you just have to assigned a link-local address to > the bridge. There are some reasons why one isn't defined by default, > which somebody more knowledgeable about the challenges in the > implementation can highlight. >=20 > Here's my configuration from rc.conf: >=20 > ipv6_ifconfig_bridge0=3D"2001:470:8337:10::1/64" > ipv6_ifconfig_bridge0_alias0=3D"fe80::2%bridge0 prefixlen 64" >=20 > Once you're doing that, rtadvd will start doing the right thing. My workaround was to enumerate each bridge member in rc.conf: rtadvd_interfaces=3D"vlan1 wlan0" --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enig6EFAB83EBD269B7769C12AAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJLJpUHAAoJEHBW16CPoSMCzI8P/iyCENlPuSqbr1MD3EphAkTG RRKkT7ILqWwtKOYCudQqYtceMgb1/rJvqotjAi/ccz6U4akPjyFwhp4nB3W+6Kqk 4sFxkqpYaWIfoO9eGBwIQ4Fa9YwoAlv+5EnefvWhfU4o6071QWov4SwrezAfywC8 rQHA9bsU9fkxz+iB2CSZbkU5ZqlJgj56Apf18+8MAgB1nAAopkcPZr3uUncJ12e2 Rcss+qUu+WLm9ibTU/cHLtw8ZVZEqrizBZ0qHeubRyWYkF5NM3Hbp6eSlSnleQjn mpNim9pmyYG3gPM37EAA695BrL6zczsUuIxb3rwR169+p6AOnQO/u+OHoGNEjSTh +1ELY5B0dq8JthlYqIvFWjquqczOROituR+0+xGVfejJk7/jOrrvG8hG6ImDTyCB ntSMCHG/1/eYJjhZq2lJsPIs35HJvZ/y0A+hKBX4foeMNA8gRlaDfbjkUJqw2lOK keOLJGpqyZpjxvuRjVjABXiSloEk1l+xbUBnTNjG3ByCM2VBlZ4XZf6Y/ec1ia3x Q8eGmAIcWwqNb0bw4dwU/skfOnUyhQPsgsjDptYinETRizSO2858wzBdhDuyf+c7 mVE9iCSQPP635EwiapTzVtV0fx7UAJ2fQrvgpUNlH3EUv5SZJcysuks2uV6ZUB2X /MorgO1D7N1kv+mWCN+R =1ief -----END PGP SIGNATURE----- --------------enig6EFAB83EBD269B7769C12AAB-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 19:48:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72C23106566C for ; Mon, 14 Dec 2009 19:48:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id F23D58FC23 for ; Mon, 14 Dec 2009 19:48:29 +0000 (UTC) Received: by ewy26 with SMTP id 26so4040216ewy.3 for ; Mon, 14 Dec 2009 11:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xsJV+pV7OtttBHcK4xi/6tvVCqVZQawEV/jTRahSxHM=; b=iK9IOP8ulrECsOHv9spd/Wn57zH2BO5zG5pg9cjuWKIDO5TWNuluLUyjxqxtZI0L9W s5ZLgnZJlzsdmRqLYmyljzaZY4RYj8hfhmuclJnfoCaFgMSc83FduCUPkPEcQxRAWN+Z 5WEUi+UmHtebfd2pWijm9i+w9T0OObkngiaIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ffgEzGwquilMoq/6B3cRcuhXrrLukbhWaNvC0qyqG19sXmug4PJmBguSn3f967Olho 6GIzpAPJp8vD9qCsXXNmJFA8axjLVtt3JcodgXBP32hBAF35t9A55Rk+zSTX3a+0nxFx vrarqqJ+pM9SOVBDn2Of+VWtgX/wYog8F2mi0= MIME-Version: 1.0 Received: by 10.216.89.73 with SMTP id b51mr2125728wef.125.1260820108914; Mon, 14 Dec 2009 11:48:28 -0800 (PST) In-Reply-To: References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> Date: Mon, 14 Dec 2009 11:48:28 -0800 Message-ID: <2a41acea0912141148y409453efj3cfc827723ec6fa8@mail.gmail.com> From: Jack Vogel To: Kurt Buff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:48:30 -0000 Usually assigning an address will bring it up, but you arent doing that, I am pretty sure using a pseudo device will always necessitating explicitly bringing it up, at least i know that is the case for VLANs also. Jack On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: > Sigh. Yes, that works. > > So, to expose even more of my ignorance, any thoughts on why it isn't > up at boot? > > Kurt > > On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > > Not familiar with ntop, but I notice below that the em interface is not > UP, > > what > > if you `ifup em0` ? > > > > Jack > > > > > > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: > >> > >> All, > >> > >> I'm having a very strange problem. I'm running ntop - the unnumbered > >> interface is not receiving any data. > >> > >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've > >> tried it against a switch that I know has a correctly configured > >> mirror port, as I have ntop running on another machine and that works > >> fine in the same port, but it's running 7.1-RELEASE. > >> > >> Anyone have thoughts on this? > >> > >> > >> # uname -a > >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > >> Nov 21 15:48:17 UTC 2009 > >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> > >> # cat /etc/rc.conf > >> hostname="zntop.mycompany.com" > >> ifconfig_rl0="DHCP" > >> ntpdate_enable="YES" > >> ntpdate_flags="-b 192.168.10.191" > >> sshd_enable="YES" > >> ntop_enable="YES" > >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W > 0" > >> > >> zntop# ifconfig > >> em0: flags=8902 metric 0 mtu 1500 > >> options=9b > >> ether 00:1b:21:04:2a:c5 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> rl0: flags=8843 metric 0 mtu > 1500 > >> options=8 > >> ether 00:0c:46:b3:43:53 > >> inet 192.168.24.51 netmask 0xffffff00 broadcast 192.168.24.255 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> lo0: flags=8049 metric 0 mtu 16384 > >> options=3 > >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >> inet6 ::1 prefixlen 128 > >> inet 127.0.0.1 netmask 0xff000000 > >> > >> > >> Kurt > >> _______________________________________________ > >> 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 Mon Dec 14 19:52:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1627D1065670 for ; Mon, 14 Dec 2009 19:52:49 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id CF4118FC08 for ; Mon, 14 Dec 2009 19:52:48 +0000 (UTC) Received: by iwn36 with SMTP id 36so2306774iwn.3 for ; Mon, 14 Dec 2009 11:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mSsO/xoWD7r/G60gs1mcj0c8SCHfg/YWYCmVgCa2PM8=; b=ptyXB5MioegCAGpDaVFKVsA6riXwOWxe0LpyvZ0Ej8lnEbQ49FnX8eNfvGHazDAjwu iEbf9jlr3ysv9PyMAMEra52ZpvjqLLf4Dwu5GyqlrWP0IFCOdP8R/YFEfBn9CImx/0BF O5lXmKH9Vvn7aLRRMk/l2jkjznRiqM22Jbo4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=h1lXyGqeEpuJy0JjrvubLDPTA4r7mjp32XTpt8evPBr+O/WtLy8vS3BKpITZfyQrVk zmOduZLM4JebfE/5mbjFJ6NMhsjA662/0KbIqOo4AdLptkdFU1PMvdRqO11OEkNckgsh Ty8z0VFsMtV6+oktDM61uz9Scfe1QP9taxOtM= MIME-Version: 1.0 Received: by 10.231.125.28 with SMTP id w28mr551128ibr.50.1260820367166; Mon, 14 Dec 2009 11:52:47 -0800 (PST) In-Reply-To: <2a41acea0912141148y409453efj3cfc827723ec6fa8@mail.gmail.com> References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> <2a41acea0912141148y409453efj3cfc827723ec6fa8@mail.gmail.com> Date: Mon, 14 Dec 2009 11:52:47 -0800 Message-ID: From: Kurt Buff To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:52:49 -0000 Interesting. I'm doing nothing really very different on my 7.1R box, but don't have this issue. Oh, well - just something to keep in mind, I suppose. Kurt On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: > Usually assigning an address will bring it up, but you arent doing that, = I > am > pretty sure using a pseudo device will always necessitating explicitly > bringing > it up, at least i know that is the case for VLANs also. > > Jack > > > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: >> >> Sigh. Yes, that works. >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> up at boot? >> >> Kurt >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> > Not familiar with ntop, but I notice below that the em interface is no= t >> > UP, >> > what >> > if you `ifup em0` ? >> > >> > Jack >> > >> > >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrot= e: >> >> >> >> All, >> >> >> >> I'm having a very strange problem. I'm running ntop - the unnumbered >> >> interface is not receiving any data. >> >> >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - I'v= e >> >> tried it against a switch that I know has a correctly configured >> >> mirror port, as I have ntop running on another machine and that works >> >> fine in the same port, but it's running 7.1-RELEASE. >> >> >> >> Anyone have thoughts on this? >> >> >> >> >> >> # uname -a >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >> >> Nov 21 15:48:17 UTC 2009 >> >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =C2=A0i386 >> >> >> >> # cat /etc/rc.conf >> >> hostname=3D"zntop.mycompany.com" >> >> ifconfig_rl0=3D"DHCP" >> >> ntpdate_enable=3D"YES" >> >> ntpdate_flags=3D"-b 192.168.10.191" >> >> sshd_enable=3D"YES" >> >> ntop_enable=3D"YES" >> >> ntop_flags=3D"-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0= -W >> >> 0" >> >> >> >> zntop# ifconfig >> >> em0: flags=3D8902 metric 0 mtu 1= 500 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D9b >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:1b:21:04:2a:c5 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> >> rl0: flags=3D8843 metric 0 mt= u >> >> 1500 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D8 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:0c:46:b3:43:53 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 192.168.24.51 netmask 0xffffff00 broa= dcast 192.168.24.255 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> >> lo0: flags=3D8049 metric 0 mtu 16384 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D3 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 ::1 prefixlen 128 >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 127.0.0.1 netmask 0xff000000 >> >> >> >> >> >> Kurt >> >> _______________________________________________ >> >> 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 Mon Dec 14 19:57:18 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD5441065670 for ; Mon, 14 Dec 2009 19:57:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 38F1B8FC23 for ; Mon, 14 Dec 2009 19:57:18 +0000 (UTC) Received: by fxm28 with SMTP id 28so1751459fxm.13 for ; Mon, 14 Dec 2009 11:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=43XBWIa3qsGd/3PE/7nxBZf4ZWvN5y4BRizwoe/ZWNw=; b=B3y8l9+K5RCuq9/Am/x6DliBiHxT7Xkhh0yKiFl8NfjvMjV3AvrLw1C8YAaD4ZwGBG 940YvMQ9v6MAqLC4euj8r+hO/dEqqk6Hsz6yMszZYilJWxA48fGu3PtzGzSfIhn4nLNq dHvhKDSxR4jpfLPrbrAiWZNyAtHkM65nt2Wbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UOnvvPXt9sk+L5ZL4A7QEuL4xoQWrgjogwmxjfhnnpHgX3gSztweJh4pmHE1jkdxV6 OZkU+bwQEwbOsLNA7CG+gRvW5aP0Ik8sOh3SkM1aOfOFQPZt1XRlJjEgkFpGcs1Dj6F+ V6finJ4HCUwFtH0cMDziABGvPx7t5zZ/GnBSI= MIME-Version: 1.0 Received: by 10.216.90.70 with SMTP id d48mr2218170wef.159.1260820637066; Mon, 14 Dec 2009 11:57:17 -0800 (PST) In-Reply-To: References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> <2a41acea0912141148y409453efj3cfc827723ec6fa8@mail.gmail.com> Date: Mon, 14 Dec 2009 11:57:17 -0800 Message-ID: <2a41acea0912141157n664c2586o3f6d15cb71e0283e@mail.gmail.com> From: Jack Vogel To: Kurt Buff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:57:18 -0000 Hmmm, well there's a LOT of shared code changes between 7.1 and 8, and this sounds like something in the device init. I don't really have time to look into the difference right now, you'll just have to live with the difference, sorry :) Jack On Mon, Dec 14, 2009 at 11:52 AM, Kurt Buff wrote: > Interesting. > > I'm doing nothing really very different on my 7.1R box, but don't have > this issue. > > Oh, well - just something to keep in mind, I suppose. > > Kurt > > On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: > > Usually assigning an address will bring it up, but you arent doing that, > I > > am > > pretty sure using a pseudo device will always necessitating explicitly > > bringing > > it up, at least i know that is the case for VLANs also. > > > > Jack > > > > > > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrote: > >> > >> Sigh. Yes, that works. > >> > >> So, to expose even more of my ignorance, any thoughts on why it isn't > >> up at boot? > >> > >> Kurt > >> > >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: > >> > Not familiar with ntop, but I notice below that the em interface is > not > >> > UP, > >> > what > >> > if you `ifup em0` ? > >> > > >> > Jack > >> > > >> > > >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff > wrote: > >> >> > >> >> All, > >> >> > >> >> I'm having a very strange problem. I'm running ntop - the unnumbered > >> >> interface is not receiving any data. > >> >> > >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - > I've > >> >> tried it against a switch that I know has a correctly configured > >> >> mirror port, as I have ntop running on another machine and that works > >> >> fine in the same port, but it's running 7.1-RELEASE. > >> >> > >> >> Anyone have thoughts on this? > >> >> > >> >> > >> >> # uname -a > >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat > >> >> Nov 21 15:48:17 UTC 2009 > >> >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> >> > >> >> # cat /etc/rc.conf > >> >> hostname="zntop.mycompany.com" > >> >> ifconfig_rl0="DHCP" > >> >> ntpdate_enable="YES" > >> >> ntpdate_flags="-b 192.168.10.191" > >> >> sshd_enable="YES" > >> >> ntop_enable="YES" > >> >> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 > -W > >> >> 0" > >> >> > >> >> zntop# ifconfig > >> >> em0: flags=8902 metric 0 mtu > 1500 > >> >> options=9b > >> >> ether 00:1b:21:04:2a:c5 > >> >> media: Ethernet autoselect (100baseTX ) > >> >> status: active > >> >> rl0: flags=8843 metric 0 mtu > >> >> 1500 > >> >> options=8 > >> >> ether 00:0c:46:b3:43:53 > >> >> inet 192.168.24.51 netmask 0xffffff00 broadcast 192.168.24.255 > >> >> media: Ethernet autoselect (100baseTX ) > >> >> status: active > >> >> lo0: flags=8049 metric 0 mtu 16384 > >> >> options=3 > >> >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >> >> inet6 ::1 prefixlen 128 > >> >> inet 127.0.0.1 netmask 0xff000000 > >> >> > >> >> > >> >> Kurt > >> >> _______________________________________________ > >> >> 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 Mon Dec 14 20:01:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1B6106566B for ; Mon, 14 Dec 2009 20:01:47 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDC18FC0C for ; Mon, 14 Dec 2009 20:01:46 +0000 (UTC) Received: by iwn36 with SMTP id 36so2313204iwn.3 for ; Mon, 14 Dec 2009 12:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4d36Uw2wq1p5uNKhn6vY/6EkRw4xB2zy8NJRf5kWQzk=; b=Uaw0hbH7FRlO+3ALhFBU/pCWAAmd46IQ4zu+G3BpUiAsLekd1ynfbGknJBQGKojvO3 +a7USZobdA3a1LrXdUNeWffyHfvt6e0x+8llfMvOHSpXa+JzemJt4JjD+M/D8dHbn5eR FVfZWweC2X2gwANPGY/BiZi0ubwLw0seN1zHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ae0tqYSPzxoRxxAeVMziNtCuEBJR+CFhRT++VQXVN5d4IlGMAalVv4gB/zW1xClYU7 JcdlhQfaoWDWK/CZMncELJfr7vbTnnNC1/PXUpGe6USb3gkwjI3UdGSOWmbPxYPijsSu HkZz5PdCNZdOukIVgJlj59UE44+j8ONJBU8sk= MIME-Version: 1.0 Received: by 10.231.29.149 with SMTP id q21mr469456ibc.35.1260820906292; Mon, 14 Dec 2009 12:01:46 -0800 (PST) In-Reply-To: <2a41acea0912141157n664c2586o3f6d15cb71e0283e@mail.gmail.com> References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> <2a41acea0912141148y409453efj3cfc827723ec6fa8@mail.gmail.com> <2a41acea0912141157n664c2586o3f6d15cb71e0283e@mail.gmail.com> Date: Mon, 14 Dec 2009 12:01:46 -0800 Message-ID: From: Kurt Buff To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:01:47 -0000 Heh. Not a problem. Kurt On Mon, Dec 14, 2009 at 11:57, Jack Vogel wrote: > Hmmm, well there's a LOT of shared code changes between 7.1 and 8, and th= is > sounds like something in the device init.=C2=A0 I don't really have time = to look > into the > difference right now,=C2=A0 you'll just have to live with the difference,= sorry > :) > > Jack > > > On Mon, Dec 14, 2009 at 11:52 AM, Kurt Buff wrote: >> >> Interesting. >> >> I'm doing nothing really very different on my 7.1R box, but don't have >> this issue. >> >> Oh, well - just something to keep in mind, I suppose. >> >> Kurt >> >> On Mon, Dec 14, 2009 at 11:48, Jack Vogel wrote: >> > Usually assigning an address will bring it up, but you arent doing tha= t, >> > I >> > am >> > pretty sure using a pseudo device will always necessitating explicitly >> > bringing >> > it up, at least i know that is the case for VLANs also. >> > >> > Jack >> > >> > >> > On Mon, Dec 14, 2009 at 11:39 AM, Kurt Buff wrot= e: >> >> >> >> Sigh. Yes, that works. >> >> >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> >> up at boot? >> >> >> >> Kurt >> >> >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> >> > Not familiar with ntop, but I notice below that the em interface is >> >> > not >> >> > UP, >> >> > what >> >> > if you `ifup em0` ? >> >> > >> >> > Jack >> >> > >> >> > >> >> > On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff >> >> > wrote: >> >> >> >> >> >> All, >> >> >> >> >> >> I'm having a very strange problem. I'm running ntop - the unnumber= ed >> >> >> interface is not receiving any data. >> >> >> >> >> >> Running 'tcpdump -i em0' also gets no data. I am really baffled - >> >> >> I've >> >> >> tried it against a switch that I know has a correctly configured >> >> >> mirror port, as I have ntop running on another machine and that >> >> >> works >> >> >> fine in the same port, but it's running 7.1-RELEASE. >> >> >> >> >> >> Anyone have thoughts on this? >> >> >> >> >> >> >> >> >> # uname -a >> >> >> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sa= t >> >> >> Nov 21 15:48:17 UTC 2009 >> >> >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =C2=A0i3= 86 >> >> >> >> >> >> # cat /etc/rc.conf >> >> >> hostname=3D"zntop.mycompany.com" >> >> >> ifconfig_rl0=3D"DHCP" >> >> >> ntpdate_enable=3D"YES" >> >> >> ntpdate_flags=3D"-b 192.168.10.191" >> >> >> sshd_enable=3D"YES" >> >> >> ntop_enable=3D"YES" >> >> >> ntop_flags=3D"-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i = em0 >> >> >> -W >> >> >> 0" >> >> >> >> >> >> zntop# ifconfig >> >> >> em0: flags=3D8902 metric 0 mt= u >> >> >> 1500 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D9b >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:1b:21:04:2a:c5 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX <= full-duplex>) >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> >> >> rl0: flags=3D8843 metric 0= mtu >> >> >> 1500 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D8 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:0c:46:b3:43:53 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 192.168.24.51 netmask 0xffffff00 b= roadcast >> >> >> 192.168.24.255 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX <= full-duplex>) >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >> >> >> lo0: flags=3D8049 metric 0 mtu 1638= 4 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D3 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 fe80::1%lo0 prefixlen 64 scopeid = 0x3 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 ::1 prefixlen 128 >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 127.0.0.1 netmask 0xff000000 >> >> >> >> >> >> >> >> >> Kurt >> >> >> _______________________________________________ >> >> >> 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 Mon Dec 14 20:18:04 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 142E0106568B for ; Mon, 14 Dec 2009 20:18:04 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id B6F1A8FC0C for ; Mon, 14 Dec 2009 20:18:03 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 82D5348B45; Mon, 14 Dec 2009 20:18:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy1b6Kaua7MK; Mon, 14 Dec 2009 20:17:58 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id D2AC548B42; Mon, 14 Dec 2009 20:17:56 +0000 (GMT) Message-ID: <4B269D1F.3000501@tomjudge.com> Date: Mon, 14 Dec 2009 20:16:31 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kurt Buff References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:18:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kurt Buff wrote: > Sigh. Yes, that works. > > So, to expose even more of my ignorance, any thoughts on why it isn't > up at boot? > /etc/rc.conf: ifconfig_em0="UP" > Kurt > > On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >> Not familiar with ntop, but I notice below that the em interface is not UP, >> what >> if you `ifup em0` ? >> >> Jack >> >> >> On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote: >>> All, >>> >>> I'm having a very strange problem. I'm running ntop - the unnumbered >>> interface is not receiving any data. >>> >>> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >>> tried it against a switch that I know has a correctly configured >>> mirror port, as I have ntop running on another machine and that works >>> fine in the same port, but it's running 7.1-RELEASE. >>> >>> Anyone have thoughts on this? >>> >>> >>> # uname -a >>> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >>> Nov 21 15:48:17 UTC 2009 >>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> # cat /etc/rc.conf >>> hostname="zntop.mycompany.com" >>> ifconfig_rl0="DHCP" >>> ntpdate_enable="YES" >>> ntpdate_flags="-b 192.168.10.191" >>> sshd_enable="YES" >>> ntop_enable="YES" >>> ntop_flags="-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 -W 0" >>> >>> zntop# ifconfig >>> em0: flags=8902 metric 0 mtu 1500 >>> options=9b >>> ether 00:1b:21:04:2a:c5 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> rl0: flags=8843 metric 0 mtu 1500 >>> options=8 >>> ether 00:0c:46:b3:43:53 >>> inet 192.168.24.51 netmask 0xffffff00 broadcast 192.168.24.255 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> lo0: flags=8049 metric 0 mtu 16384 >>> options=3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>> inet6 ::1 prefixlen 128 >>> inet 127.0.0.1 netmask 0xff000000 >>> >>> >>> Kurt >>> _______________________________________________ >>> 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" - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJp0eAAoJEMSwVS7lr0OdTRcIAIoEqsw+3Va6QSRDsCpOyVZY q/QdmlMQ9hLV5KM9VakXxQAyaLSAzqmF9l3YdAtfoDsTdOwVzzi+XpVIQa4pxRLE a8XWjkIc8xXHXwq30tqJa75EZuExhvGjZqaB8nhMEpvTWodYF1OcoP8OfaXHc9ZO RsC9jl6pIRbcR83AsTH+ZK8g2hzKvNEDT1Uw9/RfK7X/Fa3Jzkdb2041fIzQEsel 4FCuNGUbmu2noDGPN06zMCGUCLwukWzuAq13DuzX+1B4UgrJf4fVfDuESA3SWlr3 kvCZllDIWmcfsKnaUmkQ80qRVJws0hjZAfjHWYk6tHFIMzxVp5MOx+Lyumq6WEQ= =aTAi -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 20:37:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4B11065692 for ; Mon, 14 Dec 2009 20:37:37 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id A0A3F8FC1E for ; Mon, 14 Dec 2009 20:37:37 +0000 (UTC) Received: by iwn36 with SMTP id 36so2338252iwn.3 for ; Mon, 14 Dec 2009 12:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9Iq2qEFne95PbOHt6yHrvl2bn6dgjbDifza68La6miQ=; b=iPK/HPvs9ILM7sJFslacWjv2ThwyZ2z683cqxcTKJDQ2L75hoEBUVLAXuYcIILnaw8 V3tGmSwh9xQ9toSMeIwW+oSVrbr0MmiM70RV76v7gy9k6u6/5VTowR0dC8jqSc/umsQX IMim413N/O8o1KbDsEC6AbgqDjDgYs7FzH1/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ffB9UO4FKHZwnU9z3eWvZiuGLs9HeievLLzHnNlhHmdCpqEImrhOOxroUi9pizm5DF C6giu+k6Zlex2mDboJFl05j6PDkfOawB6RmsvBFo9Xix0ntO5RL2P4tR4nyhVrialh7w J/pDhHOJpNOVkfB/WGkk2aGHWggelS/xqkd/I= MIME-Version: 1.0 Received: by 10.231.29.149 with SMTP id q21mr502751ibc.35.1260823056995; Mon, 14 Dec 2009 12:37:36 -0800 (PST) In-Reply-To: <4B269D1F.3000501@tomjudge.com> References: <2a41acea0912141135k35a4bd1fi8f727aaf19a188ec@mail.gmail.com> <4B269D1F.3000501@tomjudge.com> Date: Mon, 14 Dec 2009 12:37:36 -0800 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Not seeing data on an unnumbered interface... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:37:37 -0000 Oh, good grief. That's way too easy. How can I be l33t if it's that simple? Thanks. Kurt On Mon, Dec 14, 2009 at 12:16, Tom Judge wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kurt Buff wrote: >> Sigh. Yes, that works. >> >> So, to expose even more of my ignorance, any thoughts on why it isn't >> up at boot? >> > > /etc/rc.conf: > > ifconfig_em0=3D"UP" > > > > >> Kurt >> >> On Mon, Dec 14, 2009 at 11:35, Jack Vogel wrote: >>> Not familiar with ntop, but I notice below that the em interface is not= UP, >>> what >>> if you `ifup em0` ? >>> >>> Jack >>> >>> >>> On Mon, Dec 14, 2009 at 11:29 AM, Kurt Buff wrote= : >>>> All, >>>> >>>> I'm having a very strange problem. I'm running ntop - the unnumbered >>>> interface is not receiving any data. >>>> >>>> Running 'tcpdump -i em0' also gets no data. I am really baffled - I've >>>> tried it against a switch that I know has a correctly configured >>>> mirror port, as I have ntop running on another machine and that works >>>> fine in the same port, but it's running 7.1-RELEASE. >>>> >>>> Anyone have thoughts on this? >>>> >>>> >>>> # uname -a >>>> FreeBSD zntop.mycompany.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat >>>> Nov 21 15:48:17 UTC 2009 >>>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =C2=A0i386 >>>> >>>> # cat /etc/rc.conf >>>> hostname=3D"zntop.mycompany.com" >>>> ifconfig_rl0=3D"DHCP" >>>> ntpdate_enable=3D"YES" >>>> ntpdate_flags=3D"-b 192.168.10.191" >>>> sshd_enable=3D"YES" >>>> ntop_enable=3D"YES" >>>> ntop_flags=3D"-d -u ntop -P /home/ntop/databases -K -L -t 6 -o -i em0 = -W 0" >>>> >>>> zntop# ifconfig >>>> em0: flags=3D8902 metric 0 mtu 15= 00 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D9b >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:1b:21:04:2a:c5 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >>>> rl0: flags=3D8843 metric 0 mtu= 1500 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D8 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:0c:46:b3:43:53 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 192.168.24.51 netmask 0xffffff00 broad= cast 192.168.24.255 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (100baseTX ) >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active >>>> lo0: flags=3D8049 metric 0 mtu 16384 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D3 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet6 ::1 prefixlen 128 >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 127.0.0.1 netmask 0xff000000 >>>> >>>> >>>> Kurt >>>> _______________________________________________ >>>> 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" > > > - -- > TJU13-ARIN > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.13 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLJp0eAAoJEMSwVS7lr0OdTRcIAIoEqsw+3Va6QSRDsCpOyVZY > q/QdmlMQ9hLV5KM9VakXxQAyaLSAzqmF9l3YdAtfoDsTdOwVzzi+XpVIQa4pxRLE > a8XWjkIc8xXHXwq30tqJa75EZuExhvGjZqaB8nhMEpvTWodYF1OcoP8OfaXHc9ZO > RsC9jl6pIRbcR83AsTH+ZK8g2hzKvNEDT1Uw9/RfK7X/Fa3Jzkdb2041fIzQEsel > 4FCuNGUbmu2noDGPN06zMCGUCLwukWzuAq13DuzX+1B4UgrJf4fVfDuESA3SWlr3 > kvCZllDIWmcfsKnaUmkQ80qRVJws0hjZAfjHWYk6tHFIMzxVp5MOx+Lyumq6WEQ=3D > =3DaTAi > -----END PGP SIGNATURE----- > From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 21:47:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C9B41065696 for ; Mon, 14 Dec 2009 21:47:36 +0000 (UTC) (envelope-from jgoral@choppertrading.com) Received: from mail2.guavatech.com (mail2.guavatech.com [66.28.82.13]) by mx1.freebsd.org (Postfix) with ESMTP id 377008FC1F for ; Mon, 14 Dec 2009 21:47:36 +0000 (UTC) X-AuditID: c0a80302-00000bd000000508-b9-4b26ae7915f3 Received: from chopperexchange.choppertrading.com ([10.21.11.70] RDNS failed) by mail2.guavatech.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 15:30:33 -0600 Received: from chopperexchange.choppertrading.com ([10.21.11.70]) by chopperexchange.choppertrading.com ([10.21.11.70]) with mapi; Mon, 14 Dec 2009 15:30:33 -0600 From: Jack Goral To: "'freebsd-net@freebsd.org'" Date: Mon, 14 Dec 2009 15:30:32 -0600 Thread-Topic: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) Thread-Index: Acp9BKpry5opf245QXW8qhoSi5TyMw== Message-ID: <44AE62A7ED7A1F40AF0FC503B50F92780154727454@chopperexchange.choppertrading.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 21:47:36 -0000 Any idea how to debug problem mentioned in the subject line? Command used to load stock driver: kldload if_cxgb.ko Thanks, Jack Goral ________________________________ CONFIDENTIALITY WARNING: This email including any attachments may contain p= rivileged or confidential information and is for the sole use of the intend= ed recipient(s). Any unauthorized use or disclosure of this communication i= s prohibited. This e-mail may also be subject to specific non-disclosure an= d confidentiality provisions. The information contained herein is the prope= rty of Chopper Trading, LLC. If you believe that you have received this ema= il in error, please notify the sender immediately and delete it from your s= ystem. From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 21:54:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBB1106566B for ; Mon, 14 Dec 2009 21:54:13 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3315A8FC0C for ; Mon, 14 Dec 2009 21:54:12 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBELsCdR025514; Mon, 14 Dec 2009 13:54:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 13:54:02 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thread-Index: Acp8SKAbhwxMeAtwTF63R/FlkYplbgApuV0gAAYSEhA= References: From: "Li, Qing" To: "Dennis Glatting" , Cc: Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 21:54:13 -0000 Please try the temporary patch at: http://people.freebsd.org/~qingli/nd6-ns.diff and it should fix your problem. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, December 14, 2009 10:59 AM > To: Dennis Glatting; freebsd-net@freebsd.org > Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 > I will take a look at it later today. >=20 > -- Qing >=20 >=20 > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > net@freebsd.org] On Behalf Of Dennis Glatting > > Sent: Sunday, December 13, 2009 1:59 PM > > To: freebsd-net@freebsd.org > > Subject: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > > > > I am having a problem diagnosing a multiple IPv6 interfaces problem. > > Any > > hint is appreciated. > > > > OS: > > > > Elmer# uname -a FreeBSD Elmer 8.0-STABLE FreeBSD 8.0-STABLE #94: Fri > > Dec 11 > > 17:24:09 MST 2009 root@Elmer:/usr/src/sys/amd64/compile/ELMER amd64 > > > > > > I have two interfaces on the same switch fabric. They both reside > > within > > the same prefix. One is IPv4/IPv6 and the other strictly IPv6. The > > purpose > > of these two interfaces is the "normal" stuff and a "bulk data net." > > The > > bulk data net is merely an Ethernet intreface with a larger MTU to > aid > > back-up (incoming data) and otehr tasks. The interfaces are defiend > as > > follows: > > > > Elmer# ifconfig -a > > bce0: flags=3D8843 metric 0 mtu > > 1500 > > > > > options=3D1bb > ,TSO4> > > ether 00:13:72:60:ac:52 > > inet 172.19.10.10 netmask 0xffffff00 broadcast 172.19.10.255 > > inet6 fe80::213:72ff:fe60:ac52%bce0 prefixlen 64 scopeid 0x1 > > inet6 fd7c:3f2b:e791:1::ac13:a0a prefixlen 64 > > nd6 options=3D3 > > media: Ethernet 1000baseT > > status: active > > bce1: flags=3D8843 metric 0 mtu > > 8192 > > > > > options=3D1bb > ,TSO4> > > ether 00:13:72:60:ac:50 > > inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a prefixlen 64 > > inet6 fe80::213:72ff:fe60:ac50%bce1 prefixlen 64 scopeid 0x2 > > nd6 options=3D3 > > media: Ethernet autoselect (1000baseT ) > > status: active > > lo0: flags=3D8049 metric 0 mtu 16384 > > options=3D3 > > inet 127.0.0.1 netmask 0xff000000 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > nd6 options=3D3 > > > > Bce1 is the bulk data net. I can ping6 a host out the bce0 interface > > and > > get a response. However, though I can send ping6 packets out bce1 to > > the > > same host, that host cannot discover the MAC for bce1. For example: > > > > Elmer# ping6 -S fd7c:3f2b:e791:1::ac13:a0a docs.penx.com > > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1::ac13:a0a --> > > fd7c:3f2b:e791:1::ac13:a15 > > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=3D0 hlim=3D64 > time=3D0.301 > > ms > > 16 bytes from fd7c:3f2b:e791:1::ac13:a15, icmp_seq=3D1 hlim=3D64 > time=3D0.224 > > ms > > > > Elmer# ping6 -S fd7c:3f2b:e791:1:0:1:ac13:a0a docs.penx.com > > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > > fd7c:3f2b:e791:1::ac13:a15 > > > > (nothing returned). > > > > > > Docs# tcpdump -n -q ip6 and not tcp and not udp > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > > 13:11:05.557252 IP6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > > fd7c:3f2b:e791:1::ac13:a15: ICMP6, echo request, seq 55, length 16 > > 13:11:05.557275 IP6 fd7c:3f2b:e791:1::ac13:a15 > ff02::1:ff13:a0a: > > ICMP6, neighbor solicitation, who has fd7c:3f2b:e791:1:0:1:ac13:a0a, > > length 32 > > > > (and so on) > > > > Note: Docs: > > bge0: flags=3D8843 metric 0 mtu > > 1500 > > options=3D9b > > ether 00:11:85:ee:02:54 > > inet 172.19.10.21 netmask 0xffffff00 broadcast 172.19.10.255 > > inet6 fe80::211:85ff:feee:254%bge0 prefixlen 64 scopeid 0x1 > > inet6 fd7c:3f2b:e791:1::ac13:a15 prefixlen 64 > > nd6 options=3D3 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > > > If I watch the bce1 interface on Elmer using TCPdump in another > window > > session, it is seeing the solicitation, at least via tcpdump; but no > > response as to who has fd7c:3f2b:e791:1:0:1:ac13:a0a. > > > > I've included other data below. I am at a loss to understand why the > > bce1 > > interface isn't being advertised on the fabric. I am an IPv6 newbie. > I > > have a router on the network. > > > > > > Elmer# ndp -an > > Neighbor Linklayer Address Netif Expire > > S Flags > > fe80::213:72ff:fe60:ac50%bce1 0:13:72:60:ac:50 bce1 > permanent > > R > > fd7c:3f2b:e791:1:0:1:ac13:a0a 0:13:72:60:ac:50 bce1 > permanent > > R > > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bce0 12s > > R > > fe80::213:72ff:fe60:ac52%bce0 0:13:72:60:ac:52 bce0 > permanent > > R > > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bce0 > 23h58m20s > > S R > > fe80::217:95ff:fe25:5c90%bce0 0:17:95:25:5c:90 bce0 > 23h59m22s > > S R > > fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bce0 > permanent > > R > > > > > > Docs# ndp -an > > Neighbor Linklayer Address Netif Expire > > S Flags > > fd7c:3f2b:e791:1::ac13:a15 0:11:85:ee:2:54 bge0 > permanent > > R > > fd7c:3f2b:e791:1::1 0:17:95:25:5c:90 bge0 2s > > D R > > fe80::211:85ff:feee:254%bge0 0:11:85:ee:2:54 bge0 > permanent > > R > > fe80::217:95ff:fe25:5c90%bge0 0:17:95:25:5c:90 bge0 > 23h58m30s > > S R > > fd7c:3f2b:e791:1::ac13:a0a 0:13:72:60:ac:52 bge0 > 23h59m46s > > S > > > > > > Elmer# netstat -rn > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif > > Expire > > default 172.19.10.1 UGS 152 3711257 bce0 > > 127.0.0.1 link#3 UH 0 442332 lo0 > > 172.19.10.0/24 link#1 U 0 10116355 bce0 > > 172.19.10.10 link#1 UHS 0 0 lo0 > > > > Internet6: > > Destination Gateway Flags > > Netif Expire > > ::/96 ::1 UGRS > > lo0 =3D> > > default fd7c:3f2b:e791:1::1 UGS > > bce0 > > ::1 ::1 UH > > lo0 > > ::ffff:0.0.0.0/96 ::1 UGRS > > lo0 > > fd7c:3f2b:e791:1::/64 link#1 U > > bce0 > > fd7c:3f2b:e791:1::ac13:a0a link#1 UHS > > lo0 > > fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS > > lo0 > > fe80::/10 ::1 UGRS > > lo0 > > fe80::%bce0/64 link#1 U > > bce0 > > fe80::213:72ff:fe60:ac52%bce0 link#1 UHS > > lo0 > > fe80::%bce1/64 link#2 U > > bce1 > > fe80::213:72ff:fe60:ac50%bce1 link#2 UHS > > lo0 > > fe80::%lo0/64 link#3 U > > lo0 > > fe80::1%lo0 link#3 UHS > > lo0 > > ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U > > bce0 > > ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > > bce1 > > ff01:3::/32 ::1 U > > lo0 > > ff02::/16 ::1 UGRS > > lo0 > > ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U > > bce0 > > ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U > > bce1 > > ff02::%lo0/32 ::1 U > > lo0 > > > > > > Elmer's rc.config: > > > > ipv6_enable=3D"YES" > > ipv6_network_interfaces=3D"bce0 bce1" > > ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" > > ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen = 64 > > mtu 8192" > > ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > > > > > > The router (cisco): > > > > interface GigabitEthernet0/0 > > ipv6 address FD7C:3F2B:E791:1::1/64 > > ipv6 enable > > ipv6 nd prefix FD7C:3F2B:E791:1::/64 > > (etc) > > > > > > Elmer# tcpdump -nq ip6 and not tcp > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > listening on bce0, link-type EN10MB (Ethernet), capture size 96 bytes > > 13:21:52.819632 IP6 fe80::217:95ff:fe25:5c90 > ff02::1: ICMP6, router > > advertisement, length 64 > > > > _______________________________________________ > > 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 Mon Dec 14 21:57:10 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B98FF106566B for ; Mon, 14 Dec 2009 21:57:10 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 870458FC16 for ; Mon, 14 Dec 2009 21:57:10 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBELuLf0025868; Mon, 14 Dec 2009 13:56:21 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 13:56:12 -0800 Message-ID: In-Reply-To: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thread-Index: Acp8nasMFpsjHm6ORH6hBHMNsNFZjAAalmgw References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> From: "Li, Qing" To: "JASSAL Aman" , "Dennis Glatting" Cc: freebsd-net@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 21:57:10 -0000 >=20 > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > expecting bce1 rather than lo0, I suppose you were as well :) > This loopback route is necessary for short circuiting traffic to local address within a node. -- Qing > > If I'm not mistaken, the packets emanating from bce1 go to the loopback > interface, thus not really going out. You can try specifying the route > manually with "route add *your parameters*" or even set it in > /etc/rc.conf > so that it's loaded at boot-time. There's no reason why among 2 > physical > interfaces sharing the same fabric, one can ship packets out and the > other > can't. >=20 > > > > Elmer's rc.config: > > > > > > ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > > ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" > > ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen = 64 > mtu > > 8192" > > ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > > >=20 > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never > used > this myself so I can't really comment, and I can't say if there aren't > any > sort of "interferences" with what you're trying to do. >=20 > > > > > > The router (cisco): > > > > > > interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 > > enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > > >=20 > Just a side-note, I'm not sure if it will be really useful to you, but > you > could give it a try if you want to. Have you tried using your Cisco > router > as a Router Advertisement Daemon ? That way, addresses would be built > automatically and you could see how both interfaces react to such > advertisements. >=20 > I hope this helps. >=20 > ------------ > Aman Jassal >=20 > Wisdom comes from experience. > Experience comes from a lack of wisdom. >=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" From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 22:04:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21C0106566B for ; Mon, 14 Dec 2009 22:04:28 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD1B8FC16 for ; Mon, 14 Dec 2009 22:04:28 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBEM3pEn017878; Mon, 14 Dec 2009 15:03:51 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 14 Dec 2009 15:03:51 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: JASSAL Aman In-Reply-To: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> Message-ID: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:04:28 -0000 Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: > Hello Mr.Glatting, > > Not that I'm an IPv6 genius, but at first sight your problem seems to be a > route-related. I've put comments in-line. > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >> >> >> Elmer# netstat -rn >> Routing tables >> >> >> Internet6: >> Destination Gateway Flags >> Netif Expire >> ::/96 ::1 UGRS >> lo0 => default fd7c:3f2b:e791:1::1 >> UGS bce0 >> ::1 ::1 UH >> lo0 ::ffff:0.0.0.0/96 ::1 UGRS >> lo0 fd7c:3f2b:e791:1::/64 link#1 U >> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 UHS >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS >> lo0 fe80::/10 ::1 UGRS >> lo0 fe80::%bce0/64 link#1 U >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS >> lo0 fe80::%bce1/64 link#2 U >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS >> lo0 fe80::%lo0/64 link#3 U >> lo0 fe80::1%lo0 link#3 UHS >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >> bce1 ff01:3::/32 ::1 U >> lo0 ff02::/16 ::1 UGRS >> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >> bce1 ff02::%lo0/32 ::1 U >> lo0 >> > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > expecting bce1 rather than lo0, I suppose you were as well :) If I'm not > mistaken, the packets emanating from bce1 go to the loopback interface, > thus not really going out. You can try specifying the route manually > with "route add *your parameters*" or even set it in /etc/rc.conf so > that it's loaded at boot-time. There's no reason why among 2 physical > interfaces sharing the same fabric, one can ship packets out and the > other can't. > I was wondering about the route however I haven't figured out the trick to get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table I did delete the lo0 route before I exected the above command. Also, I haven't been able to specify a higher metric (e.g., -metric 2). That is rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS bce1 I don't think that is what I want. WHat I think I just said is "host X" is out that door, rather than route net. If, however, I say Docs is out that door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6 docs.penx.com PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 ping6: sendmsg: Operation not permitted ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >> >> Elmer's rc.config: >> >> >> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" >> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu >> 8192" >> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >> > > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used > this myself so I can't really comment, and I can't say if there aren't any > sort of "interferences" with what you're trying to do. > I hope what I am specifying is to use the 32 bit IPv4 address as the last 32 bits of the IPv6 address, at least that is how it works out numerically. My numbering scheme for fixed assets is the last 32 bits of the 128 bit IPv6 address is the same as its IPv4 address. >> >> >> The router (cisco): >> >> >> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 >> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >> > > Just a side-note, I'm not sure if it will be really useful to you, but you > could give it a try if you want to. Have you tried using your Cisco router > as a Router Advertisement Daemon ? That way, addresses would be built > automatically and you could see how both interfaces react to such > advertisements. > > I hope this helps. > > ------------ > Aman Jassal > > Wisdom comes from experience. > Experience comes from a lack of wisdom. > > From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 22:06:54 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DEF1065670 for ; Mon, 14 Dec 2009 22:06:54 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id CE2758FC13 for ; Mon, 14 Dec 2009 22:06:53 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBEM6cve018180; Mon, 14 Dec 2009 15:06:38 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 14 Dec 2009 15:06:38 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: Tom Pusateri In-Reply-To: <4B2691EC.4090202@bangj.com> Message-ID: References: <4B2691EC.4090202@bangj.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:06:54 -0000 On Mon, 14 Dec 2009, Tom Pusateri wrote: > Does netstat -s show any "bad neighbor solicitation messages" or any > other ip6 or icmp6 errors? > Yes: Elmer# netstat -s| grep "bad neighbor solicitation" 270 bad neighbor solicitation messages > I'm seeing that and though my symptoms may be different, I thought maybe > the root cause is the same. > > Tom > From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 22:38:38 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241451065694; Mon, 14 Dec 2009 22:38:38 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F063F8FC0A; Mon, 14 Dec 2009 22:38:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEMcbOJ080878; Mon, 14 Dec 2009 22:38:37 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEMcbT4080874; Mon, 14 Dec 2009 22:38:37 GMT (envelope-from yongari) Date: Mon, 14 Dec 2009 22:38:37 GMT Message-Id: <200912142238.nBEMcbT4080874@freefall.freebsd.org> To: mcj@bluetonic.org, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:38:38 -0000 Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 State-Changed-Why: I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 22:41:41 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A27D01065670; Mon, 14 Dec 2009 22:41:41 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 934B58FC14; Mon, 14 Dec 2009 22:41:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEMffVx089064; Mon, 14 Dec 2009 22:41:41 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEMff09089051; Mon, 14 Dec 2009 22:41:41 GMT (envelope-from yongari) Date: Mon, 14 Dec 2009 22:41:41 GMT Message-Id: <200912142241.nBEMff09089051@freefall.freebsd.org> To: tahkun-send-pr@milkcup.jp, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/141414: [vge] vge(4) problem on 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:41:41 -0000 Synopsis: [vge] vge(4) problem on 8.0-RELEASE State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Dec 14 22:40:55 UTC 2009 State-Changed-Why: I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? You can download the following latest vge(4) files from HEAD and it should build on 8.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Dec 14 22:40:55 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=141414 From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 22:50:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFEBC1065692 for ; Mon, 14 Dec 2009 22:50:17 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 955B88FC1A for ; Mon, 14 Dec 2009 22:50:17 +0000 (UTC) Received: by pxi12 with SMTP id 12so1700995pxi.3 for ; Mon, 14 Dec 2009 14:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HERhYuGFI5HkQx0f1Ztc7MihClgrd/m/SKLemjULBLU=; b=AH8/Djz7H1qA8JKB+RltTbuxHdZTMVHUwpXI5BKzxTSErWjhOq4zky0D9jaNjIeK22 tvvjVrmCSFyeqNm29CKsGz9aPGuFQqTrb4qT0FRJVtWwX6PkBghhvIOdx3iJVsvSPt+E 6NfDCkitnlThClJvxx/9nIa2/t75BGyk6l4gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iOs/J4pZBBFr2H2BUawlgoCO2DAraUlsHyvTDx2LScYiwg0VI4XVnSG038dtBkUox6 jlh3jA9RJiBWXo7CosaWrgH7q+oUzaRbeyr9ZnIWFNub8LuXgvMHRqBboUyVx9Cvnejf aELo3g+3elKy6bAmagCLHXOtE2z2aD69Ki3qo= MIME-Version: 1.0 Received: by 10.142.56.17 with SMTP id e17mr3552419wfa.324.1260829432688; Mon, 14 Dec 2009 14:23:52 -0800 (PST) In-Reply-To: <44AE62A7ED7A1F40AF0FC503B50F92780154727454@chopperexchange.choppertrading.com> References: <44AE62A7ED7A1F40AF0FC503B50F92780154727454@chopperexchange.choppertrading.com> Date: Mon, 14 Dec 2009 14:23:52 -0800 Message-ID: From: Navdeep Parhar To: Jack Goral Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 22:50:17 -0000 On Mon, Dec 14, 2009 at 1:30 PM, Jack Goral wro= te: > > Any idea how to debug problem mentioned in the subject line? This card is supported in 8-STABLE (r199206 or later). Looks like you're running 8.0 release. You can grab cxgb(4) code from stable and build + run it on your system. Regards, Navdeep > > Command used to load stock driver: > =A0 =A0 =A0 =A0 =A0 =A0kldload if_cxgb.ko > > Thanks, > Jack Goral > > > ________________________________ > CONFIDENTIALITY WARNING: This email including any attachments may contain= privileged or confidential information and is for the sole use of the inte= nded recipient(s). Any unauthorized use or disclosure of this communication= is prohibited. This e-mail may also be subject to specific non-disclosure = and confidentiality provisions. The information contained herein is the pro= perty of Chopper Trading, LLC. If you believe that you have received this e= mail in error, please notify the sender immediately and delete it from your= system. > _______________________________________________ > 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 Mon Dec 14 23:00:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FA79106568B for ; Mon, 14 Dec 2009 23:00:43 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 416828FC15 for ; Mon, 14 Dec 2009 23:00:42 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBEMwev6005283; Mon, 14 Dec 2009 15:00:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 14:59:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Understanding multiple IPv6 interfaces under 8.0 (fwd) Thread-Index: Acp9CYAEfe0QuEo9RaSvMCfLPriRwAABmAT5 References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> From: "Li, Qing" To: "Dennis Glatting" , "JASSAL Aman" Cc: freebsd-net@freebsd.org Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 23:00:43 -0000 You don't need to perform all that route-foo. I believe the root cause = of this issue may be due to a bit of regression in the IPv6 prefix = management code, and I am in the process of putting together a permanent fix. The issue as it stands today, is due to how the prefix was inserted in the first place. Since bce0 was configured first, the interface = associated with the prefix is bce0. Later the reference count on the prefix is simply incremented when bce1 configures another IPv6 address of the=20 same prefix.=20 When ND6 NS arrives for bce1, due to the interface mismatch of the = prefix interface against the input interface, the NS packet was considered invalid and thus dropped. Again, in case you didn't see my earlier reply, try the temporary hack = at http://people.freebsd.org/~qingli/nd6-ns.diff=20 until I commit a permanent patch. The problem was easily reproducible = and=20 I have verified with limited unit testing the patch works. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting Sent: Mon 12/14/2009 2:03 PM To: JASSAL Aman Cc: freebsd-net@freebsd.org Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) =20 Thanks. Responses in-line. On Mon, 14 Dec 2009, JASSAL Aman wrote: > Hello Mr.Glatting, > > Not that I'm an IPv6 genius, but at first sight your problem seems to = be a > route-related. I've put comments in-line. > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >> >> >> Elmer# netstat -rn >> Routing tables >> >> >> Internet6: >> Destination Gateway Flags >> Netif Expire >> ::/96 ::1 UGRS >> lo0 =3D> default fd7c:3f2b:e791:1::1 >> UGS bce0 >> ::1 ::1 UH >> lo0 ::ffff:0.0.0.0/96 ::1 = UGRS >> lo0 fd7c:3f2b:e791:1::/64 link#1 U >> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 = UHS >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 = UHS >> lo0 fe80::/10 ::1 = UGRS >> lo0 fe80::%bce0/64 link#1 U >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 = UHS >> lo0 fe80::%bce1/64 link#2 U >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 = UHS >> lo0 fe80::%lo0/64 link#3 U >> lo0 fe80::1%lo0 link#3 = UHS >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a = U >> bce1 ff01:3::/32 ::1 = U >> lo0 ff02::/16 ::1 = UGRS >> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U >> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a = U >> bce1 ff02::%lo0/32 ::1 = U >> lo0 >> > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was=20 > expecting bce1 rather than lo0, I suppose you were as well :) If I'm = not=20 > mistaken, the packets emanating from bce1 go to the loopback = interface,=20 > thus not really going out. You can try specifying the route manually=20 > with "route add *your parameters*" or even set it in /etc/rc.conf so=20 > that it's loaded at boot-time. There's no reason why among 2 physical=20 > interfaces sharing the same fabric, one can ship packets out and the=20 > other can't. > I was wondering about the route however I haven't figured out the trick = to=20 get what I want. For example: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add=20 -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 route: writing to routing socket: File exists add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in = table I did delete the lo0 route before I exected the above command. Also, I=20 haven't been able to specify a higher metric (e.g., -metric 2). That is=20 rejected too. However, I can say: Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a delete host fd7c:3f2b:e791:1:0:1:ac13:a0a Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 Elmer# netstat -rn (snip) fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS = bce1 I don't think that is what I want. WHat I think I just said is "host X" = is=20 out that door, rather than route net. If, however, I say Docs is out = that=20 door, I get: Elmer# route add -inet6 docs.dco.penx.com -iface bce1 add host docs.dco.penx.com: gateway bce1 Elmer# ping6=20 docs.penx.com PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> = fd7c:3f2b:e791:1::ac13:a15 ping6: sendmsg: Operation not permitted ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 >> >> Elmer's rc.config: >> >> >> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" >> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen = 64" >> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen = 64 mtu >> 8192" >> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" >> > > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never = used > this myself so I can't really comment, and I can't say if there aren't = any > sort of "interferences" with what you're trying to do. > I hope what I am specifying is to use the 32 bit IPv4 address as the = last=20 32 bits of the IPv6 address, at least that is how it works out=20 numerically. My numbering scheme for fixed assets is the last 32 bits of = the 128 bit IPv6 address is the same as its IPv4 address. >> >> >> The router (cisco): >> >> >> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 >> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >> > > Just a side-note, I'm not sure if it will be really useful to you, but = you > could give it a try if you want to. Have you tried using your Cisco = router > as a Router Advertisement Daemon ? That way, addresses would be built > automatically and you could see how both interfaces react to such > advertisements. > > I hope this helps. > > ------------ > Aman Jassal > > Wisdom comes from experience. > Experience comes from a lack of wisdom. > > _______________________________________________ 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 Mon Dec 14 23:20:10 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E94B1065670 for ; Mon, 14 Dec 2009 23:20:10 +0000 (UTC) (envelope-from fjo@ogris.de) Received: from ns1.ogris.net (ns1.ogris.net [212.62.68.23]) by mx1.freebsd.org (Postfix) with ESMTP id D70E18FC12 for ; Mon, 14 Dec 2009 23:20:09 +0000 (UTC) Received: from [192.168.0.14] (p54877C65.dip.t-dialin.net [84.135.124.101]) by ns1.ogris.net (Postfix) with ESMTPA id 1CF3F1211A3; Tue, 15 Dec 2009 00:03:00 +0100 (CET) User-Agent: Microsoft-Entourage/13.3.0.091002 Date: Tue, 15 Dec 2009 00:02:59 +0100 From: "Felix J. Ogris" To: Message-ID: Thread-Topic: tcp keepalive after fin+ack from client and server Thread-Index: Acp9EZRVHLr2RcLOAUGJrR7El/yqSA== In-Reply-To: <4B25BFF3.4060103@elischer.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Julian Elischer Subject: Re: tcp keepalive after fin+ack from client and server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 23:20:10 -0000 On 12/14/09 5:32 AM, "Julian Elischer" wrote: > Felix J. Ogris wrote: >> Hi, >> >> I am experiencing some strange problem where FreeBSD sometimes starts >> sending tcp keepalives after client and server have sent and ack'ed FINs. >> The server runs 7.1-RELEASE/amd64 with open-vm-tools-nox11-148847 in a >> VMware ESXi 4.0. The client runs a CentOS Linux 2.6.18-164.6.1.el5PAE SMP on >> a bare metal machine. FreeBSD houses a Apache installation with sendfile and >> mmap enabled. The Linux machine runs a homemade monitoring system and starts >> a Perl script every 5 minutes to check if Apache is still alive. I have put >> a tcpdump output on http://ogris.de/keepalive.txt for readability and can >> provide the raw tcpdump file, if needed. Client and server keep sending >> those keepalives for about 2 hours (yielding 300kB/s constantly) if not >> stopped manually by an ipfw rule. lsof shows that no user process has open >> the corresponding sockets anymore, whereas netstat shows established >> connections. >> FreeBSD has loaded ipfw with some keep-state rules, the Linux box has >> iptables disabled. > > > are you sure it isn't the firewall (ipfw) sending keepalives? it is > one of the options with kept state to inject keepalives. > if it didint' see all the FINs for some reason, it may think the > session is still alive. Thanks for the hint - net.inet.ip.fw.dyn_keepalive=0 did the trick. Felix From owner-freebsd-net@FreeBSD.ORG Mon Dec 14 23:36:09 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A371106566B for ; Mon, 14 Dec 2009 23:36:08 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6BE8FC12 for ; Mon, 14 Dec 2009 23:36:08 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBENZUCo076810; Mon, 14 Dec 2009 16:35:30 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 14 Dec 2009 16:35:30 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: "Li, Qing" In-Reply-To: Message-ID: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, JASSAL Aman Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 23:36:10 -0000 The nd6.c patch is currently compiling. On Mon, 14 Dec 2009, Li, Qing wrote: > > You don't need to perform all that route-foo. I believe the root cause of > this issue may be due to a bit of regression in the IPv6 prefix management > code, and I am in the process of putting together a permanent fix. > > The issue as it stands today, is due to how the prefix was inserted in > the first place. Since bce0 was configured first, the interface associated > with the prefix is bce0. Later the reference count on the prefix is > simply incremented when bce1 configures another IPv6 address of the > same prefix. > > When ND6 NS arrives for bce1, due to the interface mismatch of the prefix > interface against the input interface, the NS packet was considered > invalid and thus dropped. > > Again, in case you didn't see my earlier reply, try the temporary hack at > http://people.freebsd.org/~qingli/nd6-ns.diff > > until I commit a permanent patch. The problem was easily reproducible and > I have verified with limited unit testing the patch works. > > -- Qing > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > Sent: Mon 12/14/2009 2:03 PM > To: JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > Thanks. Responses in-line. > > > > On Mon, 14 Dec 2009, JASSAL Aman wrote: > >> Hello Mr.Glatting, >> >> Not that I'm an IPv6 genius, but at first sight your problem seems to be a >> route-related. I've put comments in-line. >> >> >> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>> >>> >>> Elmer# netstat -rn >>> Routing tables >>> >>> >>> Internet6: >>> Destination Gateway Flags >>> Netif Expire >>> ::/96 ::1 UGRS >>> lo0 => default fd7c:3f2b:e791:1::1 >>> UGS bce0 >>> ::1 ::1 UH >>> lo0 ::ffff:0.0.0.0/96 ::1 UGRS >>> lo0 fd7c:3f2b:e791:1::/64 link#1 U >>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 UHS >>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS >>> lo0 fe80::/10 ::1 UGRS >>> lo0 fe80::%bce0/64 link#1 U >>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS >>> lo0 fe80::%bce1/64 link#2 U >>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS >>> lo0 fe80::%lo0/64 link#3 U >>> lo0 fe80::1%lo0 link#3 UHS >>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U >>> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >>> bce1 ff01:3::/32 ::1 U >>> lo0 ff02::/16 ::1 UGRS >>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U >>> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >>> bce1 ff02::%lo0/32 ::1 U >>> lo0 >>> >> >> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was >> expecting bce1 rather than lo0, I suppose you were as well :) If I'm not >> mistaken, the packets emanating from bce1 go to the loopback interface, >> thus not really going out. You can try specifying the route manually >> with "route add *your parameters*" or even set it in /etc/rc.conf so >> that it's loaded at boot-time. There's no reason why among 2 physical >> interfaces sharing the same fabric, one can ship packets out and the >> other can't. >> > > I was wondering about the route however I haven't figured out the trick to > get what I want. For example: > > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > Elmer# route add > -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > route: writing to routing socket: File exists > add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table > > I did delete the lo0 route before I exected the above command. Also, I > haven't been able to specify a higher metric (e.g., -metric 2). That is > rejected too. However, I can say: > > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > > Elmer# netstat -rn > (snip) > fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS bce1 > > I don't think that is what I want. WHat I think I just said is "host X" is > out that door, rather than route net. If, however, I say Docs is out that > door, I get: > > Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > add host docs.dco.penx.com: gateway bce1 > > Elmer# ping6 > docs.penx.com > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 > ping6: sendmsg: Operation not permitted > ping6: wrote docs.dco.penx.com 16 chars, ret=-1 > > >>> >>> Elmer's rc.config: >>> >>> >>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" >>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu >>> 8192" >>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>> >> >> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used >> this myself so I can't really comment, and I can't say if there aren't any >> sort of "interferences" with what you're trying to do. >> > > I hope what I am specifying is to use the 32 bit IPv4 address as the last > 32 bits of the IPv6 address, at least that is how it works out > numerically. My numbering scheme for fixed assets is the last 32 bits of > the 128 bit IPv6 address is the same as its IPv4 address. > > >>> >>> >>> The router (cisco): >>> >>> >>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 >>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>> >> >> Just a side-note, I'm not sure if it will be really useful to you, but you >> could give it a try if you want to. Have you tried using your Cisco router >> as a Router Advertisement Daemon ? That way, addresses would be built >> automatically and you could see how both interfaces react to such >> advertisements. >> >> I hope this helps. >> >> ------------ >> Aman Jassal >> >> Wisdom comes from experience. >> Experience comes from a lack of wisdom. >> >> > _______________________________________________ > 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 Dec 15 00:07:46 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1F141065672; Tue, 15 Dec 2009 00:07:46 +0000 (UTC) (envelope-from mcj@bluetonic.org) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 173D58FC15; Tue, 15 Dec 2009 00:07:45 +0000 (UTC) Received: by ewy26 with SMTP id 26so4293456ewy.3 for ; Mon, 14 Dec 2009 16:07:45 -0800 (PST) Received: by 10.213.24.21 with SMTP id t21mr4325029ebb.56.1260833803303; Mon, 14 Dec 2009 15:36:43 -0800 (PST) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx.google.com with ESMTPS id 15sm3345515ewy.4.2009.12.14.15.36.39 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 15:36:40 -0800 (PST) Received: by ewy26 with SMTP id 26so4268631ewy.3 for ; Mon, 14 Dec 2009 15:36:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.131 with SMTP id w3mr2177816wee.156.1260833799124; Mon, 14 Dec 2009 15:36:39 -0800 (PST) In-Reply-To: <200912142238.nBEMcbT4080874@freefall.freebsd.org> References: <200912142238.nBEMcbT4080874@freefall.freebsd.org> From: Carey Jones Date: Mon, 14 Dec 2009 17:36:19 -0600 Message-ID: <77e6ee410912141536i7731618xe8ec0553ac5c4956@mail.gmail.com> To: yongari@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:07:46 -0000 Would I need to bring the whole system up to HEAD, or can I just add the relevant vge(4) file to my current RELENG_8 system? Thanks, -c On Mon, Dec 14, 2009 at 4:38 PM, wrote: > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > State-Changed-Why: > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 00:34:38 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C778D106566B for ; Tue, 15 Dec 2009 00:34:38 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9B45E8FC08 for ; Tue, 15 Dec 2009 00:34:38 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBF0Y8dt002058; Mon, 14 Dec 2009 17:34:09 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 14 Dec 2009 17:34:08 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: "Li, Qing" In-Reply-To: Message-ID: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, JASSAL Aman Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:34:39 -0000 The patch works. Thanks. On Mon, 14 Dec 2009, Li, Qing wrote: > > You don't need to perform all that route-foo. I believe the root cause of > this issue may be due to a bit of regression in the IPv6 prefix management > code, and I am in the process of putting together a permanent fix. > > The issue as it stands today, is due to how the prefix was inserted in > the first place. Since bce0 was configured first, the interface associated > with the prefix is bce0. Later the reference count on the prefix is > simply incremented when bce1 configures another IPv6 address of the > same prefix. > > When ND6 NS arrives for bce1, due to the interface mismatch of the prefix > interface against the input interface, the NS packet was considered > invalid and thus dropped. > > Again, in case you didn't see my earlier reply, try the temporary hack at > http://people.freebsd.org/~qingli/nd6-ns.diff > > until I commit a permanent patch. The problem was easily reproducible and > I have verified with limited unit testing the patch works. > > -- Qing > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > Sent: Mon 12/14/2009 2:03 PM > To: JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > > Thanks. Responses in-line. > > > > On Mon, 14 Dec 2009, JASSAL Aman wrote: > >> Hello Mr.Glatting, >> >> Not that I'm an IPv6 genius, but at first sight your problem seems to be a >> route-related. I've put comments in-line. >> >> >> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>> >>> >>> Elmer# netstat -rn >>> Routing tables >>> >>> >>> Internet6: >>> Destination Gateway Flags >>> Netif Expire >>> ::/96 ::1 UGRS >>> lo0 => default fd7c:3f2b:e791:1::1 >>> UGS bce0 >>> ::1 ::1 UH >>> lo0 ::ffff:0.0.0.0/96 ::1 UGRS >>> lo0 fd7c:3f2b:e791:1::/64 link#1 U >>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 UHS >>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 UHS >>> lo0 fe80::/10 ::1 UGRS >>> lo0 fe80::%bce0/64 link#1 U >>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 UHS >>> lo0 fe80::%bce1/64 link#2 U >>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 UHS >>> lo0 fe80::%lo0/64 link#3 U >>> lo0 fe80::1%lo0 link#3 UHS >>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 U >>> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >>> bce1 ff01:3::/32 ::1 U >>> lo0 ff02::/16 ::1 UGRS >>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 U >>> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a U >>> bce1 ff02::%lo0/32 ::1 U >>> lo0 >>> >> >> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was >> expecting bce1 rather than lo0, I suppose you were as well :) If I'm not >> mistaken, the packets emanating from bce1 go to the loopback interface, >> thus not really going out. You can try specifying the route manually >> with "route add *your parameters*" or even set it in /etc/rc.conf so >> that it's loaded at boot-time. There's no reason why among 2 physical >> interfaces sharing the same fabric, one can ship packets out and the >> other can't. >> > > I was wondering about the route however I haven't figured out the trick to > get what I want. For example: > > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > Elmer# route add > -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > route: writing to routing socket: File exists > add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already in table > > I did delete the lo0 route before I exected the above command. Also, I > haven't been able to specify a higher metric (e.g., -metric 2). That is > rejected too. However, I can say: > > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > > Elmer# netstat -rn > (snip) > fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS bce1 > > I don't think that is what I want. WHat I think I just said is "host X" is > out that door, rather than route net. If, however, I say Docs is out that > door, I get: > > Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > add host docs.dco.penx.com: gateway bce1 > > Elmer# ping6 > docs.penx.com > PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> fd7c:3f2b:e791:1::ac13:a15 > ping6: sendmsg: Operation not permitted > ping6: wrote docs.dco.penx.com 16 chars, ret=-1 > > >>> >>> Elmer's rc.config: >>> >>> >>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen 64" >>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 mtu >>> 8192" >>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>> >> >> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never used >> this myself so I can't really comment, and I can't say if there aren't any >> sort of "interferences" with what you're trying to do. >> > > I hope what I am specifying is to use the 32 bit IPv4 address as the last > 32 bits of the IPv6 address, at least that is how it works out > numerically. My numbering scheme for fixed assets is the last 32 bits of > the 128 bit IPv6 address is the same as its IPv4 address. > > >>> >>> >>> The router (cisco): >>> >>> >>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 ipv6 >>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>> >> >> Just a side-note, I'm not sure if it will be really useful to you, but you >> could give it a try if you want to. Have you tried using your Cisco router >> as a Router Advertisement Daemon ? That way, addresses would be built >> automatically and you could see how both interfaces react to such >> advertisements. >> >> I hope this helps. >> >> ------------ >> Aman Jassal >> >> Wisdom comes from experience. >> Experience comes from a lack of wisdom. >> >> > _______________________________________________ > 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 Dec 15 01:06:54 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 274B01065676; Tue, 15 Dec 2009 01:06:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id BD64F8FC16; Tue, 15 Dec 2009 01:06:53 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so845077qwb.7 for ; Mon, 14 Dec 2009 17:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=7mUHJDo78eniq9Pe6O9Pozcd7ECYg+rsqb9nNiuiM0w=; b=DIylf24DvSMJfBxahhcvdqQVv3yz1J/gqHiLQT375bifLBCTEry7vR4Ms4GUW1TpTq MOYSbPZoRE4eV4K4rcnOfVRXap6c1EZ8IgPhgNEpgUJaFnjnVFTjFfQg7tWrYYZ3Fyu+ fy/a1GeLRQ8LODeBL0TuxAiDt9+wkoQV7TyUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=DHPI6PrBcDF2SpMoN1TUzAE1M41L94CQ+OMOuvfvY3xm7ZphzGmh2/qwM4muZVEoCV 62zhAb71KjOP6t9C7fVY0F6sSfVmnzpNQt3PrpQVtd4guLur2/bTlUQ1x+yu86I4Z776 7JIbrm6N5MKJt4LiFPWBedtpIiSQHfknHT978= Received: by 10.224.15.210 with SMTP id l18mr3510586qaa.91.1260839212483; Mon, 14 Dec 2009 17:06:52 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm13353750qwi.47.2009.12.14.17.06.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 17:06:51 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 14 Dec 2009 17:06:41 -0800 From: Pyun YongHyeon Date: Mon, 14 Dec 2009 17:06:41 -0800 To: Carey Jones Message-ID: <20091215010641.GD1122@michelle.cdnetworks.com> References: <200912142238.nBEMcbT4080874@freefall.freebsd.org> <77e6ee410912141536i7731618xe8ec0553ac5c4956@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77e6ee410912141536i7731618xe8ec0553ac5c4956@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 01:06:54 -0000 On Mon, Dec 14, 2009 at 05:36:19PM -0600, Carey Jones wrote: > Would I need to bring the whole system up to HEAD, or can I just add the > relevant vge(4) file to my current RELENG_8 system? > You can download the following latest vge(4) files from HEAD and it should build on 8.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h > Thanks, > > > -c > > On Mon, Dec 14, 2009 at 4:38 PM, wrote: > > > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > > > State-Changed-From-To: open->feedback > > State-Changed-By: yongari > > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > State-Changed-Why: > > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > > > > > Responsible-Changed-From-To: freebsd-net->yongari > > Responsible-Changed-By: yongari > > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > Responsible-Changed-Why: > > Grab. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 02:58:45 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E5DC106566C; Tue, 15 Dec 2009 02:58:45 +0000 (UTC) (envelope-from mcj@bluetonic.org) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id C76428FC0A; Tue, 15 Dec 2009 02:58:44 +0000 (UTC) Received: by ewy26 with SMTP id 26so4407758ewy.3 for ; Mon, 14 Dec 2009 18:58:43 -0800 (PST) Received: by 10.213.109.69 with SMTP id i5mr1072970ebp.11.1260845923552; Mon, 14 Dec 2009 18:58:43 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx.google.com with ESMTPS id 23sm9117371eya.19.2009.12.14.18.58.40 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 18:58:41 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so87248eyf.9 for ; Mon, 14 Dec 2009 18:58:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.11 with SMTP id d11mr41814wef.187.1260845919760; Mon, 14 Dec 2009 18:58:39 -0800 (PST) In-Reply-To: <20091215010641.GD1122@michelle.cdnetworks.com> References: <200912142238.nBEMcbT4080874@freefall.freebsd.org> <77e6ee410912141536i7731618xe8ec0553ac5c4956@mail.gmail.com> <20091215010641.GD1122@michelle.cdnetworks.com> From: Carey Jones Date: Mon, 14 Dec 2009 20:58:19 -0600 Message-ID: <77e6ee410912141858w2395cefcrcd689ba0f028aec6@mail.gmail.com> To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 02:58:45 -0000 Hello, The version from HEAD seems to work better than any of the previous patches I've tried, though it still doesn't seem to get quite the throughput that the adapter managed under RELENG_7. Unfortunately I don't have any quantitative data for you. However, the symptoms from my pr are definitely gone. Thanks, -c On Mon, Dec 14, 2009 at 7:06 PM, Pyun YongHyeon wrote: > On Mon, Dec 14, 2009 at 05:36:19PM -0600, Carey Jones wrote: > > Would I need to bring the whole system up to HEAD, or can I just add the > > relevant vge(4) file to my current RELENG_8 system? > > > > You can download the following latest vge(4) files from HEAD and it > should build on 8.0-RELEASE. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h > > > Thanks, > > > > > > -c > > > > On Mon, Dec 14, 2009 at 4:38 PM, wrote: > > > > > Synopsis: [vge] Strange behavior with vge gigabit ethernet adapter > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: yongari > > > State-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > > State-Changed-Why: > > > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > > > > > > > > > > > > Responsible-Changed-From-To: freebsd-net->yongari > > > Responsible-Changed-By: yongari > > > Responsible-Changed-When: Mon Dec 14 22:37:50 UTC 2009 > > > Responsible-Changed-Why: > > > Grab. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141276 > > > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 03:14:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFCC3106572D; Tue, 15 Dec 2009 03:14:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7343E8FC14; Tue, 15 Dec 2009 03:14:33 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so866126qwb.7 for ; Mon, 14 Dec 2009 19:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=S/6PfnXrlu4XzpIT5Zch2zaqDlMxYEUITXpUjoOgrZE=; b=cKYkFRXUWS4hBFpgsh20kBLtCirDY6KY1+yATTWHrzdhS6soATT+daeOGPpA6kiFLx eveAJ5zfyjZUF4gO6HOq/cvJ6JSh7E/HsTN0z7G46YEjcODNXtD/NPptWaKii5lnwp0u PpdXXIZ1v1SGkysbW2LFu+Oxdb52+gqfhuzqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Rbp4TCKoxUmZmZ5rhl39kHdRy4Zl0hUPvuQj6Yc4r3BOLy1O2VM+uDIZa8pg9FjQ84 mdfW1bLuOb3E0lF8vEdh4izqUKv2j3qgcURWXAIlcG/zFfekxPgFxMaJT3hhY4u2EIal GFeeYWgtTw0VKE0kBCEbvAdcd9lGPpo7b6yIE= Received: by 10.224.109.141 with SMTP id j13mr3544643qap.84.1260846872982; Mon, 14 Dec 2009 19:14:32 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm13581886qwb.2.2009.12.14.19.14.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 19:14:31 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 14 Dec 2009 19:14:16 -0800 From: Pyun YongHyeon Date: Mon, 14 Dec 2009 19:14:16 -0800 To: Carey Jones Message-ID: <20091215031416.GE1122@michelle.cdnetworks.com> References: <200912142238.nBEMcbT4080874@freefall.freebsd.org> <77e6ee410912141536i7731618xe8ec0553ac5c4956@mail.gmail.com> <20091215010641.GD1122@michelle.cdnetworks.com> <77e6ee410912141858w2395cefcrcd689ba0f028aec6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77e6ee410912141858w2395cefcrcd689ba0f028aec6@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: kern/141276: [vge] Strange behavior with vge gigabit ethernet adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 03:14:35 -0000 On Mon, Dec 14, 2009 at 08:58:19PM -0600, Carey Jones wrote: > Hello, > > The version from HEAD seems to work better than any of the previous patches > I've tried, though it still doesn't seem to get quite the throughput that > the adapter managed under RELENG_7. Unfortunately I don't have any > quantitative data for you. However, the symptoms from my pr are definitely > gone. > Glad to hear that. I have strong evidence that the vge(4) can't saturate the link for any frame size. I still have no idea why it shows poor TX performance(about 650Mbps) compared to RX(about 930Mbps). The best performance number I can get from my local patch was about 800Mbps which is still very lower than any other gigabit controllers. I'm working on it with various scenarios but I couldn't find clue. > Thanks, From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 03:21:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CD57106568B for ; Tue, 15 Dec 2009 03:21:32 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id ED9E98FC28 for ; Tue, 15 Dec 2009 03:21:31 +0000 (UTC) Received: by iwn36 with SMTP id 36so2557916iwn.3 for ; Mon, 14 Dec 2009 19:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ErWEW1ZCMZVV1iXSE3hceKi7YrNSmz+yF1l9qjUhc2c=; b=LPEt3vknfvnDMohAyQ9B3JxQnY+Krs2aSYzv4IeX6QxY2RThq7f2PPu3kkQ8hww5mc VVCs9Xw/RggIhtpQY2grFmMNLd6QTUBOZOP4V75JtOL/OZ8Ba3w3bEixwVjQauxbFF1M zYny5TaQoWKQtV8gsUhD8uJtU3iB/BcbinR0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fYZN93yvYAFq0G03wx5Q8MFKVxyP+wb+/rxDFhNnvWhf5LmjORQcLEfOSp1GRzUb22 NHfB82aK7qNhfRMuz+Vc4dQ9UCX1Mpkc2EjNoBYl/SuW6T0nSWn5vqlnwC3tFp86f+H9 aC7FLwdGOS3Mg0xUVDiP6x1oZvnlWsJ7m96iE= MIME-Version: 1.0 Received: by 10.231.5.23 with SMTP id 23mr3070223ibt.45.1260847291168; Mon, 14 Dec 2009 19:21:31 -0800 (PST) Date: Mon, 14 Dec 2009 19:21:31 -0800 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: 8.0R, AMD64 and wpi is giving me major grief X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 03:21:32 -0000 All, I've got a Lenovo t61 with 4gbytes RAM that is giving me fits. It's got a 3945abg chip in it, and it's getting really flaky. I can boot it up, and work at the console for a while, and that seems to work OK, usually. However, today, when I start up my gui (xfce4), wireless just dies on me. For a week before, it would usually run for a while (sometimes days) before dying on me and requiring a reboot. Below is a snippet of /var/log/messages - Does this mean anything to anyone? Is there anything I can do to recover once this happens? Thanks, Kurt Dec 14 07:16:43 grimsqueaker kernel: wlan0: Ethernet address: 00:1f:3c:4d:e2:55 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 1 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 3 Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 4 Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification version 10e02 alive 1 Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification version 10e02 alive 1 Dec 14 07:16:43 grimsqueaker kernel: wpi_newstate: INIT -> SCAN flags 0x0 Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-SCAN-RESULTS Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Trying to associate with 00:23:69:82:b2:bf (SSID='5705NE197th' freq=2462 MHz) Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: SCAN -> AUTH flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8005 cck f ofdm 15 Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: AUTH -> ASSOC flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Associated with 00:23:69:82:b2:bf Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: ASSOC -> RUN flags 0x0 Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8035 Dec 14 07:16:45 grimsqueaker kernel: wlan0: link state changed to UP Dec 14 07:16:45 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: WPA: Key negotiation completed with 00:23:69:82:b2:bf [PTK=CCMP GTK=CCMP] Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-CONNECTED - Connection to 00:23:69:82:b2:bf completed (auth) [id=0 id_str=] Dec 14 07:16:53 grimsqueaker dhclient: New IP Address (wlan0): 192.168.151.104 Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback Dec 14 07:16:53 grimsqueaker dhclient: New Subnet Mask (wlan0): 255.255.255.0 Dec 14 07:16:53 grimsqueaker dhclient: New Broadcast Address (wlan0): 192.168.151.255 Dec 14 07:16:53 grimsqueaker dhclient: New Routers (wlan0): 192.168.151.1 Dec 14 07:17:56 grimsqueaker kernel: drm0: on vgapci0 Dec 14 07:17:56 grimsqueaker kernel: info: [drm] MSI enabled 1 message(s) Dec 14 07:17:56 grimsqueaker kernel: vgapci0: child drm0 requested pci_enable_busmaster Dec 14 07:17:56 grimsqueaker kernel: info: [drm] AGP at 0xe0000000 256MB Dec 14 07:17:56 grimsqueaker kernel: info: [drm] Initialized i915 1.6.0 20080730 Dec 14 07:17:57 grimsqueaker kernel: drm0: [ITHREAD] Dec 14 07:18:24 grimsqueaker kernel: pid 1424 (xfce4-panel), uid 1001: exited on signal 11 (core dumped) Dec 14 07:25:43 grimsqueaker wpa_supplicant[381]: WPA: Group rekeying completed with 00:23:69:82:b2:bf [GTK=CCMP] Dec 14 07:48:38 grimsqueaker kernel: wpi0: device timeout Dec 14 07:48:39 grimsqueaker kernel: wpi0: could not set power mode From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 04:53:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D3A106568F; Tue, 15 Dec 2009 04:53:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 83E428FC1F; Tue, 15 Dec 2009 04:53:47 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBF4rlDj015247; Mon, 14 Dec 2009 20:53:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2009 20:53:41 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9CYAEfe0QuEo9RaSvMCfLPriRwAABmAT5AAo0PKA= References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> From: "Li, Qing" To: , Cc: Subject: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 04:53:47 -0000 Please find the more proper fix at http://people.freebsd.org/~qingli/nd6-patch.diff I realized I was slightly off in my previous email after I spent a bit more time looking through the problem.=20 Both prefixes are present but one was marked off-link due to the fact only a single prefix route was installed in the routing table (non RADIX_MPATH system). I evaluated various options to fixing this issue, however,=20 due to the association between NDPRF_ONLINK and the route installation, I decided to go with what I have here for the time being. I have verified the fix in my setup. Please apply the patch and report back. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, December 14, 2009 3:00 PM > To: Dennis Glatting; JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 >=20 > You don't need to perform all that route-foo. I believe the root cause > of > this issue may be due to a bit of regression in the IPv6 prefix > management > code, and I am in the process of putting together a permanent fix. >=20 > The issue as it stands today, is due to how the prefix was inserted in > the first place. Since bce0 was configured first, the interface > associated > with the prefix is bce0. Later the reference count on the prefix is > simply incremented when bce1 configures another IPv6 address of the > same prefix. >=20 > When ND6 NS arrives for bce1, due to the interface mismatch of the > prefix > interface against the input interface, the NS packet was considered > invalid and thus dropped. >=20 > Again, in case you didn't see my earlier reply, try the temporary hack > at > http://people.freebsd.org/~qingli/nd6-ns.diff >=20 > until I commit a permanent patch. The problem was easily reproducible > and > I have verified with limited unit testing the patch works. >=20 > -- Qing >=20 >=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > Sent: Mon 12/14/2009 2:03 PM > To: JASSAL Aman > Cc: freebsd-net@freebsd.org > Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >=20 >=20 > Thanks. Responses in-line. >=20 >=20 >=20 > On Mon, 14 Dec 2009, JASSAL Aman wrote: >=20 > > Hello Mr.Glatting, > > > > Not that I'm an IPv6 genius, but at first sight your problem seems to > be a > > route-related. I've put comments in-line. > > > > > > Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > >> > >> > >> Elmer# netstat -rn > >> Routing tables > >> > >> > >> Internet6: > >> Destination Gateway > Flags > >> Netif Expire > >> ::/96 ::1 UGRS > >> lo0 =3D> default fd7c:3f2b:e791:1::1 > >> UGS bce0 > >> ::1 ::1 UH > >> lo0 ::ffff:0.0.0.0/96 ::1 > UGRS > >> lo0 fd7c:3f2b:e791:1::/64 link#1 > U > >> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > UHS > >> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > UHS > >> lo0 fe80::/10 ::1 > UGRS > >> lo0 fe80::%bce0/64 link#1 > U > >> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > UHS > >> lo0 fe80::%bce1/64 link#2 > U > >> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > UHS > >> lo0 fe80::%lo0/64 link#3 > U > >> lo0 fe80::1%lo0 link#3 > UHS > >> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff01:2::/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff01:3::/32 ::1 > U > >> lo0 ff02::/16 ::1 > UGRS > >> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 > U > >> bce0 ff02::%bce1/32 fd7c:3f2b:e791:1:0:1:ac13:a0a > U > >> bce1 ff02::%lo0/32 ::1 > U > >> lo0 > >> > > > > Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was > > expecting bce1 rather than lo0, I suppose you were as well :) If I'm > not > > mistaken, the packets emanating from bce1 go to the loopback > interface, > > thus not really going out. You can try specifying the route manually > > with "route add *your parameters*" or even set it in /etc/rc.conf so > > that it's loaded at boot-time. There's no reason why among 2 physical > > interfaces sharing the same fabric, one can ship packets out and the > > other can't. > > >=20 > I was wondering about the route however I haven't figured out the trick > to > get what I want. For example: >=20 > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >=20 > Elmer# route add > -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > route: writing to routing socket: File exists > add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already > in table >=20 > I did delete the lo0 route before I exected the above command. Also, I > haven't been able to specify a higher metric (e.g., -metric 2). That is > rejected too. However, I can say: >=20 > Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >=20 > Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >=20 > Elmer# netstat -rn > (snip) > fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS > bce1 >=20 > I don't think that is what I want. WHat I think I just said is "host X" > is > out that door, rather than route net. If, however, I say Docs is out > that > door, I get: >=20 > Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > add host docs.dco.penx.com: gateway bce1 >=20 > Elmer# ping6 > docs.penx.com > PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > fd7c:3f2b:e791:1::ac13:a15 > ping6: sendmsg: Operation not permitted > ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 >=20 >=20 > >> > >> Elmer's rc.config: > >> > >> > >> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > >> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen > 64" > >> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen 64 > mtu > >> 8192" > >> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > >> > > > > Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never > used > > this myself so I can't really comment, and I can't say if there > aren't any > > sort of "interferences" with what you're trying to do. > > >=20 > I hope what I am specifying is to use the 32 bit IPv4 address as the > last > 32 bits of the IPv6 address, at least that is how it works out > numerically. My numbering scheme for fixed assets is the last 32 bits > of > the 128 bit IPv6 address is the same as its IPv4 address. >=20 >=20 > >> > >> > >> The router (cisco): > >> > >> > >> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > ipv6 > >> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > >> > > > > Just a side-note, I'm not sure if it will be really useful to you, > but you > > could give it a try if you want to. Have you tried using your Cisco > router > > as a Router Advertisement Daemon ? That way, addresses would be built > > automatically and you could see how both interfaces react to such > > advertisements. > > > > I hope this helps. > > > > ------------ > > Aman Jassal > > > > Wisdom comes from experience. > > Experience comes from a lack of wisdom. > > > > > _______________________________________________ > 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 > _______________________________________________ > 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 Dec 15 07:50:27 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F74106566C for ; Tue, 15 Dec 2009 07:50:27 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id DE1E58FC26 for ; Tue, 15 Dec 2009 07:50:26 +0000 (UTC) Received: from 192.168.2.38 ([192.168.2.38]) by edusrv05.edu.irc.local ([192.168.44.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Dec 2009 07:50:45 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 15 Dec 2009 08:50:24 +0100 From: Jon Otterholm To: Mike Tancsa , Message-ID: Thread-Topic: Racoon site-to site Thread-Index: Acp9W0I4iumaAiID7UW0R5PI75/Lyw== In-Reply-To: <200912111923.nBBJNLk3072715@lava.sentex.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Subject: Re: Racoon site-to site X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 07:50:27 -0000 On 2009-12-11 20.23, "Mike Tancsa" wrote: > At 11:33 AM 12/11/2009, David DeSimone wrote: >> Jon Otterholm wrote: >>>=20 >>> If I restart racoon or wait approximately 30 min the connection is >>> re-established. >>=20 >> Since this is approximately =C2=BDof the phase 2 lifetime, you are probably >> running into lifetime negotiation issues, or PFS issues. >>=20 >>> What would be the obvious way to debug this? Any suggestions on what >>> to tweak appreciated. >>=20 >> I would turn up the debugging on racoon to get more information around >> the time that the tunnel fails. >>=20 >>> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any) >>> { >>> pfs_group 1; >>> lifetime time 3600 sec; >>> encryption_algorithm des; >>> authentication_algorithm hmac_md5,hmac_sha1; >>> compression_algorithm deflate; >>> } >>=20 >> My hunch is that you have a PFS mismatch, so that the first tunnel >> negotiates, but the second SA negotiation fails, then the third >> succeeds, etc. >=20 >=20 > You might also want to turn on DPD (dead peer > detection) in ipsectools if you dont already have > it on both sides. Are you really using des for > the crypto ? Also, when the session is > negotiated, take a look at the output of > setkey -D > and see what was actually negotiated and post it > here (just make sure you get rid of the info on the E and A lines. >=20 > e.g. > 1.1.1.2 2.2.2.2 > esp mode=3Dtunnel spi=3D125444787(0x077a22b3) reqid=3D16416(0x00004020= ) > E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd= 7b > A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb >=20 > ie. mask out the 5cfdbabb and 770cdd7b values > before posting as thats your crypto :) >=20 >=20 Here is output from setkey -D when we lost connection: localip remoteip esp mode=3Dtunnel spi=3D989823717(0x3aff82e5) reqid=3D0(0x00000000) E: des-cbc x x A: hmac-md5 x x x x seq=3D0x000009ac replay=3D4 flags=3D0x00000000 state=3Dmature created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 diff: 1703(s) hard: 3600(s) soft: 2880(s) last: Dec 15 08:26:03 2009 hard: 0(s) soft: 0(s) current: 400400(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2476 hard: 0 soft: 0 sadb_seq=3D1 pid=3D23175 refcnt=3D2 remoteip remoteip esp mode=3Dtunnel spi=3D117094840(0x06fab9b8) reqid=3D0(0x00000000) E: des-cbc x x A: hmac-md5 x x x x seq=3D0x00000b73 replay=3D4 flags=3D0x00000000 state=3Dmature created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 diff: 1703(s) hard: 3600(s) soft: 2880(s) last: Dec 15 08:25:37 2009 hard: 0(s) soft: 0(s) current: 2960978(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2931 hard: 0 soft: 0 sadb_seq=3D0 pid=3D23175 refcnt=3D1 //Jon From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 13:05:25 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53FF01065672 for ; Tue, 15 Dec 2009 13:05:25 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from ibox.insign.ch (ibox.insign.ch [195.134.143.207]) by mx1.freebsd.org (Postfix) with SMTP id A75958FC0A for ; Tue, 15 Dec 2009 13:05:24 +0000 (UTC) Received: (qmail 92556 invoked from network); 15 Dec 2009 12:37:20 -0000 Received: from [192.168.1.170] ([80.254.166.203]) by ibox.insign.ch ([195.134.143.207]) with ESMTP via TCP; 15 Dec 2009 12:37:20 -0000 From: Olivier Mueller To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 15 Dec 2009 13:37:18 +0100 Message-Id: <1260880638.26162.26.camel@ompc.insign.local> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: Subject: networking differences with php file_get_contents under 6.1 and 7.2 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 13:05:25 -0000 Hello, I just observed a strange thing on 2 servers with a very similar setup (apache config, php version/ini, virtual ip addresses, etc.) but under 2 different FreeBSD versions. I would like to understand if is related to the OS version and why. To test, I have a short php script which calls itselfs with file_get_contents() : under 6.1 the source IP is the one from apache virtual host, and under 7.2 it's the first interface from server : why this difference? Is it a new feature/change in 7.x, or a bug(fix)? If I do a request on an external server (like http://crazzy.se/get_ip.php ) it always return the main server IP. Only when I do the call locally and under 6.1 it's not the case... Under 6.1 I get this output (scroll down for the script): test1.example.com = virtual host under 10.0.0.239 main server ip = 10.0.0.210 ------------------------------------------------------------ Initial call: SERVER_ADDR: 10.0.0.239 REMOTE_ADDR: 10.0.0.12 calling... http://test1.example.com/iptest_om.php?recall=1 ------------------------------------------------------------ Call from self: SERVER_ADDR: 10.0.0.239 REMOTE_ADDR: 10.0.0.239 (client) <<<<====== ???? end ------------------------------------------------------------ end ifconfig: bce0: flags=8843 mtu 1500 options=3b inet6 fe80::218:feff:fe31:8ae4%bce0 prefixlen 64 scopeid 0x1 inet 10.0.0.210 netmask 0xffffff00 broadcast 10.0.0.255 inet 10.0.0.212 netmask 0xffffff00 broadcast 10.0.0.255 inet 10.0.0.239 netmask 0xffffff00 broadcast 10.0.0.255 and under 7.2: (test2.example.com = 10.0.0.122, main = .120) ------------------------------------------------------------ Initial call: SERVER_ADDR: 10.0.0.122 REMOTE_ADDR: 10.0.0.12 calling... http://test2.example.com/iptest_om.php?recall=1 ------------------------------------------------------------ Call from self: SERVER_ADDR: 10.0.0.122 REMOTE_ADDR: 10.0.0.120 (client) <<====== ok end ------------------------------------------------------------ end ifconfig: bce0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1f:29:06:9c:38 inet 10.0.0.120 netmask 0xffffff00 broadcast 10.0.0.255 inet 10.0.0.122 netmask 0xffffff00 broadcast 10.0.0.255 inet 10.0.0.123 netmask 0xffffff00 broadcast 10.0.0.255 test script: \n"; print "Initial call:
\n"; print "SERVER_ADDR: " . $_SERVER["SERVER_ADDR"] . "
\n"; print "REMOTE_ADDR: " . $_SERVER["REMOTE_ADDR"] . "
\n"; print "
\n"; $url = "http://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"] . "?recall=1"; print "calling... $url
\n"; print "\n"; echo file_get_contents($url); print "\n"; print "
\n"; } if ($_GET["recall"] == 1) { print "
\n"; print "Call from self:
\n"; print "SERVER_ADDR: " . $_SERVER["SERVER_ADDR"] . "
\n"; print "REMOTE_ADDR: " . $_SERVER["REMOTE_ADDR"] . " (client)
\n"; print "
\n"; print "\n"; } print "end
\n"; ?> Thanks for any feedback & regards, Olivier From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 15:01:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B95AC106566C for ; Tue, 15 Dec 2009 15:01:34 +0000 (UTC) (envelope-from jgoral@choppertrading.com) Received: from mail2.guavatech.com (mail2.guavatech.com [66.28.82.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3668FC14 for ; Tue, 15 Dec 2009 15:01:34 +0000 (UTC) X-AuditID: c0a80302-0000091c00000508-2d-4b27a4cd7ac6 Received: from chopperexchange.choppertrading.com ([10.21.11.70] RDNS failed) by mail2.guavatech.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 09:01:33 -0600 Received: from chopperexchange.choppertrading.com ([10.21.11.70]) by chopperexchange.choppertrading.com ([10.21.11.70]) with mapi; Tue, 15 Dec 2009 09:01:32 -0600 From: Jack Goral To: 'Navdeep Parhar' Date: Tue, 15 Dec 2009 09:01:32 -0600 Thread-Topic: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) Thread-Index: Acp9DB6iZxwbdMzMSpivw8oHvaDhlgAiYJUg Message-ID: <44AE62A7ED7A1F40AF0FC503B50F92780154727456@chopperexchange.choppertrading.com> References: <44AE62A7ED7A1F40AF0FC503B50F92780154727454@chopperexchange.choppertrading.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "freebsd-net@freebsd.org" , Jack Goral Subject: RE: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 15:01:34 -0000 Hi Navdeep, Thank you for response. I've build 8.0-stable as of Dec 11 and I get same error message as before: #kldload if_cxgb.ko cxgbc): mem 0xf46fe000-0xf44fefffm = 0xf4800000-0xf4ffff,0xf46ff000-0xf46ffff irq 30 at device 0.0 on pci 3 prep adapter failed cxgbc0: no msi message to release device_attach: cxgbc0 attach returned 19 Any hints? Thanks, Jack Goral Software Engineer -----Original Message----- From: Navdeep Parhar [mailto:nparhar@gmail.com]=20 Sent: Monday, December 14, 2009 4:24 PM To: Jack Goral Cc: freebsd-net@freebsd.org Subject: Re: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) On Mon, Dec 14, 2009 at 1:30 PM, Jack Goral wro= te: > > Any idea how to debug problem mentioned in the subject line? This card is supported in 8-STABLE (r199206 or later). Looks like you're running 8.0 release. You can grab cxgb(4) code from stable and build + run it on your system. Regards, Navdeep > > Command used to load stock driver: > =A0 =A0 =A0 =A0 =A0 =A0kldload if_cxgb.ko > > Thanks, > Jack Goral > > > ________________________________ > CONFIDENTIALITY WARNING: This email including any attachments may contain= privileged or confidential information and is for the sole use of the inte= nded recipient(s). Any unauthorized use or disclosure of this communication= is prohibited. This e-mail may also be subject to specific non-disclosure = and confidentiality provisions. The information contained herein is the pro= perty of Chopper Trading, LLC. If you believe that you have received this e= mail in error, please notify the sender immediately and delete it from your= system. > _______________________________________________ > 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 Dec 15 18:11:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9431065676 for ; Tue, 15 Dec 2009 18:11:56 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6F68FC1C for ; Tue, 15 Dec 2009 18:11:55 +0000 (UTC) Received: by fxm27 with SMTP id 27so154923fxm.3 for ; Tue, 15 Dec 2009 10:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=jaNPBuwQIbxylNh2Cny40k0NZIROKFwRifnH6kXBa+g=; b=LNVZ+2VJvVvtHwz2P50oJ7WHsYLoAnclbmwv3F8G3OaizpN6JIN2sJpnbKtszDVISv 8hNQzViV4JpKDHLOSCv6odrQqa6w35J/spG9qBbpvlhGvuxkfUTtSLatkUrdtjT4MitZ 3C7RvAEMzVw2mTeabQikqUf2aFsUCt+FBfZws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=qtwwxJF3IPCNZiltxuv+2rHSIGckVutqro3WZwtRv9Stnqz5P8Sf2mrUbimwhGc89e Wd+KVi223yRG3vY5GiSbVE6YxG66Khql0dQyJUAfCn6Psq2ttmdVcgwAUJEjPq28Xs2n FiVwdcbcuBStvfMJ+q1Mtt9bQdatth/4I2C8E= Received: by 10.223.95.72 with SMTP id c8mr149948fan.73.1260900714419; Tue, 15 Dec 2009 10:11:54 -0800 (PST) Received: from doormat.home (c-98-207-40-172.hsd1.ca.comcast.net [98.207.40.172]) by mx.google.com with ESMTPS id 16sm35218fxm.12.2009.12.15.10.11.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 10:11:53 -0800 (PST) Date: Tue, 15 Dec 2009 10:11:47 -0800 From: Navdeep Parhar To: Jack Goral Message-ID: <20091215181147.GA1136@doormat.home> Mail-Followup-To: Jack Goral , "freebsd-net@freebsd.org" References: <44AE62A7ED7A1F40AF0FC503B50F92780154727454@chopperexchange.choppertrading.com> <44AE62A7ED7A1F40AF0FC503B50F92780154727456@chopperexchange.choppertrading.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AE62A7ED7A1F40AF0FC503B50F92780154727456@chopperexchange.choppertrading.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" Subject: Re: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 18:11:56 -0000 On Tue, Dec 15, 2009 at 09:01:32AM -0600, Jack Goral wrote: > Hi Navdeep, > > Thank you for response. > > I've build 8.0-stable as of Dec 11 and I get same error message as before: > > #kldload if_cxgb.ko > cxgbc): mem 0xf46fe000-0xf44fefffm 0xf4800000-0xf4ffff,0xf46ff000-0xf46ffff irq 30 at device 0.0 on pci 3 Are you certain you installed the latest driver after you built it? The driver in 8-stable no longer displays "... rev:0 nports: ..." and so I think you still have an old driver. Please check the timestamp on your /boot/kernel/*cxgb*ko files. Send me the output of "pciconf -lv" from your system if it still doesn't work. Regards, Navdeep > prep adapter failed > cxgbc0: no msi message to release > device_attach: cxgbc0 attach returned 19 > > Any hints? > > Thanks, > Jack Goral > Software Engineer > > -----Original Message----- > From: Navdeep Parhar [mailto:nparhar@gmail.com] > Sent: Monday, December 14, 2009 4:24 PM > To: Jack Goral > Cc: freebsd-net@freebsd.org > Subject: Re: Chelsio S310E-BT: cxgbc0: prep adapter faliled (FreeBSD 8.0) > > On Mon, Dec 14, 2009 at 1:30 PM, Jack Goral wrote: > > > > Any idea how to debug problem mentioned in the subject line? > > This card is supported in 8-STABLE (r199206 or later). Looks like > you're running > 8.0 release. You can grab cxgb(4) code from stable and build + run it > on your system. > > Regards, > Navdeep > > > > > Command used to load stock driver: > > ? ? ? ? ? ?kldload if_cxgb.ko > > > > Thanks, > > Jack Goral > > > > > > ________________________________ > > CONFIDENTIALITY WARNING: This email including any attachments may contain privileged or confidential information and is for the sole use of the intended recipient(s). Any unauthorized use or disclosure of this communication is prohibited. This e-mail may also be subject to specific non-disclosure and confidentiality provisions. The information contained herein is the property of Chopper Trading, LLC. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system. > > _______________________________________________ > > 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 Dec 15 19:16:28 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD0C106568F; Tue, 15 Dec 2009 19:16:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 654FD8FC1A; Tue, 15 Dec 2009 19:16:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFJGSwB079401; Tue, 15 Dec 2009 19:16:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFJGSv7079397; Tue, 15 Dec 2009 19:16:28 GMT (envelope-from linimon) Date: Tue, 15 Dec 2009 19:16:28 GMT Message-Id: <200912151916.nBFJGSv7079397@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 19:16:28 -0000 Old Synopsis: em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames New Synopsis: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 15 19:15:47 UTC 2009 Responsible-Changed-Why: I'm not sure this is particular to em(4), but the assignee is probably net@ in any case. http://www.freebsd.org/cgi/query-pr.cgi?pr=141646 From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 20:09:39 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2C41065692; Tue, 15 Dec 2009 20:09:39 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DADC38FC24; Tue, 15 Dec 2009 20:09:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFK9cqX027316; Tue, 15 Dec 2009 20:09:38 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFK9c2X027312; Tue, 15 Dec 2009 20:09:38 GMT (envelope-from yongari) Date: Tue, 15 Dec 2009 20:09:38 GMT Message-Id: <200912152009.nBFK9c2X027312@freefall.freebsd.org> To: doconnor@gsoft.com.au, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/81644: [vge] vge(4) does not work properly when loaded as a KLD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:09:39 -0000 Synopsis: [vge] vge(4) does not work properly when loaded as a KLD State-Changed-From-To: feedback->closed State-Changed-By: yongari State-Changed-When: Tue Dec 15 20:07:50 UTC 2009 State-Changed-Why: Close, I can't reproduce this on recent 9-CURRENT. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Dec 15 20:07:50 UTC 2009 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=81644 From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 20:13:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3895410656AB; Tue, 15 Dec 2009 20:13:03 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 106928FC1C; Tue, 15 Dec 2009 20:13:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFKD2Lf035929; Tue, 15 Dec 2009 20:13:02 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFKD23o035925; Tue, 15 Dec 2009 20:13:02 GMT (envelope-from yongari) Date: Tue, 15 Dec 2009 20:13:02 GMT Message-Id: <200912152013.nBFKD23o035925@freefall.freebsd.org> To: cracauer@schlepper.zs64.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/82497: [vge] vge(4) on AMD64 only works when loaded late, not in loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:13:03 -0000 Synopsis: [vge] vge(4) on AMD64 only works when loaded late, not in loader.conf State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Dec 15 20:11:46 UTC 2009 State-Changed-Why: Would you try the patch at the following URL? http://people.freebsd.org/~yongari/vge/vge.miipoll.diff The patch generated against latest CURRENT. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Dec 15 20:11:46 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=82497 From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 20:15:09 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EBA21065696; Tue, 15 Dec 2009 20:15:09 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46A7C8FC1D; Tue, 15 Dec 2009 20:15:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFKF95a037122; Tue, 15 Dec 2009 20:15:09 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFKF9oO037118; Tue, 15 Dec 2009 20:15:09 GMT (envelope-from yongari) Date: Tue, 15 Dec 2009 20:15:09 GMT Message-Id: <200912152015.nBFKF9oO037118@freefall.freebsd.org> To: mamruoc@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/129135: [vge] vge driver on a VIA mini-ITX not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:15:09 -0000 Synopsis: [vge] vge driver on a VIA mini-ITX not working State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Dec 15 20:14:33 UTC 2009 State-Changed-Why: Would you try the patch at the following URL? http://people.freebsd.org/~yongari/vge/vge.miipoll.diff The patch generated against latest CURRENT. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Dec 15 20:14:33 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=129135 From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 20:50:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D13291065676 for ; Tue, 15 Dec 2009 20:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C21AE8FC18 for ; Tue, 15 Dec 2009 20:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFKo3MC065318 for ; Tue, 15 Dec 2009 20:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFKo3xt065317; Tue, 15 Dec 2009 20:50:03 GMT (envelope-from gnats) Date: Tue, 15 Dec 2009 20:50:03 GMT Message-Id: <200912152050.nBFKo3xt065317@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/140571: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:50:03 -0000 The following reply was made to PR bin/140571; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/140571: commit references a PR Date: Tue, 15 Dec 2009 20:44:26 +0000 (UTC) Author: gavin Date: Tue Dec 15 20:44:12 2009 New Revision: 200587 URL: http://svn.freebsd.org/changeset/base/200587 Log: ifconfig(8) is documented to take a ISO 3166-1 country code to set the regulatory domain with the "country" parameter, but will also take a full country name. The man page warns that only the ISO code is unambiguous. In reality, however, the first match on either would be accepted, leading to "DE" being interpreted as the "DEBUG" country rather than Germany, and "MO" selecting Morocco rather than the correct country, Macau. Fix this by always checking for an ISO CC match first, and only search on the full country name if that fails. PR: bin/140571 Tested by: Dirk Meyer dirk.meyer dinoex.sub.org Reviewed by: sam Approved by: ed (mentor) MFC after: 1 month Modified: head/sbin/ifconfig/regdomain.c Modified: head/sbin/ifconfig/regdomain.c ============================================================================== --- head/sbin/ifconfig/regdomain.c Tue Dec 15 20:20:05 2009 (r200586) +++ head/sbin/ifconfig/regdomain.c Tue Dec 15 20:44:12 2009 (r200587) @@ -694,8 +694,11 @@ lib80211_country_findbyname(const struct len = strlen(name); LIST_FOREACH(cp, &rdp->countries, next) { - if (strcasecmp(cp->isoname, name) == 0 || - strncasecmp(cp->name, name, len) == 0) + if (strcasecmp(cp->isoname, name) == 0) + return cp; + } + LIST_FOREACH(cp, &rdp->countries, next) { + if (strncasecmp(cp->name, name, len) == 0) return cp; } return NULL; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 21:09:06 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20BD310656CC; Tue, 15 Dec 2009 21:09:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EBD968FC22; Tue, 15 Dec 2009 21:09:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBFL95mg083007; Tue, 15 Dec 2009 21:09:05 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBFL95gm083003; Tue, 15 Dec 2009 21:09:05 GMT (envelope-from gavin) Date: Tue, 15 Dec 2009 21:09:05 GMT Message-Id: <200912152109.nBFL95gm083003@freefall.freebsd.org> To: dirk.meyer@dinoex.sub.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: bin/140571: [patch] ifconfig(8) does not set country DE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:09:06 -0000 Synopsis: [patch] ifconfig(8) does not set country DE State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Tue Dec 15 21:08:39 UTC 2009 State-Changed-Why: Fixed in HEAD Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Tue Dec 15 21:08:39 UTC 2009 Responsible-Changed-Why: Mine http://www.freebsd.org/cgi/query-pr.cgi?pr=140571 From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 21:32:27 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B17361065670 for ; Tue, 15 Dec 2009 21:32:27 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf01.insightbb.com (mxsf01.insightbb.com [74.128.0.71]) by mx1.freebsd.org (Postfix) with ESMTP id 79B7B8FC20 for ; Tue, 15 Dec 2009 21:32:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFACGIJ0vQLicL/2dsb2JhbACBS48CAchWhCsEgWI X-IronPort-AV: E=Sophos;i="4.47,402,1257138000"; d="scan'208";a="784199594" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf01.insightbb.com with ESMTP; 15 Dec 2009 16:03:33 -0500 X-IronPort-AV: E=Sophos;i="4.47,402,1257138000"; d="scan'208";a="340493092" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout02.manage.insightbb.com with ESMTP; 15 Dec 2009 16:03:33 -0500 To: freebsd-net@freebsd.org From: Steven Friedrich Date: Tue, 15 Dec 2009 16:03:31 -0500 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912151603.32111.freebsd@insightbb.com> Subject: uath under FreeBSD 8.0-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:32:27 -0000 Ok, I am able to load firmware with: uathload -d /dev/ugen4.3 but it also appears to do so when I plug it in... Now what? It doesn't show up in ifconfig... From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 21:45:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CF461065670 for ; Tue, 15 Dec 2009 21:45:42 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (jj.bangj.com [198.86.87.199]) by mx1.freebsd.org (Postfix) with ESMTP id F31548FC0A for ; Tue, 15 Dec 2009 21:45:41 +0000 (UTC) Received: from [172.16.10.11] (cpe-066-026-040-218.nc.res.rr.com [66.26.40.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by jj.bangj.com (Postfix) with ESMTPSA id 9818F380; Tue, 15 Dec 2009 16:27:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tom Pusateri In-Reply-To: Date: Tue, 15 Dec 2009 16:27:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> To: "Li, Qing" X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:45:42 -0000 I didn't think this routing patch was related to the "bad neighbor = solicitation messages" as suggested in the subject field but I tried it = anyway. It does not fix my IPv6 problem. I still get "bad neighbor = solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: > Please find the more proper fix at >=20 > http://people.freebsd.org/~qingli/nd6-patch.diff >=20 > I realized I was slightly off in my previous email after > I spent a bit more time looking through the problem.=20 > Both prefixes are present but one was marked off-link due > to the fact only a single prefix route was installed in > the routing table (non RADIX_MPATH system). >=20 > I evaluated various options to fixing this issue, however,=20 > due to the association between NDPRF_ONLINK and the route > installation, I decided to go with what I have here for > the time being. >=20 > I have verified the fix in my setup. Please apply the > patch and report back. >=20 > Thanks, >=20 > -- Qing >=20 >=20 >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Li, Qing >> Sent: Monday, December 14, 2009 3:00 PM >> To: Dennis Glatting; JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >>=20 >>=20 >> You don't need to perform all that route-foo. I believe the root = cause >> of >> this issue may be due to a bit of regression in the IPv6 prefix >> management >> code, and I am in the process of putting together a permanent fix. >>=20 >> The issue as it stands today, is due to how the prefix was inserted = in >> the first place. Since bce0 was configured first, the interface >> associated >> with the prefix is bce0. Later the reference count on the prefix is >> simply incremented when bce1 configures another IPv6 address of the >> same prefix. >>=20 >> When ND6 NS arrives for bce1, due to the interface mismatch of the >> prefix >> interface against the input interface, the NS packet was considered >> invalid and thus dropped. >>=20 >> Again, in case you didn't see my earlier reply, try the temporary = hack >> at >> http://people.freebsd.org/~qingli/nd6-ns.diff >>=20 >> until I commit a permanent patch. The problem was easily reproducible >> and >> I have verified with limited unit testing the patch works. >>=20 >> -- Qing >>=20 >>=20 >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >> Sent: Mon 12/14/2009 2:03 PM >> To: JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >>=20 >>=20 >> Thanks. Responses in-line. >>=20 >>=20 >>=20 >> On Mon, 14 Dec 2009, JASSAL Aman wrote: >>=20 >>> Hello Mr.Glatting, >>>=20 >>> Not that I'm an IPv6 genius, but at first sight your problem seems > to >> be a >>> route-related. I've put comments in-line. >>>=20 >>>=20 >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>>=20 >>>>=20 >>>> Elmer# netstat -rn >>>> Routing tables >>>>=20 >>>>=20 >>>> Internet6: >>>> Destination Gateway >> Flags >>>> Netif Expire >>>> ::/96 ::1 > UGRS >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 >>>> UGS bce0 >>>> ::1 ::1 UH >>>> lo0 ::ffff:0.0.0.0/96 ::1 >> UGRS >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >> U >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >> UHS >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >> UHS >>>> lo0 fe80::/10 ::1 >> UGRS >>>> lo0 fe80::%bce0/64 link#1 >> U >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >> UHS >>>> lo0 fe80::%bce1/64 link#2 >> U >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >> UHS >>>> lo0 fe80::%lo0/64 link#3 >> U >>>> lo0 fe80::1%lo0 link#3 >> UHS >>>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff01:2::/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff01:3::/32 ::1 >> U >>>> lo0 ff02::/16 ::1 >> UGRS >>>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff02::%bce1/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff02::%lo0/32 ::1 >> U >>>> lo0 >>>>=20 >>>=20 >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > was >>> expecting bce1 rather than lo0, I suppose you were as well :) If I'm >> not >>> mistaken, the packets emanating from bce1 go to the loopback >> interface, >>> thus not really going out. You can try specifying the route manually >>> with "route add *your parameters*" or even set it in /etc/rc.conf so >>> that it's loaded at boot-time. There's no reason why among 2 > physical >>> interfaces sharing the same fabric, one can ship packets out and the >>> other can't. >>>=20 >>=20 >> I was wondering about the route however I haven't figured out the > trick >> to >> get what I want. For example: >>=20 >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>=20 >> Elmer# route add >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >> route: writing to routing socket: File exists >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already >> in table >>=20 >> I did delete the lo0 route before I exected the above command. Also, = I >> haven't been able to specify a higher metric (e.g., -metric 2). That > is >> rejected too. However, I can say: >>=20 >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>=20 >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >>=20 >> Elmer# netstat -rn >> (snip) >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS >> bce1 >>=20 >> I don't think that is what I want. WHat I think I just said is "host > X" >> is >> out that door, rather than route net. If, however, I say Docs is out >> that >> door, I get: >>=20 >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >> add host docs.dco.penx.com: gateway bce1 >>=20 >> Elmer# ping6 >> docs.penx.com >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >> fd7c:3f2b:e791:1::ac13:a15 >> ping6: sendmsg: Operation not permitted >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 >>=20 >>=20 >>>>=20 >>>> Elmer's rc.config: >>>>=20 >>>>=20 >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen >> 64" >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen > 64 >> mtu >>>> 8192" >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" >>>>=20 >>>=20 >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never >> used >>> this myself so I can't really comment, and I can't say if there >> aren't any >>> sort of "interferences" with what you're trying to do. >>>=20 >>=20 >> I hope what I am specifying is to use the 32 bit IPv4 address as the >> last >> 32 bits of the IPv6 address, at least that is how it works out >> numerically. My numbering scheme for fixed assets is the last 32 bits >> of >> the 128 bit IPv6 address is the same as its IPv4 address. >>=20 >>=20 >>>>=20 >>>>=20 >>>> The router (cisco): >>>>=20 >>>>=20 >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 >> ipv6 >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>>=20 >>>=20 >>> Just a side-note, I'm not sure if it will be really useful to you, >> but you >>> could give it a try if you want to. Have you tried using your Cisco >> router >>> as a Router Advertisement Daemon ? That way, addresses would be > built >>> automatically and you could see how both interfaces react to such >>> advertisements. >>>=20 >>> I hope this helps. >>>=20 >>> ------------ >>> Aman Jassal >>>=20 >>> Wisdom comes from experience. >>> Experience comes from a lack of wisdom. >>>=20 >>>=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 >> _______________________________________________ >> 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-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 21:45:55 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8C81065693; Tue, 15 Dec 2009 21:45:55 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A35E18FC12; Tue, 15 Dec 2009 21:45:55 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFLjqdS003573; Tue, 15 Dec 2009 13:45:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 13:45:40 -0800 Message-ID: In-Reply-To: <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9zXC6xmQlJbuwQsG95QYD+62J8QAAkxaA References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> <5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> From: "Li, Qing" To: "Tom Pusateri" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 21:45:55 -0000 Thanks for reporting back. I asked you for a routing table dump in my previous email, would you mind emailing it to me privately? -- Qing > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@bangj.com] > Sent: Tuesday, December 15, 2009 1:28 PM > To: Li, Qing > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: patch: bad ipv6 neighbor solicitation >=20 > I didn't think this routing patch was related to the "bad neighbor > solicitation messages" as suggested in the subject field but I tried it > anyway. It does not fix my IPv6 problem. I still get "bad neighbor > solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 pings. >=20 > Thanks, > Tom >=20 > On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: >=20 > > Please find the more proper fix at > > > > http://people.freebsd.org/~qingli/nd6-patch.diff > > > > I realized I was slightly off in my previous email after > > I spent a bit more time looking through the problem. > > Both prefixes are present but one was marked off-link due > > to the fact only a single prefix route was installed in > > the routing table (non RADIX_MPATH system). > > > > I evaluated various options to fixing this issue, however, > > due to the association between NDPRF_ONLINK and the route > > installation, I decided to go with what I have here for > > the time being. > > > > I have verified the fix in my setup. Please apply the > > patch and report back. > > > > Thanks, > > > > -- Qing > > > > > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > >> net@freebsd.org] On Behalf Of Li, Qing > >> Sent: Monday, December 14, 2009 3:00 PM > >> To: Dennis Glatting; JASSAL Aman > >> Cc: freebsd-net@freebsd.org > >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > >> > >> > >> You don't need to perform all that route-foo. I believe the root > cause > >> of > >> this issue may be due to a bit of regression in the IPv6 prefix > >> management > >> code, and I am in the process of putting together a permanent fix. > >> > >> The issue as it stands today, is due to how the prefix was inserted > in > >> the first place. Since bce0 was configured first, the interface > >> associated > >> with the prefix is bce0. Later the reference count on the prefix is > >> simply incremented when bce1 configures another IPv6 address of the > >> same prefix. > >> > >> When ND6 NS arrives for bce1, due to the interface mismatch of the > >> prefix > >> interface against the input interface, the NS packet was considered > >> invalid and thus dropped. > >> > >> Again, in case you didn't see my earlier reply, try the temporary > hack > >> at > >> http://people.freebsd.org/~qingli/nd6-ns.diff > >> > >> until I commit a permanent patch. The problem was easily > reproducible > >> and > >> I have verified with limited unit testing the patch works. > >> > >> -- Qing > >> > >> > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > >> Sent: Mon 12/14/2009 2:03 PM > >> To: JASSAL Aman > >> Cc: freebsd-net@freebsd.org > >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > >> > >> > >> Thanks. Responses in-line. > >> > >> > >> > >> On Mon, 14 Dec 2009, JASSAL Aman wrote: > >> > >>> Hello Mr.Glatting, > >>> > >>> Not that I'm an IPv6 genius, but at first sight your problem seems > > to > >> be a > >>> route-related. I've put comments in-line. > >>> > >>> > >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > >>>> > >>>> > >>>> Elmer# netstat -rn > >>>> Routing tables > >>>> > >>>> > >>>> Internet6: > >>>> Destination Gateway > >> Flags > >>>> Netif Expire > >>>> ::/96 ::1 > > UGRS > >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 > >>>> UGS bce0 > >>>> ::1 ::1 UH > >>>> lo0 ::ffff:0.0.0.0/96 ::1 > >> UGRS > >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 > >> U > >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > >> UHS > >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > >> UHS > >>>> lo0 fe80::/10 ::1 > >> UGRS > >>>> lo0 fe80::%bce0/64 link#1 > >> U > >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > >> UHS > >>>> lo0 fe80::%bce1/64 link#2 > >> U > >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > >> UHS > >>>> lo0 fe80::%lo0/64 link#3 > >> U > >>>> lo0 fe80::1%lo0 link#3 > >> UHS > >>>> lo0 ff01:1::/32 > fe80::213:72ff:fe60:ac52%bce0 > >> U > >>>> bce0 ff01:2::/32 > > fd7c:3f2b:e791:1:0:1:ac13:a0a > >> U > >>>> bce1 ff01:3::/32 ::1 > >> U > >>>> lo0 ff02::/16 ::1 > >> UGRS > >>>> lo0 ff02::%bce0/32 > fe80::213:72ff:fe60:ac52%bce0 > >> U > >>>> bce0 ff02::%bce1/32 > > fd7c:3f2b:e791:1:0:1:ac13:a0a > >> U > >>>> bce1 ff02::%lo0/32 ::1 > >> U > >>>> lo0 > >>>> > >>> > >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > > was > >>> expecting bce1 rather than lo0, I suppose you were as well :) If > I'm > >> not > >>> mistaken, the packets emanating from bce1 go to the loopback > >> interface, > >>> thus not really going out. You can try specifying the route > manually > >>> with "route add *your parameters*" or even set it in /etc/rc.conf > so > >>> that it's loaded at boot-time. There's no reason why among 2 > > physical > >>> interfaces sharing the same fabric, one can ship packets out and > the > >>> other can't. > >>> > >> > >> I was wondering about the route however I haven't figured out the > > trick > >> to > >> get what I want. For example: > >> > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > >> > >> Elmer# route add > >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > >> route: writing to routing socket: File exists > >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route > already > >> in table > >> > >> I did delete the lo0 route before I exected the above command. Also, > I > >> haven't been able to specify a higher metric (e.g., -metric 2). That > > is > >> rejected too. However, I can say: > >> > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > >> > >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > >> > >> Elmer# netstat -rn > >> (snip) > >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS > >> bce1 > >> > >> I don't think that is what I want. WHat I think I just said is "host > > X" > >> is > >> out that door, rather than route net. If, however, I say Docs is out > >> that > >> door, I get: > >> > >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > >> add host docs.dco.penx.com: gateway bce1 > >> > >> Elmer# ping6 > >> docs.penx.com > >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > >> fd7c:3f2b:e791:1::ac13:a15 > >> ping6: sendmsg: Operation not permitted > >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 > >> > >> > >>>> > >>>> Elmer's rc.config: > >>>> > >>>> > >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 = prefixlen > >> 64" > >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 = prefixlen > > 64 > >> mtu > >>>> 8192" > >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > >>>> > >>> > >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've > never > >> used > >>> this myself so I can't really comment, and I can't say if there > >> aren't any > >>> sort of "interferences" with what you're trying to do. > >>> > >> > >> I hope what I am specifying is to use the 32 bit IPv4 address as the > >> last > >> 32 bits of the IPv6 address, at least that is how it works out > >> numerically. My numbering scheme for fixed assets is the last 32 > bits > >> of > >> the 128 bit IPv6 address is the same as its IPv4 address. > >> > >> > >>>> > >>>> > >>>> The router (cisco): > >>>> > >>>> > >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > >> ipv6 > >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > >>>> > >>> > >>> Just a side-note, I'm not sure if it will be really useful to you, > >> but you > >>> could give it a try if you want to. Have you tried using your Cisco > >> router > >>> as a Router Advertisement Daemon ? That way, addresses would be > > built > >>> automatically and you could see how both interfaces react to such > >>> advertisements. > >>> > >>> I hope this helps. > >>> > >>> ------------ > >>> Aman Jassal > >>> > >>> Wisdom comes from experience. > >>> Experience comes from a lack of wisdom. > >>> > >>> > >> _______________________________________________ > >> 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" > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 22:01:14 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C1B106566C; Tue, 15 Dec 2009 22:01:14 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 064908FC16; Tue, 15 Dec 2009 22:01:13 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFM0u2g006018; Tue, 15 Dec 2009 14:01:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 14:00:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: patch: bad ipv6 neighbor solicitation Thread-Index: Acp9zXC6xmQlJbuwQsG95QYD+62J8QAAkxaAAABuX9A= References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr><5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> From: "Li, Qing" To: "Tom Pusateri" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RE: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:01:14 -0000 Thanks for sending me the routing table output. Actually I believe both your problems are indeed related to the=20 prefix route.=20 I was able to reproduce Dennis Glatting's problem, which was due to one of the prefix entry being off-link. In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad disappeared and is not in the routing table. If you add the route by hand the problem should go away. I guess the question is what triggered the prefix route deletion. -- Qing > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Li, Qing > Sent: Tuesday, December 15, 2009 1:46 PM > To: Tom Pusateri > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > Subject: RE: patch: bad ipv6 neighbor solicitation >=20 > Thanks for reporting back. I asked you for a routing table dump > in my previous email, would you mind emailing it to me privately? >=20 > -- Qing >=20 >=20 > > -----Original Message----- > > From: Tom Pusateri [mailto:pusateri@bangj.com] > > Sent: Tuesday, December 15, 2009 1:28 PM > > To: Li, Qing > > Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org > > Subject: Re: patch: bad ipv6 neighbor solicitation > > > > I didn't think this routing patch was related to the "bad neighbor > > solicitation messages" as suggested in the subject field but I tried > it > > anyway. It does not fix my IPv6 problem. I still get "bad neighbor > > solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 > pings. > > > > Thanks, > > Tom > > > > On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: > > > > > Please find the more proper fix at > > > > > > http://people.freebsd.org/~qingli/nd6-patch.diff > > > > > > I realized I was slightly off in my previous email after > > > I spent a bit more time looking through the problem. > > > Both prefixes are present but one was marked off-link due > > > to the fact only a single prefix route was installed in > > > the routing table (non RADIX_MPATH system). > > > > > > I evaluated various options to fixing this issue, however, > > > due to the association between NDPRF_ONLINK and the route > > > installation, I decided to go with what I have here for > > > the time being. > > > > > > I have verified the fix in my setup. Please apply the > > > patch and report back. > > > > > > Thanks, > > > > > > -- Qing > > > > > > > > >> -----Original Message----- > > >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > >> net@freebsd.org] On Behalf Of Li, Qing > > >> Sent: Monday, December 14, 2009 3:00 PM > > >> To: Dennis Glatting; JASSAL Aman > > >> Cc: freebsd-net@freebsd.org > > >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > >> > > >> > > >> You don't need to perform all that route-foo. I believe the root > > cause > > >> of > > >> this issue may be due to a bit of regression in the IPv6 prefix > > >> management > > >> code, and I am in the process of putting together a permanent fix. > > >> > > >> The issue as it stands today, is due to how the prefix was > inserted > > in > > >> the first place. Since bce0 was configured first, the interface > > >> associated > > >> with the prefix is bce0. Later the reference count on the prefix > is > > >> simply incremented when bce1 configures another IPv6 address of > the > > >> same prefix. > > >> > > >> When ND6 NS arrives for bce1, due to the interface mismatch of the > > >> prefix > > >> interface against the input interface, the NS packet was > considered > > >> invalid and thus dropped. > > >> > > >> Again, in case you didn't see my earlier reply, try the temporary > > hack > > >> at > > >> http://people.freebsd.org/~qingli/nd6-ns.diff > > >> > > >> until I commit a permanent patch. The problem was easily > > reproducible > > >> and > > >> I have verified with limited unit testing the patch works. > > >> > > >> -- Qing > > >> > > >> > > >> -----Original Message----- > > >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting > > >> Sent: Mon 12/14/2009 2:03 PM > > >> To: JASSAL Aman > > >> Cc: freebsd-net@freebsd.org > > >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) > > >> > > >> > > >> Thanks. Responses in-line. > > >> > > >> > > >> > > >> On Mon, 14 Dec 2009, JASSAL Aman wrote: > > >> > > >>> Hello Mr.Glatting, > > >>> > > >>> Not that I'm an IPv6 genius, but at first sight your problem > seems > > > to > > >> be a > > >>> route-related. I've put comments in-line. > > >>> > > >>> > > >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : > > >>>> > > >>>> > > >>>> Elmer# netstat -rn > > >>>> Routing tables > > >>>> > > >>>> > > >>>> Internet6: > > >>>> Destination Gateway > > >> Flags > > >>>> Netif Expire > > >>>> ::/96 ::1 > > > UGRS > > >>>> lo0 =3D> default fd7c:3f2b:e791:1::1 > > >>>> UGS bce0 > > >>>> ::1 ::1 > UH > > >>>> lo0 ::ffff:0.0.0.0/96 ::1 > > >> UGRS > > >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 > > >> U > > >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 > > >> UHS > > >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 > > >> UHS > > >>>> lo0 fe80::/10 ::1 > > >> UGRS > > >>>> lo0 fe80::%bce0/64 link#1 > > >> U > > >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 > > >> UHS > > >>>> lo0 fe80::%bce1/64 link#2 > > >> U > > >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 > > >> UHS > > >>>> lo0 fe80::%lo0/64 link#3 > > >> U > > >>>> lo0 fe80::1%lo0 link#3 > > >> UHS > > >>>> lo0 ff01:1::/32 > > fe80::213:72ff:fe60:ac52%bce0 > > >> U > > >>>> bce0 ff01:2::/32 > > > fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> U > > >>>> bce1 ff01:3::/32 ::1 > > >> U > > >>>> lo0 ff02::/16 ::1 > > >> UGRS > > >>>> lo0 ff02::%bce0/32 > > fe80::213:72ff:fe60:ac52%bce0 > > >> U > > >>>> bce0 ff02::%bce1/32 > > > fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> U > > >>>> bce1 ff02::%lo0/32 ::1 > > >> U > > >>>> lo0 > > >>>> > > >>> > > >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > > > was > > >>> expecting bce1 rather than lo0, I suppose you were as well :) If > > I'm > > >> not > > >>> mistaken, the packets emanating from bce1 go to the loopback > > >> interface, > > >>> thus not really going out. You can try specifying the route > > manually > > >>> with "route add *your parameters*" or even set it in /etc/rc.conf > > so > > >>> that it's loaded at boot-time. There's no reason why among 2 > > > physical > > >>> interfaces sharing the same fabric, one can ship packets out and > > the > > >>> other can't. > > >>> > > >> > > >> I was wondering about the route however I haven't figured out the > > > trick > > >> to > > >> get what I want. For example: > > >> > > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> > > >> Elmer# route add > > >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 > > >> route: writing to routing socket: File exists > > >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route > > already > > >> in table > > >> > > >> I did delete the lo0 route before I exected the above command. > Also, > > I > > >> haven't been able to specify a higher metric (e.g., -metric 2). > That > > > is > > >> rejected too. However, I can say: > > >> > > >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a > > >> > > >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 > > >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 > > >> > > >> Elmer# netstat -rn > > >> (snip) > > >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 > UHS > > >> bce1 > > >> > > >> I don't think that is what I want. WHat I think I just said is > "host > > > X" > > >> is > > >> out that door, rather than route net. If, however, I say Docs is > out > > >> that > > >> door, I get: > > >> > > >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 > > >> add host docs.dco.penx.com: gateway bce1 > > >> > > >> Elmer# ping6 > > >> docs.penx.com > > >> PING6(56=3D40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> > > >> fd7c:3f2b:e791:1::ac13:a15 > > >> ping6: sendmsg: Operation not permitted > > >> ping6: wrote docs.dco.penx.com 16 chars, ret=3D-1 > > >> > > >> > > >>>> > > >>>> Elmer's rc.config: > > >>>> > > >>>> > > >>>> ipv6_enable=3D"YES" ipv6_network_interfaces=3D"bce0 bce1" > > >>>> ipv6_ifconfig_bce0=3D"FD7C:3F2B:E791:0001::0:172.19.10.10 > prefixlen > > >> 64" > > >>>> ipv6_ifconfig_bce1=3D"FD7C:3F2B:E791:0001::1:172.19.10.10 > prefixlen > > > 64 > > >> mtu > > >>>> 8192" > > >>>> ipv6_defaultrouter=3D"FD7C:3F2B:E791:0001::1" > > >>>> > > >>> > > >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've > > never > > >> used > > >>> this myself so I can't really comment, and I can't say if there > > >> aren't any > > >>> sort of "interferences" with what you're trying to do. > > >>> > > >> > > >> I hope what I am specifying is to use the 32 bit IPv4 address as > the > > >> last > > >> 32 bits of the IPv6 address, at least that is how it works out > > >> numerically. My numbering scheme for fixed assets is the last 32 > > bits > > >> of > > >> the 128 bit IPv6 address is the same as its IPv4 address. > > >> > > >> > > >>>> > > >>>> > > >>>> The router (cisco): > > >>>> > > >>>> > > >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 > > >> ipv6 > > >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) > > >>>> > > >>> > > >>> Just a side-note, I'm not sure if it will be really useful to you, > > >> but you > > >>> could give it a try if you want to. Have you tried using your > Cisco > > >> router > > >>> as a Router Advertisement Daemon ? That way, addresses would be > > > built > > >>> automatically and you could see how both interfaces react to such > > >>> advertisements. > > >>> > > >>> I hope this helps. > > >>> > > >>> ------------ > > >>> Aman Jassal > > >>> > > >>> Wisdom comes from experience. > > >>> Experience comes from a lack of wisdom. > > >>> > > >>> > > >> _______________________________________________ > > >> 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" > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable- > > unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 22:58:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86FA5106566C; Tue, 15 Dec 2009 22:58:33 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (jj.bangj.com [198.86.87.199]) by mx1.freebsd.org (Postfix) with ESMTP id 2845B8FC15; Tue, 15 Dec 2009 22:58:33 +0000 (UTC) Received: from [172.16.10.11] (cpe-066-026-040-218.nc.res.rr.com [66.26.40.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by jj.bangj.com (Postfix) with ESMTPSA id 4D2383A1; Tue, 15 Dec 2009 17:58:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tom Pusateri In-Reply-To: Date: Tue, 15 Dec 2009 17:58:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr><5ED6B687-4191-4B11-A2F7-B01F67FB9D16@bangj.com> To: "Li, Qing" X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 22:58:33 -0000 You are correct. I added the route and it works fine. route add -inet6 2610:28:1800:4001::/64 -iface em0 Thanks, Tom On Dec 15, 2009, at 5:00 PM, Li, Qing wrote: > Thanks for sending me the routing table output. > > Actually I believe both your problems are indeed related to the > prefix route. > > I was able to reproduce Dennis Glatting's problem, which was due > to one of the prefix entry being off-link. > > In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad > disappeared and is not in the routing table. If you add the route > by hand the problem should go away. > > I guess the question is what triggered the prefix route deletion. > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Li, Qing >> Sent: Tuesday, December 15, 2009 1:46 PM >> To: Tom Pusateri >> Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org >> Subject: RE: patch: bad ipv6 neighbor solicitation >> >> Thanks for reporting back. I asked you for a routing table dump >> in my previous email, would you mind emailing it to me privately? >> >> -- Qing >> >> >>> -----Original Message----- >>> From: Tom Pusateri [mailto:pusateri@bangj.com] >>> Sent: Tuesday, December 15, 2009 1:28 PM >>> To: Li, Qing >>> Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org >>> Subject: Re: patch: bad ipv6 neighbor solicitation >>> >>> I didn't think this routing patch was related to the "bad neighbor >>> solicitation messages" as suggested in the subject field but I tried >> it >>> anyway. It does not fix my IPv6 problem. I still get "bad neighbor >>> solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 >> pings. >>> >>> Thanks, >>> Tom >>> >>> On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: >>> >>>> Please find the more proper fix at >>>> >>>> http://people.freebsd.org/~qingli/nd6-patch.diff >>>> >>>> I realized I was slightly off in my previous email after >>>> I spent a bit more time looking through the problem. >>>> Both prefixes are present but one was marked off-link due >>>> to the fact only a single prefix route was installed in >>>> the routing table (non RADIX_MPATH system). >>>> >>>> I evaluated various options to fixing this issue, however, >>>> due to the association between NDPRF_ONLINK and the route >>>> installation, I decided to go with what I have here for >>>> the time being. >>>> >>>> I have verified the fix in my setup. Please apply the >>>> patch and report back. >>>> >>>> Thanks, >>>> >>>> -- Qing >>>> >>>> >>>>> -----Original Message----- >>>>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>>>> net@freebsd.org] On Behalf Of Li, Qing >>>>> Sent: Monday, December 14, 2009 3:00 PM >>>>> To: Dennis Glatting; JASSAL Aman >>>>> Cc: freebsd-net@freebsd.org >>>>> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 > (fwd) >>>>> >>>>> >>>>> You don't need to perform all that route-foo. I believe the root >>> cause >>>>> of >>>>> this issue may be due to a bit of regression in the IPv6 prefix >>>>> management >>>>> code, and I am in the process of putting together a permanent > fix. >>>>> >>>>> The issue as it stands today, is due to how the prefix was >> inserted >>> in >>>>> the first place. Since bce0 was configured first, the interface >>>>> associated >>>>> with the prefix is bce0. Later the reference count on the prefix >> is >>>>> simply incremented when bce1 configures another IPv6 address of >> the >>>>> same prefix. >>>>> >>>>> When ND6 NS arrives for bce1, due to the interface mismatch of > the >>>>> prefix >>>>> interface against the input interface, the NS packet was >> considered >>>>> invalid and thus dropped. >>>>> >>>>> Again, in case you didn't see my earlier reply, try the temporary >>> hack >>>>> at >>>>> http://people.freebsd.org/~qingli/nd6-ns.diff >>>>> >>>>> until I commit a permanent patch. The problem was easily >>> reproducible >>>>> and >>>>> I have verified with limited unit testing the patch works. >>>>> >>>>> -- Qing >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >>>>> Sent: Mon 12/14/2009 2:03 PM >>>>> To: JASSAL Aman >>>>> Cc: freebsd-net@freebsd.org >>>>> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 > (fwd) >>>>> >>>>> >>>>> Thanks. Responses in-line. >>>>> >>>>> >>>>> >>>>> On Mon, 14 Dec 2009, JASSAL Aman wrote: >>>>> >>>>>> Hello Mr.Glatting, >>>>>> >>>>>> Not that I'm an IPv6 genius, but at first sight your problem >> seems >>>> to >>>>> be a >>>>>> route-related. I've put comments in-line. >>>>>> >>>>>> >>>>>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>>>>> >>>>>>> >>>>>>> Elmer# netstat -rn >>>>>>> Routing tables >>>>>>> >>>>>>> >>>>>>> Internet6: >>>>>>> Destination Gateway >>>>> Flags >>>>>>> Netif Expire >>>>>>> ::/96 ::1 >>>> UGRS >>>>>>> lo0 => default fd7c:3f2b:e791:1::1 >>>>>>> UGS bce0 >>>>>>> ::1 ::1 >> UH >>>>>>> lo0 ::ffff:0.0.0.0/96 ::1 >>>>> UGRS >>>>>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >>>>> U >>>>>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >>>>> UHS >>>>>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >>>>> UHS >>>>>>> lo0 fe80::/10 ::1 >>>>> UGRS >>>>>>> lo0 fe80::%bce0/64 link#1 >>>>> U >>>>>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >>>>> UHS >>>>>>> lo0 fe80::%bce1/64 link#2 >>>>> U >>>>>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >>>>> UHS >>>>>>> lo0 fe80::%lo0/64 link#3 >>>>> U >>>>>>> lo0 fe80::1%lo0 link#3 >>>>> UHS >>>>>>> lo0 ff01:1::/32 >>> fe80::213:72ff:fe60:ac52%bce0 >>>>> U >>>>>>> bce0 ff01:2::/32 >>>> fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> U >>>>>>> bce1 ff01:3::/32 ::1 >>>>> U >>>>>>> lo0 ff02::/16 ::1 >>>>> UGRS >>>>>>> lo0 ff02::%bce0/32 >>> fe80::213:72ff:fe60:ac52%bce0 >>>>> U >>>>>>> bce0 ff02::%bce1/32 >>>> fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> U >>>>>>> bce1 ff02::%lo0/32 ::1 >>>>> U >>>>>>> lo0 >>>>>>> >>>>>> >>>>>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. > I >>>> was >>>>>> expecting bce1 rather than lo0, I suppose you were as well :) If >>> I'm >>>>> not >>>>>> mistaken, the packets emanating from bce1 go to the loopback >>>>> interface, >>>>>> thus not really going out. You can try specifying the route >>> manually >>>>>> with "route add *your parameters*" or even set it in > /etc/rc.conf >>> so >>>>>> that it's loaded at boot-time. There's no reason why among 2 >>>> physical >>>>>> interfaces sharing the same fabric, one can ship packets out and >>> the >>>>>> other can't. >>>>>> >>>>> >>>>> I was wondering about the route however I haven't figured out the >>>> trick >>>>> to >>>>> get what I want. For example: >>>>> >>>>> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> >>>>> Elmer# route add >>>>> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >>>>> route: writing to routing socket: File exists >>>>> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route >>> already >>>>> in table >>>>> >>>>> I did delete the lo0 route before I exected the above command. >> Also, >>> I >>>>> haven't been able to specify a higher metric (e.g., -metric 2). >> That >>>> is >>>>> rejected too. However, I can say: >>>>> >>>>> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >>>>> >>>>> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >>>>> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >>>>> >>>>> Elmer# netstat -rn >>>>> (snip) >>>>> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 >> UHS >>>>> bce1 >>>>> >>>>> I don't think that is what I want. WHat I think I just said is >> "host >>>> X" >>>>> is >>>>> out that door, rather than route net. If, however, I say Docs is >> out >>>>> that >>>>> door, I get: >>>>> >>>>> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >>>>> add host docs.dco.penx.com: gateway bce1 >>>>> >>>>> Elmer# ping6 >>>>> docs.penx.com >>>>> PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >>>>> fd7c:3f2b:e791:1::ac13:a15 >>>>> ping6: sendmsg: Operation not permitted >>>>> ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >>>>> >>>>> >>>>>>> >>>>>>> Elmer's rc.config: >>>>>>> >>>>>>> >>>>>>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>>>>>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 >> prefixlen >>>>> 64" >>>>>>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 >> prefixlen >>>> 64 >>>>> mtu >>>>>>> 8192" >>>>>>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>>>>>> >>>>>> >>>>>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've >>> never >>>>> used >>>>>> this myself so I can't really comment, and I can't say if there >>>>> aren't any >>>>>> sort of "interferences" with what you're trying to do. >>>>>> >>>>> >>>>> I hope what I am specifying is to use the 32 bit IPv4 address as >> the >>>>> last >>>>> 32 bits of the IPv6 address, at least that is how it works out >>>>> numerically. My numbering scheme for fixed assets is the last 32 >>> bits >>>>> of >>>>> the 128 bit IPv6 address is the same as its IPv4 address. >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> The router (cisco): >>>>>>> >>>>>>> >>>>>>> interface GigabitEthernet0/0 ipv6 address > FD7C:3F2B:E791:1::1/64 >>>>> ipv6 >>>>>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>>>>> >>>>>> >>>>>> Just a side-note, I'm not sure if it will be really useful to > you, >>>>> but you >>>>>> could give it a try if you want to. Have you tried using your >> Cisco >>>>> router >>>>>> as a Router Advertisement Daemon ? That way, addresses would be >>>> built >>>>>> automatically and you could see how both interfaces react to > such >>>>>> advertisements. >>>>>> >>>>>> I hope this helps. >>>>>> >>>>>> ------------ >>>>>> Aman Jassal >>>>>> >>>>>> Wisdom comes from experience. >>>>>> Experience comes from a lack of wisdom. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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" >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable- >>> unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 15 23:37:18 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FA6106566C; Tue, 15 Dec 2009 23:37:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 19CFC8FC13; Tue, 15 Dec 2009 23:37:18 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBFNbHq6020534; Tue, 15 Dec 2009 15:37:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Dec 2009 15:37:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: net/mpd5, ppp, proxy-arp issues Thread-Index: Acp934LhgJ2LhcpOScatB1tE2Gb5UQ== From: "Li, Qing" To: , Cc: Qing Li , freebsd-current@freebsd.org Subject: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 23:37:18 -0000 Hi, Recently there have been several reports regarding issues with ppp, mpd5 and proxy-arp configuration over the ppp links. I read through the various postings and the problems seem to be: 1. Unable to add proxy-arp entries for the remote ppp clients. 2. Log showing "ifa_add_loopback_route: insertion failed" causing=20 some userland applications to fail. May I ask that you try applying patch http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff and report back if the patch fixes your problems. And if not,=20 please describe what additional issues you are having. Thanks, -- Qing From owner-freebsd-net@FreeBSD.ORG Wed Dec 16 00:30:50 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D6B106566B for ; Wed, 16 Dec 2009 00:30:50 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from traktor.dnepro.net (roof1.dnepro.net [212.3.111.66]) by mx1.freebsd.org (Postfix) with ESMTP id DC4308FC0A for ; Wed, 16 Dec 2009 00:30:49 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id nBG0UkHJ063408 for ; Wed, 16 Dec 2009 02:30:47 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id nBG0UkJX063407 for freebsd-net@freebsd.org; Wed, 16 Dec 2009 02:30:46 +0200 (EET) (envelope-from john) Date: Wed, 16 Dec 2009 02:30:46 +0200 From: Eugene Perevyazko To: "freebsd-net@freebsd.org" Message-ID: <20091216003046.GA57694@traktor.dnepro.net> Mail-Followup-To: "freebsd-net@freebsd.org" References: <20091211102928.GA40831@traktor.dnepro.net> <9F5E7B59-0CF1-47A7-BE85-41B2C9F0D22B@gmail.com> <20091211105336.GB40831@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091211105336.GB40831@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: How can I find the reason network writes fail with ENOMEM on 7.x? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 00:30:50 -0000 I've found a high number of failures in output of `vmstat -z` in category of "NetGraph data items". Trying to monitor those failures I see that they increase in short moments and stay at the level for longer. It's like NetGraph data items: 36, 546, 1, 545, 514855314626, 1247384311 NetGraph data items: 36, 546, 6, 540, 514855480968, 1247384311 NetGraph data items: 36, 546, 5, 541, 514855721631, 1247384311 NetGraph data items: 36, 546, 507, 39, 514857074684, 1247384437 NetGraph data items: 36, 546, 22, 524, 514857862740, 1247384443 with a second between consecutive lines. It looks like I need to raise net.graph.maxdata from a default of 512. What are the safe values for this tunable cause it carries comment of "limit the damage of a DoS"? What kind of DoS is it about? -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Wed Dec 16 02:45:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308C11065670 for ; Wed, 16 Dec 2009 02:45:35 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer-sprint.dco.penx.com [65.173.215.114]) by mx1.freebsd.org (Postfix) with ESMTP id F13B98FC15 for ; Wed, 16 Dec 2009 02:45:34 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.3/8.14.3) with ESMTP id nBG2jIKb001477; Tue, 15 Dec 2009 19:45:18 -0700 (MST) (envelope-from freebsd@penx.com) Date: Tue, 15 Dec 2009 19:45:18 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: "Li, Qing" In-Reply-To: Message-ID: References: <9223.83.206.131.26.1260781902.squirrel@webmail.esigetel.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch: bad ipv6 neighbor solicitation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 02:45:35 -0000 This patch works for me. On Mon, 14 Dec 2009, Li, Qing wrote: > Please find the more proper fix at > > http://people.freebsd.org/~qingli/nd6-patch.diff > > I realized I was slightly off in my previous email after > I spent a bit more time looking through the problem. > Both prefixes are present but one was marked off-link due > to the fact only a single prefix route was installed in > the routing table (non RADIX_MPATH system). > > I evaluated various options to fixing this issue, however, > due to the association between NDPRF_ONLINK and the route > installation, I decided to go with what I have here for > the time being. > > I have verified the fix in my setup. Please apply the > patch and report back. > > Thanks, > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Li, Qing >> Sent: Monday, December 14, 2009 3:00 PM >> To: Dennis Glatting; JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> You don't need to perform all that route-foo. I believe the root cause >> of >> this issue may be due to a bit of regression in the IPv6 prefix >> management >> code, and I am in the process of putting together a permanent fix. >> >> The issue as it stands today, is due to how the prefix was inserted in >> the first place. Since bce0 was configured first, the interface >> associated >> with the prefix is bce0. Later the reference count on the prefix is >> simply incremented when bce1 configures another IPv6 address of the >> same prefix. >> >> When ND6 NS arrives for bce1, due to the interface mismatch of the >> prefix >> interface against the input interface, the NS packet was considered >> invalid and thus dropped. >> >> Again, in case you didn't see my earlier reply, try the temporary hack >> at >> http://people.freebsd.org/~qingli/nd6-ns.diff >> >> until I commit a permanent patch. The problem was easily reproducible >> and >> I have verified with limited unit testing the patch works. >> >> -- Qing >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Dennis Glatting >> Sent: Mon 12/14/2009 2:03 PM >> To: JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> Thanks. Responses in-line. >> >> >> >> On Mon, 14 Dec 2009, JASSAL Aman wrote: >> >>> Hello Mr.Glatting, >>> >>> Not that I'm an IPv6 genius, but at first sight your problem seems > to >> be a >>> route-related. I've put comments in-line. >>> >>> >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : >>>> >>>> >>>> Elmer# netstat -rn >>>> Routing tables >>>> >>>> >>>> Internet6: >>>> Destination Gateway >> Flags >>>> Netif Expire >>>> ::/96 ::1 > UGRS >>>> lo0 => default fd7c:3f2b:e791:1::1 >>>> UGS bce0 >>>> ::1 ::1 UH >>>> lo0 ::ffff:0.0.0.0/96 ::1 >> UGRS >>>> lo0 fd7c:3f2b:e791:1::/64 link#1 >> U >>>> bce0 fd7c:3f2b:e791:1::ac13:a0a link#1 >> UHS >>>> lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >> UHS >>>> lo0 fe80::/10 ::1 >> UGRS >>>> lo0 fe80::%bce0/64 link#1 >> U >>>> bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >> UHS >>>> lo0 fe80::%bce1/64 link#2 >> U >>>> bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >> UHS >>>> lo0 fe80::%lo0/64 link#3 >> U >>>> lo0 fe80::1%lo0 link#3 >> UHS >>>> lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff01:2::/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff01:3::/32 ::1 >> U >>>> lo0 ff02::/16 ::1 >> UGRS >>>> lo0 ff02::%bce0/32 fe80::213:72ff:fe60:ac52%bce0 >> U >>>> bce0 ff02::%bce1/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U >>>> bce1 ff02::%lo0/32 ::1 >> U >>>> lo0 >>>> >>> >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > was >>> expecting bce1 rather than lo0, I suppose you were as well :) If I'm >> not >>> mistaken, the packets emanating from bce1 go to the loopback >> interface, >>> thus not really going out. You can try specifying the route manually >>> with "route add *your parameters*" or even set it in /etc/rc.conf so >>> that it's loaded at boot-time. There's no reason why among 2 > physical >>> interfaces sharing the same fabric, one can ship packets out and the >>> other can't. >>> >> >> I was wondering about the route however I haven't figured out the > trick >> to >> get what I want. For example: >> >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >> >> Elmer# route add >> -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1 >> route: writing to routing socket: File exists >> add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already >> in table >> >> I did delete the lo0 route before I exected the above command. Also, I >> haven't been able to specify a higher metric (e.g., -metric 2). That > is >> rejected too. However, I can say: >> >> Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a >> delete host fd7c:3f2b:e791:1:0:1:ac13:a0a >> >> Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1 >> add host fd7c:3f2b:e791:1:0:1:ac13:a0a: gateway bce1 >> >> Elmer# netstat -rn >> (snip) >> fd7c:3f2b:e791:1:0:1:ac13:a0a 00:13:72:60:ac:50 UHS >> bce1 >> >> I don't think that is what I want. WHat I think I just said is "host > X" >> is >> out that door, rather than route net. If, however, I say Docs is out >> that >> door, I get: >> >> Elmer# route add -inet6 docs.dco.penx.com -iface bce1 >> add host docs.dco.penx.com: gateway bce1 >> >> Elmer# ping6 >> docs.penx.com >> PING6(56=40+8+8 bytes) fd7c:3f2b:e791:1:0:1:ac13:a0a --> >> fd7c:3f2b:e791:1::ac13:a15 >> ping6: sendmsg: Operation not permitted >> ping6: wrote docs.dco.penx.com 16 chars, ret=-1 >> >> >>>> >>>> Elmer's rc.config: >>>> >>>> >>>> ipv6_enable="YES" ipv6_network_interfaces="bce0 bce1" >>>> ipv6_ifconfig_bce0="FD7C:3F2B:E791:0001::0:172.19.10.10 prefixlen >> 64" >>>> ipv6_ifconfig_bce1="FD7C:3F2B:E791:0001::1:172.19.10.10 prefixlen > 64 >> mtu >>>> 8192" >>>> ipv6_defaultrouter="FD7C:3F2B:E791:0001::1" >>>> >>> >>> Erm... You're using IPv4 addresses encapsulated in IPv6 ? I've never >> used >>> this myself so I can't really comment, and I can't say if there >> aren't any >>> sort of "interferences" with what you're trying to do. >>> >> >> I hope what I am specifying is to use the 32 bit IPv4 address as the >> last >> 32 bits of the IPv6 address, at least that is how it works out >> numerically. My numbering scheme for fixed assets is the last 32 bits >> of >> the 128 bit IPv6 address is the same as its IPv4 address. >> >> >>>> >>>> >>>> The router (cisco): >>>> >>>> >>>> interface GigabitEthernet0/0 ipv6 address FD7C:3F2B:E791:1::1/64 >> ipv6 >>>> enable ipv6 nd prefix FD7C:3F2B:E791:1::/64 (etc) >>>> >>> >>> Just a side-note, I'm not sure if it will be really useful to you, >> but you >>> could give it a try if you want to. Have you tried using your Cisco >> router >>> as a Router Advertisement Daemon ? That way, addresses would be > built >>> automatically and you could see how both interfaces react to such >>> advertisements. >>> >>> I hope this helps. >>> >>> ------------ >>> Aman Jassal >>> >>> Wisdom comes from experience. >>> Experience comes from a lack of wisdom. >>> >>> >> _______________________________________________ >> 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" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Dec 16 15:10:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AE2B106568F for ; Wed, 16 Dec 2009 15:10:03 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from Harpy.sky.od.ua (harpy.sky.od.ua [81.25.224.2]) by mx1.freebsd.org (Postfix) with ESMTP id E674E8FC23 for ; Wed, 16 Dec 2009 15:10:01 +0000 (UTC) Received: from logos.sky.od.ua (logos [81.25.224.11]) by Harpy.sky.od.ua (8.12.10/8.12.10) with ESMTP id nBGF9Dwi008553; Wed, 16 Dec 2009 17:09:13 +0200 Message-ID: <4B28F841.1070900@skylinetele.com> Date: Wed, 16 Dec 2009 17:09:53 +0200 From: "Prokofiev S.P." User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: "Li, Qing" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Qing Li Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 15:10:03 -0000 Thank you ! The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with mpd5). Please, somebody fix the bug kern/141285... Li, Qing wrote: > Hi, > > Recently there have been several reports regarding issues with ppp, mpd5 > and proxy-arp configuration over the ppp links. I read through the > various postings and the problems seem to be: > > 1. Unable to add proxy-arp entries for the remote ppp clients. > > 2. Log showing "ifa_add_loopback_route: insertion failed" causing > some userland applications to fail. > > May I ask that you try applying patch > > http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff > > and report back if the patch fixes your problems. And if not, > please describe what additional issues you are having. > > Thanks, > > -- Qing > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 16 23:40:03 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03C8B106566C; Wed, 16 Dec 2009 23:40:03 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D43868FC0C; Wed, 16 Dec 2009 23:40:02 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBGNdtT2006250; Wed, 16 Dec 2009 15:39:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: BdEZ Di0j LAwe MdcC OUS0 SFMO TOS7 TY1S T5Ob Xt1z e78K jn7w rAL1 r7xz s38X t1fW; 4; YgB1AGMAaAB0AGEAagB6AEAAYgBvAHIAcwBpAGMAZQAuAG4AZQB0ADsAZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAYQBkAGEAbQAuAGcAcwA7AGYAcgBlAGUAYgBzAGQALQBuAGUAdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AHEAaQBuAGcAbABpAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {4697F427-529E-4117-8786-345C7FF5F023}; cQBpAG4AZwAuAGwAaQBAAGIAbAB1AGUAYwBvAGEAdAAuAGMAbwBtAA==; Wed, 16 Dec 2009 23:39:34 GMT; aQBzAHMAdQBlACAAdwBpAHQAaAAgAG8AcABlAG4AYgBnAHAAZAAgACsAIAA4AC4AMAA= x-cr-puzzleid: {4697F427-529E-4117-8786-345C7FF5F023} Content-class: urn:content-classes:message Date: Wed, 16 Dec 2009 15:39:34 -0800 Message-ID: In-Reply-To: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue with openbgpd + 8.0 Thread-Index: AcprHnTWtOIcBwzBR62XF8pkB9C/XATiTX4g References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> From: "Li, Qing" To: "Adam Jacob Muller" , "Michal Buchtik" Cc: freebsd-net@freebsd.org, Qing Li Subject: issue with openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:40:03 -0000 Hi, You have reported issues regarding openbgp/bgpd exiting=20 abnormally. Please apply patch: http://people.freebsd.org/~qingli/bgpd-patch-121615.diff and let me know if it fixes your issue. I performed limited=20 unit testing. Thanks, -- Qing From owner-freebsd-net@FreeBSD.ORG Wed Dec 16 23:58:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E13106566C for ; Wed, 16 Dec 2009 23:58:33 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id D7D898FC19 for ; Wed, 16 Dec 2009 23:58:32 +0000 (UTC) Received: by iwn36 with SMTP id 36so1065574iwn.3 for ; Wed, 16 Dec 2009 15:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=BJnJ72Va8H5CtdRa2H5ZdWabqfWmzt1NEGddecOmlCo=; b=m3A+uxFNoqhCbUy58S/JlXMY6J//pjPbsQ+2oflGvshlP7amqrgrRkdJ5VWyj2PzJh kENb2zQFTylrN6xa94NrsGF+K/YyoBB6UVLG3jQd0r53Cx2herTHwNzpH1olE1BcotES hMQUVgGcupNzD4Jpig6Q5VAy5pcotAYD+suqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wqIrTyO9i6o01lRYT+G39L5NBvyptGMFZftZyx2B5KIzQZLYAkHQ+M+hENHXum4fN+ njOIV5sHyUExvrL0HqRpvm1aPYhlfZTF7P6x1lbmLbYk4159/tvrtOnYsOF0tM6l7Xi1 kXVwDCnSEDV553/tMunjJ4cywELX5R2whf8J4= MIME-Version: 1.0 Received: by 10.231.156.205 with SMTP id y13mr337524ibw.27.1261007911939; Wed, 16 Dec 2009 15:58:31 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2009 15:58:31 -0800 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: 8.0R, AMD64 and wpi is giving me major grief X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:58:33 -0000 Anyone? BTW - I dual-boot this with XP, and don't have any issues with wireless when running that. Also works flawlessly when running wired, over em0. I've just done a BIOS update - I'll be trying that out tomorrow, and will update this with results. Kurt On Mon, Dec 14, 2009 at 19:21, Kurt Buff wrote: > All, > > I've got a Lenovo t61 with 4gbytes RAM that is giving me fits. > > It's got a 3945abg chip in it, and it's getting really flaky. I can > boot it up, and work at the console for a while, and that seems to > work OK, usually. > > However, today, when I start up my gui (xfce4), wireless just dies on > me. For a week before, it would usually run for a while (sometimes > days) before dying on me and requiring a reboot. > > Below is a snippet of /var/log/messages - Does this mean anything to > anyone? Is there anything I can do to recover once this happens? > > Thanks, > > Kurt > > Dec 14 07:16:43 grimsqueaker kernel: wlan0: Ethernet address: 00:1f:3c:4d:e2:55 > Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 1 > Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 3 > Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 4 > Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification > version 10e02 alive 1 > Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification > version 10e02 alive 1 > Dec 14 07:16:43 grimsqueaker kernel: wpi_newstate: INIT -> SCAN flags 0x0 > Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-SCAN-RESULTS > Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Trying to associate > with 00:23:69:82:b2:bf (SSID='5705NE197th' freq=2462 MHz) > Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: SCAN -> AUTH flags 0x0 > Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8005 cck f ofdm 15 > Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: AUTH -> ASSOC flags 0x0 > Dec 14 07:16:45 grimsqueaker kernel: > Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Associated with > 00:23:69:82:b2:bf > Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: ASSOC -> RUN flags 0x0 > Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8035 > Dec 14 07:16:45 grimsqueaker kernel: wlan0: link state changed to UP > Dec 14 07:16:45 grimsqueaker kernel: wpi0: need multicast update callback > Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: WPA: Key negotiation > completed with 00:23:69:82:b2:bf [PTK=CCMP GTK=CCMP] > Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-CONNECTED > - Connection to 00:23:69:82:b2:bf completed (auth) [id=0 id_str=] > Dec 14 07:16:53 grimsqueaker dhclient: New IP Address (wlan0): 192.168.151.104 > Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback > Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback > Dec 14 07:16:53 grimsqueaker dhclient: New Subnet Mask (wlan0): 255.255.255.0 > Dec 14 07:16:53 grimsqueaker dhclient: New Broadcast Address (wlan0): > 192.168.151.255 > Dec 14 07:16:53 grimsqueaker dhclient: New Routers (wlan0): 192.168.151.1 > Dec 14 07:17:56 grimsqueaker kernel: drm0: on vgapci0 > Dec 14 07:17:56 grimsqueaker kernel: info: [drm] MSI enabled 1 message(s) > Dec 14 07:17:56 grimsqueaker kernel: vgapci0: child drm0 requested > pci_enable_busmaster > Dec 14 07:17:56 grimsqueaker kernel: info: [drm] AGP at 0xe0000000 256MB > Dec 14 07:17:56 grimsqueaker kernel: info: [drm] Initialized i915 1.6.0 20080730 > Dec 14 07:17:57 grimsqueaker kernel: drm0: [ITHREAD] > Dec 14 07:18:24 grimsqueaker kernel: pid 1424 (xfce4-panel), uid 1001: > exited on signal 11 (core dumped) > Dec 14 07:25:43 grimsqueaker wpa_supplicant[381]: WPA: Group rekeying > completed with 00:23:69:82:b2:bf [GTK=CCMP] > Dec 14 07:48:38 grimsqueaker kernel: wpi0: device timeout > Dec 14 07:48:39 grimsqueaker kernel: wpi0: could not set power mode > From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 01:23:54 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 007011065676; Thu, 17 Dec 2009 01:23:54 +0000 (UTC) (envelope-from tahkun-send-pr@milkcup.jp) Received: from maxi.milkcup.jp (unknown [IPv6:2001:240:503:2::7]) by mx1.freebsd.org (Postfix) with ESMTP id 8003F8FC0A; Thu, 17 Dec 2009 01:23:53 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by maxi.milkcup.jp (8.13.8/8.13.8) with ESMTP id nBH1NqCU009655; Thu, 17 Dec 2009 10:23:52 +0900 Date: Thu, 17 Dec 2009 10:23:51 +0900 (JST) Message-Id: <20091217.102351.45367077.tahkun@milkcup.jp> To: yongari@FreeBSD.org From: Takao TAGAMI In-Reply-To: <200912142241.nBEMff09089051@freefall.freebsd.org> References: <200912142241.nBEMff09089051@freefall.freebsd.org> X-Mailer: Mew version 6.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, tahkun-send-pr@milkcup.jp Subject: Re: kern/141414: [vge] vge(4) problem on 8.0-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 01:23:54 -0000 Dear yongari. From: yongari@FreeBSD.org Subject: Re: kern/141414: [vge] vge(4) problem on 8.0-RELEASE Date: Mon, 14 Dec 2009 22:41:41 GMT > Synopsis: [vge] vge(4) problem on 8.0-RELEASE > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Mon Dec 14 22:40:55 UTC 2009 > State-Changed-Why: > I think I fixed the issue in HEAD. Would you try vge(4) in HEAD? > You can download the following latest vge(4) files from HEAD and it > should build on 8.0-RELEASE. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgereg.h > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vgevar.h Immediately, the source of the HEAD branch was acquired. Kernel was able to be compiled unquestionably. The browse of a heavy page with Apache has been improved. The problem is not in the update of the source with cvsup either. (Though the source has returned to the origin because it executed cvsup.:-) It is unquestionable on the second of the first though the appearance was seen. The thing that MFC is done is hoped for as soon as possible. Thank you. > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Mon Dec 14 22:40:55 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141414 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 03:29:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBDA8106566B; Thu, 17 Dec 2009 03:29:03 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9288A8FC0A; Thu, 17 Dec 2009 03:29:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBH3T3wa089545; Thu, 17 Dec 2009 03:29:03 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBH3T3GU089541; Thu, 17 Dec 2009 03:29:03 GMT (envelope-from brucec) Date: Thu, 17 Dec 2009 03:29:03 GMT Message-Id: <200912170329.nBH3T3GU089541@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/141695: [sctp] [panic] kernel page fault with non-sleepable lock sctp-inp held X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:29:03 -0000 Synopsis: [sctp] [panic] kernel page fault with non-sleepable lock sctp-inp held Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Dec 17 03:27:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141695 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 03:59:31 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13BAF106568B; Thu, 17 Dec 2009 03:59:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DF18F8FC13; Thu, 17 Dec 2009 03:59:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBH3xUFB017254; Thu, 17 Dec 2009 03:59:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBH3xU7F017250; Thu, 17 Dec 2009 03:59:30 GMT (envelope-from linimon) Date: Thu, 17 Dec 2009 03:59:30 GMT Message-Id: <200912170359.nBH3xU7F017250@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 03:59:31 -0000 Old Synopsis: rum(4)+ vimage = kernel panic New Synopsis: [rum] [panic] rum(4)+ vimage = kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 17 03:59:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141696 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 04:42:44 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6621065679; Thu, 17 Dec 2009 04:42:44 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A66518FC0C; Thu, 17 Dec 2009 04:42:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBH4giJV062972; Thu, 17 Dec 2009 04:42:44 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBH4giIp062968; Thu, 17 Dec 2009 04:42:44 GMT (envelope-from brucec) Date: Thu, 17 Dec 2009 04:42:44 GMT Message-Id: <200912170442.nBH4giIp062968@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/141697: [sctp] [panic] lock (sleep mutex) sctp-tcb not locked X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 04:42:44 -0000 Synopsis: [sctp] [panic] lock (sleep mutex) sctp-tcb not locked Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Dec 17 04:42:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141697 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 05:21:49 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0346C1065670; Thu, 17 Dec 2009 05:21:49 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE7668FC1F; Thu, 17 Dec 2009 05:21:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBH5Lmal003634; Thu, 17 Dec 2009 05:21:48 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBH5LmDA003630; Thu, 17 Dec 2009 05:21:48 GMT (envelope-from brucec) Date: Thu, 17 Dec 2009 05:21:48 GMT Message-Id: <200912170521.nBH5LmDA003630@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/141698: [sctp] [panic] Own lock on stcb at return from input X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 05:21:49 -0000 Synopsis: [sctp] [panic] Own lock on stcb at return from input Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Dec 17 05:21:20 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141698 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 06:10:02 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE03106566B for ; Thu, 17 Dec 2009 06:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB2A98FC08 for ; Thu, 17 Dec 2009 06:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBH6A2Dv039909 for ; Thu, 17 Dec 2009 06:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBH6A2Tt039908; Thu, 17 Dec 2009 06:10:02 GMT (envelope-from gnats) Date: Thu, 17 Dec 2009 06:10:02 GMT Message-Id: <200912170610.nBH6A2Tt039908@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Julian Elischer Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Julian Elischer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 06:10:02 -0000 The following reply was made to PR kern/141696; it has been noted by GNATS. From: Julian Elischer To: bug-followup@FreeBSD.org, venture37@geeklan.co.uk Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic Date: Wed, 16 Dec 2009 21:53:50 -0800 almost certainly there is an entry-point/code-path into the networking code from the rum driver that does not set the current vnet context. the easiest way to find this point is to compile in hte kernel debugger, (options ddb and kdb) and then make it happen again. then get a stack packtrace (bt). this will show us exactly what the code path is. There is a small possibility it is a generic path from usb code through usb-based netywork interfaces, as I remember something like htis being fixed in -current but I don't remember exactly the details.. julian From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 07:39:44 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B6B1065676 for ; Thu, 17 Dec 2009 07:39:44 +0000 (UTC) (envelope-from gaurav.bhateja@aricent.com) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id EB8778FC14 for ; Thu, 17 Dec 2009 07:39:43 +0000 (UTC) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 76F7336B50 for ; Thu, 17 Dec 2009 12:44:28 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 5CCCF36B4F for ; Thu, 17 Dec 2009 12:44:28 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Thu, 17 Dec 2009 12:47:02 +0530 From: Gaurav Bhateja To: "freebsd-net@freebsd.org" Date: Thu, 17 Dec 2009 12:47:00 +0530 Thread-Topic: SCTP : problems in sending ASCONF chunks Thread-Index: Acp+6Ox/xb1ieegeRgey9IHMkGxsFw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:39:44 -0000 Hi Vlad, I would really appreciate if you could help me out on this issue. I came to know about this email ID from the link http://lists.freebsd.org/p= ipermail/freebsd-net/2009-January/020683.html I am getting error, "Operation not permitted" when setting peer primary add= ress from server. I am using linux version 2.6-15(client) --- 2.6.21(server) Would there be a problem in dynamically configuring primary address using s= ctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for these lin= ux versions? You have suggested that its better to use linux version - 2.6-25. (It is d= ifficult for us to switch to these versions due to license issues) Could you provide is any other way to solve this issue. Regrds, Gaurav ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 08:45:14 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35FD3106566B for ; Thu, 17 Dec 2009 08:45:14 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from mail.esigetel.fr (venus.esigetel.fr [192.134.106.8]) by mx1.freebsd.org (Postfix) with ESMTP id B939F8FC0A for ; Thu, 17 Dec 2009 08:45:13 +0000 (UTC) Received: by mail.esigetel.fr (Postfix, from userid 65534) id 78A0A10273; Thu, 17 Dec 2009 09:45:09 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on venus.esigetel.avon X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from localhost (localhost [127.0.0.1]) by mail.esigetel.fr (Postfix) with ESMTP id 1897410270; Thu, 17 Dec 2009 09:45:09 +0100 (CET) X-Virus-Scanned: amavisd-new at esigetel.fr Received: from mail.esigetel.fr ([127.0.0.1]) by localhost (venus.esigetel.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56-hdZ61tmHJ; Thu, 17 Dec 2009 09:45:03 +0100 (CET) Received: from webmail.esigetel.fr (neo.ecampus.avon [192.168.106.14]) by mail.esigetel.fr (Postfix) with ESMTP id 5E2411026E; Thu, 17 Dec 2009 09:45:03 +0100 (CET) Received: from 83.206.131.26 (proxying for unknown) by webmail.esigetel.fr with HTTP; Thu, 17 Dec 2009 09:45:03 +0100 (CET) Message-ID: <57591.83.206.131.26.1261039503.squirrel@webmail.esigetel.fr> In-Reply-To: References: Date: Thu, 17 Dec 2009 09:45:03 +0100 (CET) From: "JASSAL Aman" To: "Gaurav Bhateja" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 08:45:14 -0000 Hello Gaurav, Le Jeu 17 décembre 2009 08:17, Gaurav Bhateja a écrit : > Hi Vlad, > > > I would really appreciate if you could help me out on this issue. > > > I came to know about this email ID from the link > http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020683.html > > > I am getting error, "Operation not permitted" when setting peer primary > address from server. I am using linux version 2.6-15(client) --- > 2.6.21(server) > > > Would there be a problem in dynamically configuring primary address using > sctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for these > linux versions? > I was working on performing hard handovers with SCTP using a FreeBSD client (7.0 at that time) and a Linux base-station (2.6.21 if memory serves), but the SCTP module for this version didn't support the dynamic configuration of the address for the ASCONF chunk very well, eventually I just switched both machines to FreeBSD to continue working on this subject. > > You have suggested that its better to use linux version - 2.6-25. (It is > difficult for us to switch to these versions due to license issues) > > Could you provide is any other way to solve this issue. > You could manually build and install a newer version of the lk-SCTP module from the source code. But I haven't worked with lk-sctp since then (January I mean), so I don't know if it is wiser to upgrade all your kernel sources, and not just the sctp source code. Vlad is much better suited to answer that one. > > > Regrds, > Gaurav > > > > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or > used for any purpose other than for what it is intended. If you have > received this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing the > contents of this message. Aricent accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus." > _______________________________________________ > 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" > > ------------ Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 10:22:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1233F106568F for ; Thu, 17 Dec 2009 10:22:28 +0000 (UTC) (envelope-from sashaandtanya@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9A81B8FC1C for ; Thu, 17 Dec 2009 10:22:27 +0000 (UTC) Received: by ewy26 with SMTP id 26so1055857ewy.3 for ; Thu, 17 Dec 2009 02:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=rOriUDgOMSAyE+eekhW4SXbyCs3lOP758MEHscEmdrg=; b=CMYxNLMoE2gUrh6oR4zSRjIcNztBD79YOiOQRNODRzdwXz21RG2rdSfV7z1A9aJ5+Q LQ+cCTumTLCASfpTSvsCW4y5IUWvY6/7qmMCa5UabDkLj9JJurL9Ixpc72gsGvuhmepH STAJPDynsWjZg3pSZK59lvP7lrBo6mgNCWMew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TDlIp19Z8KKIglF96uwgGM/0V0ASuP3nlvFklnTYQaXtSVb7JRCw4TsrA0ZSlstEtH ijF0lH+E2rV01D/vENgoKqdkD3bkBS9aiirF6xmI1YRy+dpl3Rk80c8TaORKWEQ2V4om PSEbhiWbgLh6Q2fA2fpXtEzGoX+y83Jpnc5gE= MIME-Version: 1.0 Received: by 10.213.100.11 with SMTP id w11mr2611840ebn.34.1261044017368; Thu, 17 Dec 2009 02:00:17 -0800 (PST) Date: Thu, 17 Dec 2009 12:00:17 +0200 Message-ID: From: Alexander Kapshuk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: re: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:22:28 -0000 Dear FreeBSD-net Community, I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my NIC properly. Please see below for some technical details related to the problem. output of less /var/run/dmesg.boot | grep re0 re0: port 0x2000-0x20ff mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 re0: Unknown H/W revision: 0x24c00000 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 re0: Unknown H/W revision: 0x24c00000 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 re0: Unknown H/W revision: 0x24c00000 device_attach: re0 attach returned 6 re0: port 0x2000-0x20ff mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x24800000 re0: MAC rev. 0x00400000 re0: Unknown H/W revision: 0x24c00000 device_attach: re0 attach returned 6 output of pciconf -l | grep re0 re0@pci0:3:0:0: class=0x020000 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 output of ifconfig ath0: flags=8802 metric 0 mtu 1500 ether 00:24:2c:5e:06:f2 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst bintval 0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=0<> metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 Please let me know if you require further details that might be of help. Look forward to hearing from anyone who would care to help at your convenience. Regards, Alexander Kapshuk. From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 11:32:19 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 746F910656A4 for ; Thu, 17 Dec 2009 11:32:19 +0000 (UTC) (envelope-from buchtajz@borsice.net) Received: from mx.sitkom.cz (mx.sitkom.cz [88.146.187.34]) by mx1.freebsd.org (Postfix) with ESMTP id 254F28FC0C for ; Thu, 17 Dec 2009 11:32:18 +0000 (UTC) Received: from spamd.mail.sitkom.cz (mail.mx.sitkom.cz [10.13.126.5]) by mx.mail.sitkom.cz (Postfix) with ESMTP id A9E961C6915; Thu, 17 Dec 2009 12:13:26 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.mx.sitkom.cz X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from avscan.mail.sitkom.cz (mail.mx.sitkom.cz [10.13.126.5]) by spamd.mail.sitkom.cz (Postfix) with ESMTP id 784151C68FC; Thu, 17 Dec 2009 12:13:26 +0100 (CET) Received: from [10.8.20.20] (buchtajz-notebook-lan.brestek.sfn [10.8.20.20]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.sitkom.cz (Postfix) with ESMTPSA id 3C4EE1C67F1; Thu, 17 Dec 2009 12:13:26 +0100 (CET) From: Michal Buchtik To: "Li, Qing" In-Reply-To: References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Dec 2009 12:13:11 +0100 Message-ID: <1261048391.1705.54.camel@manwe.buchtikov.borsice.sfn> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: issue with openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 11:32:19 -0000 Hi, thanks for help. Li, Qing píše v st 16. 12. 2009 v 15:39 -0800: > Hi, > > You have reported issues regarding openbgp/bgpd exiting > abnormally. Please apply patch: > > http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > and let me know if it fixes your issue. I performed limited > unit testing. > - bgpd don't terminate, it's OK but there appeared some new problems: TEST: bgpd is running, vlan3 not exists ---------------------------------------------------------------------- # netstat -rnf inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.8.20.1 UGS 5 135040 bge0 10.8.20.0/24 link#1 U 0 0 bge0 10.8.20.20 link#1 UHS 0 0 lo0 127.0.0.1 link#4 UH 0 35 lo0 $ bgpctl show fib flags: * = valid, B = BGP, C = Connected, S = Static N = BGP Nexthop reachable via this route r = reject route, b = blackhole route flags prio destination gateway *S 48 0.0.0.0/0 10.8.20.1 *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32 link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 # ifconfig vlan3 create # ifconfig vlan3 172.16.1.1/24 # netstat -rnfinet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.8.20.1 UGS 2 136107 bge0 10.8.20.0/24 link#1 U 0 0 bge0 10.8.20.20 link#1 UHS 0 0 lo0 127.0.0.1 link#4 UH 0 35 lo0 172.16.1.0/24 link#6 U 0 0 vlan3 172.16.1.1 link#6 UHS 0 0 lo0 $ bgpctl show fib *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32 link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 C 48 172.16.1.0/24 link#6 /* there is 172.16.1.1/32 link#4 missing and 172.16.1.0/24 is not marked as valid */ # ifconfig vlan3 alias 172.16.1.2/32 $ bgpctl show fib *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32 link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 C 48 172.16.1.0/24 link#6 C 48 172.16.1.2/32 link#6 new alias /32 is added correctly after restart bgpd, it prints this: # netstat -rnfinet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.8.20.1 UGS 6 141282 bge0 10.8.20.0/24 link#1 U 0 0 bge0 10.8.20.20 link#1 UHS 0 0 lo0 127.0.0.1 link#4 UH 0 35 lo0 172.16.1.0/24 link#6 U 0 0 vlan3 172.16.1.1 link#6 UHS 0 0 lo0 172.16.1.2 link#6 UHS 0 0 lo0 => 172.16.1.2/32 link#6 U 0 0 vlan3 $ bgpctl show fib flags: * = valid, B = BGP, C = Connected, S = Static N = BGP Nexthop reachable via this route r = reject route, b = blackhole route flags prio destination gateway *S 48 0.0.0.0/0 10.8.20.1 *C 48 10.8.20.0/24 link#1 *C 48 10.8.20.20/32 link#4 *C 0 127.0.0.1/8 link#0 *C 48 127.0.0.1/32 link#4 *C 48 172.16.1.0/24 link#6 *C 48 172.16.1.1/32 link#4 *C 48 172.16.1.2/32 link#4 *C 48 172.16.1.2/32 link#6 /* So, after bgpd restart, it registered new interface and all routes correctly and routes are valid. When I start bgpd >after< creating vlan3 (without ip adresses), it's behavior is same, but routes in "bgpctl show fib" output are displayed as valid (with *) */ From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 15:30:14 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4D710656A7 for ; Thu, 17 Dec 2009 15:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 237A78FC0A for ; Thu, 17 Dec 2009 15:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBHFUDqK087118 for ; Thu, 17 Dec 2009 15:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBHFUDBO087113; Thu, 17 Dec 2009 15:30:13 GMT (envelope-from gnats) Date: Thu, 17 Dec 2009 15:30:13 GMT Message-Id: <200912171530.nBHFUDBO087113@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Venture37 Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Venture37 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:30:14 -0000 The following reply was made to PR kern/141696; it has been noted by GNATS. From: Venture37 To: bug-followup@FreeBSD.org, venture37@geeklan.co.uk Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic Date: Thu, 17 Dec 2009 15:25:28 +0000 Photo of the trace output http://img64.imageshack.us/i/img1517.jpg/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 15:46:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1FA110656A4 for ; Thu, 17 Dec 2009 15:46:59 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 67FAB8FC5A for ; Thu, 17 Dec 2009 15:46:59 +0000 (UTC) Received: by bwz5 with SMTP id 5so1563485bwz.3 for ; Thu, 17 Dec 2009 07:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=+UMGiZma0u5jgZjEqoL5XNQ/E5VmB9LMLBiRZ3yd4Oc=; b=lAS2OhL9qmD5N62SIkX6NC9mw49ljm+EOOKM1SSAORatVO8UBnMFEfPgrJG0uedVGb fUJFhGSS0zB49PM+YAX0mRxyiKxtmqN6euenTOmFqAbHmbf9KV/1Is3vydz6HDiqRZba 1xN2idzo2Au2elQtfWCCCc36JktlR8RJv5Bwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=P7ZVC/5PKGkSVcXNX/hIRXmdd3yM3nWJfq7rZWha5JOfrtPpgBEEvt89MyPEyuSVZl JkSO0Er8w+A+/g+1Uz8I65PAhFqf0qT0AQOrVuY8KUHwOIXEk9fsT164rOZ5x5gceONM EreUk4I897iztP/11s5sUjy+RgzXgqdMi/nuM= Received: by 10.204.10.18 with SMTP id n18mr1432679bkn.152.1261064818426; Thu, 17 Dec 2009 07:46:58 -0800 (PST) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 14sm647654bwz.5.2009.12.17.07.46.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 07:46:57 -0800 (PST) To: FreeBSD-NET Organization: TOA Ukraine From: Mikolaj Golub Date: Thu, 17 Dec 2009 17:46:55 +0200 Message-ID: <86aaxhfvrk.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: close: Socket is not connected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:47:00 -0000 Hi, We have an application that consists of two processes communicating via unix socket (client connects, sends requests, reads response and close the connection). Sometimes the error 'Socket is not connected' is observed when client closes the socket. We observed this problem on FreeBSD6.X and now have been observing it on 7.1. To model the behaviour of the application I have written a simple test program (see below) based on relevant parts from the application code. Using this test program it requires from an a half of hour to several hours to reproduce the error. It might fail on close() both in the parent (server) and the children (client). $ date; ./unixsocket ; date Thu Dec 17 09:38:35 UTC 2009 unixsocket: parent: close error: 57 Thu Dec 17 14:13:07 UTC 2009 unixsocket: child: connect error 61 $ ./unixsocket unixsocket: child: close error: 57 I can reproduce the error running the test on 8.0 too. Does this indicate some bug in FreeBSD or may be just something is wrong with our code? #include #include #include #include #include #include #include #include #include #include #include #include #include #define UNIXSTR_PATH "/tmp/mytest.socket" #define BUFSIZE 557 #define USLEEP 10000 #define timeout 10 int waitData(int handle, int reading, int writing) { struct timeval tv; int result; fd_set rset; fd_set wset; fd_set eset; FD_ZERO(&rset); FD_SET(handle, &rset); FD_ZERO(&wset); FD_SET(handle, &wset); FD_ZERO(&eset); FD_SET(handle, &eset); tv.tv_sec = timeout; tv.tv_usec = 0; for (;;) { if (reading && !writing) result = select(handle + 1, &rset, 0, &eset, &tv); else if (!reading && writing) result = select(handle + 1, 0, &wset, &eset, &tv); else result = select(handle + 1, &rset, &wset, &eset, &tv); if (result == 0) /* timeout */ return 0; if (result < 0) { if (errno == EINTR) { continue; } errx(1, "select: %d", errno); } if (FD_ISSET(handle, &rset) || FD_ISSET(handle, &wset)) { int err = 0; socklen_t err_size = sizeof(err); if (getsockopt(handle, SOL_SOCKET, SO_ERROR, (char*)&err, &err_size) != 0) { errx(1, "getsockopts: %d", errno); } if (err != 0) { errx(1, "getsockopts: err: %d", err); } } else { errx(1, "select problems"); } return 1; /* OK */ } } void Write(int handle, const char* buf, size_t size) { size_t left = size; while (left > 0) { while (1) { int sent = send(handle, buf, size, 0); if (sent <= 0) { if (errno == EAGAIN) { if (!waitData(handle, 0, 1)) errx(1, "Write: timeout"); continue; } errx(1, "Write: error: %d", errno); } left -= sent; buf += sent; break; } } } void Read(int handle, char* buf, size_t size) { while (size > 0) { int blockSize; if (!waitData(handle, 1, 0)) errx(1, "Read: timeout"); blockSize = recv(handle, buf, size, 0); if (blockSize <= 0) { errx(1, "Read: error: blockSize: %d", blockSize); } buf += blockSize; size -= blockSize; } } int main(int argc, char **argv) { int listenfd, connfd, pid; struct sockaddr_un servaddr; char buf[BUFSIZE]; memset(buf, 'X', sizeof(buf)); pid = fork(); if (-1 == pid) errx(1, "fork(): %d", errno); if (0 != pid) { /* parent */ if ((listenfd = socket(AF_LOCAL, SOCK_STREAM, 0)) < 0) errx(1, "parent: socket error: %d", errno); unlink(UNIXSTR_PATH); bzero(&servaddr, sizeof(servaddr)); servaddr.sun_family = AF_LOCAL; strcpy(servaddr.sun_path, UNIXSTR_PATH); if (bind(listenfd, (struct sockaddr *) &servaddr, sizeof(servaddr)) < 0) errx(1, "parent: bind error: %d", errno); if (listen(listenfd, 1024) < 0) errx(1, "parent: listen error: %d", errno); for ( ; ; ) { if ((connfd = accept(listenfd, (struct sockaddr *) NULL, NULL)) < 0) errx(1, "parent: accept error: %d", errno); if (fcntl(connfd, F_SETFL, O_NONBLOCK) == -1) errx(1, "parent: fcntl error: %d", errno); Read(connfd, buf, sizeof(buf)); Write(connfd, buf, sizeof(buf)); if (close(connfd) < 0) errx(1, "parent: close error: %d", errno); } } else { /* child */ /* wait some time while parent has created socket */ sleep(1); for ( ; ; ) { if ((connfd = socket(AF_LOCAL, SOCK_STREAM, 0)) < 0) errx(1, "child: socket error: %d", errno); if (fcntl(connfd, F_SETFL, O_NONBLOCK) == -1) errx(1, "child: fcntl error: %d", errno); bzero(&servaddr, sizeof(servaddr)); servaddr.sun_family = AF_LOCAL; strcpy(servaddr.sun_path, UNIXSTR_PATH); if (connect(connfd, (struct sockaddr *) &servaddr, sizeof(servaddr)) < 0) errx(1, "child: connect error %d", errno); Write(connfd, buf, sizeof(buf)); Read(connfd, buf, sizeof(buf)); if (close(connfd) != 0) errx(1, "child: close error: %d", errno); usleep(USLEEP); } } return 0; } -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 16:00:17 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B3A106566C for ; Thu, 17 Dec 2009 16:00:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1AA8FC13 for ; Thu, 17 Dec 2009 16:00:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBHG0H3f014733 for ; Thu, 17 Dec 2009 16:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBHG0HHj014729; Thu, 17 Dec 2009 16:00:17 GMT (envelope-from gnats) Date: Thu, 17 Dec 2009 16:00:17 GMT Message-Id: <200912171600.nBHG0HHj014729@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sevan / Venture37 Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sevan / Venture37 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:00:17 -0000 The following reply was made to PR kern/141696; it has been noted by GNATS. From: Sevan / Venture37 To: bug-followup@FreeBSD.org, venture37@geeklan.co.uk Cc: Subject: Re: kern/141696: [rum] [panic] rum(4)+ vimage = kernel panic Date: Thu, 17 Dec 2009 15:27:18 +0000 Photo of the trace output http://img64.imageshack.us/i/img1517.jpg/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 16:34:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03945106568D for ; Thu, 17 Dec 2009 16:34:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id B92B78FC16 for ; Thu, 17 Dec 2009 16:34:07 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id nBHGY69O019300; Thu, 17 Dec 2009 11:34:06 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200912171634.nBHGY69O019300@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Dec 2009 11:01:00 -0500 To: Jon Otterholm , From: Mike Tancsa In-Reply-To: References: <200912111923.nBBJNLk3072715@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Racoon site-to site X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:34:08 -0000 At 02:50 AM 12/15/2009, Jon Otterholm wrote: >On 2009-12-11 20.23, "Mike Tancsa" wrote: > > > > > > You might also want to turn on DPD (dead peer > > detection) in ipsectools if you dont already have > > it on both sides. Are you really using des for > > the crypto ? Also, when the session is > > negotiated, take a look at the output of > > setkey -D > > and see what was actually negotiated and post it > > here (just make sure you get rid of the info on the E and A lines. > > > > e.g. > > 1.1.1.2 2.2.2.2 > > esp mode=tunnel spi=125444787(0x077a22b3) reqid=16416(0x00004020) > > E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b > > A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb > > > > ie. mask out the 5cfdbabb and 770cdd7b values > > before posting as thats your crypto :) > > > > > >Here is output from setkey -D when we lost connection: > >localip remoteip > esp mode=tunnel spi=989823717(0x3aff82e5) reqid=0(0x00000000) > E: des-cbc x x > A: hmac-md5 x x x x > seq=0x000009ac replay=4 flags=0x00000000 state=mature > created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 > diff: 1703(s) hard: 3600(s) soft: 2880(s) > last: Dec 15 08:26:03 2009 hard: 0(s) soft: 0(s) > current: 400400(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 2476 hard: 0 soft: 0 > sadb_seq=1 pid=23175 refcnt=2 >remoteip remoteip > esp mode=tunnel spi=117094840(0x06fab9b8) reqid=0(0x00000000) > E: des-cbc x x > A: hmac-md5 x x x x > seq=0x00000b73 replay=4 flags=0x00000000 state=mature > created: Dec 15 07:57:41 2009 current: Dec 15 08:26:04 2009 > diff: 1703(s) hard: 3600(s) soft: 2880(s) > last: Dec 15 08:25:37 2009 hard: 0(s) soft: 0(s) > current: 2960978(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 2931 hard: 0 soft: 0 > sadb_seq=0 pid=23175 refcnt=1 The state looks good (mature). It would be useful to see what the other side thinks is going on. 3 different things to try when its down. racoonctl vpn-disconnect remoteip ... where remoteip is the public IP of the endpoint and then generate some traffic and see if things are re-established. setkey -F to flush the associations on this side... and again, generate some traffic. Another thing to try is sysctl -w net.key.preferred_oldsa=0 setkey -F restart racoon and then see if the hangs still happen. But you should try and get some debugging info from the other side to see what state things are in when the tunnel fails. In general, I have found setting net.key.preferred_oldsa=0 important when inter-operating with other platforms. Also, check and make sure you have dpd compiled into ipsectools and make sure enabled. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 16:43:54 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F2F1065679 for ; Thu, 17 Dec 2009 16:43:54 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id F2EDE8FC08 for ; Thu, 17 Dec 2009 16:43:53 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 44A7A2798BC; Thu, 17 Dec 2009 17:43:52 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 2F22B1705D; Thu, 17 Dec 2009 17:43:52 +0100 (CET) Date: Thu, 17 Dec 2009 17:43:52 +0100 From: VANHULLEBUS Yvan To: Mike Tancsa Message-ID: <20091217164351.GA66492@zeninc.net> References: <200912111923.nBBJNLk3072715@lava.sentex.ca> <200912171634.nBHGY69O019300@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912171634.nBHGY69O019300@lava.sentex.ca> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org, Jon Otterholm Subject: Re: Racoon site-to site X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:43:54 -0000 Hi all. On Thu, Dec 17, 2009 at 11:01:00AM -0500, Mike Tancsa wrote: [...] > Another thing to try is > sysctl -w net.key.preferred_oldsa=0 Yep, this is how most IPsec devices works and expects peers to work. > Also, check and make sure you have dpd compiled into > ipsectools and make sure enabled. Yes .... or no: misconfigured, or used in situations with important loss, DPD can be worst than nothing.... The best would be to first understand the issue, then fix it, and only after that consider finding useful DPD configuration regarding the setup.... Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 17:03:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29560106568D for ; Thu, 17 Dec 2009 17:03:02 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4C48FC1F for ; Thu, 17 Dec 2009 17:03:01 +0000 (UTC) Received: from [192.168.1.100] (p508FEF90.dip.t-dialin.net [80.143.239.144]) by mail-n.franken.de (Postfix) with ESMTP id 838D61C0B4627; Thu, 17 Dec 2009 18:03:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Thu, 17 Dec 2009 18:02:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01D4CAEB-00E7-44BC-9A26-1C96918CFC30@lurchi.franken.de> References: To: Gaurav Bhateja X-Mailer: Apple Mail (2.1077) Cc: "freebsd-net@freebsd.org" Subject: Re: SCTP : problems in sending ASCONF chunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 17:03:02 -0000 Hi Gaurav, you might want to discuss this on the Linux SCTP mailing list, not on the FreeBSD net mailing list. You find Linux experts there... Best regards Michael On Dec 17, 2009, at 8:17 AM, Gaurav Bhateja wrote: > Hi Vlad, >=20 > I would really appreciate if you could help me out on this issue. >=20 > I came to know about this email ID from the link = http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020683.html >=20 > I am getting error, "Operation not permitted" when setting peer = primary address from server. > I am using linux version 2.6-15(client) --- 2.6.21(server) >=20 > Would there be a problem in dynamically configuring primary address = using sctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for = these linux versions? >=20 > You have suggested that its better to use linux version - 2.6-25. (It = is difficult for us to switch to these versions due to license issues) >=20 > Could you provide is any other way to solve this issue. >=20 >=20 > Regrds, > Gaurav >=20 >=20 >=20 > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of the individual to whom it is addressed. It may = contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. = If you have received this message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 18:39:04 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F4AF1065670 for ; Thu, 17 Dec 2009 18:39:04 +0000 (UTC) (envelope-from adam@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 47CD98FC16 for ; Thu, 17 Dec 2009 18:39:04 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id D8FFE3E45A1 for ; Thu, 17 Dec 2009 13:23:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Adam Jacob Muller In-Reply-To: Date: Thu, 17 Dec 2009 13:23:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> To: "Li, Qing" X-Authentication: niLHdWy5F/H8ICPtDBsGfQfMAMV01tCI+ct5ghjSLdpChKDwStajMpAIYDe1lkzfRmGY5RSB9wr4jVKjB3eVOwtuHSqeguA9JjlQBNMBhhwkTgujJHBxj9EplRHPhwCDiGkuVhXP9B6RVUbBpFRFw9OL5xRYVR8r/AkztHKEHKUmzcZnqym6TxFwNQ== Cc: freebsd-net@freebsd.org, Adam Jacob Muller , Michal Buchtik , Qing Li Subject: Re: issue with openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:39:04 -0000 Hi Qing, This indeed fixes the issue for me! Thanks very much, I hope to see the patch committed :) -Adam ---- Adam Jacob Muller adam@adam.gs 201-616-0620 On Dec 16, 2009, at 6:39 PM, Li, Qing wrote: > Hi, > > You have reported issues regarding openbgp/bgpd exiting > abnormally. Please apply patch: > > http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > and let me know if it fixes your issue. I performed limited > unit testing. > > Thanks, > > -- Qing > > > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 15:55:47 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271AE1065693 for ; Thu, 17 Dec 2009 15:55:47 +0000 (UTC) (envelope-from fengdreamer@126.com) Received: from m15-49.126.com (m15-49.126.com [220.181.15.49]) by mx1.freebsd.org (Postfix) with SMTP id 5C9028FC13 for ; Thu, 17 Dec 2009 15:55:42 +0000 (UTC) Received: from fengdreamer ( [219.237.184.82] ) by ajax-webmail-wmsvr49 (Coremail) ; Thu, 17 Dec 2009 23:24:04 +0800 (CST) Date: Thu, 17 Dec 2009 23:24:04 +0800 (CST) From: =?gbk?B?zfW0urfn?= To: freebsd-net Message-ID: <31264189.456321261063444556.JavaMail.coremail@bj126app49.126.com> MIME-Version: 1.0 X-Originating-IP: [219.237.184.82] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 090923(9022.2651.2651) Copyright (c) 2002-2009 www.mailtech.cn 126com X-CM-CTRLDATA: xaE/smZvb3Rlcl9odG09MTI5Njo0NA== X-CM-TRANSID: McqowKBbPR4UTSpLgMPJAQ--.19046W X-CM-SenderInfo: pihqwv5uhdzvbu6rjloofrz/1tbi5wk8s0oZh9fZDgACs3 X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJTRUUUbIxYjxAI6xAIw2 8IcVW8XFylb7IF0VCF04k20xvEw2I207IF0wAYjxAI6xCIbckI1I0E57IF64kEYxAxMc80 4VCqF7xvr2I5M4IEnf9ElVAFpTB2q-sK649IAas0WaI_GwCS07vEb7Iv0xC_Jr1lV2xY67 kC6x804xWlV2xY67AvxsIEb2xv6ckvw2WlV2xY67CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMIAIbVAFxVCF77xC64kEw24lV2xY67C26IkvcIIF6IxKo4kEV4ylV2xY628EF7 xvwVC0I7IYx2IY67AKxVWDJVCq3wCS07vE84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE 3s1lV2xY628EF7xvwVC2z280aVAFwI0_GcCE3s1lV2xY628EF7xvwVC2z280aVCY1x0267 AKxVW0oVCq3wCS07vE5I8CrVACY4xI64kE6c02F40Ex7xfMIAIbVAv7VC0I7IYx2IY67AK xVWUGVWUXwCS07vEYx0Ex4A2jsIE14v26r1j6r4UMIAIbVCjxxvEw4WlV2xY6xkFs20EY4 vE8sxKj4xv1wCS07vEc2xSY4AK67AK6ryrMIAIbVCY0x0Ix7I2Y4AK64vIr41lV2xY6xCj nVCjjxCrMIAIbVC2zVAF1VAY17CE14v26r1j6r15MIAIbVCI42IY6xAIw20EY4v20xvaj4 0_WFyUJVCq3wCS07vEIxAIcVC2z280aVAFwI0_Jr0_Gr1lV2xY6IIF0xvEx4A2jsIEc7Cj xVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUU== X-Mailman-Approved-At: Thu, 17 Dec 2009 18:48:08 +0000 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Bug discussion:Tcp snd_nxt will not be increased. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 15:55:47 -0000 Hello All: There's a problem i am facing. Is it a bug ? It's tcp connect socket, SYN will be send, but if before SYN ACK was received, the SYN will be retransmited, there'll be some problem. the restransmit is like this: move the snd_nxt to snd_una, and begin to sendout by tcp_output. after send the snd_nxt will return to normal just like below. before tcp_output after tcp output |--Seq--|--Seq+1--| |--Seq--|--Seq+1--| snd_una snd_una snd_nxt snd_nxt If the tcp_output just have some error, for example: when alloc mbuf, it returns NULL, and then the snd_nxt number will not be return to normal. If just in this time, SYN Ack arrives, freeBSD can't handle this situdition. Thanks! From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 18:51:32 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B57A106568B; Thu, 17 Dec 2009 18:51:32 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5321B8FC1C; Thu, 17 Dec 2009 18:51:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBHIpW4V078328; Thu, 17 Dec 2009 18:51:32 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBHIpW20078324; Thu, 17 Dec 2009 18:51:32 GMT (envelope-from brucec) Date: Thu, 17 Dec 2009 18:51:32 GMT Message-Id: <200912171851.nBHIpW20078324@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/141720: [sctp] [lor] [hang] sctp-create vs. sctp-it causes system hang X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:51:32 -0000 Synopsis: [sctp] [lor] [hang] sctp-create vs. sctp-it causes system hang Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Dec 17 18:51:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141720 From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 18:52:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DB81065696 for ; Thu, 17 Dec 2009 18:52:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by mx1.freebsd.org (Postfix) with ESMTP id BBECA8FC31 for ; Thu, 17 Dec 2009 18:52:14 +0000 (UTC) Received: by ywh2 with SMTP id 2so2405379ywh.27 for ; Thu, 17 Dec 2009 10:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=of5ixkDGFE0+1KGimShmJG0CPX6JxkAdPyHex9jyj1Y=; b=XObqQjzXbHcRA/cExXxtVi4jc/2dG/aXY23Dr3xMEfKuzfAwa4wbt6A1lIGYtCMVhE BVvlY5ff8f+TjW7nOIl+kxpM0xDI/gPd/Nc6gT+CnAKrVzlfgNLVtLvUmrvGYNQQDLv0 K7RsNtoH1D1DNoT2DFSNc1iAr+7hlu2fDL6r8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=OJldX291bNLXCStiHjcYB6SYOPXtYrJ7LHgegBS+tmq5ztyBezVryMdlUmfiMfzjKx YbP20GB9XqS8rCyUeINqb7/exGp6+t348NG1JD8BxMnRGIKjAtonIxOywBFDHHUeQAAn xLphkOVDWQOIlVC9zm5Fa7kp9dk7hbcigi4Ns= Received: by 10.150.9.18 with SMTP id 18mr4567265ybi.164.1261075933844; Thu, 17 Dec 2009 10:52:13 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm822425ywh.47.2009.12.17.10.52.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 10:52:12 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 17 Dec 2009 10:52:04 -0800 From: Pyun YongHyeon Date: Thu, 17 Dec 2009 10:52:04 -0800 To: Alexander Kapshuk Message-ID: <20091217185204.GA12063@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:52:15 -0000 On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: > Dear FreeBSD-net Community, > > I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my > NIC properly. > > Please see below for some technical details related to the problem. > > output of less /var/run/dmesg.boot | grep re0 > > re0: port 0x2000-0x20ff > mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x24800000 > re0: MAC rev. 0x00400000 > re0: Unknown H/W revision: 0x24c00000 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x24800000 > re0: MAC rev. 0x00400000 > re0: Unknown H/W revision: 0x24c00000 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x24800000 > re0: MAC rev. 0x00400000 > re0: Unknown H/W revision: 0x24c00000 > device_attach: re0 attach returned 6 > re0: port 0x2000-0x20ff > mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x24800000 > re0: MAC rev. 0x00400000 > re0: Unknown H/W revision: 0x24c00000 > device_attach: re0 attach returned 6 > Support for the controller was made in r195675 and the change was already MFCed to stable/8 and stable7. Try recent CURRENT or 8/stable and 7/stable. I guess you can download the following files from latest stable/7 via web interface and rebuilding both re(4) and rl(4) on your 7.2-RELEASE should make your controller recognized. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h > output of pciconf -l | grep re0 > > re0@pci0:3:0:0: class=0x020000 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 > > output of ifconfig > > ath0: flags=8802 metric 0 mtu 1500 > ether 00:24:2c:5e:06:f2 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 1 (2412 Mhz 11b) > authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst > bintval 0 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > pflog0: flags=0<> metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > > > Please let me know if you require further details that might be of help. > > Look forward to hearing from anyone who would care to help at your convenience. > > Regards, > > Alexander Kapshuk. From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 19:14:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0C51065670 for ; Thu, 17 Dec 2009 19:14:07 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id E19F88FC17 for ; Thu, 17 Dec 2009 19:14:06 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBHJE1ug011685; Thu, 17 Dec 2009 11:14:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 17 Dec 2009 11:13:55 -0800 Message-ID: In-Reply-To: <1261048391.1705.54.camel@manwe.buchtikov.borsice.sfn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue with openbgpd + 8.0 Thread-Index: Acp/CfeDA31a+oAUScyYI1EyAa8CdAAQUh4Q References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> <1261048391.1705.54.camel@manwe.buchtikov.borsice.sfn> From: "Li, Qing" To: "Michal Buchtik" Cc: freebsd-net@freebsd.org Subject: RE: issue with openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:14:07 -0000 VGhhbmtzIGZvciByZXBvcnRpbmcgYmFjayBhbmQgdGhlIGRldGFpbGVkIGRlc2NyaXB0aW9uLg0K DQo+DQo+IC0gYmdwZCBkb24ndCB0ZXJtaW5hdGUsIGl0J3MgT0sNCj4gDQoNCk9rYXksIG1ha2lu ZyBwcm9ncmVzcy4NCg0KPg0KPiBidXQgdGhlcmUgYXBwZWFyZWQgc29tZSBuZXcgcHJvYmxlbXM6 DQo+DQoNCkludGVyZXN0aW5nbHkgZW5vdWdoLCBteSBwYXRjaCBpcyB0byByZXNvbHZlIHRoZSBp c3N1ZSB3aGVyZSBhZGRpbmcNCmFuZCByZW1vdmluZyBhZGRyZXNzIGFsaWFzZXMgYXJlIG5vdCBy ZXBvcnRlZC4gVGhpcyBpc3N1ZSBhcHBlYXJzIHRvDQpiZSBzb2x2ZWQgYnV0IHRoZSByZWd1bGFy IGFkZHJlc3MgbWFuaXB1bGF0aW9uIHNlZW1zIHByb2JsZW1hdGljIGFzDQp5b3UgZGVzY3JpYmUg aW4geW91ciBlbnZpcm9ubWVudC4NCg0KTGV0IG1lIGludmVzdGlnYXRlIGZ1cnRoZXIgd2l0aCBt eSBiZ3Agc2V0dXAuDQoNClBsZWFzZSBub3RlIEkgYW0gZ29pbmcgb24gdmFjYXRpb24gZm9yIGEg Y291cGxlIG9mIHdlZWtzIHNvIHRoZXJlDQptYXkgYmUgc29tZSBkZWxheSBmb3IgYSBwYXRjaC4N Cg0KLS0gUWluZw0KDQoNCiANCj4gVEVTVDogYmdwZCBpcyBydW5uaW5nLCB2bGFuMyBub3QgZXhp c3RzDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIyBuZXRzdGF0IC1ybmYgaW5ldA0KPiBSb3V0aW5nIHRh Ymxlcw0KPiANCj4gSW50ZXJuZXQ6DQo+IERlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAg ICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAgTmV0aWYNCj4gRXhwaXJlDQo+IGRlZmF1bHQg ICAgICAgICAgICAxMC44LjIwLjEgICAgICAgICAgVUdTICAgICAgICAgNSAgIDEzNTA0MCAgIGJn ZTANCj4gMTAuOC4yMC4wLzI0ICAgICAgIGxpbmsjMSAgICAgICAgICAgICBVICAgICAgICAgICAw ICAgICAgICAwICAgYmdlMA0KPiAxMC44LjIwLjIwICAgICAgICAgbGluayMxICAgICAgICAgICAg IFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wDQo+IDEyNy4wLjAuMSAgICAgICAgICBsaW5r IzQgICAgICAgICAgICAgVUggICAgICAgICAgMCAgICAgICAzNSAgICBsbzANCj4gDQo+ICQgYmdw Y3RsIHNob3cgZmliDQo+IGZsYWdzOiAqID0gdmFsaWQsIEIgPSBCR1AsIEMgPSBDb25uZWN0ZWQs IFMgPSBTdGF0aWMNCj4gICAgICAgIE4gPSBCR1AgTmV4dGhvcCByZWFjaGFibGUgdmlhIHRoaXMg cm91dGUNCj4gICAgICAgIHIgPSByZWplY3Qgcm91dGUsIGIgPSBibGFja2hvbGUgcm91dGUNCj4g DQo+IGZsYWdzIHByaW8gZGVzdGluYXRpb24gICAgICAgICAgZ2F0ZXdheQ0KPiAqUyAgICAgIDQ4 IDAuMC4wLjAvMCAgICAgICAgICAgIDEwLjguMjAuMQ0KPiAqQyAgICAgIDQ4IDEwLjguMjAuMC8y NCAgICAgICAgIGxpbmsjMQ0KPiAqQyAgICAgIDQ4IDEwLjguMjAuMjAvMzIgICAgICAgIGxpbmsj NA0KPiAqQyAgICAgICAwIDEyNy4wLjAuMS84ICAgICAgICAgIGxpbmsjMA0KPiAqQyAgICAgIDQ4 IDEyNy4wLjAuMS8zMiAgICAgICAgIGxpbmsjNA0KPiANCj4gIyBpZmNvbmZpZyB2bGFuMyBjcmVh dGUNCj4gIyBpZmNvbmZpZyB2bGFuMyAxNzIuMTYuMS4xLzI0DQo+ICMgbmV0c3RhdCAtcm5maW5l dA0KPiBSb3V0aW5nIHRhYmxlcw0KPiANCj4gSW50ZXJuZXQ6DQo+IERlc3RpbmF0aW9uICAgICAg ICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVmcyAgICAgIFVzZSAgTmV0aWYNCj4gRXhw aXJlDQo+IGRlZmF1bHQgICAgICAgICAgICAxMC44LjIwLjEgICAgICAgICAgVUdTICAgICAgICAg MiAgIDEzNjEwNyAgIGJnZTANCj4gMTAuOC4yMC4wLzI0ICAgICAgIGxpbmsjMSAgICAgICAgICAg ICBVICAgICAgICAgICAwICAgICAgICAwICAgYmdlMA0KPiAxMC44LjIwLjIwICAgICAgICAgbGlu ayMxICAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wDQo+IDEyNy4wLjAu MSAgICAgICAgICBsaW5rIzQgICAgICAgICAgICAgVUggICAgICAgICAgMCAgICAgICAzNSAgICBs bzANCj4gMTcyLjE2LjEuMC8yNCAgICAgIGxpbmsjNiAgICAgICAgICAgICBVICAgICAgICAgICAw ICAgICAgICAwICB2bGFuMw0KPiAxNzIuMTYuMS4xICAgICAgICAgbGluayM2ICAgICAgICAgICAg IFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wDQo+IA0KPiAkIGJncGN0bCBzaG93IGZpYg0K PiAqQyAgICAgIDQ4IDEwLjguMjAuMC8yNCAgICAgICAgIGxpbmsjMQ0KPiAqQyAgICAgIDQ4IDEw LjguMjAuMjAvMzIgICAgICAgIGxpbmsjNA0KPiAqQyAgICAgICAwIDEyNy4wLjAuMS84ICAgICAg ICAgIGxpbmsjMA0KPiAqQyAgICAgIDQ4IDEyNy4wLjAuMS8zMiAgICAgICAgIGxpbmsjNA0KPiAg QyAgICAgIDQ4IDE3Mi4xNi4xLjAvMjQgICAgICAgIGxpbmsjNg0KPiANCj4gLyogdGhlcmUgaXMg MTcyLjE2LjEuMS8zMiAgbGluayM0ICBtaXNzaW5nDQo+IGFuZCAxNzIuMTYuMS4wLzI0IGlzIG5v dCBtYXJrZWQgYXMgdmFsaWQgKi8NCj4gDQo+ICMgaWZjb25maWcgdmxhbjMgYWxpYXMgMTcyLjE2 LjEuMi8zMg0KPiAkIGJncGN0bCBzaG93IGZpYg0KPiAqQyAgICAgIDQ4IDEwLjguMjAuMC8yNCAg ICAgICAgIGxpbmsjMQ0KPiAqQyAgICAgIDQ4IDEwLjguMjAuMjAvMzIgICAgICAgIGxpbmsjNA0K PiAqQyAgICAgICAwIDEyNy4wLjAuMS84ICAgICAgICAgIGxpbmsjMA0KPiAqQyAgICAgIDQ4IDEy Ny4wLjAuMS8zMiAgICAgICAgIGxpbmsjNA0KPiAgQyAgICAgIDQ4IDE3Mi4xNi4xLjAvMjQgICAg ICAgIGxpbmsjNg0KPiAgQyAgICAgIDQ4IDE3Mi4xNi4xLjIvMzIgICAgICAgIGxpbmsjNg0KPiAN Cj4gbmV3IGFsaWFzIC8zMiBpcyBhZGRlZCBjb3JyZWN0bHkNCj4gDQo+IGFmdGVyIHJlc3RhcnQg YmdwZCwgaXQgcHJpbnRzIHRoaXM6DQo+IA0KPiAjIG5ldHN0YXQgLXJuZmluZXQNCj4gUm91dGlu ZyB0YWJsZXMNCj4gDQo+IEludGVybmV0Og0KPiBEZXN0aW5hdGlvbiAgICAgICAgR2F0ZXdheSAg ICAgICAgICAgIEZsYWdzICAgIFJlZnMgICAgICBVc2UgIE5ldGlmDQo+IEV4cGlyZQ0KPiBkZWZh dWx0ICAgICAgICAgICAgMTAuOC4yMC4xICAgICAgICAgIFVHUyAgICAgICAgIDYgICAxNDEyODIg ICBiZ2UwDQo+IDEwLjguMjAuMC8yNCAgICAgICBsaW5rIzEgICAgICAgICAgICAgVSAgICAgICAg ICAgMCAgICAgICAgMCAgIGJnZTANCj4gMTAuOC4yMC4yMCAgICAgICAgIGxpbmsjMSAgICAgICAg ICAgICBVSFMgICAgICAgICAwICAgICAgICAwICAgIGxvMA0KPiAxMjcuMC4wLjEgICAgICAgICAg bGluayM0ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgMzUgICAgbG8wDQo+IDE3Mi4x Ni4xLjAvMjQgICAgICBsaW5rIzYgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAgICAgMCAg dmxhbjMNCj4gMTcyLjE2LjEuMSAgICAgICAgIGxpbmsjNiAgICAgICAgICAgICBVSFMgICAgICAg ICAwICAgICAgICAwICAgIGxvMA0KPiAxNzIuMTYuMS4yICAgICAgICAgbGluayM2ICAgICAgICAg ICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICAgbG8wID0+DQo+IDE3Mi4xNi4xLjIvMzIgICAg ICBsaW5rIzYgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICAgICAgMCAgdmxhbjMNCj4gDQo+ ICQgYmdwY3RsIHNob3cgZmliDQo+IGZsYWdzOiAqID0gdmFsaWQsIEIgPSBCR1AsIEMgPSBDb25u ZWN0ZWQsIFMgPSBTdGF0aWMNCj4gICAgICAgIE4gPSBCR1AgTmV4dGhvcCByZWFjaGFibGUgdmlh IHRoaXMgcm91dGUNCj4gICAgICAgIHIgPSByZWplY3Qgcm91dGUsIGIgPSBibGFja2hvbGUgcm91 dGUNCj4gDQo+IGZsYWdzIHByaW8gZGVzdGluYXRpb24gICAgICAgICAgZ2F0ZXdheQ0KPiAqUyAg ICAgIDQ4IDAuMC4wLjAvMCAgICAgICAgICAgIDEwLjguMjAuMQ0KPiAqQyAgICAgIDQ4IDEwLjgu MjAuMC8yNCAgICAgICAgIGxpbmsjMQ0KPiAqQyAgICAgIDQ4IDEwLjguMjAuMjAvMzIgICAgICAg IGxpbmsjNA0KPiAqQyAgICAgICAwIDEyNy4wLjAuMS84ICAgICAgICAgIGxpbmsjMA0KPiAqQyAg ICAgIDQ4IDEyNy4wLjAuMS8zMiAgICAgICAgIGxpbmsjNA0KPiAqQyAgICAgIDQ4IDE3Mi4xNi4x LjAvMjQgICAgICAgIGxpbmsjNg0KPiAqQyAgICAgIDQ4IDE3Mi4xNi4xLjEvMzIgICAgICAgIGxp bmsjNA0KPiAqQyAgICAgIDQ4IDE3Mi4xNi4xLjIvMzIgICAgICAgIGxpbmsjNA0KPiAqQyAgICAg IDQ4IDE3Mi4xNi4xLjIvMzIgICAgICAgIGxpbmsjNg0KPiANCj4gLyogU28sIGFmdGVyIGJncGQg cmVzdGFydCwgaXQgcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGFuZCBhbGwgcm91dGVzDQo+IGNv cnJlY3RseSBhbmQgcm91dGVzIGFyZSB2YWxpZC4NCj4gDQo+IFdoZW4gSSBzdGFydCBiZ3BkID5h ZnRlcjwgY3JlYXRpbmcgdmxhbjMgKHdpdGhvdXQgaXAgYWRyZXNzZXMpLCBpdCdzDQo+IGJlaGF2 aW9yIGlzIHNhbWUsIGJ1dCByb3V0ZXMgaW4gImJncGN0bCBzaG93IGZpYiIgb3V0cHV0IGFyZSBk aXNwbGF5ZWQNCj4gYXMgdmFsaWQgKHdpdGggKikNCj4gDQo+ICovDQo= From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 19:16:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FBA106568B for ; Thu, 17 Dec 2009 19:16:36 +0000 (UTC) (envelope-from sashaandtanya@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A3BC38FC14 for ; Thu, 17 Dec 2009 19:16:35 +0000 (UTC) Received: by fxm27 with SMTP id 27so2232162fxm.3 for ; Thu, 17 Dec 2009 11:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=htm7mAThaFoGkP27NdWpohr59lgsuaAmrsWLsoLZaWY=; b=d1SYsgU3d14nhEO8K0V0ZpAP5U+qybLaJVY3igi2PvTC6cH1ca2sqT59iOaSa8P9cc OApu68QIwTmVw/JGCDoqLON49FS4PkG2OB78R06VhxEOgSsYtqlPGdIaYviBzj+xZ+un QYoKpIK1XSe3FYeY0HeMiv4So+DiwE4BhNlIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ClEOYZ9Kc5Q2CtRN4GNokKy6W0BEsjD0DU6+jURx+XADwzw/SvlHCra0BasY0AKBJL ZxTmQvUCo75S8VAdHJDPWH+lLDanxO6f9IwdjfdSpA8XApZkiJP5p6lEWZyjLidqOKtw LjBFF1AhFGFEnlBIIfRfJEwl/0kD6ZstDzJh8= Received: by 10.223.4.84 with SMTP id 20mr3567297faq.97.1261077394417; Thu, 17 Dec 2009 11:16:34 -0800 (PST) Received: from ?192.168.1.2? (93-127-28-148.static.vega-ua.net [93.127.28.148]) by mx.google.com with ESMTPS id 16sm797358fxm.12.2009.12.17.11.16.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 11:16:33 -0800 (PST) Message-ID: <4B2A8387.9040304@gmail.com> Date: Thu, 17 Dec 2009 21:16:23 +0200 From: Alexander Kaphuk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20091217185204.GA12063@michelle.cdnetworks.com> In-Reply-To: <20091217185204.GA12063@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:16:36 -0000 Pyun YongHyeon wrote: > On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: > >> Dear FreeBSD-net Community, >> >> I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my >> NIC properly. >> >> Please see below for some technical details related to the problem. >> >> output of less /var/run/dmesg.boot | grep re0 >> >> re0: port 0x2000-0x20ff >> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >> on pci3 >> re0: Using 1 MSI messages >> re0: Chip rev. 0x24800000 >> re0: MAC rev. 0x00400000 >> re0: Unknown H/W revision: 0x24c00000 >> device_attach: re0 attach returned 6 >> re0: port 0x2000-0x20ff >> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >> on pci3 >> re0: Using 1 MSI messages >> re0: Chip rev. 0x24800000 >> re0: MAC rev. 0x00400000 >> re0: Unknown H/W revision: 0x24c00000 >> device_attach: re0 attach returned 6 >> re0: port 0x2000-0x20ff >> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >> on pci3 >> re0: Using 1 MSI messages >> re0: Chip rev. 0x24800000 >> re0: MAC rev. 0x00400000 >> re0: Unknown H/W revision: 0x24c00000 >> device_attach: re0 attach returned 6 >> re0: port 0x2000-0x20ff >> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >> on pci3 >> re0: Using 1 MSI messages >> re0: Chip rev. 0x24800000 >> re0: MAC rev. 0x00400000 >> re0: Unknown H/W revision: 0x24c00000 >> device_attach: re0 attach returned 6 >> >> > > Support for the controller was made in r195675 and the change was > already MFCed to stable/8 and stable7. Try recent CURRENT or > 8/stable and 7/stable. I guess you can download the following files > from latest stable/7 via web interface and rebuilding both re(4) > and rl(4) on your 7.2-RELEASE should make your controller > recognized. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h > > >> output of pciconf -l | grep re0 >> >> re0@pci0:3:0:0: class=0x020000 card=0x306a103c chip=0x813610ec rev=0x02 hdr=0x00 >> >> output of ifconfig >> >> ath0: flags=8802 metric 0 mtu 1500 >> ether 00:24:2c:5e:06:f2 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> ssid "" channel 1 (2412 Mhz 11b) >> authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan >> bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst >> bintval 0 >> lo0: flags=8049 metric 0 mtu 16384 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> pflog0: flags=0<> metric 0 mtu 33204 >> pfsync0: flags=0<> metric 0 mtu 1460 >> syncpeer: 224.0.0.240 maxupd: 128 >> >> >> Please let me know if you require further details that might be of help. >> >> Look forward to hearing from anyone who would care to help at your convenience. >> >> Regards, >> >> Alexander Kapshuk. >> > > Thanks a lot! I'll give it a go. I've never rebuilt a driver before. So I'll have to look into it. Can the info on how to do it be found in the Handbook, or should I look elsewhere? Thanks. From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 19:19:15 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D95D1106566B; Thu, 17 Dec 2009 19:19:15 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id BF49E8FC0C; Thu, 17 Dec 2009 19:19:15 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBHJJALu012726; Thu, 17 Dec 2009 11:19:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Dec 2009 11:19:05 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue with openbgpd + 8.0 Thread-Index: Acp/Ri+qvotJ1lm3SOGSwiKQ3n80pwABzbOQ References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> From: "Li, Qing" To: "Adam Jacob Muller" Cc: freebsd-net@freebsd.org, Michal Buchtik , Qing Li Subject: RE: issue with openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:19:15 -0000 Hi Adam, Thanks for the update. I think I will postpone the commit until I get a better handle on the addition behavior reported by Michal, hopefully soon. -- Qing > -----Original Message----- > From: Adam Jacob Muller [mailto:adam@adam.gs] > Sent: Thursday, December 17, 2009 10:24 AM > To: Li, Qing > Cc: Adam Jacob Muller; Michal Buchtik; freebsd-net@freebsd.org; Qing Li > Subject: Re: issue with openbgpd + 8.0 >=20 > Hi Qing, > This indeed fixes the issue for me! >=20 > Thanks very much, I hope to see the patch committed :) >=20 > -Adam >=20 >=20 > ---- > Adam Jacob Muller > adam@adam.gs > 201-616-0620 >=20 > On Dec 16, 2009, at 6:39 PM, Li, Qing wrote: >=20 > > Hi, > > > > You have reported issues regarding openbgp/bgpd exiting > > abnormally. Please apply patch: > > > > http://people.freebsd.org/~qingli/bgpd-patch-121615.diff > > > > and let me know if it fixes your issue. I performed limited > > unit testing. > > > > Thanks, > > > > -- Qing > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 19:27:49 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D621065672 for ; Thu, 17 Dec 2009 19:27:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8647A8FC18 for ; Thu, 17 Dec 2009 19:27:48 +0000 (UTC) Received: by qyk5 with SMTP id 5so1089316qyk.8 for ; Thu, 17 Dec 2009 11:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=1Cp98vui4w5PwmK315fDdtucvkCl9QiRl1H4LJRwqvI=; b=hy13jRjYQdLyZBC1KftJHbevjqCCzWbDw5BzVT3LReJ0ZsAAH+Ou9ZC6cUI6KwbGqV /GQvb4o/wbNLkpUgisWeRFWygYxOs1GPLEznsRblx2euXRAxYAD4HrdQ1gqWxyKMS88D ihrhCTfnBdbaerXCWDamhBCCg6BcGPOjo1/Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rWRg9U10rNZ882GUx4N87nCxMcQbrUuRSN7oW5H9P6vAwfG2+SGGbYp1mvTNbFYThc RT2ZHTN+GtQ3IqedAhkkVAuMygMdYmAbPhleW7z8mY532rPIuy8R+FDumaRmvaG8HzuV w5el07SonZkhsLvhQlnGU67+sU/FprMwD7I+s= Received: by 10.224.118.81 with SMTP id u17mr1834270qaq.301.1261078066677; Thu, 17 Dec 2009 11:27:46 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm6218540qwj.23.2009.12.17.11.27.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 11:27:45 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 17 Dec 2009 11:27:37 -0800 From: Pyun YongHyeon Date: Thu, 17 Dec 2009 11:27:37 -0800 To: Alexander Kaphuk Message-ID: <20091217192737.GB12063@michelle.cdnetworks.com> References: <20091217185204.GA12063@michelle.cdnetworks.com> <4B2A8387.9040304@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2A8387.9040304@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:27:49 -0000 On Thu, Dec 17, 2009 at 09:16:23PM +0200, Alexander Kaphuk wrote: > Pyun YongHyeon wrote: > >On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: > > > >>Dear FreeBSD-net Community, > >> > >>I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my > >>NIC properly. > >> > >>Please see below for some technical details related to the problem. > >> > >>output of less /var/run/dmesg.boot | grep re0 > >> > >>re0: port 0x2000-0x20ff > >>mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x24800000 > >>re0: MAC rev. 0x00400000 > >>re0: Unknown H/W revision: 0x24c00000 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x24800000 > >>re0: MAC rev. 0x00400000 > >>re0: Unknown H/W revision: 0x24c00000 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x24800000 > >>re0: MAC rev. 0x00400000 > >>re0: Unknown H/W revision: 0x24c00000 > >>device_attach: re0 attach returned 6 > >>re0: port 0x2000-0x20ff > >>mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 > >>on pci3 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x24800000 > >>re0: MAC rev. 0x00400000 > >>re0: Unknown H/W revision: 0x24c00000 > >>device_attach: re0 attach returned 6 > >> > >> > > > >Support for the controller was made in r195675 and the change was > >already MFCed to stable/8 and stable7. Try recent CURRENT or > >8/stable and 7/stable. I guess you can download the following files > >from latest stable/7 via web interface and rebuilding both re(4) > >and rl(4) on your 7.2-RELEASE should make your controller > >recognized. > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h > > > > > >>output of pciconf -l | grep re0 > >> > >>re0@pci0:3:0:0: class=0x020000 card=0x306a103c chip=0x813610ec > >>rev=0x02 hdr=0x00 > >> > >>output of ifconfig > >> > >>ath0: flags=8802 metric 0 mtu 1500 > >> ether 00:24:2c:5e:06:f2 > >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > >> status: no carrier > >> ssid "" channel 1 (2412 Mhz 11b) > >> authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan > >> bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst > >> bintval 0 > >>lo0: flags=8049 metric 0 mtu 16384 > >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >> inet6 ::1 prefixlen 128 > >> inet 127.0.0.1 netmask 0xff000000 > >>pflog0: flags=0<> metric 0 mtu 33204 > >>pfsync0: flags=0<> metric 0 mtu 1460 > >> syncpeer: 224.0.0.240 maxupd: 128 > >> > >> > >>Please let me know if you require further details that might be of help. > >> > >>Look forward to hearing from anyone who would care to help at your > >>convenience. > >> > >>Regards, > >> > >>Alexander Kapshuk. > >> > > > > > Thanks a lot! I'll give it a go. > > I've never rebuilt a driver before. So I'll have to look into it. Can > the info on how to do it be found in the Handbook, or should I look > elsewhere? > Basically you may have to save your old driver sources to safe place. And download the three files above and copy them to appropriate source directory and rebuild kernel/reboot. For instance, after downloading, Copy if_re.c to /usr/src/sys/dev/re/ Copy if_rl.c to /usr/src/sys/pci/ Copy if_rlreg.h to /usr/src/sys/pci/ And rebuild kernel. Handbook may have instructions how to rebuild kernel. Good luck. > Thanks. > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 19:28:46 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 797771065670 for ; Thu, 17 Dec 2009 19:28:46 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 619D88FC17 for ; Thu, 17 Dec 2009 19:28:46 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nBHJSgwH014161; Thu, 17 Dec 2009 11:28:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Dec 2009 11:28:36 -0800 Message-ID: In-Reply-To: <31264189.456321261063444556.JavaMail.coremail@bj126app49.126.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug discussion:Tcp snd_nxt will not be increased. Thread-Index: Acp/SY4IAyf5MlVuTLeGlVWWUClLyAABIxNA References: <31264189.456321261063444556.JavaMail.coremail@bj126app49.126.com> From: "Li, Qing" To: =?gb2312?B?zfW0urfn?= , "freebsd-net" Cc: Subject: RE: Bug discussion:Tcp snd_nxt will not be increased. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:28:46 -0000 Hi, Could you please tell us what version you are running? > > If the tcp_output just have some error, for example: when alloc mbuf, > it returns NULL, and then the snd_nxt number will not be return to > normal. > If just in this time, SYN Ack arrives, freeBSD can't handle this > situdition. > I have seen a related issue in older versions that I fixed, but it's = from=20 the SYN+ACK perspective. If my memory serves me right, local listener = receives a SYN packet, transmits the SYN+ACK, but memory allocation fails, so the SYN+ACK packet was never transmitted onto the wire, however, the SEQ = advanced by 1. As a result of SEQ update, the retransmitted SYN packet from the = other=20 end were discard as duplicates, eventually the connection times out. -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Dec 17 20:38:05 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11634106566B for ; Thu, 17 Dec 2009 20:38:05 +0000 (UTC) (envelope-from sashaandtanya@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 937B08FC1C for ; Thu, 17 Dec 2009 20:38:04 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so902991fgg.13 for ; Thu, 17 Dec 2009 12:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QOY7rn2RWeWtQth7ntINoL1lU9d157Qhl+rO9i8uARQ=; b=IaZAF0nxguY2lrCiHK5bOBig5QbXfvoWYmMUt2qtVX5ojnHsADePcx5kPSkuRJsXKX CXNQyMyRJnLrwONsC5S/t/MfAdiU6BscTL3EZvEDCq2Hx0VmxN7zd5vJ86hLtpoj5YqN qUMsfe4k9J3HyEhmxo0SSK/JXXzELCHhYO8EA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dna1Dfy3l18tnHcHVDBxXfjb6c8TU6Q1f5y+Zr20MHFK9dtsufMtuAb+iwVMVbxtav QHsy+i3p5WcJ/jKekaz8J9+KJY8w274oOEJNHHi6AFuXCSwDjo96dBW8xevlcB/8papl xQFmKJ0az4M03ckcaVic18SjyeGhgCQUWYkHI= Received: by 10.86.198.12 with SMTP id v12mr3919684fgf.17.1261082283627; Thu, 17 Dec 2009 12:38:03 -0800 (PST) Received: from ?192.168.1.2? (93-127-28-148.static.vega-ua.net [93.127.28.148]) by mx.google.com with ESMTPS id 14sm822575fxm.7.2009.12.17.12.38.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 12:38:02 -0800 (PST) Message-ID: <4B2A96A6.2030400@gmail.com> Date: Thu, 17 Dec 2009 22:37:58 +0200 From: Alexander Kaphuk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20091217185204.GA12063@michelle.cdnetworks.com> <4B2A8387.9040304@gmail.com> <20091217192737.GB12063@michelle.cdnetworks.com> In-Reply-To: <20091217192737.GB12063@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: trouble with Realtek NIC RTL8101E/RTL8102E under FreeBSD 7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 20:38:05 -0000 Pyun YongHyeon wrote: > On Thu, Dec 17, 2009 at 09:16:23PM +0200, Alexander Kaphuk wrote: > >> Pyun YongHyeon wrote: >> >>> On Thu, Dec 17, 2009 at 12:00:17PM +0200, Alexander Kapshuk wrote: >>> >>> >>>> Dear FreeBSD-net Community, >>>> >>>> I have trouble with FreeBSD 7.2 as well as PCBSD 7.1.1 detecting my >>>> NIC properly. >>>> >>>> Please see below for some technical details related to the problem. >>>> >>>> output of less /var/run/dmesg.boot | grep re0 >>>> >>>> re0: port 0x2000-0x20ff >>>> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >>>> on pci3 >>>> re0: Using 1 MSI messages >>>> re0: Chip rev. 0x24800000 >>>> re0: MAC rev. 0x00400000 >>>> re0: Unknown H/W revision: 0x24c00000 >>>> device_attach: re0 attach returned 6 >>>> re0: port 0x2000-0x20ff >>>> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >>>> on pci3 >>>> re0: Using 1 MSI messages >>>> re0: Chip rev. 0x24800000 >>>> re0: MAC rev. 0x00400000 >>>> re0: Unknown H/W revision: 0x24c00000 >>>> device_attach: re0 attach returned 6 >>>> re0: port 0x2000-0x20ff >>>> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >>>> on pci3 >>>> re0: Using 1 MSI messages >>>> re0: Chip rev. 0x24800000 >>>> re0: MAC rev. 0x00400000 >>>> re0: Unknown H/W revision: 0x24c00000 >>>> device_attach: re0 attach returned 6 >>>> re0: port 0x2000-0x20ff >>>> mem 0xd4010000-0xd4010fff,0xd4000000-0xd400ffff irq 17 at device 0.0 >>>> on pci3 >>>> re0: Using 1 MSI messages >>>> re0: Chip rev. 0x24800000 >>>> re0: MAC rev. 0x00400000 >>>> re0: Unknown H/W revision: 0x24c00000 >>>> device_attach: re0 attach returned 6 >>>> >>>> >>>> >>> Support for the controller was made in r195675 and the change was >>> already MFCed to stable/8 and stable7. Try recent CURRENT or >>> 8/stable and 7/stable. I guess you can download the following files >>> >> >from latest stable/7 via web interface and rebuilding both re(4) >> >>> and rl(4) on your 7.2-RELEASE should make your controller >>> recognized. >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h >>> >>> >>> >>>> output of pciconf -l | grep re0 >>>> >>>> re0@pci0:3:0:0: class=0x020000 card=0x306a103c chip=0x813610ec >>>> rev=0x02 hdr=0x00 >>>> >>>> output of ifconfig >>>> >>>> ath0: flags=8802 metric 0 mtu 1500 >>>> ether 00:24:2c:5e:06:f2 >>>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>>> status: no carrier >>>> ssid "" channel 1 (2412 Mhz 11b) >>>> authmode OPEN privacy OFF txpower 50 bmiss 7 scanvalid 60 bgscan >>>> bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 burst >>>> bintval 0 >>>> lo0: flags=8049 metric 0 mtu 16384 >>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>>> inet6 ::1 prefixlen 128 >>>> inet 127.0.0.1 netmask 0xff000000 >>>> pflog0: flags=0<> metric 0 mtu 33204 >>>> pfsync0: flags=0<> metric 0 mtu 1460 >>>> syncpeer: 224.0.0.240 maxupd: 128 >>>> >>>> >>>> Please let me know if you require further details that might be of help. >>>> >>>> Look forward to hearing from anyone who would care to help at your >>>> convenience. >>>> >>>> Regards, >>>> >>>> Alexander Kapshuk. >>>> >>>> >>> >>> >> Thanks a lot! I'll give it a go. >> >> I've never rebuilt a driver before. So I'll have to look into it. Can >> the info on how to do it be found in the Handbook, or should I look >> elsewhere? >> >> > > Basically you may have to save your old driver sources to safe > place. And download the three files above and copy them to > appropriate source directory and rebuild kernel/reboot. > For instance, after downloading, > Copy if_re.c to /usr/src/sys/dev/re/ > Copy if_rl.c to /usr/src/sys/pci/ > Copy if_rlreg.h to /usr/src/sys/pci/ > And rebuild kernel. > Handbook may have instructions how to rebuild kernel. > Good luck. > > >> Thanks. >> >> >> > > No worries. Thanks a lot for your help once again! From owner-freebsd-net@FreeBSD.ORG Fri Dec 18 15:40:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344B21065679; Fri, 18 Dec 2009 15:40:20 +0000 (UTC) (envelope-from pierre.reveillon@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8E36D8FC08; Fri, 18 Dec 2009 15:40:19 +0000 (UTC) Received: by ewy26 with SMTP id 26so2505388ewy.3 for ; Fri, 18 Dec 2009 07:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=18ZVebnruDTvGY+WnA9ykcvArxYRyMhnuX8aRUQ1jxU=; b=LOLDwADukhoxO1UQ5b2gcEuiUiZIMyAaoQvMXXimMohOGsRDEG1xBgD9zGSUjKK8s8 PC691k5O6VT+/BJEfxH7lszcZG/+iLyys2oUCZ8qBDjEiqW0wse6BN99qdwP+85+HSZB tiJuJzQS73JRHDDl6rx0kQkksxO4b8fiWIQMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=Gs8xkQ6NBrZl9YbuWmCX0ywyoJmQwIVOdWL/QDxS8foIZR1u1anc1cbAMBqw+TodD1 fYqhaRdW6qzTm177C4to8UkRbDGWm3YbEBqQvPqhTMS5cEEt4em36KUg3gj2h2Ow55wO 8UpS06m2aiHjQXNS3b04KYE0bRBjPlD0wTmTk= Received: by 10.213.102.66 with SMTP id f2mr4925552ebo.12.1261149290058; Fri, 18 Dec 2009 07:14:50 -0800 (PST) Received: from ?192.168.51.51? (lns-bzn-50f-81-56-231-226.adsl.proxad.net [81.56.231.226]) by mx.google.com with ESMTPS id 23sm5268407eya.3.2009.12.18.07.14.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 07:14:49 -0800 (PST) Message-ID: <4B2B9C67.2010801@gmail.com> Date: Fri, 18 Dec 2009 16:14:47 +0100 From: "pierre.reveillon" User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Network ACK loss problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 15:40:20 -0000 Hi, I just upgraded a server to 8.0_RELEASE and I started having network problems when pf is enabled (even with only "pass all" rules). It seems that some ACK are loss (see tcpdump results at the end). I still have some strange mail server problems when pf is disabled but I'm not sure it's linked. Thanks, Pierre Informations about my configuration : [root@papaya ~]# uname -a FreeBSD papaya.yyy.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root@papaya ~]# dmesg | grep vge0 vge0: port 0xfc00-0xfcff mem 0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0 miibus0: on vge0 vge0: WARNING: using obsoleted if_watchdog interface vge0: Ethernet address: 00:xx:xx:xx:xx:xx vge0: [ITHREAD] vge0: link state changed to UP vge0: promiscuous mode enabled vge0: promiscuous mode disabled [root@papaya ~]# pfctl -sr No ALTQ support in kernel ALTQ related functions disabled pass in all flags S/SA keep state pass out all flags S/SA keep state Tcpdump output: ******************** BAD ONE (pf enabled) ******************** listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:29:26.847488 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [S], seq 4010981448, win 5840, options [mss 1460,sackOK,TS val 27823034 ecr 0,nop,wscale 7], length 0 15:29:26.891968 IP papaya.yyy.net.www > bagherra.local.42567: Flags [S.], seq 3588656077, ack 4010981449, win 65535, options [mss 1412,nop,wscale 3,sackOK,TS val 1087266140 ecr 27823034], length 0 15:29:26.892034 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.], ack 1, win 46, options [nop,nop,TS val 27823045 ecr 1087266140], length 0 15:29:26.892281 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27823045 ecr 1087266140], length 119 15:29:26.982496 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1087266186 ecr 27823045], length 1400 15:29:26.982536 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.], ack 1401, win 69, options [nop,nop,TS val 27823068 ecr 1087266186], length 0 15:29:27.027653 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr 27823068], length 1400 15:29:27.028035 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr 27823068], length 1400 15:29:27.446470 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266694 ecr 27823068], length 1400 15:29:28.082905 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087267331 ecr 27823068], length 1400 15:29:29.156079 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087268404 ecr 27823068], length 1400 15:29:31.100271 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087270349 ecr 27823068], length 1400 15:29:34.788167 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087274038 ecr 27823068], length 1400 15:29:40.266521 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087279519 ecr 27823068], length 1400 15:29:51.023919 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087290280 ecr 27823068], length 1400 15:30:12.336745 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087311601 ecr 27823068], length 1400 15:30:54.762699 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087354042 ecr 27823068], length 1400 15:31:58.740422 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087418043 ecr 27823068], length 1400 15:33:02.718736 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087482044 ecr 27823068], length 1400 15:34:06.696421 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087546045 ecr 27823068], length 1400 ********************** GOOD ONE (pf disabled) ********************** listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:35:20.857405 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [S], seq 989268196, win 5840, options [mss 1460,sackOK,TS val 27911536 ecr 0,nop,wscale 7], length 0 15:35:20.901493 IP papaya.yyy.net.www > bagherra.local.52734: Flags [S.], seq 2220327620, ack 989268197, win 65535, options [mss 1412,nop,wscale 3,sackOK,TS val 1324570413 ecr 27911536], length 0 15:35:20.901541 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 1, win 46, options [nop,nop,TS val 27911548 ecr 1324570413], length 0 15:35:20.901682 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27911548 ecr 1324570413], length 119 15:35:20.949199 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1324570459 ecr 27911548], length 1400 15:35:20.949243 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 1401, win 69, options [nop,nop,TS val 27911559 ecr 1324570459], length 0 15:35:20.994274 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr 27911559], length 1400 15:35:20.994310 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 2801, win 91, options [nop,nop,TS val 27911571 ecr 1324570504], length 0 15:35:20.994758 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr 27911559], length 1400 15:35:20.994772 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 4201, win 114, options [nop,nop,TS val 27911571 ecr 1324570504], length 0 15:35:21.038843 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 4201:5601, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr 27911571], length 1400 15:35:21.038876 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 5601, win 137, options [nop,nop,TS val 27911582 ecr 1324570549], length 0 15:35:21.039366 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 5601:7001, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr 27911571], length 1400 15:35:21.039383 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 7001, win 159, options [nop,nop,TS val 27911582 ecr 1324570549], length 0 15:35:21.040337 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 7001:8401, ack 120, win 8225, options [nop,nop,TS val 1324570550 ecr 27911571], length 1400 15:35:21.040351 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 8401, win 182, options [nop,nop,TS val 27911582 ecr 1324570550], length 0 15:35:21.084159 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 8401:9801, ack 120, win 8225, options [nop,nop,TS val 1324570594 ecr 27911582], length 1400 15:35:21.084201 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 9801, win 204, options [nop,nop,TS val 27911593 ecr 1324570594], length 0 15:35:21.085054 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 9801:11201, ack 120, win 8225, options [nop,nop,TS val 1324570595 ecr 27911582], length 1400 15:35:21.085076 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11201, win 227, options [nop,nop,TS val 27911593 ecr 1324570595], length 0 15:35:21.085088 IP papaya.yyy.net.www > bagherra.local.52734: Flags [P.], seq 11201:11727, ack 120, win 8225, options [nop,nop,TS val 1324570595 ecr 27911582], length 526 15:35:21.085098 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11727, win 249, options [nop,nop,TS val 27911593 ecr 1324570595], length 0 15:35:21.085950 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [F.], seq 120, ack 11727, win 249, options [nop,nop,TS val 27911594 ecr 1324570595], length 0 15:35:21.131345 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], ack 121, win 8225, options [nop,nop,TS val 1324570642 ecr 27911594], length 0 15:35:21.131563 IP papaya.yyy.net.www > bagherra.local.52734: Flags [F.], seq 11727, ack 121, win 8225, options [nop,nop,TS val 1324570642 ecr 27911594], length 0 15:35:21.131596 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11728, win 249, options [nop,nop,TS val 27911605 ecr 1324570642], length 0 From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 08:46:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2121065670 for ; Sat, 19 Dec 2009 08:46:52 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83811.mail.sp1.yahoo.com (web83811.mail.sp1.yahoo.com [69.147.85.85]) by mx1.freebsd.org (Postfix) with SMTP id B473C8FC08 for ; Sat, 19 Dec 2009 08:46:52 +0000 (UTC) Received: (qmail 17823 invoked by uid 60001); 19 Dec 2009 08:46:52 -0000 Message-ID: <354781.17776.qm@web83811.mail.sp1.yahoo.com> X-YMail-OSG: PHzMpHsVM1nqGfgDTX_eOkrBa6C9pPewWfRWPrDHX5xlomjhDtQRAYKmhVr7O19mmQSVE4om_PAEANxcvSfDtfwm2YV7vEGpH6o_VZ_sE58VsLhdFZrXAqwPUXfZETGDoOLf9qqhVoegg9N5w2SGpY2SHiDbVtV1NdODpA5JSp_LCyt.KIExZkddK6z2KVj4qMKK5OH58HsGf.v0RVQ21pN7GZ_il2tHeAB8imS_n84ISWCA6RCiPKCSgzIlV4jbfV1.Kn_7qlR_rX6BGZo39WCXq2I9K9U- Received: from [69.43.143.59] by web83811.mail.sp1.yahoo.com via HTTP; Sat, 19 Dec 2009 00:46:51 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 Date: Sat, 19 Dec 2009 00:46:51 -0800 (PST) From: Gabe To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: IPSEC: ipsec4_common_input_cb: queue full; proto 50 packet dropped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 08:46:52 -0000 Anyone know what causes this? It only happens on one side of the tunnel/gateway and its intermittent. I was also trying to scp a big file (~240MB) from the actual tunnel/gateway that displays this error and it ended with: testfile.wmv 100% 249MB 2.0MB/s 02:07 ./testfile.wmv: Input/output error though that could be due to restrictions on the actual switch, I don't know yet. Any clues? -gabe From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 10:15:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB51E106566C for ; Sat, 19 Dec 2009 10:15:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 823748FC13 for ; Sat, 19 Dec 2009 10:15:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9F33C41C751; Sat, 19 Dec 2009 11:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id OxdTKXWXAYmu; Sat, 19 Dec 2009 11:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 4CA9241C75A; Sat, 19 Dec 2009 11:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 165714448EC; Sat, 19 Dec 2009 10:11:07 +0000 (UTC) Date: Sat, 19 Dec 2009 10:11:07 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Gabe In-Reply-To: <354781.17776.qm@web83811.mail.sp1.yahoo.com> Message-ID: <20091219100922.F86040@maildrop.int.zabbadoz.net> References: <354781.17776.qm@web83811.mail.sp1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPSEC: ipsec4_common_input_cb: queue full; proto 50 packet dropped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 10:15:09 -0000 On Sat, 19 Dec 2009, Gabe wrote: > Anyone know what causes this? It only happens on one side of the tunnel/gateway and its intermittent. I was also trying to scp a big file (~240MB) from the actual tunnel/gateway that displays this error and it ended with: > > testfile.wmv 100% 249MB 2.0MB/s 02:07 > ./testfile.wmv: Input/output error > > though that could be due to restrictions on the actual switch, I don't know yet. > > Any clues? What you gave in the subject means that the netisr ("kernel software interrupt network dispatch service") returned an error. Why that is I don't know yet. Which version of FreeBSD are you running? Would you be able to test a patch (recompiling the kernel)? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 12:08:01 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03A71065696 for ; Sat, 19 Dec 2009 12:08:01 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83803.mail.sp1.yahoo.com (web83803.mail.sp1.yahoo.com [69.147.85.69]) by mx1.freebsd.org (Postfix) with SMTP id 904CA8FC18 for ; Sat, 19 Dec 2009 12:08:01 +0000 (UTC) Received: (qmail 92336 invoked by uid 60001); 19 Dec 2009 12:08:00 -0000 Message-ID: <654285.89304.qm@web83803.mail.sp1.yahoo.com> X-YMail-OSG: EN9gyHYVM1mUXz9ymXM_KKs0OcVwpdA.o483YR2_anuf_aIPJMebC4EOs.Y0mNn0vkLwmATHNPw39O0qkGRtcFwvHCFfEoHQYdq3HRQMZKJ57mthdndz3dnmwB2q_ucQeGcc6_8bnk7kyQ4RAqolrRhZSnAswel1pEsUPWwGT0k7.RNa0Dqo2uPhVtKOxuJG4V.PHGhRFSmbRg8s6Fsz2mgSCApvT79Pi84U0crY5id1wvq2VyIN8lPslSzlkEJUcz7pXXhS_XW4PVHoAE8i7E0mH4LaH99ug3EwpLnjlmZq_wlkZZd22ARlR4qoj2aTV3VaQyjtnlbFtv6kDD8- Received: from [69.43.143.59] by web83803.mail.sp1.yahoo.com via HTTP; Sat, 19 Dec 2009 04:08:00 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <354781.17776.qm@web83811.mail.sp1.yahoo.com> <20091219100922.F86040@maildrop.int.zabbadoz.net> Date: Sat, 19 Dec 2009 04:08:00 -0800 (PST) From: Gabe To: "Bjoern A. Zeeb" In-Reply-To: <20091219100922.F86040@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: IPSEC: ipsec4_common_input_cb: queue full; proto 50 packet dropped X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 12:08:01 -0000 Hey, I'm running 7.1-RELEASE-p8 with ipsec-tools-0.7.3. And yes, this is a dev box. Thanks, -gabe ----- Original Message ---- > From: Bjoern A. Zeeb > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Sat, December 19, 2009 2:11:07 AM > Subject: Re: IPSEC: ipsec4_common_input_cb: queue full; proto 50 packet dropped > > On Sat, 19 Dec 2009, Gabe wrote: > > > Anyone know what causes this? It only happens on one side of the > tunnel/gateway and its intermittent. I was also trying to scp a big file > (~240MB) from the actual tunnel/gateway that displays this error and it ended > with: > > > > testfile.wmv 100% 249MB > 2.0MB/s 02:07 > > ./testfile.wmv: Input/output error > > > > though that could be due to restrictions on the actual switch, I don't know > yet. > > > > Any clues? > > > What you gave in the subject means that the netisr ("kernel software > interrupt network dispatch service") returned an error. Why that is > I don't know yet. > > Which version of FreeBSD are you running? Would you be able to test a > patch (recompiling the kernel)? > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 17:11:01 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2919C1065670; Sat, 19 Dec 2009 17:11:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F41B58FC15; Sat, 19 Dec 2009 17:11:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBJHB0ON014146; Sat, 19 Dec 2009 17:11:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBJHB0lq014134; Sat, 19 Dec 2009 17:11:00 GMT (envelope-from linimon) Date: Sat, 19 Dec 2009 17:11:00 GMT Message-Id: <200912191711.nBJHB0lq014134@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141777: [rum] [request] Support usbdevs / rum(4) for Buffalo WLI-UC-G X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 17:11:01 -0000 Old Synopsis: [patch] Support usbdevs / rum(4) for Buffalo WLI-UC-G New Synopsis: [rum] [request] Support usbdevs / rum(4) for Buffalo WLI-UC-G Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Dec 19 17:09:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). Note that there is an output of usbdevs but not an actual patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=141777 From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 17:20:07 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87B84106566C for ; Sat, 19 Dec 2009 17:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE558FC13 for ; Sat, 19 Dec 2009 17:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBJHK707020500 for ; Sat, 19 Dec 2009 17:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBJHK7nZ020499; Sat, 19 Dec 2009 17:20:07 GMT (envelope-from gnats) Date: Sat, 19 Dec 2009 17:20:07 GMT Message-Id: <200912191720.nBJHK7nZ020499@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kunio Murasawa Cc: Subject: Re: kern/141777: [patch] Support usbdevs / rum(4) for Buffalo WLI-UC-G X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kunio Murasawa List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 17:20:07 -0000 The following reply was made to PR kern/141777; it has been noted by GNATS. From: Kunio Murasawa To: bug-followup@freebsd.org Cc: Subject: Re: kern/141777: [patch] Support usbdevs / rum(4) for Buffalo WLI-UC-G Date: Sun, 20 Dec 2009 01:43:49 +0900 --000e0cd5391c84dd31047b178f51 Content-Type: multipart/alternative; boundary=000e0cd5391c84dd28047b178f4f --000e0cd5391c84dd28047b178f4f Content-Type: text/plain; charset=ISO-8859-1 Sorry, didn't send patch. I send a patch. -- Kunio Murasawa --000e0cd5391c84dd28047b178f4f Content-Type: text/html; charset=ISO-8859-1 Sorry, didn't send patch.
I send a patch.

--
Kunio Murasawa
--000e0cd5391c84dd28047b178f4f-- --000e0cd5391c84dd31047b178f51 Content-Type: application/octet-stream; name="wli-uc-g.patch" Content-Disposition: attachment; filename="wli-uc-g.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g3em3agd0 ZGlmZiAtcnUgL3Vzci9zcmMvc3lzL2Rldi91c2Iub3JpZy91c2JkZXZzIC91c3Ivc3JjL3N5cy9k ZXYvdXNiL3VzYmRldnMKLS0tIC91c3Ivc3JjL3N5cy9kZXYvdXNiLm9yaWcvdXNiZGV2cwkyMDA5 LTEwLTI1IDEwOjEwOjI5LjAwMDAwMDAwMCArMDkwMAorKysgL3Vzci9zcmMvc3lzL2Rldi91c2Iv dXNiZGV2cwkyMDA5LTEyLTE5IDIxOjA4OjI0Ljg0NzM1NTA4MCArMDkwMApAQCAtMTcwNiw2ICsx NzA2LDcgQEAKIHByb2R1Y3QgTUVMQ08gRzU0SFAJCTB4MDBkOQlXTEktVTItRzU0SFAKIHByb2R1 Y3QgTUVMQ08gS0c1NEwJCTB4MDBkYQlXTEktVTItS0c1NEwKIHByb2R1Y3QgTUVMQ08gU0c1NEhH CQkweDAwZjQJV0xJLVUyLVNHNTRIRworcHJvZHVjdCBNRUxDTyBVQ0cJCTB4MDEzNwlXTEktVUMt RwogCiAvKiBNZXJsaW4gcHJvZHVjdHMgKi8KIHByb2R1Y3QgTUVSTElOIFY2MjAgICAgICAgICAg ICAgMHgxMTEwICBNZXJsaW4gVjYyMApkaWZmIC1ydSAvdXNyL3NyYy9zeXMvZGV2L3VzYi5vcmln L3dsYW4vaWZfcnVtLmMgL3Vzci9zcmMvc3lzL2Rldi91c2Ivd2xhbi9pZl9ydW0uYwotLS0gL3Vz ci9zcmMvc3lzL2Rldi91c2Iub3JpZy93bGFuL2lmX3J1bS5jCTIwMDktMTAtMjUgMTA6MTA6Mjku MDAwMDAwMDAwICswOTAwCisrKyAvdXNyL3NyYy9zeXMvZGV2L3VzYi93bGFuL2lmX3J1bS5jCTIw MDktMTItMTkgMjE6MDc6MDAuMjM3ODQ5NDAzICswOTAwCkBAIC0xMTYsNiArMTE2LDcgQEAKICAg ICB7IFVTQl9WUChVU0JfVkVORE9SX0hVQVdFSTNDT00sCVVTQl9QUk9EVUNUX0hVQVdFSTNDT01f V1VCMzIwRykgfSwKICAgICB7IFVTQl9WUChVU0JfVkVORE9SX01FTENPLAkJVVNCX1BST0RVQ1Rf TUVMQ09fRzU0SFApIH0sCiAgICAgeyBVU0JfVlAoVVNCX1ZFTkRPUl9NRUxDTywJCVVTQl9QUk9E VUNUX01FTENPX1NHNTRIUCkgfSwKKyAgICB7IFVTQl9WUChVU0JfVkVORE9SX01FTENPLAkJVVNC X1BST0RVQ1RfTUVMQ09fVUNHKSB9LAogICAgIHsgVVNCX1ZQKFVTQl9WRU5ET1JfTVNJLAkJVVNC X1BST0RVQ1RfTVNJX1JUMjU3M18xKSB9LAogICAgIHsgVVNCX1ZQKFVTQl9WRU5ET1JfTVNJLAkJ VVNCX1BST0RVQ1RfTVNJX1JUMjU3M18yKSB9LAogICAgIHsgVVNCX1ZQKFVTQl9WRU5ET1JfTVNJ LAkJVVNCX1BST0RVQ1RfTVNJX1JUMjU3M18zKSB9LApkaWZmIC1ydSAvdXNyL3NyYy9zaGFyZS9t YW4vbWFuNC5vcmlnL3J1bS40IC91c3Ivc3JjL3NoYXJlL21hbi9tYW40L3J1bS40Ci0tLSAvdXNy L3NyYy9zaGFyZS9tYW4vbWFuNC5vcmlnL3J1bS40CTIwMDktMTAtMjUgMTA6MTA6MjkuMDAwMDAw MDAwICswOTAwCisrKyAvdXNyL3NyYy9zaGFyZS9tYW4vbWFuNC9ydW0uNAkyMDA5LTEyLTIwIDAw OjExOjU4Ljc5NzgzNjEyMiArMDkwMApAQCAtOTMsNiArOTMsNyBAQAogLkl0ICJCdWZmYWxvIFdM SS1VMi1TRzU0SFAiIFRhIFVTQgogLkl0ICJCdWZmYWxvIFdMSS1VMi1TRzU0SEciIFRhIFVTQgog Lkl0ICJCdWZmYWxvIFdMSS1VMi1HNTRIUCIgVGEgVVNCCisuSXQgIkJ1ZmZhbG8gV0xJLVVDLUci IFRhIFVTQgogLkl0ICJDTmV0IENXRC04NTQgdmVyIEYiIFRhIFVTQgogLkl0ICJDb25jZXB0cm9u aWMgQzU0UlUgdmVyIDIiIFRhIFVTQgogLkl0ICJDb3JlZ2EgQ0ctV0xVU0IyR08iIFRhIFVTQgo= --000e0cd5391c84dd31047b178f51-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 19 15:45:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6641065676 for ; Sat, 19 Dec 2009 15:45:39 +0000 (UTC) (envelope-from fengdreamer@126.com) Received: from m50-110.126.com (m50-110.126.com [123.125.50.110]) by mx1.freebsd.org (Postfix) with ESMTP id 34EFD8FC08 for ; Sat, 19 Dec 2009 15:45:36 +0000 (UTC) Received: from hao251 (unknown [219.237.184.215]) by smtp4 (Coremail) with SMTP id jdKowLAbjzYa9SxLQCxCBg--.2096S2; Sat, 19 Dec 2009 23:45:30 +0800 (CST) Date: Sat, 19 Dec 2009 23:45:19 +0800 From: "fengdreamer" To: "Li, Qing" , "freebsd-net" References: <31264189.456321261063444556.JavaMail.coremail@bj126app49.126.com> Message-ID: <200912192345192969851@126.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 X-CM-TRANSID: jdKowLAbjzYa9SxLQCxCBg--.2096S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXr48Ar1UWr1kCF4DXF1DKFg_yoW5AryUpa 90g39xGFn7trWYyrs7Cr4xGF1v93ySyFy5J3yjqryYvw15W39agF1ayrWa9wnrua1Iqw1Y vFWUXF15GF4DC3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyvb7IF0VCYb41lb7IF0VCF04k20xv_Gry3M7k042IE42xK82IY 64kIx2x0424lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI4VWUJwAYFVCjjxCrM7Avxs IEb2xv6ckvw2Wl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq 3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjx v20xvEc7CjxVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2 jsIEc7CjxVAFwI0_GcCE3s1ln7IjY7xE6298Mc804VCY07AIYIkI8VC2zVCFFI0UMc804V CqF7xvr2I5Mc02F40E42I26xC2a48xMcIj6I8E87Iv67AKxVWUJVW8JwACjcxG0xvY0x0E wIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lFVAaXTZC67ZELS n0mTvEwaV2v3VFvVW8Mx02cVAKzwCY1Ik26cxK620vw7xCY7Wlc2xSY4AK67AK6ryrMxkI 7II2jI8vz4vEwIxGrwCF04k20xvY0x0EwIxGrwCF72vE52k0Y41lx4CE17CEb7AF67AKxV WUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCqF7xvr2IY 62kE34x0Y4UvcSsGvfC2KfnxnUUI43ZEXa7IUjBHq7UUUUU== X-CM-SenderInfo: pihqwv5uhdzvbu6rjloofrz/1tbiHRc+s0ihO3R+JQAAs6 X-Mailman-Approved-At: Sat, 19 Dec 2009 18:20:41 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Actual this is sender sider, the KASSERT. //Re: RE: Bug discussion:Tcp snd_nxt will not be increased. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 15:45:39 -0000 DQpIZWxsbyBMaSwgUWluZyBhbmQgQUxMOg0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgYW0g dXNpbmcgdGhlIEZyZWVCU0QgNy4xLiANCldoYXQgaSBhbSB0YWxraW5nIGFib3V0IGlzIHRoZSBj b25uZWN0IHNpZGUuICBIZXJlIGlzIG15IGRlc2NyaXB0aW9uLCBwbGVhc2UgcmVhZCB0aGUgYnJp ZWYgZmlyc3QgYW5kIGdldCB0aGUgcHJvYmxlbSBhbmQgdGhlbiBjb250bnVlIHdpdGggdGhlIGRl dGFpbCBkZXNjcmlwdGlvbi4NCg0KSG93IGlzIHRoaXMgcHJvYmxlbSBoYXBwZW46DQpCcmllZiBk ZXNjcmlwdGlvbjoNCjEuIEZpcnN0LCBDb25uZWN0IHNpZGUgc2VuZCBTWU4gdG8gdGhlIGxpc3Rl cm5lcg0KMi4gU2Vjb25kLCBDb25uZWN0IHNpZGUgd2lsbCByZXRyYW5zbWl0IHRoZSBTWU4gcGFj a2V0LCBidXQgd2hlbiBpdCBhbGxvYyBtYnVmIGZhaWwgaW4gdGhlIHRjcF9vdXRwdXQuIHRoZSB0 Y3Bfc25kbnh0IHdpbGwgbm90IGluY3JlYXNlLg0KMy4gU1lOIEFDSyBhcnJpdmVzLCB0Y3Bfc25k dW5hIGluY3JlYXNlLCBhbmQgd2lsbCBsYWdlciB0aGVuIHRjcF9zbmRueHQgYnkgMS4gc2VuZGVy IHNpZGUgd2lsbCByZXNwb25zZSB0aGUgQUNLLCBpbnZva2UgdGNwX291dHB1dDogbGVuIGlzIDEs IGJ1dCBjYyBpcyB6ZXJvLiBLQVNTRVJUIGhhcHBlbi4NCg0KRGV0YWlsIGRlc2NyaXB0aW9uOg0K MS5GaXJzdCwgQ29ubmVjdCBzaWRlIHNlbmQgU1lOIHRvIHRoZSBsaXN0ZXJuZXIsIHRjcC0+c25k X254dCB3aWxsIGp1c3QgbGFyZ2VyIHRoYW4gdGhlIHRjcC0+c25kX3VuYSBieSAxLg0KMi4gU2Vj b25kLCBDb25uZWN0IHNpZGUgd2lsbCByZXRyYW5zbWl0IHRoZSBTWU4gcGFja2V0LiBUaGUgcmV0 cmFuc21pdCBpcyB0cmlnZXIgYnkgdGhlIHJldHJhbnNtaXQgdGltZXIsIGl0IHdpbGwgdGhlbiBy b2xsIGJhY2sgdGhlIHRjcC0+c25kX254dCBlcXVhbCB0byB0Y3AtPnNuZF91bmEuICBhbmQgYmVn aW4gdG8gY2FsbCB0aGUgdGNwX291dHB1dC4gSWYgdGhlIHRjcF9vdXRwdXQgd29ya2luZyBmdW4s IHRoZSB0Y3AtPnNuZF9ueHQgd2lsbCB0aGVuIGFkdmFuY2VkIGJ5IDEgYmVmb3JlIGl0IGNhbGxz IHRoZSBpcF9vdXRwdXQuIEJ1dCBpZiB0aGUgbWJ1ZiBhbGxvYyBmYWlsLCB0aGUgdGNwLT5zbmRf bnh0IHdpbGwgc3RheSBlcXVhbCB0byB0Y3AtPnNuZF91bmEuIChvbiBteSBzeXN0ZW0sIG1lbWVy eSBpcyBydW5uaW5nIG91dCwgc28gbWJ1ZiBhbGxvYyBtYXkgZmFpbC4gKSBwbGVhc2UgcmVmZXIg dGhlIGJlbG93IGNvZGUgaW4gdGhlIHRjcF9vdXRwdXQ6DQoNCk1HRVRIRFIobSwgTV9ET05UV0FJ VCwgTVRfREFUQSk7DQppZiAobSA9PSBOVUxMKSB7DQplcnJvciA9IEVOT0JVRlM7DQpnb3RvIG91 dDsgLy8gZ290byBvdXQsIHNvIHRoZSB0Y3AtPnNuZF9ueHQgd2lsbCBub3QgaW5jcmVhc2VkLg0K fSANCg0KDQozLiBhcyBhYm92ZSBkZXNjcmlidGlvbiwgdGhlIHRjcC0+c25kX254dCBpcyBlcXVh bCB0byB0Y3AtPnNuZF91bmEuIHRoZW4gdGhlIFNZTiBBQ0sgcGFja2V0IGFycml2ZXMsIGFuZCB0 aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwgYW5kIHRoZSB0Y3AtPnNuZF91bmEgd2lsbCBp bmNyZWFzZSBieSAxLiBBbHNvIHRoZSBjb25uZWN0IHNpZGUgd2lsbCB0aGVuIHNlbmQgdGhlIGxh c3QgQUNLLCBpdCBpbnZvZGUgdGhlIHRjcF9vdXRwdXQsIHRjcCBvdXRwdXQgbGVuIGlzIGNvbXB1 dGUgYnkgdGhlIGJlbG93IGV4cHJlc3Npb246DQoNCm9mZiA9IHRwLT5zbmRfbnh0IC0gdHAtPnNu ZF91bmE7IA0KbGVuID0gKChsb25nKXVsbWluKHNvLT5zb19zbmQuc2JfY2MsIHNlbmR3aW4pIC0g b2ZmKTsgDQoNCm9mY291cnNlIHlvdSBoYXZlIHNlZW4uIHRoZSBvZmYgaXMgLTEsIHRoZSBzb19z bmQuc2JfY2MgaXMgMCwgc28gdGhlIGxlbiBpcyAxLiBzbyBiZWxvdyBLQVNTRVJUIHdpbGwgY2Ft ZToNCg0KS0FTU0VSVChzYi0+c2JfbWIgIT0gTlVMTCwgKCIlczogc2JfbWIgaXMgTlVMTCIsIF9f ZnVuY19fKSk7IC8qIChzYnNuZHB0ciApICovDQoNClRoYW5rcyANClJlZ2FyZA0KDQoNCjIwMDkt MTItMTkgDQoNCg0KDQpmZW5nZHJlYW1lciANCg0KDQoNCreivP7Iy6O6IExpLCBRaW5nIA0Kt6LL zcqxvOSjuiAyMDA5LTEyLTE4ICAwMzoyODo0NSANCsrVvP7Iy6O6IM31tLq35zsgZnJlZWJzZC1u ZXQgDQqzrcvNo7ogDQrW98zio7ogUkU6IEJ1ZyBkaXNjdXNzaW9uOlRjcCBzbmRfbnh0IHdpbGwg bm90IGJlIGluY3JlYXNlZC4gDQogDQpIaSwNCkNvdWxkIHlvdSBwbGVhc2UgdGVsbCB1cyB3aGF0 IHZlcnNpb24geW91IGFyZSBydW5uaW5nPw0KPg0KPiBJZiB0aGUgdGNwX291dHB1dCBqdXN0IGhh dmUgc29tZSBlcnJvciwgZm9yIGV4YW1wbGU6IHdoZW4gYWxsb2MgbWJ1ZiwNCj4gaXQgcmV0dXJu cyBOVUxMLCBhbmQgdGhlbiB0aGUgc25kX254dCBudW1iZXIgd2lsbCBub3QgYmUgcmV0dXJuIHRv DQo+IG5vcm1hbC4NCj4gSWYganVzdCBpbiB0aGlzIHRpbWUsIFNZTiBBY2sgYXJyaXZlcywgZnJl ZUJTRCBjYW4ndCBoYW5kbGUgdGhpcw0KPiBzaXR1ZGl0aW9uLg0KPg0KSSBoYXZlIHNlZW4gYSBy ZWxhdGVkIGlzc3VlIGluIG9sZGVyIHZlcnNpb25zIHRoYXQgSSBmaXhlZCwgYnV0IGl0J3MgZnJv bSANCnRoZSBTWU4rQUNLIHBlcnNwZWN0aXZlLiBJZiBteSBtZW1vcnkgc2VydmVzIG1lIHJpZ2h0 LCBsb2NhbCBsaXN0ZW5lciByZWNlaXZlcw0KYSBTWU4gcGFja2V0LCB0cmFuc21pdHMgdGhlIFNZ TitBQ0ssIGJ1dCBtZW1vcnkgYWxsb2NhdGlvbiBmYWlscywgc28gdGhlDQpTWU4rQUNLIHBhY2tl dCB3YXMgbmV2ZXIgdHJhbnNtaXR0ZWQgb250byB0aGUgd2lyZSwgaG93ZXZlciwgdGhlIFNFUSBh ZHZhbmNlZA0KYnkgMS4gQXMgYSByZXN1bHQgb2YgU0VRIHVwZGF0ZSwgdGhlIHJldHJhbnNtaXR0 ZWQgU1lOIHBhY2tldCBmcm9tIHRoZSBvdGhlciANCmVuZCB3ZXJlIGRpc2NhcmQgYXMgZHVwbGlj YXRlcywgZXZlbnR1YWxseSB0aGUgY29ubmVjdGlvbiB0aW1lcyBvdXQuDQotLSBRaW5nDQo=