From Michael.Tuexen at lurchi.franken.de Thu Jan 1 16:59:12 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Thu Jan 1 16:59:18 2009 Subject: SCTP related issue with recent ARP changes? Message-ID: Dear all, I'm running the current CVS version of FreeBSD 8 in a virtual machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) and bridged networking having an em interface on the virtual machine. I'm using a similar setup with older FreeBSD machines and they are running fine. Loopback communication based on UDP, TCP, SCTP or ICMP works fine. Communicating with other hosts using UDP, TCP or ICMP works fine. Communicating with other hosts using SCTP does not work. The SCTP stack calls ip_output() and an ARP request for the correct destination IP address is send out. A corresponding ARP reply is visible in Wireshark (running on the FreeBSD 8 box) and looks good. However, the corresponding SCTP packet it never sent out. I'm not sure, but this might be related to the recent ARP changes. Is there anything required from the transport layer to be done when calling ip_output() that was not required before? Best regards Michael From qing.li at bluecoat.com Thu Jan 1 20:19:22 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Jan 1 20:19:34 2009 Subject: SCTP related issue with recent ARP changes? References: Message-ID: Hi Michael, Your problem could be related to the recent ARP changes. I will investigate further to confirm. Thanks, -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Michael T?xen Sent: Thu 1/1/2009 8:59 AM To: FreeBSD Net Subject: SCTP related issue with recent ARP changes? Dear all, I'm running the current CVS version of FreeBSD 8 in a virtual machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) and bridged networking having an em interface on the virtual machine. I'm using a similar setup with older FreeBSD machines and they are running fine. Loopback communication based on UDP, TCP, SCTP or ICMP works fine. Communicating with other hosts using UDP, TCP or ICMP works fine. Communicating with other hosts using SCTP does not work. The SCTP stack calls ip_output() and an ARP request for the correct destination IP address is send out. A corresponding ARP reply is visible in Wireshark (running on the FreeBSD 8 box) and looks good. However, the corresponding SCTP packet it never sent out. I'm not sure, but this might be related to the recent ARP changes. Is there anything required from the transport layer to be done when calling ip_output() that was not required before? Best regards Michael _______________________________________________ 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 ericlin at tamama.org Fri Jan 2 06:19:57 2009 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Fri Jan 2 06:20:04 2009 Subject: TCP packet out-of-order problem In-Reply-To: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> Message-ID: <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> Dear listers, We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. % uname -a FreeBSD bsd 7.1-RC2 FreeBSD 7.1-RC2 #2: Wed Dec 31 03:12:39 CST 2008 root@bsd:/usr/obj/usr/src/sys/KERNEL amd64 % iperf -c 10.1.1.250 ------------------------------------------------------------ Client connecting to office, TCP port 5001 TCP window size: 3.07 MByte (default) ------------------------------------------------------------ [ 4] local 10.1.1.210 port 61488 connected with 10.1.1.250 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.2 sec 5.74 MBytes 4.74 Mbits/sec 03:47:21.146397 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 159305:160753(1448) ack 1 win 1040 03:47:21.146409 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 160753 win 12568 03:47:21.146473 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 160753:162201(1448) ack 1 win 1040 03:47:21.146485 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 162201 win 12568 03:47:21.146972 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 163649:165097(1448) ack 1 win 1040 03:47:21.146983 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 162201 win 12573 03:47:21.146985 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 162201:163649(1448) ack 1 win 1040 03:47:21.146996 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 163649 win 12568 03:47:21.146998 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 165097:166545(1448) ack 1 win 1040 03:47:21.147006 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 163649 win 12573 03:47:21.147009 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 166545:167993(1448) ack 1 win 1040 03:47:21.147017 IP 10.1.1.250.5001 > 10.1.1.210.54919: . ack 163649 win 12573 03:47:21.147019 IP 10.1.1.210.54919 > 10.1.1.250.5001: . 167993:169441(1448) ack 1 win 1040 * You can see "ack 163649" repeating, but the packet is transmitted before 163649:165097. % cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8 2003/03/13 18:43:50 mux Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 debug.bootverbose=1 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.maxprocperuid=65536 net.inet.ip.fastforwarding=1 net.inet.tcp.delayed_ack=0 vm.pmap.shpgperproc=2000 kern.ipc.maxsockbuf=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 Is our configuration wrong? Or it is an known bug? I have searched stable & net list, but found no similar discussion. Best Regards, Eric From ericlin at tamama.org Fri Jan 2 06:49:30 2009 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Fri Jan 2 06:49:37 2009 Subject: TCP packet out-of-order problem In-Reply-To: <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> Message-ID: <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> Dear All listers, After running "netstat -s -p tcp", we found that lots of packets are discarded due to memory problems. We googled for it, and found that sysctl oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never reassembled. Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf, the network works perfectly now. Thank you all for the help! From linimon at FreeBSD.org Fri Jan 2 09:57:51 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 2 09:58:03 2009 Subject: kern/130109: [ipfw] Can not set fib for packets originated from local host Message-ID: <200901020957.n029voif091486@freefall.freebsd.org> Old Synopsis: Can not set fib for packets originated from local host New Synopsis: [ipfw] Can not set fib for packets originated from local host Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 2 09:57:11 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130109 From jd at ods.org Fri Jan 2 21:01:13 2009 From: jd at ods.org (Jason DiCioccio) Date: Fri Jan 2 21:01:21 2009 Subject: kern/130059: [panic] Leaking 50k mbufs/hour In-Reply-To: References: <200812311353.mBVDraLJ042040@freefall.freebsd.org> Message-ID: Adding a bit more info.. Here's the netstat -m and vmstat -z output after the mbufs have had a while to build up: -- netstat -m -- 959510/235/959745 mbufs in use (current/cache/total) 257/133/390/25600 mbuf clusters in use (current/cache/total/max) 257/127 mbuf+clusters out of packet secondary zone in use (current/cache) 0/117/117/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 240391K/792K/241184K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/152/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2716 requests for I/O initiated by sendfile 0 calls to protocol drain routines -- vmstat -z -- ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 99, 21, 99, 0 UMA Zones: 120, 0, 99, 21, 99, 0 UMA Slabs: 64, 0, 1132, 48, 15590, 0 UMA RCntSlabs: 104, 0, 312, 21, 856, 0 UMA Hash: 128, 0, 4, 26, 7, 0 16 Bucket: 76, 0, 21, 29, 64, 0 32 Bucket: 140, 0, 32, 24, 107, 0 64 Bucket: 268, 0, 34, 8, 142, 0 128 Bucket: 524, 0, 628, 9, 45698, 5387 VM OBJECT: 124, 0, 9136, 32404, 20553589, 0 MAP: 140, 0, 7, 49, 7, 0 KMAP ENTRY: 68, 56560, 17, 487, 153898, 0 MAP ENTRY: 68, 0, 15360, 2336, 53481139, 0 DP fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 72, 0, 194, 71, 194, 0 16: 16, 0, 1996, 643, 81641919, 0 32: 32, 0, 2542, 283, 9470304, 0 64: 64, 0, 4584, 7039, 61275174, 0 128: 128, 0, 1101, 549, 6280868, 0 256: 256, 0, 1299, 366, 20697494, 0 512: 512, 0, 145, 279, 79529, 0 1024: 1024, 0, 173, 71, 532899, 0 2048: 2048, 0, 104, 146, 14198, 0 4096: 4096, 0, 266, 63, 1242097, 0 Files: 76, 0, 1595, 655, 16940144, 0 TURNSTILE: 76, 0, 295, 41, 295, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 696, 0, 229, 46, 541535, 0 THREAD: 552, 0, 283, 11, 952, 0 UPCALL: 44, 0, 0, 0, 0, 0 SLEEPQUEUE: 32, 0, 295, 157, 295, 0 VMSPACE: 232, 0, 196, 59, 541501, 0 cpuset: 40, 0, 2, 182, 2, 0 mbuf_packet: 256, 0, 258, 126, 20757971, 0 mbuf: 256, 0, 960618, 33, 116817015, 0 mbuf_cluster: 2048, 25600, 384, 6, 384, 0 mbuf_jumbo_pagesize: 4096, 12800, 0, 117, 19593255, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 406, 26807, 0 ACL UMA zone: 388, 0, 0, 20, 65073710, 0 g_bio: 132, 0, 12, 423, 10043465, 0 ata_request: 192, 0, 3, 337, 3212743, 0 ata_composite: 184, 0, 0, 0, 0, 0 cryptop: 60, 0, 0, 0, 0, 0 cryptodesc: 56, 0, 0, 0, 0, 0 VNODE: 276, 0, 19330, 33618, 3235279, 0 VNODEPOLL: 64, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 28, 38128632, 0 S VFS Cache: 68, 0, 20134, 23490, 10825579, 0 L VFS Cache: 291, 0, 27, 207, 175327, 0 NFSMOUNT: 560, 0, 0, 0, 0, 0 NFSNODE: 452, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 1946, 170, 28110, 0 pipe: 396, 0, 89, 31, 229902, 0 ksiginfo: 80, 0, 248, 40, 248, 0 itimer: 220, 0, 0, 36, 1, 0 KNOTE: 68, 0, 175, 217, 2157098, 0 socket: 416, 25605, 404, 127, 3609347, 0 unpcb: 168, 25622, 278, 136, 1352116, 0 ipq: 32, 904, 0, 226, 42, 0 udpcb: 180, 25608, 13, 75, 1774380, 0 inpcb: 180, 25608, 155, 197, 482839, 0 tcpcb: 464, 25600, 92, 60, 482839, 0 tcptw: 52, 5184, 63, 297, 96034, 0 syncache: 104, 15392, 9, 102, 474336, 0 hostcache: 76, 15400, 626, 124, 4537, 0 tcpreass: 20, 1690, 0, 169, 92838, 0 sackhole: 20, 0, 0, 169, 7789, 0 sctp_ep: 804, 25600, 0, 0, 0, 0 sctp_asoc: 1412, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 145, 28, 0 sctp_raddr: 400, 80000, 0, 0, 0, 0 sctp_chunk: 92, 400008, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 60, 400050, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 180, 25608, 1, 43, 2, 0 rtentry: 124, 0, 78, 46, 3549, 0 SWAPMETA: 276, 121576, 158, 108, 19610, 0 Mountpoints: 716, 0, 6, 4, 6, 0 FFS inode: 128, 0, 19299, 19191, 3235170, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 19299, 16011, 3235170, 0 pfsrctrpl: 124, 10013, 0, 0, 0, 0 pfrulepl: 828, 0, 12, 8, 12, 0 pfstatepl: 284, 10010, 0, 0, 0, 0 pfaltqpl: 224, 0, 0, 0, 0, 0 pfpooladdrpl: 68, 0, 6, 106, 6, 0 pfrktable: 1240, 1002, 1, 5, 2, 0 pfrkentry: 156, 200000, 3, 47, 3, 0 pfrkentry2: 156, 0, 0, 0, 0, 0 pffrent: 16, 5075, 0, 0, 0, 0 pffrag: 48, 0, 0, 0, 0, 0 pffrcache: 48, 10062, 0, 0, 0, 0 pffrcent: 12, 50141, 0, 0, 0, 0 pfstatescrub: 28, 0, 0, 0, 0, 0 pfiaddrpl: 100, 0, 0, 0, 0, 0 pfospfen: 108, 0, 696, 24, 696, 0 pfosfp: 28, 0, 407, 228, 407, 0 From jd at ods.org Fri Jan 2 21:30:11 2009 From: jd at ods.org (Jason DiCioccio) Date: Fri Jan 2 21:30:23 2009 Subject: kern/130059: [panic] Leaking 50k mbufs/hour Message-ID: <200901022130.n02LUB9x010187@freefall.freebsd.org> The following reply was made to PR kern/130059; it has been noted by GNATS. From: "Jason DiCioccio" To: bug-followup@freebsd.org Cc: Subject: Re: kern/130059: [panic] Leaking 50k mbufs/hour Date: Fri, 2 Jan 2009 13:02:47 -0800 ------=_Part_175155_3729370.1230930167365 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adding a bit more info.. Here's the netstat -m and vmstat -z output after the mbufs have had a while to build up: -- netstat -m -- 959510/235/959745 mbufs in use (current/cache/total) 257/133/390/25600 mbuf clusters in use (current/cache/total/max) 257/127 mbuf+clusters out of packet secondary zone in use (current/cache) 0/117/117/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 240391K/792K/241184K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/152/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2716 requests for I/O initiated by sendfile 0 calls to protocol drain routines -- vmstat -z -- ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 99, 21, 99, 0 UMA Zones: 120, 0, 99, 21, 99, 0 UMA Slabs: 64, 0, 1132, 48, 15590, 0 UMA RCntSlabs: 104, 0, 312, 21, 856, 0 UMA Hash: 128, 0, 4, 26, 7, 0 16 Bucket: 76, 0, 21, 29, 64, 0 32 Bucket: 140, 0, 32, 24, 107, 0 64 Bucket: 268, 0, 34, 8, 142, 0 128 Bucket: 524, 0, 628, 9, 45698, 5387 VM OBJECT: 124, 0, 9136, 32404, 20553589, 0 MAP: 140, 0, 7, 49, 7, 0 KMAP ENTRY: 68, 56560, 17, 487, 153898, 0 MAP ENTRY: 68, 0, 15360, 2336, 53481139, 0 DP fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 72, 0, 194, 71, 194, 0 16: 16, 0, 1996, 643, 81641919, 0 32: 32, 0, 2542, 283, 9470304, 0 64: 64, 0, 4584, 7039, 61275174, 0 128: 128, 0, 1101, 549, 6280868, 0 256: 256, 0, 1299, 366, 20697494, 0 512: 512, 0, 145, 279, 79529, 0 1024: 1024, 0, 173, 71, 532899, 0 2048: 2048, 0, 104, 146, 14198, 0 4096: 4096, 0, 266, 63, 1242097, 0 Files: 76, 0, 1595, 655, 16940144, 0 TURNSTILE: 76, 0, 295, 41, 295, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 696, 0, 229, 46, 541535, 0 THREAD: 552, 0, 283, 11, 952, 0 UPCALL: 44, 0, 0, 0, 0, 0 SLEEPQUEUE: 32, 0, 295, 157, 295, 0 VMSPACE: 232, 0, 196, 59, 541501, 0 cpuset: 40, 0, 2, 182, 2, 0 mbuf_packet: 256, 0, 258, 126, 20757971, 0 mbuf: 256, 0, 960618, 33, 116817015, 0 mbuf_cluster: 2048, 25600, 384, 6, 384, 0 mbuf_jumbo_pagesize: 4096, 12800, 0, 117, 19593255, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 406, 26807, 0 ACL UMA zone: 388, 0, 0, 20, 65073710, 0 g_bio: 132, 0, 12, 423, 10043465, 0 ata_request: 192, 0, 3, 337, 3212743, 0 ata_composite: 184, 0, 0, 0, 0, 0 cryptop: 60, 0, 0, 0, 0, 0 cryptodesc: 56, 0, 0, 0, 0, 0 VNODE: 276, 0, 19330, 33618, 3235279, 0 VNODEPOLL: 64, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 28, 38128632, 0 S VFS Cache: 68, 0, 20134, 23490, 10825579, 0 L VFS Cache: 291, 0, 27, 207, 175327, 0 NFSMOUNT: 560, 0, 0, 0, 0, 0 NFSNODE: 452, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 1946, 170, 28110, 0 pipe: 396, 0, 89, 31, 229902, 0 ksiginfo: 80, 0, 248, 40, 248, 0 itimer: 220, 0, 0, 36, 1, 0 KNOTE: 68, 0, 175, 217, 2157098, 0 socket: 416, 25605, 404, 127, 3609347, 0 unpcb: 168, 25622, 278, 136, 1352116, 0 ipq: 32, 904, 0, 226, 42, 0 udpcb: 180, 25608, 13, 75, 1774380, 0 inpcb: 180, 25608, 155, 197, 482839, 0 tcpcb: 464, 25600, 92, 60, 482839, 0 tcptw: 52, 5184, 63, 297, 96034, 0 syncache: 104, 15392, 9, 102, 474336, 0 hostcache: 76, 15400, 626, 124, 4537, 0 tcpreass: 20, 1690, 0, 169, 92838, 0 sackhole: 20, 0, 0, 169, 7789, 0 sctp_ep: 804, 25600, 0, 0, 0, 0 sctp_asoc: 1412, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 145, 28, 0 sctp_raddr: 400, 80000, 0, 0, 0, 0 sctp_chunk: 92, 400008, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 60, 400050, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 180, 25608, 1, 43, 2, 0 rtentry: 124, 0, 78, 46, 3549, 0 SWAPMETA: 276, 121576, 158, 108, 19610, 0 Mountpoints: 716, 0, 6, 4, 6, 0 FFS inode: 128, 0, 19299, 19191, 3235170, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 19299, 16011, 3235170, 0 pfsrctrpl: 124, 10013, 0, 0, 0, 0 pfrulepl: 828, 0, 12, 8, 12, 0 pfstatepl: 284, 10010, 0, 0, 0, 0 pfaltqpl: 224, 0, 0, 0, 0, 0 pfpooladdrpl: 68, 0, 6, 106, 6, 0 pfrktable: 1240, 1002, 1, 5, 2, 0 pfrkentry: 156, 200000, 3, 47, 3, 0 pfrkentry2: 156, 0, 0, 0, 0, 0 pffrent: 16, 5075, 0, 0, 0, 0 pffrag: 48, 0, 0, 0, 0, 0 pffrcache: 48, 10062, 0, 0, 0, 0 pffrcent: 12, 50141, 0, 0, 0, 0 pfstatescrub: 28, 0, 0, 0, 0, 0 pfiaddrpl: 100, 0, 0, 0, 0, 0 pfospfen: 108, 0, 696, 24, 696, 0 pfosfp: 28, 0, 407, 228, 407, 0 ------=_Part_175155_3729370.1230930167365 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Adding a bit more info..  Here's the netstat -m and vmstat -z output after the mbufs have had a while to build up:

-- netstat -m --
959510/235/959745 mbufs in use (current/cache/total)
257/133/390/25600 mbuf clusters in use (current/cache/total/max)
257/127 mbuf+clusters out of packet secondary zone in use (current/cache)
0/117/117/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
240391K/792K/241184K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/152/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
2716 requests for I/O initiated by sendfile
0 calls to protocol drain routines

-- vmstat -z --

ITEM                     SIZE     LIMIT      USED      FREE  REQUESTS  FAILURES

UMA Kegs:                 128,        0,       99,       21,       99,        0
UMA Zones:                120,        0,       99,       21,       99,        0
UMA Slabs:               & nbsp; 64,        0,     1132,       48,    15590,        0
UMA RCntSlabs:            104,        0,      312,       21,      856,        0
UMA Hash:                 128,        0,        4,       26,        7,        0
16 Bucket:                 76,   ;      0,       21,       29,       64,        0
32 Bucket:                140,        0,       32,       24,      107,        0
64 Bucket:                268,        0,       34,        8,      142,        0
128 Bucket:               524,   ;      0,      628,        9,    45698,     5387
VM OBJECT:                124,        0,     9136,    32404, 20553589,        0
MAP:                      140,        0,        7,       49,        7,        0
KMAP ENTRY:                68,   ;  56560,       17,      487,   153898,        0
MAP ENTRY:                 68,        0,    15360,     2336, 53481139,        0
DP fakepg:                 72,        0,        0,        0,        0,        0
mt_zone:                   72,   &nb sp;    0,      194,       71,      194,        0
16:                        16,        0,     1996,      643, 81641919,        0
32:                        32,        0,     2542,      283,  9470304,        0
64:                   &nbs p;    64,        0,     4584,     7039, 61275174,        0
128:                      128,        0,     1101,      549,  6280868,        0
256:                      256,        0,     1299,      366, 20697494,        0
512:                       512,        0,      145,      279,    79529,        0
1024:                    1024,        0,      173,       71,   532899,        0
2048:                    2048,        0,      104,      146,    14198,        0
4096:                   &n bsp;4096,        0,      266,       63,  1242097,        0
Files:                     76,        0,     1595,      655, 16940144,        0
TURNSTILE:                 76,        0,      295,       41,      295,        0
umtx pi:                   52,   &nb sp;    0,        0,        0,        0,        0
PROC:                     696,        0,      229,       46,   541535,        0
THREAD:                   552,        0,      283,       11,      952,        0
UPCALL:                    44,        0,        0,        0,        0,        0
SLEEPQUEUE:                32,        0,      295,      157,      295,        0
VMSPACE:                  232,        0,      196,       59,   541501,        0
cpuset:                    40,        0,        2,      182,        2,        0
mbuf_packet:              256,        0,      258,      126, 20757971,        0
mbuf:                     256,        0,   960618,       33, 116817015,        0
mbuf_cluster:            2048,    25600,      384, &nbs p;      6,      384,        0
mbuf_jumbo_pagesize:     4096,    12800,        0,      117, 19593255,        0
mbuf_jumbo_9k:           9216,     6400,        0,        0,        0,        0
mbuf_jumbo_16k:         16384,     3200,        0,        0,   ;      0,        0
mbuf_ext_refcnt:            4,        0,        0,      406,    26807,        0
ACL UMA zone:             388,        0,        0,       20, 65073710,        0
g_bio:                    132,       &nbs p;0,       12,      423, 10043465,        0
ata_request:              192,        0,        3,      337,  3212743,        0
ata_composite:            184,        0,        0,        0,        0,        0
cryptop:                   60,   ;      0,        0,        0,        0,        0
cryptodesc:                56,        0,        0,        0,        0,        0
VNODE:                    276,        0,    19330,    33618,  3235279,        0
VNODEPOLL:                 64,        0,        0,        0,        0,        0
NAMEI:                   1024,        0,        0,       28, 38128632,        0
S VFS Cache:               68,        0,    20134,    23490, 10825579,        0
L VFS Cache:              291,        0,     & nbsp; 27,      207,   175327,        0
NFSMOUNT:                 560,        0,        0,        0,        0,        0
NFSNODE:                  452,        0,        0,        0,        0,        0
DIRHASH:         &nbs p;       1024,        0,     1946,      170,    28110,        0
pipe:                     396,        0,       89,       31,   229902,        0
ksiginfo:                  80,        0,      248,       40,      248,        0
itimer:                   220,        0,        0,       36,        1,        0
KNOTE:                     68,        0,      175,      217,  2157098,        0
socket:                   416,    25605,      404,      127,  3609347,        0
unpcb:                    168,   &nb sp;25622,      278,      136,  1352116,        0
ipq:                       32,      904,        0,      226,       42,        0
udpcb:                    180,    25608,       13,       75,  1774380,        0
inpcb:                   & nbsp;180,    25608,      155,      197,   482839,        0
tcpcb:                    464,    25600,       92,       60,   482839,        0
tcptw:                     52,     5184,       63,      297,    96034,        0
syncache:                 104,    15392,        9,      102,   474336,        0
hostcache:                 76,    15400,      626,      124,     4537,        0
tcpreass:                  20,     1690,        0,      169,    92838,        0
sackhole:                  20,        0,        0,      169,     7789,        0
sctp_ep:                  804,    25600,        0,        0,        0,        0
sctp_asoc:               1412,    40000,        0,        0,        0,        0
sctp_laddr:                 ;24,    80040,        0,      145,       28,        0
sctp_raddr:               400,    80000,        0,        0,        0,        0
sctp_chunk:                92,   400008,        0,        0,        0,        0
sctp_readq:                76,   ; 400000,        0,        0,        0,        0
sctp_stream_msg_out:       60,   400050,        0,        0,        0,        0
sctp_asconf:               24,   400055,        0,        0,        0,        0
sctp_asconf_ack:           24,   400055,        0,   ;      0,        0,        0
ripcb:                    180,    25608,        1,       43,        2,        0
rtentry:                  124,        0,       78,       46,     3549,        0
SWAPMETA:                 276,   121576,      158,      108,    19610,        0
Mountpoints:              716,        0,        6,        4,        6,        0
FFS inode:                128,        0,    19299,    19191,  3235170,        0
FFS1 dinode:              128,        0,        0,        0,        0,        0
FFS2 dinode:              256,        0,    19299,    16011,  3235170,        0
pfsrctrpl:                124,    10013,        0,        0,        0,        0
pfrulepl:                 828,       &nbs p;0,       12,        8,       12,        0
pfstatepl:                284,    10010,        0,        0,        0,        0
pfaltqpl:                 224,        0,        0,        0,        0,        0
pfpooladdrpl:              68,        0,        6,      106,        6,        0
pfrktable:               1240,     1002,        1,        5,        2,        0
pfrkentry:                156,   200000,        3,       47,        3,        0
pfrkentry2:               156,     & nbsp;  0,        0,        0,        0,        0
pffrent:                   16,     5075,        0,        0,        0,        0
pffrag:                    48,        0,        0,        0,        0,        0
pffrcache:         &n bsp;       48,    10062,        0,        0,        0,        0
pffrcent:                  12,    50141,        0,        0,        0,        0
pfstatescrub:              28,        0,        0,        0,        0,        0
pfiaddrpl:             &nb sp;  100,        0,        0,        0,        0,        0
pfospfen:                 108,        0,      696,       24,      696,        0
pfosfp:                    28,        0,      407,      228,      407,        0



------=_Part_175155_3729370.1230930167365-- From qing.li at bluecoat.com Fri Jan 2 22:15:08 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Jan 2 22:15:14 2009 Subject: SCTP related issue with recent ARP changes? In-Reply-To: References: Message-ID: Hi Michael, The SCTP problem you were having was attributed to the arp-v2 changes. The reason TCP and UDP works well is because the TCP and UDP modules does not supply a route entry when calling ip_output(). Consequently in ip_output() the destination (sockaddr) was reinitialized and the sin_port field is 0. The destination sockaddr supplied in the route entry from the SCTP module has the actual port value in it. The new L2 search was (initially) written as a generic function. So the L3 address comparison was performed using bcmp() of sockaddr_len bytes. The L2 entry was created with a sockaddr object that includes the port value, however, on ARP input the port value does not apply. The mismatch in port value causes the ARP lookup to fail and the SCTP connection never complete its negotiation. Please apply the patch for IPv4 in my home directory at http://people.freebsd.org/~qingli/in.c.diff I did the basic testing using the programs you gave me and now the client connects successful and completes the transfer. I also verified the packets in wireshark trace. Please let me know if this patch fixes your SCTP problems. Thank you for your help. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Li, Qing > Sent: Thursday, January 01, 2009 12:17 PM > To: Michael T?xen; FreeBSD Net > Cc: qingli@freebsd.org; current@freebsd.org > Subject: RE: SCTP related issue with recent ARP changes? > > > Hi Michael, > > Your problem could be related to the recent ARP changes. > I will investigate further to confirm. > > Thanks, > > -- Qing > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Michael T?xen > Sent: Thu 1/1/2009 8:59 AM > To: FreeBSD Net > Subject: SCTP related issue with recent ARP changes? > > Dear all, > > I'm running the current CVS version of FreeBSD 8 in a virtual > machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) > and bridged networking having an em interface on the virtual machine. > I'm using a similar setup with older FreeBSD machines and they are > running fine. > > Loopback communication based on UDP, TCP, SCTP or ICMP works fine. > > Communicating with other hosts using UDP, TCP or ICMP works fine. > > Communicating with other hosts using SCTP does not work. > The SCTP stack calls ip_output() and an ARP request for the > correct destination IP address is send out. A corresponding > ARP reply is visible in Wireshark (running on the FreeBSD 8 box) > and looks good. However, the corresponding SCTP packet it never > sent out. I'm not sure, but this might be related to the > recent ARP changes. Is there anything required from the > transport layer to be done when calling ip_output() that > was not required before? > > Best regards > Michael > From Michael.Tuexen at lurchi.franken.de Fri Jan 2 23:20:18 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Jan 2 23:20:56 2009 Subject: SCTP related issue with recent ARP changes? In-Reply-To: References: Message-ID: Hi Qing, I have tested your patch and it works! Thanks you very much for your help. Best regards Michael On Jan 2, 2009, at 11:15 PM, Li, Qing wrote: > Hi Michael, > > The SCTP problem you were having was attributed to the arp-v2 changes. > The reason TCP and UDP works well is because the TCP and UDP > modules does not supply a route entry when calling ip_output(). > Consequently in ip_output() the destination (sockaddr) was > reinitialized > and the sin_port field is 0. > > The destination sockaddr supplied in the route entry from the SCTP > module has the actual port value in it. > > The new L2 search was (initially) written as a generic function. > So the L3 address comparison was performed using bcmp() of > sockaddr_len > bytes. The L2 entry was created with a sockaddr object that includes > the port value, however, on ARP input the port value does not > apply. The mismatch in port value causes the ARP lookup to fail > and the SCTP connection never complete its negotiation. > > Please apply the patch for IPv4 in my home directory at > http://people.freebsd.org/~qingli/in.c.diff > > I did the basic testing using the programs you gave me and now > the client connects successful and completes the transfer. I also > verified the packets in wireshark trace. > > Please let me know if this patch fixes your SCTP problems. > > Thank you for your help. > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Li, Qing >> Sent: Thursday, January 01, 2009 12:17 PM >> To: Michael T?xen; FreeBSD Net >> Cc: qingli@freebsd.org; current@freebsd.org >> Subject: RE: SCTP related issue with recent ARP changes? >> >> >> Hi Michael, >> >> Your problem could be related to the recent ARP changes. >> I will investigate further to confirm. >> >> Thanks, >> >> -- Qing >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Michael T?xen >> Sent: Thu 1/1/2009 8:59 AM >> To: FreeBSD Net >> Subject: SCTP related issue with recent ARP changes? >> >> Dear all, >> >> I'm running the current CVS version of FreeBSD 8 in a virtual >> machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) >> and bridged networking having an em interface on the virtual machine. >> I'm using a similar setup with older FreeBSD machines and they are >> running fine. >> >> Loopback communication based on UDP, TCP, SCTP or ICMP works fine. >> >> Communicating with other hosts using UDP, TCP or ICMP works fine. >> >> Communicating with other hosts using SCTP does not work. >> The SCTP stack calls ip_output() and an ARP request for the >> correct destination IP address is send out. A corresponding >> ARP reply is visible in Wireshark (running on the FreeBSD 8 box) >> and looks good. However, the corresponding SCTP packet it never >> sent out. I'm not sure, but this might be related to the >> recent ARP changes. Is there anything required from the >> transport layer to be done when calling ip_output() that >> was not required before? >> >> Best regards >> Michael >> > > > From yanefbsd at gmail.com Fri Jan 2 23:27:12 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 2 23:27:44 2009 Subject: Annoyance with msk(4) going up and down when initializing interface In-Reply-To: <20081224021016.GF95088@cdnetworks.co.kr> References: <20081224021016.GF95088@cdnetworks.co.kr> Message-ID: Hi Pyun, I've noticed an issue for a while now with my chipset (I think that this is post an MFC between 7.0 and 7.1, but I could be wrong). Basically, each CPU (with the ULE scheduler) grabs the task to check for media status, goes out and attempts to get an IP, and if the timing of the status modifications is just right, one of the CPU's will mark the link up and others will mark it down, and it will stay down. Same thing occurs when trying to get a DHCP request -- there will typically be multiple requests and ACK's for any given requests. This occurs with my onboard NICs on my P5K-e motherboards on 7.1- rc[12], and also 8-CURRENT. Thanks! -Garrett From perryh at pluto.rain.com Sat Jan 3 04:08:57 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 3 04:09:04 2009 Subject: tun0 not responding to ping Message-ID: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> Why would a local interface, reported as up in ifconfig, not respond to a ping of its own IP address? The tun0 reported below doesn't, and I have no idea how to debug it. (I've overwritten the two most- significant octets of its IP address, which is Class B, so as not to publicly identify the network to which I am attempting to connect.) $ ifconfig -a xl0: flags=8843 mtu 1500 options=9 inet6 fe80::2b0:d0ff:fe28:ad4f%xl0 prefixlen 64 scopeid 0x1 inet 192.168.200.61 netmask 0xffffff00 broadcast 192.168.200.255 ether 00:b0:d0:28:ad:4f media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 mtu 1412 inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff Opened by PID 24635 $ ping ZZZ.ZZZ.233.42 PING ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42): 56 data bytes ^C --- ZZZ.ZZZ.233.42 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss $ traceroute -n ZZZ.ZZZ.233.42 traceroute to ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42), 64 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * ^C $ netstat -r -n Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.200.254 UGS 0 2209723 xl0 127.0.0.1 127.0.0.1 UH 0 2 lo0 ZZZ.ZZZ ZZZ.ZZZ.233.42 UGS 0 0 tun0 ZZZ.ZZZ.57.128/32 ZZZ.ZZZ.233.42 UGS 0 19 tun0 ZZZ.ZZZ.57.133/32 ZZZ.ZZZ.233.42 UGS 0 18 tun0 ZZZ.ZZZ.233.42 ZZZ.ZZZ.233.42 UH 59 20 tun0 YYY.YYY.127/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 YYY.YYY.127.96/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 YYY.YYY.127.224/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 YYY.YYY.127.228 192.168.200.254 UGHS 0 106 xl0 192.168.200 link#1 UC 0 0 xl0 192.168.200.254 00:09:5b:a1:c8:9e UHLW 3 4318078 xl0 1148 192.168.200.255 ff:ff:ff:ff:ff:ff UHLWb 1 3 xl0 In case it matters the tunnel was set up by the security/vpnc port, however my focus in this inquiry is on the expected behavior of the tun(4) driver, which is part of the base and therefore (I hope) on-topic here. Inquiries regarding vpnc on ports@ and questions@ have not yielded a solution. For background, the network geometry involved is: 192.168.200.0/8 +---------------------+---------------------+ | | | 192.168.200.254 192.168.200.95 192.168.200.61[xl0] +-----------------+ +-----------------+ +-----------------+ | Netgear router | | Windows | | FreeBSD | | | | Cisco VPN client| | vpnc | +-----------------+ +-----------------+ +-----------------+ 71.111.59.66 ZZZ.ZZZ.233.6 ZZZ.ZZZ.233.42[tun0] | | | +-----------------+ | DSL modem | | | +-----------------+ [works] [does not work] | | | -- Internet -- | | | YYY.YYY.127.228 +-----------------+ | | | Cisco 3000 | < - - - - - - - - - - - - - - - -+ +-----------------+ ZZZ.ZZZ.2.13 | ZZZ.ZZZ.0.0/16 +---------------------+---------------------+ (and no, I am not trying to have both the Windows client and the FreeBSD client connected at the same time, although that ought to work -- the Cisco will supposedly allow up to 4 concurrent connections from the same LAN using the same credentials). I think the tunnel's data flow should be something like: +---------------+---------------+ | application (ping, ssh, etc.) | | to (say) ZZZ.ZZZ.11.220 | +---------------+---------------+ ^ [socket] v +----------+----------+ | kernel TCP/IP stack | +----------+----------+ ^ [routing] v +--------+--------+ | tun0 interface | <-- ping packets to ZZZ.ZZZ.233.42 looped | ZZZ.ZZZ.233.42 | <-- back here, all else passed to vpnc +--------+--------+ ^ | v +--------------+--------------+ | userspace vpnc daemon | | [encapsulation/encryption] | | to YYY.YYY.127.228 | +--------------+--------------+ ^ [socket] v +----------+----------+ | kernel TCP/IP stack | +----------+----------+ ^ [routing] v +-------+-------+ | xl0 interface | | 192.168.200.61| +-------+-------+ ^ 192.168.200.0/8 v +--------+--------+ | 192.168.200.254 | | Netgear router | | 71.111.59.66 | +--------+--------+ ^ DSL/Internet v +--------------+--------------+ | YYY.YYY.127.228 | | Cisco 3000 | | [decapsulation/decryption] | | ZZZ.ZZZ.2.13 | +--------------+--------------+ ^ ZZZ.ZZZ.0.0/16 v ZZZ.ZZZ.11.220 From smithi at nimnet.asn.au Sat Jan 3 04:55:46 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jan 3 04:56:26 2009 Subject: tun0 not responding to ping In-Reply-To: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> Message-ID: <20090103154232.P28770@sola.nimnet.asn.au> On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > Why would a local interface, reported as up in ifconfig, not respond > to a ping of its own IP address? The tun0 reported below doesn't, > and I have no idea how to debug it. (I've overwritten the two most- > significant octets of its IP address, which is Class B, so as not to > publicly identify the network to which I am attempting to connect.) > > $ ifconfig -a > xl0: flags=8843 mtu 1500 > options=9 > inet6 fe80::2b0:d0ff:fe28:ad4f%xl0 prefixlen 64 scopeid 0x1 > inet 192.168.200.61 netmask 0xffffff00 broadcast 192.168.200.255 > ether 00:b0:d0:28:ad:4f > media: Ethernet autoselect (10baseT/UTP) > status: active > plip0: flags=108810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > tun0: flags=8051 mtu 1412 > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > Opened by PID 24635 I don't know if this is relevant or not, but I've never seen a point to point interface use the same IP address on both ends of its link before. I noticed this before when you posed this on questions@ but not knowing anything about vpnc and very little about VPNs in general, I let it go. > $ ping ZZZ.ZZZ.233.42 > PING ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42): 56 data bytes > ^C > --- ZZZ.ZZZ.233.42 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > > $ traceroute -n ZZZ.ZZZ.233.42 > traceroute to ZZZ.ZZZ.233.42 (ZZZ.ZZZ.233.42), 64 hops max, 40 byte packets > 1 * * * > 2 * * * > 3 * * * > 4 * * * > 5 * * * > ^C > > $ netstat -r -n > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.200.254 UGS 0 2209723 xl0 > 127.0.0.1 127.0.0.1 UH 0 2 lo0 > ZZZ.ZZZ ZZZ.ZZZ.233.42 UGS 0 0 tun0 > ZZZ.ZZZ.57.128/32 ZZZ.ZZZ.233.42 UGS 0 19 tun0 > ZZZ.ZZZ.57.133/32 ZZZ.ZZZ.233.42 UGS 0 18 tun0 > ZZZ.ZZZ.233.42 ZZZ.ZZZ.233.42 UH 59 20 tun0 There it is again. Looks circular to me, but I may be way off base .. Nice diagrams :) cheers, Ian > YYY.YYY.127/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 > YYY.YYY.127.96/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 > YYY.YYY.127.224/27 ZZZ.ZZZ.233.42 UGS 0 0 tun0 > YYY.YYY.127.228 192.168.200.254 UGHS 0 106 xl0 > 192.168.200 link#1 UC 0 0 xl0 > 192.168.200.254 00:09:5b:a1:c8:9e UHLW 3 4318078 xl0 1148 > 192.168.200.255 ff:ff:ff:ff:ff:ff UHLWb 1 3 xl0 > > In case it matters the tunnel was set up by the security/vpnc port, > however my focus in this inquiry is on the expected behavior of the > tun(4) driver, which is part of the base and therefore (I hope) > on-topic here. Inquiries regarding vpnc on ports@ and questions@ > have not yielded a solution. > > For background, the network geometry involved is: > > 192.168.200.0/8 > +---------------------+---------------------+ > | | | > 192.168.200.254 192.168.200.95 192.168.200.61[xl0] > +-----------------+ +-----------------+ +-----------------+ > | Netgear router | | Windows | | FreeBSD | > | | | Cisco VPN client| | vpnc | > +-----------------+ +-----------------+ +-----------------+ > 71.111.59.66 ZZZ.ZZZ.233.6 ZZZ.ZZZ.233.42[tun0] > | | | > +-----------------+ > | DSL modem | | | > +-----------------+ [works] [does not work] > | | | > -- Internet -- > | | | > YYY.YYY.127.228 > +-----------------+ | | > | Cisco 3000 | < - - - - - - - - - - - - - - - -+ > +-----------------+ > ZZZ.ZZZ.2.13 > | ZZZ.ZZZ.0.0/16 > +---------------------+---------------------+ > > (and no, I am not trying to have both the Windows client and the > FreeBSD client connected at the same time, although that ought > to work -- the Cisco will supposedly allow up to 4 concurrent > connections from the same LAN using the same credentials). > > I think the tunnel's data flow should be something like: > > +---------------+---------------+ > | application (ping, ssh, etc.) | > | to (say) ZZZ.ZZZ.11.220 | > +---------------+---------------+ > ^ > [socket] > v > +----------+----------+ > | kernel TCP/IP stack | > +----------+----------+ > ^ > [routing] > v > +--------+--------+ > | tun0 interface | <-- ping packets to ZZZ.ZZZ.233.42 looped > | ZZZ.ZZZ.233.42 | <-- back here, all else passed to vpnc > +--------+--------+ > ^ > | > v > +--------------+--------------+ > | userspace vpnc daemon | > | [encapsulation/encryption] | > | to YYY.YYY.127.228 | > +--------------+--------------+ > ^ > [socket] > v > +----------+----------+ > | kernel TCP/IP stack | > +----------+----------+ > ^ > [routing] > v > +-------+-------+ > | xl0 interface | > | 192.168.200.61| > +-------+-------+ > ^ > 192.168.200.0/8 > v > +--------+--------+ > | 192.168.200.254 | > | Netgear router | > | 71.111.59.66 | > +--------+--------+ > ^ > DSL/Internet > v > +--------------+--------------+ > | YYY.YYY.127.228 | > | Cisco 3000 | > | [decapsulation/decryption] | > | ZZZ.ZZZ.2.13 | > +--------------+--------------+ > ^ > ZZZ.ZZZ.0.0/16 > v > ZZZ.ZZZ.11.220 From perryh at pluto.rain.com Sat Jan 3 07:37:02 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 3 07:37:08 2009 Subject: tun0 not responding to ping In-Reply-To: <20090103154232.P28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> Message-ID: <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> Ian Smith wrote: ... > > tun0: flags=8051 mtu 1412 > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > Opened by PID 24635 > > I don't know if this is relevant or not, but I've never seen > a point to point interface use the same IP address on both ends > of its link before. I don't know either, nor whether -- and if so how -- it could keep tun0 from responding to a ping of its own IP address. It looks like the same issue described, for a different way of connecting to a Cisco 3000 from FreeBSD, here: http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf If I am understanding the article correctly, the 3000 does something unexpected in the course of setting up the P2P connection. However: * Since the FreeBSD config is completely different, I don't know to what extent the w/a described there would be applicable. * Supposing that tun0 does need to be readdressed as inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get that internal address in the general case. (I got it by running a traceroute from an inside machine to a working VPN-connected Windows system, after not finding anything in the vpnc logs.) * Since vpnc is supposed to have been written specifically to connect with Cisco 3000's and similar, I'd have expected it to somehow take care of the 3000's quirks rather than needing a separate w/a, although I don't know enough about either tun(4) or P2P to understand the details. From smithi at nimnet.asn.au Sat Jan 3 09:02:30 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jan 3 09:02:38 2009 Subject: tun0 not responding to ping In-Reply-To: <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> Message-ID: <20090103185837.K28770@sola.nimnet.asn.au> On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > Ian Smith wrote: uucp .. how quaint :) > ... > > > tun0: flags=8051 mtu 1412 > > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > > Opened by PID 24635 > > > > I don't know if this is relevant or not, but I've never seen > > a point to point interface use the same IP address on both ends > > of its link before. > > I don't know either, nor whether -- and if so how -- it could keep > tun0 from responding to a ping of its own IP address. It looks like > the same issue described, for a different way of connecting to a > Cisco 3000 from FreeBSD, here: > > http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf on this server." Nor http://www.cs.rpi.edu/~flemej .. so I can't consult that, but as I said, I know next to nothing about VPN configuration anyway. > If I am understanding the article correctly, the 3000 does something > unexpected in the course of setting up the P2P connection. However: > > * Since the FreeBSD config is completely different, I don't know > to what extent the w/a described there would be applicable. > > * Supposing that tun0 does need to be readdressed as > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff > > -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on > ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get > that internal address in the general case. (I got it by running > a traceroute from an inside machine to a working VPN-connected > Windows system, after not finding anything in the vpnc logs.) Beyond me .. I don't even know what a w/a is, but I'm pretty sure ppp is going to need a remote address, and a route to it. > * Since vpnc is supposed to have been written specifically to > connect with Cisco 3000's and similar, I'd have expected it to > somehow take care of the 3000's quirks rather than needing a > separate w/a, although I don't know enough about either tun(4) > or P2P to understand the details. Usually you can ping either end; ping is the same as ping localhost, ping is, well, that. With both the same, I'm not too surprised that ppp can't figure out which end you want to talk to? We ran ppp for 10 years on a dialup link but these days for pppoe using mpd, but the routing should come to about the same, given that here it's our default route. ng0: flags=88d1 mtu 1492 inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff Destination Gateway Flags Refs Use Netif Expire default xxx.yyy.1.33 UGS 0 24390 ng0 [..] xxx.yyy.1.33 xxx.yyy.zzz.227 UH 1 0 ng0 xxx.yyy.zzz.227/32 lo0 US 0 2 lo0 This is a 5.5 system, in case different presentation might mislead. HTH, Ian From rwatson at FreeBSD.org Sat Jan 3 11:15:41 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jan 3 11:15:55 2009 Subject: net.inet.udp.blackhole issue In-Reply-To: <000001c96a78$9a5b3c20$220f000a@mtl.com> References: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> <000001c96a78$9a5b3c20$220f000a@mtl.com> Message-ID: On Tue, 30 Dec 2008, Yony Yossef wrote: >>> I'm facing lots of UDP "Connection refused" errors while running >>> multistream iperf test. Analyzing it with wireshark showed several "ICMP >>> Port Unreachable" problems. >>> >>> I've overriden it with "sysctl net.inet.udp.blackhole=1", >> but I'm not >>> sure this is the correct thing to do, I feel like I've sweeped the problem >>> under the carpet. >>> >>> PS - I see similar failures with TCP bidirectional iperf >> test, it can >>> also be overriden by "sysctl net.inet.tcp.blackhole=1". >>> >>> My question is - can it be a NIC problem? If so, how can a driver problem >>> cause an iperf UDP socket to be in a "non listening state"? >> >> This is fairly unlikely to be a NIC problem, although anything is possible >> in software. I'm not familiar with iperf, but generally speaking ICMP port >> unreachable is a result of packets arriving at a closed socket; >> net.inet.udp.blackhole suppresses that ICMP: >> >> if (udp_blackhole) >> goto badheadlocked; >> if (badport_bandlim(BANDLIM_ICMP_UNREACH) < 0) >> goto badheadlocked; >> *ip = save_ip; >> ip->ip_len += iphlen; >> icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); >> >> I think I'd suspect an application bug/feature, in which socket gets closed >> and opened during execution and once in a while a datagram is delivered in >> that window. Perhaps packets are being delivered with a non-trivial delay >> causing them to arrive after the application has timed out waiting for it? > > I'm talking about a simple multistream UDP iperf test. One stream always > works fine. More than one UDP stream has a chance of failing because of this > problem. Wireshark analysis shows no such delay and no packet loss nor > corruption, for what I've seen and understood. On the other hand, same test > on a 1Gig NIC (I'm using a 10Gig) doesn't suffer from this issue without the > blackhole assistance. Hmm. These results are confusing, given the code. Would it be possible for you to provide a packet trace that includes a few UDP packets and the ICMP errors they resulted in? While I can't preclude a network stack bug, related parts of the UDP code are relatively straight forward and well-exercised, which generally suggests an application-layer bug or interaction. If the packets are becoming corrupted during driver processing, then the ICMP rejections should show the packet header the stack saw leading to their rejection. Also, could you provide sockstat output for the application during its run? thanks, Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sat Jan 3 12:33:33 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Sat Jan 3 12:33:39 2009 Subject: kern/117717: [panic] Kernel panic with Bittorrent client. Message-ID: <200901031233.n03CXWAc031830@freefall.freebsd.org> Synopsis: [panic] Kernel panic with Bittorrent client. Responsible-Changed-From-To: rwatson->net Responsible-Changed-By: rwatson Responsible-Changed-When: Sat Jan 3 12:32:27 UTC 2009 Responsible-Changed-Why: Transfer to net@ after changing to suspended -- I've been unable to reproduce this problem and the original reporter confirms that it isn't present in 7.x, likely due to bms's substantial cleanup and rewrite of the multicast code in 7.x. I think we might reasonable close it at this point, but if someone is able to pick this up for 6.x and do the debugging, that would still be useful for 6.x users. http://www.freebsd.org/cgi/query-pr.cgi?pr=117717 From vwe at FreeBSD.org Sat Jan 3 15:02:21 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Jan 3 15:02:28 2009 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server Message-ID: <200901031502.n03F2KbP042269@freefall.freebsd.org> Synopsis: [ppp] [panic] kernel panic with pppoe_server State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Sat Jan 3 15:01:30 UTC 2009 State-Changed-Why: We're sorry to not see any feedback received for quite some time. If you think this is still an issue that should be worked on, please provide the requested information and we'll be happy to re-open this ticket. Thank you for bringing this problem to attention! Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 3 15:01:30 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 From perryh at pluto.rain.com Sat Jan 3 21:14:36 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Jan 3 21:14:47 2009 Subject: tun0 not responding to ping In-Reply-To: <20090103185837.K28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> <20090103185837.K28770@sola.nimnet.asn.au> Message-ID: <495fd4f4.LnYmNJ/Km8Riy79x%perryh@pluto.rain.com> Ian Smith wrote: > On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > > Ian Smith wrote: > > uucp .. how quaint :) Yep, but running over ssh since agora no longer has modems. How's that for a mix of ancient and modern technology? :) > > http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf > > "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf > on this server." Nor http://www.cs.rpi.edu/~flemej .. so I can't > consult that, That's odd. It worked from here as recently as 12/17. The article is FreeBSD interoperability with Cisco VPN Concentrator 3000 series James Flemer jflemer@alum.rpi.edu October 10, 2002 and the relevant excerpt -- after it describes a setup involving netgraph(4) and the mpd port -- is 3.4 Routing Unfortunately, this does not work completely. It successfully establishes the PPTP connection, but cannot send anything over it. The problem is that the PPTP implementation for the concentrator forces its end of the PPP link to have the same IP as the address of its public interface (192.168.0.2 in this network). This causes FreeBSD to have routing problems, because the default gateway becomes 192.168.0.2 (via ng0), but in order to use that tunnel it has to send GRE packets to 192.168.0.2. The solution to this is as follows. Once the PPTP link is up, you need to re-address the ng0 interface and then change your default route. In the example network, you have to execute the following commands (assuming we are assigned 10.0.2.42 for our side of the link): # ifconfig ng0 inet 10.0.2.42 10.0.0.2 netmask 0xffffffff # route delete default # route add default -interface ng0 What I see is a bit different -- both ends get the IP that's supposed to have been assigned to my end, rather than the Cisco end getting the Cisco's public IP -- but perhaps related. > but as I said, I know next to nothing about VPN configuration anyway. I suspect this problem has more to do with PPP, tun(4), and routing than with VPN's as such. vpnc does seem to be establishing the VPN connection. > > * Supposing that tun0 does need to be readdressed as > > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff > > > > -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on > > ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get > > that internal address in the general case. (I got it by running > > a traceroute from an inside machine to a working VPN-connected > > Windows system, after not finding anything in the vpnc logs.) > > Beyond me .. I don't even know what a w/a is, but I'm pretty sure > ppp is going to need a remote address, and a route to it. w/a = workaround. > Usually you can ping either end; ping is the same as ping > localhost That's what I expected. > ping is, well, that. With both the same, I'm not > too surprised that ppp can't figure out which end you want to > talk to? Maybe that's (part of?) the problem, although I would have thought that the local side would immediately respond to its own address, without even checking anything else. > We ran ppp for 10 years on a dialup link but these days for pppoe > using mpd, but the routing should come to about the same, given > that here it's our default route. > > ng0: > flags=88d1 mtu 1492 > inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff Hmm. Maybe tun0 needs NOARP and/or SIMPLEX (but, as with the remote IP address, I'd have expected vpnc to configure the interface as required rather than needing help). > Destination Gateway Flags Refs Use Netif Expire > default xxx.yyy.1.33 UGS 0 24390 ng0 > [..] > xxx.yyy.1.33 xxx.yyy.zzz.227 UH 1 0 ng0 > xxx.yyy.zzz.227/32 lo0 US 0 2 lo0 > > This is a 5.5 system, in case different presentation might mislead. This one is not all that much newer (6.1). One thing I notice, which seems odd, is the route to ng0's local IP address via lo0. Shouldn't the stack be able to communicate directly with a local ng (or tun) interface, just as it does with something like an xl0 (or lo0, for that matter)? From vwe at FreeBSD.org Sun Jan 4 01:30:28 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Jan 4 01:30:34 2009 Subject: kern/80853: [ed] [patch] add support for Compex RL2000/ISA in PnP mode Message-ID: <200901040130.n041UQ35010492@freefall.freebsd.org> Synopsis: [ed] [patch] add support for Compex RL2000/ISA in PnP mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Jan 4 01:29:36 UTC 2009 Responsible-Changed-Why: the patch is still valid, device is still not supported by ed(4) reassign to the net team http://www.freebsd.org/cgi/query-pr.cgi?pr=80853 From vwe at FreeBSD.org Sun Jan 4 01:35:10 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Jan 4 01:35:21 2009 Subject: kern/84202: [ed] [patch] Holtek HT80232 PCI NIC recognition on FreeBSD 5.4-RELEASE Message-ID: <200901040135.n041Z9YS015993@freefall.freebsd.org> Synopsis: [ed] [patch] Holtek HT80232 PCI NIC recognition on FreeBSD 5.4-RELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Jan 4 01:34:48 UTC 2009 Responsible-Changed-Why: the patch is still valid, device is still not supported by ed(4) reassign to the net team http://www.freebsd.org/cgi/query-pr.cgi?pr=84202 From smithi at nimnet.asn.au Sun Jan 4 08:37:42 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Jan 4 08:37:50 2009 Subject: tun0 not responding to ping In-Reply-To: <495fd4f4.LnYmNJ/Km8Riy79x%perryh@pluto.rain.com> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> <20090103185837.K28770@sola.nimnet.asn.au> <495fd4f4.LnYmNJ/Km8Riy79x%perryh@pluto.rain.com> Message-ID: <20090104173927.R28770@sola.nimnet.asn.au> On Sat, 3 Jan 2009, perryh@pluto.rain.com wrote: > Ian Smith wrote: > > On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > > > Ian Smith wrote: > > > > uucp .. how quaint :) > > Yep, but running over ssh since agora no longer has modems. > How's that for a mix of ancient and modern technology? :) I like it .. > > > http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn.pdf > > > > "You don't have permission to access /~flemej/fbsd-cisco-vpn.pdf > > That's odd. It worked from here as recently as 12/17. Thanks for mailing it. It's at http://smithi.id.au/fbsd-cisco-vpn.pdf (100K) for now, if anyone else is interested. > FreeBSD interoperability with Cisco VPN > Concentrator 3000 series > James Flemer > jflemer@alum.rpi.edu > October 10, 2002 > > and the relevant excerpt -- after it describes a setup involving > netgraph(4) and the mpd port -- is > > 3.4 Routing > Unfortunately, this does not work completely. It successfully > establishes the PPTP connection, but cannot send anything over > it. The problem is that the PPTP implementation for the > concentrator forces its end of the PPP link to have the same > IP as the address of its public interface (192.168.0.2 in this > network). This causes FreeBSD to have routing problems, because > the default gateway becomes 192.168.0.2 (via ng0), but in order > to use that tunnel it has to send GRE packets to 192.168.0.2. > > The solution to this is as follows. Once the PPTP link is up, > you need to re-address the ng0 interface and then change your > default route. In the example network, you have to execute the > following commands (assuming we are assigned 10.0.2.42 for our > side of the link): > > # ifconfig ng0 inet 10.0.2.42 10.0.0.2 netmask 0xffffffff > # route delete default > # route add default -interface ng0 > > What I see is a bit different -- both ends get the IP that's > supposed to have been assigned to my end, rather than the Cisco > end getting the Cisco's public IP -- but perhaps related. Had a quick look at http://www.unix-ag.uni-kl.de/~massar/vpnc/ but don't get whether it, or you, are configuring ppp? ie, does vpnc make or mess with /etc/ppp/ppp.conf? Or otherwise invoke ppp directly itself? You can do pretty much like the above by invoking an /etc/ppp/ppp.linkup script. Here you're not using the tunnel as your default route anyway, but you could perhaps fix the addressing with ifconfig, though a quick refresher skim through ppp(8) shows a way/s to force the remote ppp to supply its IP address if it's otherwise recalcitrant. Or if you know it, you can force it by an appropriate 'set if_addr' address/mask. Have you considered using mpd for this instead? It comes with PPTP example configs, and while some syntax has changed from then (2002, maybe mpd 3) to now (mpd 5 .. I'm still using 4.1) it might be more straightforward to setup, and mav@ is around here and ever helpful .. > > but as I said, I know next to nothing about VPN configuration anyway. > > I suspect this problem has more to do with PPP, tun(4), and routing > than with VPN's as such. vpnc does seem to be establishing the VPN > connection. > > > > * Supposing that tun0 does need to be readdressed as > > > > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.2.13 netmask 0xffffffff > > > > > > -- where ZZZ.ZZZ.2.13 is the address of the Cisco box on > > > ZZZ.ZZZ.0.0/16 -- I'm not at all clear on how a w/a should get > > > that internal address in the general case. (I got it by running > > > a traceroute from an inside machine to a working VPN-connected > > > Windows system, after not finding anything in the vpnc logs.) Have another dig through CONTROLLING IP ADDRESS in ppp(8) (set if_addr), which appears to include a case where remote is reluctant to supply its address. And then, it may not matter - as long as it's not the same as your end - if you're using 'route add -interface ppp0' but that's really in the realm of guesswork, treat with due suspicion .. > w/a = workaround. Ah! > > Usually you can ping either end; ping is the same as ping > > localhost > > That's what I expected. > > > ping is, well, that. With both the same, I'm not > > too surprised that ppp can't figure out which end you want to > > talk to? > > Maybe that's (part of?) the problem, although I would have thought > that the local side would immediately respond to its own address, > without even checking anything else. I don't know whether it would even get to ppp, past the routing; point to point without two points being a bit, er, pointless :) Also, any routes you add via that link specify the far (not near) end as gateway, with then a single host route for the far end via the near, as below. > > We ran ppp for 10 years on a dialup link but these days for pppoe > > using mpd, but the routing should come to about the same, given > > that here it's our default route. > > > > ng0: > > flags=88d1 mtu 1492 > > inet xxx.yyy.zzz.227 --> xxx.yyy.1.33 netmask 0xffffffff > > Hmm. Maybe tun0 needs NOARP and/or SIMPLEX (but, as with the remote > IP address, I'd have expected vpnc to configure the interface as > required rather than needing help). I've not seen ppp use those options, just mpd, but I dunno. Seems vpnc is generating your ppp.conf? I've no idea what it's doing here, sorry, nor whether such a VPN requires proxy ARP to work. If so, ppp can do. > > Destination Gateway Flags Refs Use Netif Expire > > default xxx.yyy.1.33 UGS 0 24390 ng0 > > [..] > > xxx.yyy.1.33 xxx.yyy.zzz.227 UH 1 0 ng0 > > xxx.yyy.zzz.227/32 lo0 US 0 2 lo0 > > > > This is a 5.5 system, in case different presentation might mislead. > > This one is not all that much newer (6.1). One thing I notice, > which seems odd, is the route to ng0's local IP address via lo0. > Shouldn't the stack be able to communicate directly with a local > ng (or tun) interface, just as it does with something like an xl0 > (or lo0, for that matter)? I wondered about that too, but that it works fine has been good enough. Perhaps it has something to do with the fact that ng0 is really working over another physical ethernet interface? (here, xe0 to an ADSL bridge) I'm out of ideas, so hopefully some of the Cogniscenti will chime in, if they're not all still sunning themselves in the Bahamas, or Cairns .. cheers, Ian From kes-kes at yandex.ru Sun Jan 4 09:48:08 2009 From: kes-kes at yandex.ru (KES) Date: Sun Jan 4 09:48:15 2009 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <200901031502.n03F2KbP042269@freefall.freebsd.org> References: <200901031502.n03F2KbP042269@freefall.freebsd.org> Message-ID: <666141730.20090104114754@yandex.ru> ????????????, Vwe. ?? ?????? 3 ?????? 2009 ?., 17:02:20: vFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server vFo> State-Changed-From-To: feedback->closed vFo> State-Changed-By: vwe vFo> State-Changed-When: Sat Jan 3 15:01:30 UTC 2009 vFo> State-Changed-Why: vFo> We're sorry to not see any feedback received for quite some time. vFo> If you think this is still an issue that should be worked on, vFo> please provide the requested information and we'll be happy to vFo> re-open this ticket. vFo> Thank you for bringing this problem to attention! vFo> Responsible-Changed-From-To: freebsd-net->vwe vFo> Responsible-Changed-By: vwe vFo> Responsible-Changed-When: Sat Jan 3 15:01:30 UTC 2009 vFo> Responsible-Changed-Why: vFo> track vFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 Strange, I have replied to email and provide requested information... kes# pppd --version pppd version 2.3 patch level 5 /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command adsl: set log Phase LCP tun command set device PPPoE:rl0:ukrtelecom # enable lqr # enable dns disable ipv6cp set cd 10 set dial # set login set redial 0 0 set reconnect random 999 set mtu 1492 set mru 1492 set authname name set authkey password # add! default HISADD ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) or ppp[348]: tun0: Phase: Pap Output: ******** last message repeated 2 times ppp[348]: tun0: Phase: Auth: No response from server As you can see my ISP respond with error. After 10-15 trying to login to ISP my server will reboot with kernel panic. -- ? ?????????, KES mailto:kes-kes@yandex.ru From nrml at att.net Sun Jan 4 10:23:28 2009 From: nrml at att.net (Gabe) Date: Sun Jan 4 10:23:35 2009 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <480896.12029.qm@web83811.mail.sp1.yahoo.com> Message-ID: <186728.8993.qm@web83802.mail.sp1.yahoo.com> > From: Gabe > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Bjoern A. Zeeb" > Cc: freebsd-net@freebsd.org > Date: Tuesday, December 30, 2008, 11:56 PM > > From: Bjoern A. Zeeb > > > Subject: Re: +ipsec_common_input: no key association > found for SA > > To: "Gabe" > > Cc: freebsd-net@freebsd.org > > Date: Tuesday, December 30, 2008, 6:24 AM > > On Tue, 30 Dec 2008, Gabe wrote: > > > > >> One more thing; if you are comparing SPIs > from the > > log with setkey, > > >> you can also run > > >> tcpdump -s 0 -vv -ln proto 50 > > >> and it will show you something like > > >> ... ESP(spi=0x12345678,seq=0x..), > > >> so you could as well compare what you receive > on > > the wire with what > > >> you get in the log. This would help to > eliminiate > > the case of a > > >> promblematic patch. > > > > > > However I still get the ipsec_common message > albeit > > not as often, it > > > appears to only be when I restart racoon now. I > also > > tried matching the > > > SPIs but the SPIs given by setkey -Da did not > match > > the ones on the log. > > > > Ok, can you try running the following script and see > if the > > output > > times match your racoon restarts or the log entries? > > > > You need to set your interface and the tunnel endpoint > IPs > > (as in box/box2). > > > > /bz > > I restarted racoon and cleared out the keys then I ran the > script which returned: > > on BOX: > tcpdump: verbose output suppressed, use -v or -vv for full > protocol decode > listening on em1, link-type EN10MB (Ethernet), capture size > 65535 bytes > 23:51:13.032336 SPI changed uninitialized -> 0x0878469a > 23:51:13.063318 SPI changed 0x0878469a -> 0x091b7ada > ^C1154 packets captured > 1597 packets received by filter > 0 packets dropped by kernel > > on BOX2: > tcpdump: verbose output suppressed, use -v or -vv for full > protocol decode > listening on em1, link-type EN10MB (Ethernet), capture size > 65535 bytes > 23:53:43.594785 SPI changed uninitialized -> 0x01d66237 > ^C2404 packets captured > 9701 packets received by filter > 0 packets dropped by kernel > > box and box2 are the local and end point respectively. > > /gabe I'm still unable to find the cause for this. Does anyone know what the above output is referring to? Thanks, /gabe From bzeeb-lists at lists.zabbadoz.net Sun Jan 4 11:25:12 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Jan 4 11:25:20 2009 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <186728.8993.qm@web83802.mail.sp1.yahoo.com> References: <186728.8993.qm@web83802.mail.sp1.yahoo.com> Message-ID: <20090104110430.I45399@maildrop.int.zabbadoz.net> On Sun, 4 Jan 2009, Gabe wrote: Hi, >>> Ok, can you try running the following script and see >> if the >>> output >>> times match your racoon restarts or the log entries? You hadn't answered that question to correlate the tcpdump with racoon restarts and kernel log entries. If you do that, you may want to run the script for two hours or four to actually see more changes than just the initial one. Check the syslog timestamps in the logfile where your kernel messages go to (might be /var/log/messages) for the ipsec_common_input lines. Perhaps grep upfront before startung the script to be sure that they are there. > I'm still unable to find the cause for this. Does anyone know what the above output is referring to? I think David DeSimone had last explained it to you: http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020611.html Maybe it would be time to read the RFC now; I'll try it in my own words again and shorter. Your IPsec Policy makes your racoons negotiate a Security Assosiaction for some parameters (keys, lieftime, ..). There will be one for each direction. One thing negotiated is the security policy index, the number we are tracing. This 'number' is put into each packet one of the boxes send encrypted to the other for the given direction. What your kernel tells you is that the number in the packet received does not make sense to the box receiving it. Let's say the SPI received in the packet from the other box is unknown on the receiver side. That's why the kernel complains. Without the proper SPI the kernel will not be able to find the proper other parameters for this packet, and thus will not be able to decrypt the packet. What we are trying to find out at the moment is to identify where exactly the wrong SPI is coming from. This could be: - whatever the boxes negotiated gets out of sync - a patch like the NAT-T patch could corrupt the packet - a software bug in where the kernel or racoon - ... To narrow this down from "everywhere" to "here" it is important to see where the values match, where not and when they do not match - thus correlating information from the time racoon gets restarted, the kernel prints the log message and what tcpdump is showing. It's important to get all this information for the same problematic moment, timestamped. If one is missing it's like a 1000 pieces puzzle with only 600 pieces included. One more question that hadn't been asked so far - what architectures (i386, amd64, sparc, arm, ..) are box and box2 and which version of freebsd are they running; I assume they are both on freebsd? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From perryh at pluto.rain.com Sun Jan 4 11:50:57 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Jan 4 11:51:04 2009 Subject: tun0 not responding to ping In-Reply-To: <20090104173927.R28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <495f15da.kLIW2g4L+3rMjCXS%perryh@pluto.rain.com> <20090103185837.K28770@sola.nimnet.asn.au> <495fd4f4.LnYmNJ/Km8Riy79x%perryh@pluto.rain.com> <20090104173927.R28770@sola.nimnet.asn.au> Message-ID: <49609ed3.pm0Bis/9ZOFmjtVw%perryh@pluto.rain.com> > Had a quick look at http://www.unix-ag.uni-kl.de/~massar/vpnc/ but > don't get whether it, or you, are configuring ppp? ie, does vpnc > make or mess with /etc/ppp/ppp.conf? Or otherwise invoke ppp > directly itself? Neither, I suspect. Looking at the ppp(8) manpage, it looks as if both vpnc and (user-mode) ppp use tun(4) rather than vpnc invoking ppp. There's no mention of ppp in the vpnc README or manpage, although the manpage does mention ip(8), ifconfig(8), and route(1). My /etc/ppp/ppp.conf is dated in 2006, so I guess it it "as delivered". It appears to be a template for connecting to an ISP via dialup or PAP/CHAP. > You can do pretty much like the above by invoking an > /etc/ppp/ppp.linkup script. Provided it could (somehow) be made to handle the VPN encryption and logon credentials, including RSA SecureNet one-time passwords, which vpnc seems to take care of. > Here you're not using the tunnel as your default route anyway, > but you could perhaps fix the addressing with ifconfig ... That seems to be Flemer's approach, and it may be as good a thing as any to try first. > Have you considered using mpd for this instead? That would be Flemer's setup. I got the impression from his paper that it might not handle the RSA one-time passwords very well, if at all, although it might work well enough in a shop that does not use dynamic passwords. (I suspect no one would have taken the trouble to write vpnc, or at least to port it from Linux to FreeBSD, had mpd been an altogether satisfactory solution :) From nrml at att.net Sun Jan 4 12:11:28 2009 From: nrml at att.net (Gabe) Date: Sun Jan 4 12:11:35 2009 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <20090104110430.I45399@maildrop.int.zabbadoz.net> Message-ID: <881287.90275.qm@web83809.mail.sp1.yahoo.com> > From: Bjoern A. Zeeb > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Gabe" > Cc: freebsd-net@freebsd.org > Date: Sunday, January 4, 2009, 3:24 AM > On Sun, 4 Jan 2009, Gabe wrote: > > Hi, > > >>> Ok, can you try running the following script > and see > >> if the > >>> output > >>> times match your racoon restarts or the log > entries? > > You hadn't answered that question to correlate the > tcpdump with racoon > restarts and kernel log entries. > > If you do that, you may want to run the script for two > hours or four > to actually see more changes than just the initial one. > > Check the syslog timestamps in the logfile where your > kernel messages > go to (might be /var/log/messages) for the > ipsec_common_input lines. > Perhaps grep upfront before startung the script to be sure > that they > are there. > I understand. I'm having to rebuild "box" (unrelated) so this will have to wait, I will definitely do it as mentioned above. > > I'm still unable to find the cause for this. Does > anyone know what the above output is referring to? > > I think David DeSimone had last explained it to you: > http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020611.html > > Maybe it would be time to read the RFC now; I'll try it > in my own > words again and shorter. > > Your IPsec Policy makes your racoons negotiate a Security > Assosiaction > for some parameters (keys, lieftime, ..). There will be one > for each > direction. One thing negotiated is the security policy > index, the > number we are tracing. This 'number' is put into > each packet one of the > boxes send encrypted to the other for the given direction. > > What your kernel tells you is that the number in the packet > received > does not make sense to the box receiving it. Let's say > the SPI received in > the packet from the other box is unknown on the receiver > side. That's > why the kernel complains. > Without the proper SPI the kernel will not be able to find > the proper > other parameters for this packet, and thus will not be able > to decrypt > the packet. > > > What we are trying to find out at the moment is to identify > where > exactly the wrong SPI is coming from. This could be: > - whatever the boxes negotiated gets out of sync > - a patch like the NAT-T patch could corrupt the packet > - a software bug in where the kernel or racoon > - ... > > To narrow this down from "everywhere" to > "here" it is important to see > where the values match, where not and when they do not > match - thus > correlating information from the time racoon gets > restarted, the > kernel prints the log message and what tcpdump is showing. > It's > important to get all this information for the same > problematic moment, > timestamped. If one is missing it's like a 1000 pieces > puzzle with > only 600 pieces included. > > One more question that hadn't been asked so far - what > architectures > (i386, amd64, sparc, arm, ..) are box and box2 and which > version of > freebsd are they running; I assume they are both on > freebsd? > They're i386. This is uname -a on "box": FreeBSD box.domain.tld 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 12 07:11:30 PST 2008 root@box.domain.tld:/usr/obj/usr/src/sys/KERNEL i386 This is uname -a on "box2": FreeBSD box2.domain.tld 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Fri Dec 26 01:48:31 PST 2008 root@box2.domain.tld:/usr/obj/usr/src/sys/KERNEL i386 One thing I found to be interesting is that "box2" no longer spews out the ipsec_common_input message after I corrected the 'spdadd' lines. So perhaps this is related to the different kernel sources version. Either way I'll report back once I'm finished rebuilding "box" From vwe at freebsd.org Sun Jan 4 12:29:04 2009 From: vwe at freebsd.org (Volker Werth) Date: Sun Jan 4 12:29:11 2009 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <666141730.20090104114754@yandex.ru> References: <200901031502.n03F2KbP042269@freefall.freebsd.org> <666141730.20090104114754@yandex.ru> Message-ID: <4960A3E5.7000906@freebsd.org> On 01/04/09 10:47, KES wrote: > ????????????, Vwe. > > ?? ?????? 3 ?????? 2009 ?., 17:02:20: > > vFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server > > vFo> State-Changed-From-To: feedback->closed > Eugene, > Strange, I have replied to email and provide requested information... sorry, but we can't guess where to look for any postings when working on a PR. Please understand we cannot use google for an hour just to check if somebody has sent an email to the pope or anybody else anywhere in the world. We need relevant information being ATTACHED TO THE PR! > > kes# pppd --version > pppd version 2.3 patch level 5 > > > /etc/ppp/ppp.conf > default: > set log Phase Chat LCP IPCP CCP tun command > > adsl: > set log Phase LCP tun command > set device PPPoE:rl0:ukrtelecom > # enable lqr > # enable dns > disable ipv6cp > set cd 10 > set dial > # set login > set redial 0 0 > set reconnect random 999 > set mtu 1492 > set mru 1492 > set authname name > set authkey password > # add! default HISADD > > ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) > or > ppp[348]: tun0: Phase: Pap Output: ******** > last message repeated 2 times > ppp[348]: tun0: Phase: Auth: No response from server > > As you can see my ISP respond with error. After 10-15 trying to login > to ISP my server will reboot with kernel panic. > Ok, I don't care if your ISP has resources or not to serve it's customers but I would be interested in the actual kernel panic. Better, please give us the full backtrace and everything else to investigate this. Thank you for your understanding. Volker From vwe at FreeBSD.org Sun Jan 4 14:09:48 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Jan 4 14:10:00 2009 Subject: kern/96030: [bfe] [patch] Install hangs with Broadcomm 440x NIC installed Message-ID: <200901041409.n04E9lBa018200@freefall.freebsd.org> Synopsis: [bfe] [patch] Install hangs with Broadcomm 440x NIC installed Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Jan 4 14:07:38 UTC 2009 Responsible-Changed-Why: reassign to net team There hasn't been any feedback for 2.5 years whether this issue is still true or the attached patch solves it. By checking recent sources, it looks like the patch is outdated. Leaving it to the net team for a decision what to do about the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=96030 From linimon at FreeBSD.org Sun Jan 4 15:26:32 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Jan 4 15:26:39 2009 Subject: bin/130159: [patch] ppp(8) fails to correctly set routes Message-ID: <200901041526.n04FQV8W078299@freefall.freebsd.org> Old Synopsis: [patch] ppp fail to correctly set routes New Synopsis: [patch] ppp(8) fails to correctly set routes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 4 15:25:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130159 From vwe at FreeBSD.org Sun Jan 4 15:46:42 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Jan 4 15:46:49 2009 Subject: kern/125079: [ppp] host routes added by ppp with gateway flag (regression) Message-ID: <200901041546.n04Fkfx0094034@freefall.freebsd.org> Synopsis: [ppp] host routes added by ppp with gateway flag (regression) State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sun Jan 4 15:45:32 UTC 2009 State-Changed-Why: closing this PR in favour of bin/130159 (seems to be the same issue) which contains a patch http://www.freebsd.org/cgi/query-pr.cgi?pr=125079 From vwe at FreeBSD.org Sun Jan 4 15:47:03 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun Jan 4 15:47:10 2009 Subject: kern/122068: [ppp] ppp can not set the correct interface with pptpd Message-ID: <200901041547.n04Fl2iC094074@freefall.freebsd.org> Synopsis: [ppp] ppp can not set the correct interface with pptpd State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sun Jan 4 15:46:55 UTC 2009 State-Changed-Why: closing this PR in favour of bin/130159 (seems to be the same issue) which contains a patch http://www.freebsd.org/cgi/query-pr.cgi?pr=122068 From freebsd at chrisbuechler.com Mon Jan 5 03:00:54 2009 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Mon Jan 5 03:01:01 2009 Subject: Blackberry Bold on FreeBSD ath AP not working Message-ID: <496171A3.8030000@chrisbuechler.com> Has anyone ever tried connecting a Blackberry Bold to a FreeBSD access point using an Atheros card? The card is an Atheros 5212, using FreeBSD 7.0. Every other wireless device that has been tried on this network works fine, but this Blackberry connects, gets a DHCP lease, and then sends ARP requests that get no reply. It behaves the same with the wireless open and using WPA or WPA2. The ath card is bridged to an Ethernet interface with if_bridge, which works flawlessly for everything but this Blackberry. The Blackberry works fine on several other wireless networks it has been tried on. capture of the Blackberry's ARP requests here: http://chrisbuechler.com/temp/bb-arp.pcap They're a bit different from the ARP requests of every other wireless device tried on this AP (i.e. the ones that work), in that they aren't padded to 60 byte frames, but I don't think that should be a problem. Anyone ever tried this, or have any idea what might be going on here? thanks, Chris From perryh at pluto.rain.com Mon Jan 5 04:14:25 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Mon Jan 5 04:14:42 2009 Subject: (partly) SOLVED: tun0 not responding to ping In-Reply-To: <20090103154232.P28770@sola.nimnet.asn.au> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> Message-ID: <49618962.WvA2bFthdzGdSO/b%perryh@pluto.rain.com> Ian Smith wrote: > On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > > > Why would a local interface, reported as up in ifconfig, not respond > > to a ping of its own IP address? The tun0 reported below doesn't, ... > > $ ifconfig -a ... > > tun0: flags=8051 mtu 1412 > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > Opened by PID 24635 > > I don't know if this is relevant or not, but I've never seen a point to > point interface use the same IP address on both ends of its link before. It turns out to be normal -- or at least tolerable -- for a tun(4) interface used by vpnc to have the same IP address at both ends. It started working when I added NAT Traversal Mode cisco-udp to vpnc.conf. (Presumably not all configurations of the Cisco 3000 will need that, else it would be the default, but it seems to be correct for the one involved here.) I never did figure out why that kept the interface from responding to a ping of its own address :( From julian at elischer.org Mon Jan 5 07:09:44 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 5 07:09:50 2009 Subject: Request for assitance: VIMAGE performance testing Message-ID: <4961B236.8040607@elischer.org> The current state of vimage in -current is such that we can do some performance testing. Unfortunatly I don't have a test plan in place.. The aim is to run some tests on systems with VIMAGE_GLOBALS defined and not defined and see if there are any detectable differences. Firstly I have done some simple tests myself (e.g. scps, pings, ftps) but it would be very helpful if people coudl compile up an alternative kernel with VIMAGE_GLOBALS defined and see if their everyday workloads show any noticeable differences. nothing special.. just time a few things you often do that may be special to you and are network intensive, and then switch to the other kernel and try it again. Then put the results in ministat (saying whether bigger is better or worse) Ok do it several times for statistical purposes, reply to me (and the list) and let us know if you are seeing differences anywhere.. regards.. Julian (p.s. I will put numbers up too when I get some more) From pyunyh at gmail.com Mon Jan 5 10:13:37 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Jan 5 10:13:43 2009 Subject: Annoyance with msk(4) going up and down when initializing interface In-Reply-To: References: <20081224021016.GF95088@cdnetworks.co.kr> Message-ID: <20090105095135.GH1842@cdnetworks.co.kr> On Fri, Jan 02, 2009 at 03:31:33PM -0800, Garrett Cooper wrote: > Hi Pyun, > I've noticed an issue for a while now with my chipset (I think that > this is post an MFC between 7.0 and 7.1, but I could be wrong). > Basically, each CPU (with the ULE scheduler) grabs the task to check > for media status, goes out and attempts to get an IP, and if the > timing of the status modifications is just right, one of the CPU's > will mark the link up and others will mark it down, and it will stay > down. No, the link state change event is protected by driver lock. > Same thing occurs when trying to get a DHCP request -- there will > typically be multiple requests and ACK's for any given requests. > This occurs with my onboard NICs on my P5K-e motherboards on 7.1- > rc[12], and also 8-CURRENT. If you're referring to multiple link UP/DOWN messages when dhclient(8) trying to get an IP address via DHCP it's normal for drivers that rely on mii(4) state change event. Technically it's not normal but it's the way how it was implemented on most drivers. Ideally drivers should not need to reset controllers when it's not absolutely required to reset hardwares but most drivers blindly reset hardware which in turn results in link renegotiation. You can see similiar behavour when alias addresseses are added to the interface. Because controllers that have complex firmware/embedded OS will take time to complete the reset operation, the reset operation would be pain to these controllers. Long time ago I added a hack to em(4) to mitigate the issue but I don't think it's way to go. NetBSD seems to have right fix in ioctl handler. However the approach will require careful checking of multicasting code of all drivers. I don't have all hardwares to test this and I don't know hardware internals of all drivers. -- Regards, Pyun YongHyeon From bugmaster at FreeBSD.org Mon Jan 5 11:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:08:40 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200901051106.n05B6tH1002860@freefall.freebsd.org> 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 bin/130159 net [patch] ppp(8) fails to correctly set routes 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/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [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 [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126924 net [an] [patch] printf -> device_printf and simplify prob 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 kern/121983 net [fxp] fxp0 MBUF and PAE 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre 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 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/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/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 204 problems total. From bugmaster at FreeBSD.org Mon Jan 5 11:07:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:10:01 2009 Subject: Current problem reports assigned to net@FreeBSD.org Message-ID: <200901051107.n05B7paH003938@freefall.freebsd.org> 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 -------------------------------------------------------------------------------- s kern/117717 net [panic] Kernel panic with Bittorrent client. 1 problem total. From rwatson at FreeBSD.org Mon Jan 5 13:13:25 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jan 5 13:13:37 2009 Subject: TCP packet out-of-order problem In-Reply-To: <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> Message-ID: On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote: > After running "netstat -s -p tcp", we found that lots of packets are > discarded due to memory problems. We googled for it, and found that sysctl > oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never > reassembled. > > Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that > setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. > After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf, > the network works perfectly now. Was it set to 0 through a configuration error, or did the system auto-tune improperly? Robert N M Watson Computer Laboratory University of Cambridge > > Thank you all for the help! > _______________________________________________ > 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 edwin at mavetju.org Mon Jan 5 15:24:54 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Mon Jan 5 15:25:02 2009 Subject: Annoyance with msk(4) going up and down when initializing interface In-Reply-To: <20090105095135.GH1842@cdnetworks.co.kr> References: <20081224021016.GF95088@cdnetworks.co.kr> <20090105095135.GH1842@cdnetworks.co.kr> Message-ID: <20090105104325.GA70686@mavetju.org> On Mon, Jan 05, 2009 at 06:51:35PM +0900, Pyun YongHyeon wrote: > On Fri, Jan 02, 2009 at 03:31:33PM -0800, Garrett Cooper wrote: > > Hi Pyun, > > I've noticed an issue for a while now with my chipset (I think that > > this is post an MFC between 7.0 and 7.1, but I could be wrong). > > Basically, each CPU (with the ULE scheduler) grabs the task to check > > for media status, goes out and attempts to get an IP, and if the > > timing of the status modifications is just right, one of the CPU's > > will mark the link up and others will mark it down, and it will stay > > down. > > No, the link state change event is protected by driver lock. > > > Same thing occurs when trying to get a DHCP request -- there will > > typically be multiple requests and ACK's for any given requests. > > This occurs with my onboard NICs on my P5K-e motherboards on 7.1- > > rc[12], and also 8-CURRENT. > > If you're referring to multiple link UP/DOWN messages when > dhclient(8) trying to get an IP address via DHCP it's normal for > drivers that rely on mii(4) state change event. Technically it's > not normal but it's the way how it was implemented on most drivers. > Ideally drivers should not need to reset controllers when it's not > absolutely required to reset hardwares but most drivers blindly > reset hardware which in turn results in link renegotiation. You can > see similiar behavour when alias addresseses are added to the > interface. Because controllers that have complex firmware/embedded > OS will take time to complete the reset operation, the reset > operation would be pain to these controllers. Long time ago I added > a hack to em(4) to mitigate the issue but I don't think it's way to > go. > NetBSD seems to have right fix in ioctl handler. However the > approach will require careful checking of multicasting code of all > drivers. I don't have all hardwares to test this and I don't know > hardware internals of all drivers. When booting diskless via PXE I sometimes run into this problem too: machine boots via NFS, NIC gets down and up and oh, it doesn't work anymore. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From kes-kes at yandex.ru Mon Jan 5 16:39:30 2009 From: kes-kes at yandex.ru (KES) Date: Mon Jan 5 16:39:37 2009 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <4960A3E5.7000906@freebsd.org> References: <200901031502.n03F2KbP042269@freefall.freebsd.org> <666141730.20090104114754@yandex.ru> <4960A3E5.7000906@freebsd.org> Message-ID: <1652352570.20090105183922@yandex.ru> ????????????, Volker. ?? ?????? 4 ?????? 2009 ?., 13:56:21: VW> On 01/04/09 10:47, KES wrote: >> ????????????, Vwe. >> >> ?? ?????? 3 ?????? 2009 ?., 17:02:20: >> >> vFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server >> >> vFo> State-Changed-From-To: feedback->closed >> VW> Eugene, >> Strange, I have replied to email and provide requested information... VW> sorry, but we can't guess where to look for any postings when working on VW> a PR. Please understand we cannot use google for an hour just to check VW> if somebody has sent an email to the pope or anybody else anywhere in VW> the world. We need relevant information being ATTACHED TO THE PR! I had reply as usually. Mybe my letter was droped somewhere... =( >> >> kes# pppd --version >> pppd version 2.3 patch level 5 >> >> >> /etc/ppp/ppp.conf >> default: >> set log Phase Chat LCP IPCP CCP tun command >> >> adsl: >> set log Phase LCP tun command >> set device PPPoE:rl0:ukrtelecom >> # enable lqr >> # enable dns >> disable ipv6cp >> set cd 10 >> set dial >> # set login >> set redial 0 0 >> set reconnect random 999 >> set mtu 1492 >> set mru 1492 >> set authname name >> set authkey password >> # add! default HISADD >> >> ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) >> or >> ppp[348]: tun0: Phase: Pap Output: ******** >> last message repeated 2 times >> ppp[348]: tun0: Phase: Auth: No response from server >> >> As you can see my ISP respond with error. After 10-15 trying to login >> to ISP my server will reboot with kernel panic. >> VW> Ok, I don't care if your ISP has resources or not to serve it's VW> customers but I would be interested in the actual kernel panic. VW> Better, please give us the full backtrace and everything else to VW> investigate this. VW> Thank you for your understanding. VW> Volker There were some problem with server of my ISP. Now they fix their server. So now pppd works fine. If problem will repeat I will send tcpdump of PPPoE traffic. -- ? ?????????, KES mailto:kes-kes@yandex.ru From vwe at freebsd.org Mon Jan 5 21:46:54 2009 From: vwe at freebsd.org (vwe) Date: Mon Jan 5 21:47:00 2009 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <1652352570.20090105183922@yandex.ru> References: <200901031502.n03F2KbP042269@freefall.freebsd.org> <666141730.20090104114754@yandex.ru> <4960A3E5.7000906@freebsd.org> <1652352570.20090105183922@yandex.ru> Message-ID: <1231191906.16660.1.camel@dardanos.sz.vwsoft.com> On Mon, 2009-01-05 at 18:39 +0200, KES wrote: > ????????????, Volker. > > ?? ?????? 4 ?????? 2009 ?., 13:56:21: > > VW> On 01/04/09 10:47, KES wrote: > >> , Vwe. > >> > >> 3 2009 ., 17:02:20: > >> > >> vFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server > >> > >> vFo> State-Changed-From-To: feedback->closed > >> > > VW> Eugene, > > >> Strange, I have replied to email and provide requested information... > > VW> sorry, but we can't guess where to look for any postings when working on > VW> a PR. Please understand we cannot use google for an hour just to check > VW> if somebody has sent an email to the pope or anybody else anywhere in > VW> the world. We need relevant information being ATTACHED TO THE PR! > > I had reply as usually. Mybe my letter was droped somewhere... =( > > >> > >> kes# pppd --version > >> pppd version 2.3 patch level 5 > >> > >> > >> /etc/ppp/ppp.conf > >> default: > >> set log Phase Chat LCP IPCP CCP tun command > >> > >> adsl: > >> set log Phase LCP tun command > >> set device PPPoE:rl0:ukrtelecom > >> # enable lqr > >> # enable dns > >> disable ipv6cp > >> set cd 10 > >> set dial > >> # set login > >> set redial 0 0 > >> set reconnect random 999 > >> set mtu 1492 > >> set mru 1492 > >> set authname name > >> set authkey password > >> # add! default HISADD > >> > >> ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) > >> or > >> ppp[348]: tun0: Phase: Pap Output: ******** > >> last message repeated 2 times > >> ppp[348]: tun0: Phase: Auth: No response from server > >> > >> As you can see my ISP respond with error. After 10-15 trying to login > >> to ISP my server will reboot with kernel panic. > >> > > VW> Ok, I don't care if your ISP has resources or not to serve it's > VW> customers but I would be interested in the actual kernel panic. > > VW> Better, please give us the full backtrace and everything else to > VW> investigate this. > > VW> Thank you for your understanding. > > VW> Volker > > > There were some problem with server of my ISP. Now they fix their > server. So now pppd works fine. > If problem will repeat I will send tcpdump of PPPoE traffic. > Eugene, if you should find a coredump for analysis or if your server will ever experience the same panic again, please drop us a note (cc bug-followup@ to have the information attached to the GNATS PR) and we'll reopen this ticket. Thank you for providing feedback! Volker From ericlin at tamama.org Tue Jan 6 04:25:09 2009 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Tue Jan 6 04:25:16 2009 Subject: TCP packet out-of-order problem In-Reply-To: References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> Message-ID: <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com> Hi Robert, I thought that the system auto-tune improperly in this case. On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson wrote: > On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote: > >> After running "netstat -s -p tcp", we found that lots of packets are >> discarded due to memory problems. We googled for it, and found that sysctl >> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never >> reassembled. >> >> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that >> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. >> After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf, >> the network works perfectly now. > > Was it set to 0 through a configuration error, or did the system auto-tune > improperly? > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> Thank you all for the help! >> _______________________________________________ >> 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 psteele at maxiscale.com Tue Jan 6 07:21:50 2009 From: psteele at maxiscale.com (Peter Steele) Date: Tue Jan 6 07:21:56 2009 Subject: Having problems with limited broadcast Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DE9@polaris.maxiscale.com> We have a Python app that implements a DHCP-like protocol using limited broadcast using address 255.255.255.255. Our code works fine on Linux and FreeBSD but we cannot seem to get broadcast to work on FreeBSD. We've tried both Python and C under FreeBSD 7.0. I've found a lengthy discussion of this problem here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558 It appears some work has been done to correct this problem but if I understand the discussion correctly it still is not resolved, at least as of the timeframe of this thread. In our case, we have systems with no IP identity of any kind--no IP address and no gateway, and they are connected only by switches. There is no router in the network. They receive IP addresses through a special service that we've written that runs on one of the systems, in response to address request queries sent out by the systems. All communication is done through limited broadcast. As I said, this works fine one our Linux and Windows boxes but not FreeBSD. Based on the discussion in the link above, it doesn't seem like the problem was entirely resolved by the patches mentioned in this thread. Has anything been done since this discussion took place. Surely there must be a way to get limited broadcast to work under FreeBSD. From rwatson at FreeBSD.org Tue Jan 6 08:16:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jan 6 08:16:09 2009 Subject: TCP packet out-of-order problem In-Reply-To: <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com> References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com> Message-ID: On Tue, 6 Jan 2009, Lin Jui-Nan Eric wrote: > I thought that the system auto-tune improperly in this case. Hmm. Do you have a custom setting for kern.ipc.nmbclusters in loader.conf or sysctl.conf? What does kern.ipc.nmbclusters configure itself to on your system? Also, could you send me the output of uname -a on the system? Thanks, Robert N M Watson Computer Laboratory University of Cambridge > On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson wrote: >> On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote: >> >>> After running "netstat -s -p tcp", we found that lots of packets are >>> discarded due to memory problems. We googled for it, and found that sysctl >>> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never >>> reassembled. >>> >>> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that >>> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. >>> After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf, >>> the network works perfectly now. >> >> Was it set to 0 through a configuration error, or did the system auto-tune >> improperly? >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> Thank you all for the help! >>> _______________________________________________ >>> 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 ericlin at tamama.org Tue Jan 6 15:12:18 2009 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Tue Jan 6 15:12:25 2009 Subject: TCP packet out-of-order problem In-Reply-To: References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com> <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com> <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com> <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com> Message-ID: <47713ee10901060712g7b4a204fq73cabb99c7070929@mail.gmail.com> Oops, we surely have kern.ipc.nmbclusters="0" in loader.conf, but I think that should not modify net.inet.tcp.reass.maxsegments to "0" since we wish unlimited nmbclusters but not zero TCP reassembly segments. On Tue, Jan 6, 2009 at 4:16 PM, Robert Watson wrote: > > On Tue, 6 Jan 2009, Lin Jui-Nan Eric wrote: > >> I thought that the system auto-tune improperly in this case. > > Hmm. Do you have a custom setting for kern.ipc.nmbclusters in loader.conf > or sysctl.conf? What does kern.ipc.nmbclusters configure itself to on your > system? Also, could you send me the output of uname -a on the system? > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson wrote: >>> >>> On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote: >>> >>>> After running "netstat -s -p tcp", we found that lots of packets are >>>> discarded due to memory problems. We googled for it, and found that >>>> sysctl >>>> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never >>>> reassembled. >>>> >>>> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found >>>> that >>>> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. >>>> After setting net.inet.tcp.reass.maxsegments="1600" in >>>> /boot/loader.conf, >>>> the network works perfectly now. >>> >>> Was it set to 0 through a configuration error, or did the system >>> auto-tune >>> improperly? >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >>> >>>> >>>> Thank you all for the help! >>>> _______________________________________________ >>>> 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 leeygang at gmail.com Tue Jan 6 16:41:06 2009 From: leeygang at gmail.com (Li yonggang) Date: Tue Jan 6 16:41:12 2009 Subject: the BACKWARD COMPTIBLITY code for the input for netstat leads to a crash Message-ID: <6742fb710901060812u5f1b749cubec97c8adbbe3384@mail.gmail.com> Hi, I use FreeBSD 7.0-Release and find if a mistake input for -m can make netstat crash. such as: netstat -m xxx After simple investigation, I found it is caused by the code in main.c :456 #define BACKWARD_COMPATIBILITY #ifdef BACKWARD_COMPATIBILITY if (*argv) { if (isdigit(**argv)) { interval = atoi(*argv); if (interval <= 0) usage(); ++argv; iflag = 1; } if (*argv) { nlistf = *argv; if (*++argv) memf = *argv; } } #endif if the input is incorrect, this piece of code will set nlistf as a incorrect string, this will make the live var set incorrectly. so I think there are 2 ways to resolve: 1. add input check code in case -m of switch. 2. or delete backward comptiblity code. Is my understanding correct? Thanks, Yong-gang Li. From psteele at maxiscale.com Tue Jan 6 16:46:19 2009 From: psteele at maxiscale.com (Peter Steele) Date: Tue Jan 6 16:46:25 2009 Subject: Having problems with limited broadcast Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> We have a Python app that implements a DHCP-like protocol using limited broadcast using address 255.255.255.255. Our code works fine on Linux and FreeBSD but we cannot seem to get broadcast to work on FreeBSD. We've tried both Python and C under FreeBSD 7.0. I've found a lengthy discussion of this problem here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558 It appears some work has been done to correct this problem but if I understand the discussion correctly it still is not resolved, at least as of the timeframe of this thread. In our case, we have systems with no IP identity of any kind--no IP address and no gateway, and they are connected only by switches. There is no router in the network. They receive IP addresses through a special service that we've written that runs on one of the systems, in response to address request queries sent out by the systems. All communication is done through limited broadcast. As I said, this works fine one our Linux and Windows boxes but not FreeBSD. Based on the discussion in the link above, it doesn't seem like the problem was entirely resolved by the patches mentioned in this thread. Has anything been done since this discussion took place. Surely there must be a way to get limited broadcast to work under FreeBSD. From smithi at nimnet.asn.au Wed Jan 7 04:15:05 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Jan 7 04:15:12 2009 Subject: (partly) SOLVED: tun0 not responding to ping In-Reply-To: <49618962.WvA2bFthdzGdSO/b%perryh@pluto.rain.com> References: <495edc8b.yfwTDGtb9G/8NMur%perryh@pluto.rain.com> <20090103154232.P28770@sola.nimnet.asn.au> <49618962.WvA2bFthdzGdSO/b%perryh@pluto.rain.com> Message-ID: <20090107150633.S28770@sola.nimnet.asn.au> On Sun, 4 Jan 2009, perryh@pluto.rain.com wrote: > Ian Smith wrote: > > On Fri, 2 Jan 2009, perryh@pluto.rain.com wrote: > > > > > Why would a local interface, reported as up in ifconfig, not respond > > > to a ping of its own IP address? The tun0 reported below doesn't, > ... > > > $ ifconfig -a > ... > > > tun0: flags=8051 mtu 1412 > > > inet6 fe80::2b0:d0ff:fe28:ad4f%tun0 prefixlen 64 scopeid 0x4 > > > inet ZZZ.ZZZ.233.42 --> ZZZ.ZZZ.233.42 netmask 0xffffffff > > > Opened by PID 24635 > > > > I don't know if this is relevant or not, but I've never seen a point to > > point interface use the same IP address on both ends of its link before. .. at least, not when using ppp(8) That's what I get for ASSuming :) > It turns out to be normal -- or at least tolerable -- for a tun(4) > interface used by vpnc to have the same IP address at both ends. > It started working when I added > > NAT Traversal Mode cisco-udp > > to vpnc.conf. (Presumably not all configurations of the Cisco 3000 > will need that, else it would be the default, but it seems to be > correct for the one involved here.) > > I never did figure out why that kept the interface from responding > to a ping of its own address :( Glad to hear it's working anyway, on getting back from a few days away. cheers, Ian From stadtkind2 at gmx.de Wed Jan 7 08:50:03 2009 From: stadtkind2 at gmx.de (=?iso-8859-1?Q?=22Stefan_Kr=FCger=22?=) Date: Wed Jan 7 08:50:10 2009 Subject: kern/106438: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Message-ID: <200901070850.n078o2Gh041102@freefall.freebsd.org> The following reply was made to PR kern/106438; it has been noted by GNATS. From: =?iso-8859-1?Q?=22Stefan_Kr=FCger=22?= To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/106438: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Date: Wed, 07 Jan 2009 09:16:57 +0100 I can confirm that ipf's keep state still doesn't work on FreeBSD 7.1-RELEASE :( Machine used for testing was a Sun Fire v120 (i.e. sparc64), NIC was Sun Eri (= gem driver) -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From kayvey at gmail.com Wed Jan 7 09:12:43 2009 From: kayvey at gmail.com (Kayven Riese) Date: Wed Jan 7 09:12:51 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> Message-ID: <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> On Tue, Jan 6, 2009 at 8:45 AM, Peter Steele wrote: > We have a Python app that implements a DHCP-like protocol using limited > broadcast using address 255.255.255.255. Our code works fine on Linux > and FreeBSD but we cannot seem to get broadcast to work on FreeBSD. > We've tried both Python and C under FreeBSD 7.0. > > > > I've found a lengthy discussion of this problem here: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558 > More reaently, ------------------------------ >Message: 22 >Date: Tue, 6 Jan 2009 13:29:04 -0800 >From: "Peter Steele" >Subject: RE: Do UDP broadcasts work in FreeBSD? >To: >Message-ID: > <2ACA3DE8F9758A48B8BE2C7A847F91F2479E3F@polaris.maxiscale.com> >Content-Type: text/plain; charset="us-ascii" > >> What you're trying to do with sending to the all-ones broadcast >> address is known as sending a "link-local" packet. On some systems, >> sending a UDP packet to 255.255.255.255 will actually cause a packet >> with that destination to be generated from all network interfaces >> which are "UP". That seems to be the behavior you are expecting. > >Yes it is. This is the behavior I've seen on every system I've used for >20+ years, except for FreeBSD. > I've only been a UNIX luser since 1985 when I thought I learned "EVAX" at the University of Wisconsin-Milwaukee. I have done other things than sysadmin since then, so if anyone has a better source for an EVAX operating system (if I am not confusing it with something else) I would appreciate it. >> On FreeBSD, IIRC, the behavior you get is that it will send to the >> local network broadcast address for each interface [1] using the >> network broadcast address (ie, if an interface is configured for >> 10.1.1.1 with /16 netmask, the packet will have destination >> 10.1.255.255). If an interface is UP but not configured with an IP >> +netmask, I don't believe a packet will be sent. (In fact, it might >> depend upon whether the BROADCAST flag is enabled, which gets set when > >> an inet-enabled interface is setup with a netmask...) At the risk of digressing and in hopes that there is truly "no stupid question that is at least on topic", I want to say that I was some amount through the book "TCP/IP Network Administration" by Hunt published by O'Reilly, when I picked up "Writing a UNIX Device Driver" by Egan and Teixeira (I note its regrettable emphasis on System V, though it mentiones "Berkeley Systems") because I was really hoping to get up to speed to contribute vis a vis Wireless USB adapters by Belkin that do not seem to have a driver in FreeBSD (is this a bug?). If anybody has any further suggestions for further reading, it would be appreciated. I already had the TCP/IP Hunt book but hadn't picked it up when I picked up a book by the name of "TCP/IP Illustrated Volume 2." Getting a bit into that, and cogniscient of the fact that it was "Volume 2" I decided to put it down and pick up Hunt, feeling like a TCP/IP newbie (at least a developer level newbie fo'sho'). Anyway.. back to the topic. I have also been exposed to TCP/IP recently in UC-Berkeley's undergraduate operating systems course (CS 162) where they discussed the fact that not all IP addresses are created equal. I missed some points on a test question claiming that "There are 2^32 IP adddresses" or some such, since e.g. 0.0.0.0 and 255.255.255.255 and 127.0.0.1, right? are not really legal addresses. I don't remember off the top of my head the exact IP numbers involved with this, but I vaguely recall that in addition to having IPs with "special meaning" i.e. do not exactly "point" to any "node" on the "internet," there ARE a set of IPs that are specifically designed for use in LANs (is that what we are talking about with a "set of computers" that have "no IP," right?) > >In our case our systems have no IP identity of any kind, and we don't >want to have to rely on whether or not our customers have a DHCP server >available. So we've come up with our own "light" DHCP. It works fine for >Linux and Windows. Not FreeBSD though. > >> Arguably, this is a bug in FreeBSD > >I don't think there is any doubt about that. And from what I understand >it even used to work under FreeBSD a few years ago. Okay, I jumped the gun. Is this a bug to be absolutely ignorant of the existance of an IP system that .. am I wrong in saying this?.. MANDATES that every computer has an IP even if it is just in a LAN, and acutally tries to claim it is not a part of the "internet," and, indeed, the IP system provides for this by having a set of IPs (was it 10.0.0.0/8 and 192.168.0.0/16 ?..I am professing absolute ignorance here, but hoping that I am not mistaken). We ARE talking about "just a LAN" here, right? Also, these computers are "not on the internet?" They have absolutely no connectivity? (Unlikely). I apologize for being incredibly stupid, and not having the time to "thoroughly" (umm.. well..I .. yeah. I feel that maybe the amount of background reading to really get up to speed before this thread wistfully drifts into the internet archives might be prohibitive).. research the background here, but feel at least if I am OT on freebsd-net (I would have replied to -questions, but I am set up for this "daily digest" and fear that totally destroys these neato email threads that have my name being a horses patoot all over the internet). > >> but you can work around it by >> using the BPF interface to send the traffic directly rather than using > >> the network stack via socket()+send()/write(). I believe the ISC DHCP > >> server software provides examples of how to do this, as dhclient is >> commonly used to send DHCP requests to the all-ones broadcast addr, >> without needing an interface being configured with an IP.... > >I've already looked at the ISC DHCP source code. They use raw sockets to >send their broadcasts, which seems to us to be a convoluted way of >sending a simple broadcast. I've seen examples of DHCP client/server >code written in Java using standard UDP. Unfortunately, our own system >is already largely implemented in Java/Python, so we'll need to provide >a JNI interface to support raw sockets. Alternatively we may patch the >kernel to fix the bug at its source. > After having looked closely at this question, and feeling "the guantlet has been tossed," I tossed an turned and suddenly knew I had to rise and confront this assertion on the matter of "bug versus feature." In my voluminous ignorance, I offer a simple question. I have an intuition that somebody really smart _just might_ jump in and having something really interesting to say on this matter if (despite the fact??) I do. It defintely sounds like this "feature" (I am hearby casting my pathetic carcass into the line of fire in my assertion that his is not a "bug," but a "feature.") is giving a certain Peter Steele more irritations in the form of required configuration issues than he would otherwise like. My very simple (but at the same time perhaps profoundly complex) question is, "What are the security implications of pretending there is no such thing as IP addresses that are designated for LANs that are isolated from TCP/IP of the WAN as servers, while perhaps acting as clients?" In case I am actually clueless, I also offer a potentially synonymic question, "What is the 'infinite wisdom' (note to any--feel free to replace with 'absolute folly' if you are so inclined) behind the design of FreeBSD in contrast to Penguinware and Uncle Bill's Windoze that is leading to the "feature"that is making a certain Peter Steele's life so difficult? > > It appears some work has been done to correct this problem but if I > understand the discussion correctly it still is not resolved, at least > as of the timeframe of this thread. > > > > In our case, we have systems with no IP identity of any kind--no IP > address and no gateway, and they are connected only by switches. There > is no router in the network. They receive IP addresses through a special > service that we've written that runs on one of the systems, in response > to address request queries sent out by the systems. All communication is > done through limited broadcast. As I said, this works fine one our Linux > and Windows boxes but not FreeBSD. > > > > Based on the discussion in the link above, it doesn't seem like the > problem was entirely resolved by the patches mentioned in this thread. > Has anything been done since this discussion took place. Surely there > must be a way to get limited broadcast to work under FreeBSD. > > > > _______________________________________________ > 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" > -- *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From yonyossef.lists at gmail.com Wed Jan 7 09:13:51 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Jan 7 09:13:57 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine Message-ID: <000001c970a8$3fa45240$220f000a@mtl.com> Hi All, I'm having a problem on FreeBSD 6.3 and 7.0 with VLAN management. After loading my 10GigE driver I'm creating a vlan interface: /sbin/ifconfig vlan3653 create /sbin/ifconfig vlan3653 vlan 3653 vlandev mynic0 Then I'm unloading the driver and everything is fine, the driver interface remains with a NULL parent. Problem is when I assign an IP to the vlan interface. In that case, unloading the driver results in hanging the host. Does it sound familiar to anybody? Thanks, Yony From nrml at att.net Wed Jan 7 14:13:47 2009 From: nrml at att.net (Gabe) Date: Wed Jan 7 14:13:53 2009 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <881287.90275.qm@web83809.mail.sp1.yahoo.com> Message-ID: <227893.30747.qm@web83803.mail.sp1.yahoo.com> > From: Gabe > Subject: Re: +ipsec_common_input: no key association found for SA > To: "Bjoern A. Zeeb" > Cc: freebsd-net@freebsd.org > Date: Sunday, January 4, 2009, 4:11 AM > > From: Bjoern A. Zeeb > > > Subject: Re: +ipsec_common_input: no key association > found for SA > > To: "Gabe" > > Cc: freebsd-net@freebsd.org > > Date: Sunday, January 4, 2009, 3:24 AM > > On Sun, 4 Jan 2009, Gabe wrote: > > > > Hi, > > > > >>> Ok, can you try running the following > script > > and see > > >> if the > > >>> output > > >>> times match your racoon restarts or the > log > > entries? > > > > You hadn't answered that question to correlate the > > tcpdump with racoon > > restarts and kernel log entries. > > > > If you do that, you may want to run the script for two > > hours or four > > to actually see more changes than just the initial > one. > > > > Check the syslog timestamps in the logfile where your > > kernel messages > > go to (might be /var/log/messages) for the > > ipsec_common_input lines. > > Perhaps grep upfront before startung the script to be > sure > > that they > > are there. > > > > I understand. I'm having to rebuild "box" > (unrelated) so this will have to wait, I will definitely do > it as mentioned above. > > > > I'm still unable to find the cause for this. > Does > > anyone know what the above output is referring to? > > > > I think David DeSimone had last explained it to you: > > > http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020611.html > > > > Maybe it would be time to read the RFC now; I'll > try it > > in my own > > words again and shorter. > > > > Your IPsec Policy makes your racoons negotiate a > Security > > Assosiaction > > for some parameters (keys, lieftime, ..). There will > be one > > for each > > direction. One thing negotiated is the security policy > > index, the > > number we are tracing. This 'number' is put > into > > each packet one of the > > boxes send encrypted to the other for the given > direction. > > > > What your kernel tells you is that the number in the > packet > > received > > does not make sense to the box receiving it. Let's > say > > the SPI received in > > the packet from the other box is unknown on the > receiver > > side. That's > > why the kernel complains. > > Without the proper SPI the kernel will not be able to > find > > the proper > > other parameters for this packet, and thus will not be > able > > to decrypt > > the packet. > > > > > > What we are trying to find out at the moment is to > identify > > where > > exactly the wrong SPI is coming from. This could be: > > - whatever the boxes negotiated gets out of sync > > - a patch like the NAT-T patch could corrupt the > packet > > - a software bug in where the kernel or racoon > > - ... > > > > To narrow this down from "everywhere" to > > "here" it is important to see > > where the values match, where not and when they do not > > match - thus > > correlating information from the time racoon gets > > restarted, the > > kernel prints the log message and what tcpdump is > showing. > > It's > > important to get all this information for the same > > problematic moment, > > timestamped. If one is missing it's like a 1000 > pieces > > puzzle with > > only 600 pieces included. > > > > One more question that hadn't been asked so far - > what > > architectures > > (i386, amd64, sparc, arm, ..) are box and box2 and > which > > version of > > freebsd are they running; I assume they are both on > > freebsd? > > > > They're i386. > > This is uname -a on "box": > > FreeBSD box.domain.tld 7.1-PRERELEASE FreeBSD > 7.1-PRERELEASE #0: Fri Dec 12 07:11:30 PST 2008 > root@box.domain.tld:/usr/obj/usr/src/sys/KERNEL i386 > > This is uname -a on "box2": > > FreeBSD box2.domain.tld 7.1-PRERELEASE FreeBSD > 7.1-PRERELEASE #5: Fri Dec 26 01:48:31 PST 2008 > root@box2.domain.tld:/usr/obj/usr/src/sys/KERNEL i386 > > One thing I found to be interesting is that > "box2" no longer spews out the ipsec_common_input > message after I corrected the 'spdadd' lines. So > perhaps this is related to the different kernel sources > version. > > Either way I'll report back once I'm finished > rebuilding "box" Well, I can't continue to try and figure this out. The boxes where this is occurring are live production boxes and well I need to figure out a better solution that's a little more intuitive. So it seems that just like many other freebsd users out there with IPSec and the NAT-T patch this will remain unanswered. Thanks Bjoern and everyone who answered. Cheers /gabe From psteele at maxiscale.com Wed Jan 7 14:38:27 2009 From: psteele at maxiscale.com (Peter Steele) Date: Wed Jan 7 14:38:34 2009 Subject: Having problems with limited broadcast In-Reply-To: <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> >We ARE talking about "just a LAN" here, right? Also, these computers >are "not on the internet?" They have absolutely no connectivity? >(Unlikely). When our boxes are initially deployed, they have no IP addresses assigned to them. Their ifconfig entry looks like this: ifconfig_lagg0="laggproto failover laggport nfe0 laggport nfe1" With this config, no IP is assigned to the lagg0 device, so the only way to access the boxes is via a serial console. From there we give one system a static IP, and then proceed to configure our "light DHCP" service on this box via a web app. After this is done, the remaining systems start communicating with this box via a broadcast protocol to obtain their IPs. These will be assigned statically to these boxes, and from there they can get on with launching their applications (JBOSS, etc). And I'll leave it at that. I am quite ready to give this one to Kayven Riese. He clearly knows a lot more about the subject than I do, and I apologize for the testiness of my posting (deadline pressures). We are proceeding with using raw sockets to implement our broadcast based light DHCP service. From yonyossef.lists at gmail.com Wed Jan 7 15:04:45 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Jan 7 15:04:52 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <4964C2E9.1060301@bestunion.it> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> Message-ID: <000001c970d9$4403e590$220f000a@mtl.com> > Yony Yossef wrote: > > /sbin/ifconfig vlan3653 create > > > > Problem is when I assign an IP to the vlan interface. > > In that case, unloading the driver results in hanging the host. > > > > Does it sound familiar to anybody? > > Well, surely I'd expect problems by doing so. > The correct way is to > > /sbin/ifconfig vlan3653 destroy > > before unloading the driver. > > Angelo. Thanks, I didn't know freebsd does not allow it. Yony From aturetta at bestunion.it Wed Jan 7 15:23:37 2009 From: aturetta at bestunion.it (Angelo Turetta) Date: Wed Jan 7 15:23:43 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <000001c970a8$3fa45240$220f000a@mtl.com> References: <000001c970a8$3fa45240$220f000a@mtl.com> Message-ID: <4964C2E9.1060301@bestunion.it> Yony Yossef wrote: > /sbin/ifconfig vlan3653 create > > Problem is when I assign an IP to the vlan interface. > In that case, unloading the driver results in hanging the host. > > Does it sound familiar to anybody? Well, surely I'd expect problems by doing so. The correct way is to /sbin/ifconfig vlan3653 destroy before unloading the driver. Angelo. From vladislav.yasevich at hp.com Wed Jan 7 15:26:22 2009 From: vladislav.yasevich at hp.com (Vlad Yasevich) Date: Wed Jan 7 15:26:29 2009 Subject: SCTP : problems in sending ASCONF chunks In-Reply-To: References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> <2C477D99-DB2F-4EDB-950F-23856B58ACAB@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E091067E9@ftrdmel2> <835C2156-9DE3-4C96-94F0-C7E3AF63A1BD@lurchi.franken.de> <3418F3471F1CA4409901547349FFAE2E09106883@ftrdmel2> Message-ID: <4964C59B.7050106@hp.com> Randall Stewart wrote: > Aman: > > You may also want to contact Vlad (copied above) who is responsible > for the lk-sctp implementation.. he may be able to direct you to > the one that will have all his latest fixes.. > > Regards To turn on support of ASCONF, you need to turn on at least 2 sysctl variables: net.sctp.auth_enable net.sctp.addip_enable If one of your systems does not support AUTH extension, then you need to turn on: net.sctp.addip_noauth_enable There were issues in older kernels. I'd advise using at least a 2.6.25 kernel from kernel.org. -vlad > > R > On Dec 30, 2008, at 10:59 AM, > wrote: > >> >> Hello M.T?xen, >> >> Today I switched T (the machine I use for testing, and that sends data >> to my PC) to FreeBSD 7.0. And I was very glad to see that my SCTP hard >> handover tests went through successfully :-) >> >> I am very grateful to you, for pointing out that I should check the >> INIT - INIT-ACK exchange, because so far I really didn't understand >> why my tests failed all the time. >> >> About lksctp : up until now, my problems were due to the fact that the >> CN was running under Linux, with the lksctp implementation, and that >> it didn't indicate in the INIT-ACK that it supports ASCONF, ASCONF-ACK >> and AUTH chunks at least, even if we have set the parameter >> net.sctp.addip_enable to 1. These are required for Dynamic Address >> Reconfiguration according to the RFC and very likely in FreeBSD >> implementation for sending ASCONF. >> >> I will perform tests between my PC running under FreeBSD and T running >> on Fedora Core 9 to see if I have better results than what I've had so >> far (since I was using Fedora Core 7). I will keep you updated :-) >> >> Again, thanks a LOT for the help you provided, I'm truly thankful for >> this. >> >> >> Aman Jassal >> >> >> >> -----Message d'origine----- >> De : Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] >> Envoy? : lundi 29 d?cembre 2008 19:00 >> ? : zze-Abac JASSAL A ext RD-RESA-ISS >> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS >> Objet : Re: SCTP : problems in sending ASCONF chunks >> >> Hi Aman, >> >> comments in-line. >> >> Best regards >> Michael >> >> On Dec 29, 2008, at 6:12 PM, >> wrote: >> >>> >>> Hello M.T?xen, >>> >>> I performed a quick test and at the INIT/INIT-ACK exchange, I noticed >>> the following : >>> >>> - In the INIT chunk, the Supported Extensions Parameter field >>> indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET >>> and AUTH are supported >> OK. That is the FreeBSD box. >>> >>> - In the INIT-ACK chunk, there is no field indicating that any of >>> the chunks listed above are supported... >> So it does not support ASCONF and AUTH. >> At least on a Fedora 9 box you need to enable ADD-IP by setting the >> sysctl variable >> net.sctp.addip_enable >> to 1. >> To enable SCTP-AUTH you need to set the sysctl variable >> net.sctp.auth_enable >> to 1. >> I'm not sure whether the Linux box support SCTP-AUTH or not... So the >> second step might not work. If this is the case you can disable the >> AUTH requirement for ASCONF chunks by setting on the FreeBSD box the >> sysctl >> variable >> net.inet.sctp.asconf_auth_nochk >> to 1 >> >> Let me know if this works... >>> >>> >>> I didn't think about looking in this before >_< >>> >>> Since there is no indication given to my PC, perhaps my PC assumes >>> that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, >>> STREAM_RESET and AUTH. >> Correct. At least some of the extension are not enabled. >>> >>> >>> Could it be that, because it doesn't see any Supported Extensions >>> Parameter field in the INIT-ACK, my PC doesn't try to send any >>> ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK >>> and AUTH parameters in the Supported Extensions Parameter, in both >>> the INIT and the INIT-ACK chunks, to have the possibility of sending >>> an ASCONF chunk ? >> In principle, yes! You can work around the AUTH chunks as indicated >> above, but this >> violates the specification and is only supported to interwork with >> legacy implementations. >>> >>> >>> >>> Kind regards >>> >>> >>> Aman Jassal >>> >>> >>> -----Message d'origine----- >>> De : Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] >>> Envoy? : lundi 29 d?cembre 2008 16:49 >>> ? : zze-Abac JASSAL A ext RD-RESA-ISS >>> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS >>> Objet : Re: SCTP : problems in sending ASCONF chunks >>> >>> Hi Aman, >>> >>> I'm not that familiar with the Linux box configuration. If you look >>> at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and >>> the SCTP-AUTH extension? Both are required... >>> >>> Best regards >>> Michael >>> On Dec 29, 2008, at 2:36 PM, >>> >>> wrote: >>> >>>> >>>> Hello M.T?xen, >>>> >>>> No, only the PC is running under FreeBSD 7.0. T is running under >>>> Linux >>>> (kernel version is 2.6.21 and the distribution used is Fedora Core >>>> 7). >>>> SCTP is running on T thanks to the lksctp implementation, we loaded >>>> the sctp module on it and made the necessary configurations so that >>>> it >>>> is loaded at boot time. >>>> >>>> Also, I enable net.sctp.addip_enable=1 on T, just in case, I'm not >>>> exactly sure if it has an effect on my tests. >>>> >>>> Kind regards >>>> >>>> >>>> Aman Jassal >>>> >>>> -----Message d'origine----- >>>> De : Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] >>>> Envoy? : lundi 29 d?cembre 2008 14:09 >>>> ? : zze-Abac JASSAL A ext RD-RESA-ISS >>>> Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : >>>> Re: SCTP : problems in sending ASCONF chunks >>>> >>>> Hi, >>>> >>>> are both machines (T and you PC) running FreeBSD? >>>> >>>> Best regards >>>> Michael >>>> >>>> On Dec 29, 2008, at 12:33 PM, >>>> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I have been working with SCTP and more specifically with the >>>>> mobility >>>>> features of SCTP at my work. Basically, I have been trying to use >>>>> SCTP to perform handover tests between 2 separate Wifi networks. I >>>>> use >>>>> IPv6 >>>>> for all my tests. >>>>> >>>>> I have a local LAN (wired-network), on which I have 3 machines, one >>>>> of them is the machine I use to communicate with for the tests (I'll >>>>> call it T to make things simple), and the other two are used as Wifi >>>>> Access Points (say Wifi1 and Wifi2 respectively). Since I work with >>>>> IPv6, I set up both Access Points to send Router Advertisement >>>>> messages periodically (minimum of 3 seconds, maximum of 4 seconds). >>>>> That way I can have automatic address reconfiguration when I connect >>>>> to either of the access points. >>>>> >>>>> The aim of my tests is to use a PC, connect to Wifi1 (for example), >>>>> launch an SCTP association with T (T sends data to my PC), and then >>>>> perform a handover on Wifi2. I do make address reconfiguration >>>>> during >>>>> the handover process. The important point is that I work with only >>>>> ONE address on my network interface. Before I start my tests, I set >>>>> the following sysctl parameters : >>>>> >>>>> # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w >>>>> net.inet.sctp.mobility_fasthandoff=1 >>>>> # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump >>>>> messages in /var/log/messages) >>>>> >>>>> net.inet.sctp.auto_asconf is set to 1 by default. >>>>> >>>>> I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful >>>>> but I'm trying to be thorough. This is the script I use to perform >>>>> handover >>>>> : >>>>> >>>>> ifconfig rum0 inet6 delete ifconfig rum0 ssid >>>> target access point> route del -inet6 default rtsol >>>>> rum0 >>>>> >>>>> If I'm not mistaken, the PC should have sent an ASCONF chunk to >>>>> perform dynamic address reconfiguration. However what I observed is >>>>> that nothing happens. No ASCONF chunks are sent, and therefore, T >>>>> doesn't ever know that it should send data on the PC's newly >>>>> acquired >>>>> address. >>>>> >>>>> I tried to investigate the problem myself, by adding some debug logs >>>>> in the sctp source code (to see which functions are called during >>>>> the >>>>> handover process), and it seems as if the kernel doesn't ever add an >>>>> ASCONF chunk to send in its queue... But that's just my >>>>> understanding >>>>> of the problem... >>>>> >>>>> I looked up in the CVS repository for answers, and to see the >>>>> various >>>>> changes that were gradually brought on the code. There, I noticed >>>>> that on the revision dating 24th July 2007, changes were made for >>>>> dynamic address reconfiguration : "Change behaviour so that when the >>>>> last address is deleted (auto-asconf on a boudall endpoint) no >>>>> action >>>>> is taken until an address is added ; at that time an ASCONF >>>>> add+delete is sent (if the asoc is still up)" >>>>> >>>>> In my humble opinion, this is exactly the case that corresponds to >>>>> my >>>>> handover scenario. But I just haven't been able to successfully >>>>> perform it because I don't seem to send any ASCONF chunk. I'm >>>>> struggling to understand why I do not see any ASCONF chunk sent. >>>>> >>>>> If it can help, I'm also attaching links to the kind of debug logs I >>>>> got when performing a handover test. This is the kind of debug logs >>>>> that I got : >>>>> >>>>> http://www.divshare.com/download/6200509-560 >>>>> >>>>> This is another debug logfile, but with my own debug logs added in >>>>> the sctp source code : >>>>> >>>>> http://www.divshare.com/download/6200504-2e9 >>>>> >>>>> >>>>> Many thanks for your work, and I hope someone will be able to help >>>>> and shed some light on this problem :-) >>>>> >>>>> >>>>> Aman Jassal >>>>> >>>>> _______________________________________________ >>>>> 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" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > From bmw at wezel.com Wed Jan 7 15:52:44 2009 From: bmw at wezel.com (Bruce Walker) Date: Wed Jan 7 15:52:50 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> Message-ID: <4964CA2E.5090708@wezel.com> Peter Steele wrote: > When our boxes are initially deployed, they have no IP addresses > assigned to them. Their ifconfig entry looks like this: > > ifconfig_lagg0="laggproto failover laggport nfe0 laggport nfe1" > > With this config, no IP is assigned to the lagg0 device, so the only way > to access the boxes is via a serial console. Peter, leaving aside the issue of FreeBSD limited broadcast, have you considered ZeroConf, and in particular the IPv4 Link-Level Addressing portion of it to meet your basic "get the boxes addressed" requirement? http://www.zeroconf.org/ http://files.zeroconf.org/rfc3927.txt I don't have any experience with the lagg device yet, so I don't know if that presents specific issues wrt ipv4ll code. -bmw From bms at FreeBSD.org Wed Jan 7 16:40:51 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Jan 7 16:40:57 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> Message-ID: <4964DB01.7000201@FreeBSD.org> Peter Steele wrote: > .. > > Based on the discussion in the link above, it doesn't seem like the > problem was entirely resolved by the patches mentioned in this thread. > Has anything been done since this discussion took place. Surely there > must be a way to get limited broadcast to work under FreeBSD. > You will need to go to the pcap layer to send limited broadcasts w/o any IPv4 addresses configured in a BSD stack for now. If you have an IP on the interface, you can just use IP_ONESBCAST. thanks BMS > > > _______________________________________________ > 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 sam at freebsd.org Wed Jan 7 17:54:44 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Jan 7 17:54:52 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <000001c970d9$4403e590$220f000a@mtl.com> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> Message-ID: <4964EC4F.8030507@freebsd.org> Yony Yossef wrote: >> Yony Yossef wrote: >> >>> /sbin/ifconfig vlan3653 create >>> >>> Problem is when I assign an IP to the vlan interface. >>> In that case, unloading the driver results in hanging the host. >>> >>> Does it sound familiar to anybody? >>> >> Well, surely I'd expect problems by doing so. >> The correct way is to >> >> /sbin/ifconfig vlan3653 destroy >> >> before unloading the driver. >> >> Angelo. >> > > Thanks, I didn't know freebsd does not allow it. > > This seems wrong. Someone should disallow the driver detach/unload. Please file a PR about this so the issue is not lost. Sam From psteele at maxiscale.com Wed Jan 7 18:37:16 2009 From: psteele at maxiscale.com (Peter Steele) Date: Wed Jan 7 18:37:27 2009 Subject: Having problems with limited broadcast In-Reply-To: <4964DB01.7000201@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <4964DB01.7000201@FreeBSD.org> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479ECA@polaris.maxiscale.com> > You will need to go to the pcap layer to send limited broadcasts w/o any > IPv4 addresses configured in a BSD stack for now. If you have an IP on > the interface, you can just use IP_ONESBCAST. Yes, I can send broadcasts if my box has an IP. Since we are writing our own DHCP-like service though this isn't an option for us, so pcap seems to be the route to go... From jfvogel at gmail.com Wed Jan 7 22:00:03 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Jan 7 22:00:10 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <4964EC4F.8030507@freebsd.org> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> <4964EC4F.8030507@freebsd.org> Message-ID: <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler wrote: > Yony Yossef wrote: > >> Yony Yossef wrote: >>> >>> >>>> /sbin/ifconfig vlan3653 create >>>> >>>> Problem is when I assign an IP to the vlan interface. >>>> In that case, unloading the driver results in hanging the host. >>>> Does it sound familiar to anybody? >>>> >>>> >>> Well, surely I'd expect problems by doing so. >>> The correct way is to >>> >>> /sbin/ifconfig vlan3653 destroy >>> >>> before unloading the driver. >>> >>> Angelo. >>> >>> >> >> Thanks, I didn't know freebsd does not allow it. >> >> >> > This seems wrong. Someone should disallow the driver detach/unload. Please > file a PR about this so the issue is not lost. > > Sam > In many drivers, ahem, like mine, there is a test at detach and it will not allow it if there is a non-NULL trunk. Sounds like a broken driver needs to be fixed is all... Jack From sam at freebsd.org Wed Jan 7 22:35:36 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Jan 7 22:35:41 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> <4964EC4F.8030507@freebsd.org> <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> Message-ID: <49652E25.9030705@freebsd.org> Jack Vogel wrote: > > > On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler > wrote: > > Yony Yossef wrote: > > Yony Yossef wrote: > > > /sbin/ifconfig vlan3653 create > > Problem is when I assign an IP to the vlan interface. > In that case, unloading the driver results in hanging > the host. > Does it sound familiar to anybody? > > > Well, surely I'd expect problems by doing so. > The correct way is to > > /sbin/ifconfig vlan3653 destroy > > before unloading the driver. > > Angelo. > > > > Thanks, I didn't know freebsd does not allow it. > > > > This seems wrong. Someone should disallow the driver > detach/unload. Please file a PR about this so the issue is not lost. > > Sam > > > In many drivers, ahem, like mine, there is a test at detach and it > will not allow it if there > is a non-NULL trunk. > > Sounds like a broken driver needs to be fixed is all... > I don't agree; drivers should not be required to deal with this. If someone files a PR and assigns it to me I'll look at it. Sam From yonyossef.lists at gmail.com Thu Jan 8 08:18:46 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 8 08:19:03 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <49652E25.9030705@freebsd.org> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> <4964EC4F.8030507@freebsd.org> <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> <49652E25.9030705@freebsd.org> Message-ID: <000601c97169$b85717b0$220f000a@mtl.com> > Jack Vogel wrote: > > > > > > On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler > > wrote: > > > > Yony Yossef wrote: > > > > Yony Yossef wrote: > > > > > > /sbin/ifconfig vlan3653 create > > > > Problem is when I assign an IP to the vlan > interface. > > In that case, unloading the driver results > in hanging > > the host. > > Does it sound familiar to anybody? > > > > > > Well, surely I'd expect problems by doing so. > > The correct way is to > > > > /sbin/ifconfig vlan3653 destroy > > > > before unloading the driver. > > > > Angelo. > > > > > > > > Thanks, I didn't know freebsd does not allow it. > > > > > > > > This seems wrong. Someone should disallow the driver > > detach/unload. Please file a PR about this so the issue > is not lost. > > > > Sam > > > > > > In many drivers, ahem, like mine, there is a test at detach and it > > will not allow it if there is a non-NULL trunk. > > > > Sounds like a broken driver needs to be fixed is all... > > > I don't agree; drivers should not be required to deal with > this. If someone files a PR and assigns it to me I'll look at it. > > Sam > I agree with Sam. There's no reason to leave this check to the driver. Yony From linimon at FreeBSD.org Thu Jan 8 08:31:05 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jan 8 08:31:16 2009 Subject: kern/130189: [ndis] [patch] if_ndis typo 802.11 mode test Message-ID: <200901080831.n088V4Qa082321@freefall.freebsd.org> Old Synopsis: [patch] if_ndis typo 802.11 mode test New Synopsis: [ndis] [patch] if_ndis typo 802.11 mode test Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 8 08:30:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130189 From jfvogel at gmail.com Thu Jan 8 09:09:17 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Jan 8 09:09:24 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <000601c97169$b85717b0$220f000a@mtl.com> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> <4964EC4F.8030507@freebsd.org> <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> <49652E25.9030705@freebsd.org> <000601c97169$b85717b0$220f000a@mtl.com> Message-ID: <2a41acea0901080109l6189b379q4a348cc80527e90e@mail.gmail.com> Fine with me, go do it and I'll take the driver code out :) Jack On Thu, Jan 8, 2009 at 12:18 AM, Yony Yossef wrote: > > Jack Vogel wrote: > > > > > > > > > On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler > > > wrote: > > > > > > Yony Yossef wrote: > > > > > > Yony Yossef wrote: > > > > > > > > > /sbin/ifconfig vlan3653 create > > > > > > Problem is when I assign an IP to the vlan > > interface. > > > In that case, unloading the driver results > > in hanging > > > the host. > > > Does it sound familiar to anybody? > > > > > > > > > Well, surely I'd expect problems by doing so. > > > The correct way is to > > > > > > /sbin/ifconfig vlan3653 destroy > > > > > > before unloading the driver. > > > > > > Angelo. > > > > > > > > > > > > Thanks, I didn't know freebsd does not allow it. > > > > > > > > > > > > This seems wrong. Someone should disallow the driver > > > detach/unload. Please file a PR about this so the issue > > is not lost. > > > > > > Sam > > > > > > > > > In many drivers, ahem, like mine, there is a test at detach and it > > > will not allow it if there is a non-NULL trunk. > > > > > > Sounds like a broken driver needs to be fixed is all... > > > > > I don't agree; drivers should not be required to deal with > > this. If someone files a PR and assigns it to me I'll look at it. > > > > Sam > > > > I agree with Sam. There's no reason to leave this check to the driver. > > Yony > > From psteele at maxiscale.com Thu Jan 8 19:16:50 2009 From: psteele at maxiscale.com (Peter Steele) Date: Thu Jan 8 19:16:57 2009 Subject: Having problems with limited broadcast In-Reply-To: <4964CA2E.5090708@wezel.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> >Peter, leaving aside the issue of FreeBSD limited broadcast, have you >considered ZeroConf, and in particular the IPv4 Link-Level Addressing >portion of it to meet your basic "get the boxes addressed" requirement? > >http://www.zeroconf.org/ >http://files.zeroconf.org/rfc3927.txt > >I don't have any experience with the lagg device yet, so I don't know if >that presents specific issues wrt ipv4ll code. I just found your email in my junk email folder. For some reason my filter didn't like it. Thanks for the suggestion though. I'm not familiar with ZeroConf; I'll check it out. The lagg device should not be a problem. It appears as a normal Ethernet device as far as the OS is concerned. Peter From adrian at freebsd.org Thu Jan 8 20:14:37 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jan 8 20:15:08 2009 Subject: Julian's source IP address spoofing - code review requested Message-ID: G'day all, I've finally gotten around to pulling apart some of Julian Elischer's work on the source IP address spoofing stuff and I've been testing it on my local squid-2 fork (cacheboy.) I'd appreciate some comments and review before I begin committing bits of it to freebsd-current. The work will be available here, including a brief description of what is going on: http://people.freebsd.org/~adrian/sys/spoof_bind/ I'd first like to commit the core changes which introduce a new compile option, sysctl and IP option to enable a non-local IP address in bind(). That in itself is enough to at least begin testing under -current and releng_7. The diff against -current for this first phase is available here: http://people.freebsd.org/~adrian/sys/spoof_bind/spoof_bind_sys.diff I'm currently running just this patch on a machine in the netperf cluster which is acting as a transparent HTTP interception thing. It seems to handle "moderate" request rates (~1500 socket creations a second, ~150mbit). This first patch is pretty straight forward and I'm reasonably confident that it won't break anything in -current or releng_7 which isn't already broken. There are other changes to IPFW and the bridging code which I'll ask to be reviewed separately. Thanks! Adrian From julian at elischer.org Thu Jan 8 20:55:24 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Jan 8 20:55:32 2009 Subject: Julian's source IP address spoofing - code review requested In-Reply-To: References: Message-ID: <49666189.9010406@elischer.org> Adrian Chadd wrote: > G'day all, > > I've finally gotten around to pulling apart some of Julian Elischer's > work on the source IP address spoofing stuff and I've been testing it > on my local squid-2 fork (cacheboy.) > > I'd appreciate some comments and review before I begin committing bits > of it to freebsd-current. > > The work will be available here, including a brief description of what > is going on: > > http://people.freebsd.org/~adrian/sys/spoof_bind/ Well the for_me rule in ipfw may have similar problems that the uid rules had WRT Lock order. I notice you are using a read lock which may solve that problem. I see you always call ether_demux when a packet is moved up.. hopefully that will also work if an interface is NOT ethernet? hey I know I originally wrote this but it's been a while and I must say I was following tracks made by others, and we are using aonly a subset of possible hardware... > > I'd first like to commit the core changes which introduce a new > compile option, sysctl and IP option to enable a non-local IP address > in bind(). That in itself is enough to at least begin testing under > -current and releng_7. the logical equivalent of this code (not prettied up) has been in Ironport's FreeBSD since 4.x. The code in if_bridge is new as we used the old bridge code, but it 's logically similar. FYI we will probably switch to a single netgraph node that does bridging and filtering combined in 7.x :-) > > The diff against -current for this first phase is available here: > > http://people.freebsd.org/~adrian/sys/spoof_bind/spoof_bind_sys.diff > > I'm currently running just this patch on a machine in the netperf > cluster which is acting as a transparent HTTP interception thing. It > seems to handle "moderate" request rates (~1500 socket creations a > second, ~150mbit). This first patch is pretty straight forward and I'm > reasonably confident that it won't break anything in -current or > releng_7 which isn't already broken. > For others, this is a patch that allows the proxy to be a "bump on the wire" It is proxying between two segments of the same subnet, completely transparently (assuming you do server side spoofing too.) > There are other changes to IPFW and the bridging code which I'll ask > to be reviewed separately. > > Thanks! > > > > Adrian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From psteele at maxiscale.com Thu Jan 8 21:21:48 2009 From: psteele at maxiscale.com (Peter Steele) Date: Thu Jan 8 21:21:56 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com><2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com><4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> > Thanks for the suggestion though. I'm not familiar with ZeroConf; I'll > check it out. ZeroConf is an interesting concept. Unfortunately it restricts IPs to the 169.254/16 range and it is very likely some of our customers will want to be able to configure our boxes to an IP range of their own choosing. That's the biggest concern we have with this facility. It's definitely attractive, but I don't think we can use unfortunately. From linimon at FreeBSD.org Thu Jan 8 21:41:11 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jan 8 21:41:22 2009 Subject: kern/130311: [wlan_xauth] [panic] hostapd restart causing kernel panic Message-ID: <200901082141.n08LfAfV082898@freefall.freebsd.org> Old Synopsis: [wlan_xauth] hostapd restart causing kernel panic New Synopsis: [wlan_xauth] [panic] hostapd restart causing kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 8 21:40:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130311 From adrian at freebsd.org Thu Jan 8 22:11:40 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jan 8 22:11:46 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> Message-ID: If this is all going over an L2 LAN, why not do the initial discovery and general configuration exchange over IPv6? :P Link layer network-scope addresses to the rescue. (think: just like apple wireless base stations and MacOSX hosts doing configuration do..) Adrian 2009/1/8 Peter Steele : >> Thanks for the suggestion though. I'm not familiar with ZeroConf; I'll >> check it out. > > ZeroConf is an interesting concept. Unfortunately it restricts IPs to > the 169.254/16 range and it is very likely some of our customers will > want to be able to configure our boxes to an IP range of their own > choosing. That's the biggest concern we have with this facility. It's > definitely attractive, but I don't think we can use unfortunately. > > > _______________________________________________ > 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 adrian at freebsd.org Thu Jan 8 22:18:16 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jan 8 22:18:23 2009 Subject: Julian's source IP address spoofing - code review requested In-Reply-To: <49666189.9010406@elischer.org> References: <49666189.9010406@elischer.org> Message-ID: 2009/1/8 Julian Elischer : > I see you always call ether_demux when a packet is moved up.. s/you/you/ :) This is all your stuff IIRC, I just ported and commented as required. > hopefully that will also work if an interface is NOT ethernet? this is why i left the ethernet bridge interception stuff out in a seperate diff. I'll commit it only once I've spoken to bridge-cluey people and have their blessing. > hey I know I originally wrote this but it's been a while and > I must say I was following tracks made by others, and we > are using aonly a subset of possible hardware... Well, its entirely possible this stuff will be deployed in two scenarios: * where its all done at the IP layer, eg policy routing, IPFW * where its being done as part of a transparent ethernet bridge > FYI we will probably switch to a single netgraph node that > does bridging and filtering combined in 7.x :-) That'd certainly be nicer. ;) About the only thing I'm looking to add to this later on is to flesh out IPv6 source address spoofing too, just in case V6 catches on. Adrian From psteele at maxiscale.com Thu Jan 8 22:39:12 2009 From: psteele at maxiscale.com (Peter Steele) Date: Thu Jan 8 22:39:18 2009 Subject: Having problems with limited broadcast In-Reply-To: References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> >If this is all going over an L2 LAN, why not do the initial discovery >and general configuration exchange over IPv6? :P Link layer >network-scope addresses to the rescue. > >(think: just like apple wireless base stations and MacOSX hosts doing >configuration do..) It's really a matter of time. We didn't anticipate limited broadcast being broken in FreeBSD and we're scrambling to come up with a solution. To be quite frank I haven't done anything with IPv6 before so it would be more research to get up to speed on this option. It seems our best option is scapy, which unfortunately I also haven't used before... From bms at FreeBSD.org Thu Jan 8 23:29:56 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jan 8 23:30:03 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> Message-ID: <49668C71.4090407@FreeBSD.org> Peter Steele wrote: > ... > It's really a matter of time. We didn't anticipate limited broadcast > being broken in FreeBSD and we're scrambling to come up with a solution. > To be quite frank I haven't done anything with IPv6 before so it would > be more research to get up to speed on this option. It seems our best > option is scapy, which unfortunately I also haven't used before... > It's not broken -- it has always been this way in all BSD derived networking stacks. Limited broadcast addresses just don't contain any information about where the datagram should go, and this is the case in all other implementations. They are similar to multicast addresses in that regard. Linux has a knob SO_BINDTODEVICE which is partly there to workaround this problem, however it isn't the ideal semantic fit. The folk who point out that link-local addresses could be used, have an interesting suggestion which might work for you. thanks BMS From psteele at maxiscale.com Fri Jan 9 00:50:44 2009 From: psteele at maxiscale.com (Peter Steele) Date: Fri Jan 9 00:50:51 2009 Subject: Having problems with limited broadcast In-Reply-To: <49668C71.4090407@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> <49668C71.4090407@FreeBSD.org> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FF9@polaris.maxiscale.com> > The folk who point out that link-local addresses could be used, have an > interesting suggestion which might work for you. It's definitely interesting, but it is very likely that some of our customers will want to be able to set their own IP ranges and not be limited to 169.254/16. So we need a more generic solution. From bmw at wezel.com Fri Jan 9 01:04:21 2009 From: bmw at wezel.com (Bruce Walker) Date: Fri Jan 9 01:04:28 2009 Subject: Having problems with limited broadcast In-Reply-To: <49668C71.4090407@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> <49668C71.4090407@FreeBSD.org> Message-ID: <4966A283.4070505@wezel.com> Bruce M. Simpson wrote: > > The folk who point out that link-local addresses could be used, have > an interesting suggestion which might work for you. Peter, I understand your issue with the (apparent) restriction of the 169.254/16 range, though I'd point out that the IPv4-LL addressing scheme is considered a fall-back plan by most systems implementors. Your systems could look for DHCP first then failing that, drop back to IPv4-LL and get an address. The picky customers would simply be required to supply a DHCP server. Everyone else presumably doesn't care as long as the boxes can communicate. But there's another useful point to pickup from the ZeroConf stuff. I implemented a small standalone IPv4-LLA daemon using libevent, libnet and libpcap. IPv4-LLA needs to muck around with a completely unaddressed interface (like you are doing with your DHCP-lite), sending and listening-for broadcast and directed ARP packets, per RFC 3927. It was trivial to do this in a completely portable way using libpcap and libnet. I'd highly recommend to you that you link those libraries into your Python DHCP-lite app and you will be able to deploy relatively painlessly on any platform that those libraries are ported to. http://sourceforge.net/projects/pylibpcap/ http://pylibnet.sourceforge.net/ Cheers! -bmw From bms at FreeBSD.org Fri Jan 9 01:08:54 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Jan 9 01:09:02 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F2479FF9@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> <49668C71.4090407@FreeBSD.org> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FF9@polaris.maxiscale.com> Message-ID: <4966A3A2.7030001@FreeBSD.org> Peter Steele wrote: >> The folk who point out that link-local addresses could be used, have >> > an > >> interesting suggestion which might work for you. >> > > It's definitely interesting, but it is very likely that some of our > customers will want to be able to set their own IP ranges and not be > limited to 169.254/16. So we need a more generic solution. Sounds like it's bpf/pcap city for you guys. A similar bump-in-the-stack to SO_BINDTODEVICE, e.g. let's call it IP_SENDIF has been on the drawing board, but it needs appropriate security screening -- the ability to bypass the forwarding tables, whilst specifying an interface e.g. by index or name, would be desirable only for certain privileged processes. BTW: If you guys are already looking at scapy, you may also wish to give pcs.sourceforge.net a look as an alternative. It is a Python project which I did some hacking on with George Neville-Neill who started it. It has BPF/PCAP support out of the box and has a number of powerful features, including a packet-level expect() facility, which works in a very similar manner to pexpect (Python expect for text streams). I added a scapy-like concatenation syntax ('/' operator) to it as that makes plugging packet chains together that much easier. I have the beginnings of an IGMPv3 test suite in my home repo written using PCS, it uses pcap capture. I imagine a DHCP like protocol could easily be implemented using PCS too. cheers BMS From weongyo at FreeBSD.org Fri Jan 9 01:19:50 2009 From: weongyo at FreeBSD.org (weongyo@FreeBSD.org) Date: Fri Jan 9 01:19:55 2009 Subject: kern/130189: [ndis] [patch] if_ndis typo 802.11 mode test Message-ID: <200901090119.n091JnYD039658@freefall.freebsd.org> Synopsis: [ndis] [patch] if_ndis typo 802.11 mode test Responsible-Changed-From-To: freebsd-net->weongyo Responsible-Changed-By: weongyo Responsible-Changed-When: Fri Jan 9 01:19:18 UTC 2009 Responsible-Changed-Why: Grab it. http://www.freebsd.org/cgi/query-pr.cgi?pr=130189 From bmw at wezel.com Fri Jan 9 01:25:06 2009 From: bmw at wezel.com (Bruce Walker) Date: Fri Jan 9 01:25:13 2009 Subject: Having problems with limited broadcast In-Reply-To: <4966A283.4070505@wezel.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> <49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> Message-ID: <4966A76A.5070409@wezel.com> Bruce Walker wrote: > It was trivial to do this in a completely portable way using libpcap > and libnet. Sorry, typo: I actually meant to say libdnet -- a different but similar package. Also with Python bindings. http://libdnet.sourceforge.net/ -bmw From psteele at maxiscale.com Fri Jan 9 04:50:26 2009 From: psteele at maxiscale.com (Peter Steele) Date: Fri Jan 9 04:50:33 2009 Subject: Having problems with limited broadcast In-Reply-To: <4966A283.4070505@wezel.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> >Peter, I understand your issue with the (apparent) restriction of the >169.254/16 range, though I'd point out that the IPv4-LL addressing >scheme is considered a fall-back plan by most systems implementors. >Your systems could look for DHCP first then failing that, drop back to >IPv4-LL and get an address. The picky customers would simply be >required to supply a DHCP server. Everyone else presumably doesn't care >as long as the boxes can communicate. I personally like this idea, but I'm not sure I can sell it to the others. Are there any restrictions to these 169.254.x.y addresses? Although our boxes systems operate as a cluster, there do need to be externally addressable. If there are no restrictions in how these link local addresses appear in a company LAN, then I don't think there would be a problem. The question is, if a picky customer doesn't want to use this range, will they be agreeable to providing a DHCP server for our use? The customer often has a lot of leverage in these matters unfortunately. >But there's another useful point to pickup from the ZeroConf stuff. I >implemented a small standalone IPv4-LLA daemon using libevent, libnet >and libpcap. IPv4-LLA needs to muck around with a completely >unaddressed interface (like you are doing with your DHCP-lite), sending >and listening-for broadcast and directed ARP packets, per RFC 3927. It >was trivial to do this in a completely portable way using libpcap and >libnet. I'd highly recommend to you that you link those libraries into >your Python DHCP-lite app and you will be able to deploy relatively >painlessly on any platform that those libraries are ported to. We need broadcast support for both Java and Python and we're currently looking at a relatively simple solution using scapy. If that doesn't work out I'm sure we may have to delve into libnet/libpcap. Thanks for your feedback. Peter From psteele at maxiscale.com Fri Jan 9 04:51:59 2009 From: psteele at maxiscale.com (Peter Steele) Date: Fri Jan 9 04:52:05 2009 Subject: Having problems with limited broadcast In-Reply-To: <4966A3A2.7030001@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com> <49668C71.4090407@FreeBSD.org> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FF9@polaris.maxiscale.com> <4966A3A2.7030001@FreeBSD.org> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A00F@polaris.maxiscale.com> > BTW: If you guys are already looking at scapy, you may also wish to give > pcs.sourceforge.net a look as an alternative. I didn't come across that in my research. I'll have to check it out. Thanks. Peter From bms at FreeBSD.org Fri Jan 9 06:09:54 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Jan 9 06:10:00 2009 Subject: Having problems with limited broadcast In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> Message-ID: <4966EA2F.5040603@FreeBSD.org> Peter Steele wrote: > ... > I personally like this idea, but I'm not sure I can sell it to the > others. Are there any restrictions to these 169.254.x.y addresses? > 169.254.0.0/16 must never appear outside a link -- it is strictly scoped to that link. Currently the IPv4 BSD stack has no concept of link-scoped addresses, but IPv6 does. Link is a realized concept there because of KAME's support for the % syntax. Internally, interface indexes get used. In practice this shouldn't be an issue as long as you can guarantee different addresses are used for the 169.254.0.0/16 block on each interface, however, it would mean any app using sockets would need to explicitly bind to the local address to ensure the correct interface is used. Furthermore, we effectively need to be able to support multiple next-hops for the 169.254.0.0/16 prefix, otherwise we can support only one such interface w/o significant kernel code rewrites. So, really, LL may not buy you anything at all, and it's likely you need to go straight to pcap for your app. These restrictions have existed for years, and the fact that they haven't been addressed has largely been because there has been no community strategy to deal with it. I speculate some BSD-using organisations might have already solved these problems, however, without evidence (and code sharing), that's pure speculation. cheers BMS From bms at FreeBSD.org Fri Jan 9 06:14:09 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Jan 9 06:14:15 2009 Subject: Having problems with limited broadcast In-Reply-To: <4966EA2F.5040603@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> <4966EA2F.5040603@FreeBSD.org> Message-ID: <4966EB2E.7010301@FreeBSD.org> Bruce M. Simpson wrote: > Peter Steele wrote: >> ... >> I personally like this idea, but I'm not sure I can sell it to the >> others. Are there any restrictions to these 169.254.x.y addresses? >> > > 169.254.0.0/16 must never appear outside a link -- it is strictly > scoped to that link. P.S. I checked in a change to ip_forward() a while back which enforces this, as forwarding such traffic between interfaces without NATting it or otherwise proxying it is a really bad idea (and also breaks the IPv4 LL RFC). From julian at elischer.org Fri Jan 9 07:40:50 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 9 07:40:56 2009 Subject: Having problems with limited broadcast In-Reply-To: <4966EA2F.5040603@FreeBSD.org> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> <4966EA2F.5040603@FreeBSD.org> Message-ID: <4966F8E9.90002@elischer.org> Bruce M. Simpson wrote: > Peter Steele wrote: >> ... >> I personally like this idea, but I'm not sure I can sell it to the >> others. Are there any restrictions to these 169.254.x.y addresses? >> > > 169.254.0.0/16 must never appear outside a link -- it is strictly scoped > to that link. > > Currently the IPv4 BSD stack has no concept of link-scoped addresses, > but IPv6 does. Link is a realized concept there because of KAME's > support for the % syntax. Internally, interface indexes get used. > > In practice this shouldn't be an issue as long as you can guarantee > different addresses are used for the 169.254.0.0/16 block on each > interface, however, it would mean any app using sockets would need to > explicitly bind to the local address to ensure the correct interface is > used. Furthermore, we effectively need to be able to support multiple > next-hops for the 169.254.0.0/16 prefix, otherwise we can support only > one such interface w/o significant kernel code rewrites. we now have multiple routing tables, multiple default routes, and per interface arp tables, so we can now do more of this than before. we can now support two interfaces with different instantiations of the same range by assigning them only in one routing table each. With Vimage you'll be able to do more.... > > So, really, LL may not buy you anything at all, and it's likely you need > to go straight to pcap for your app. These restrictions have existed for > years, and the fact that they haven't been addressed has largely been > because there has been no community strategy to deal with it. I > speculate some BSD-using organisations might have already solved these > problems, however, without evidence (and code sharing), that's pure > speculation. > > cheers > BMS > _______________________________________________ > 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 guru at unixarea.de Fri Jan 9 08:48:47 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Jan 9 08:48:55 2009 Subject: FreeBSD 7.0R && ADSL Message-ID: <20090109083642.GA7507@rebelion.Sisis.de> Hello, I've at home a connection of ISDN-BRI and ADSL to my phone/Internet provider; BRI and ADSL get splitted in a so called ISDN-splitter, from which a line goes to a DSL modem (Thomson speedTouch 536i) which is connected via Ethernet to a WLAN/WAN router (SMCWBR14-G2). Actually I have the problem that DSL is not connecting (while BRI is fine). The WLAN of the router is fine too, i.e. I can connect to the router management interface (HTTP), but this does not give much help on trouble-shooting. I have had this already sometimes in the past and I want to nail this down and kicking out the WLAN/WAN router, connecting my FreeBSD laptop directly to the DSL modem. The router has a configured PPPoE connection for the WAN interface. What kind of software I could use in FreeBSD? There is some port net/rp-pppoe but the man pages speaks about incoming connections? What else? I'm hoping that with better log files directly on the FreeBSD side I can figure out what's wrong with my DSL line/provider/modem? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion From gerald at pfeifer.com Fri Jan 9 09:27:31 2009 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Fri Jan 9 09:27:40 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: On Tue, 30 Dec 2008, Li, Qing wrote: > I don't think we can provide binary compatibility without putting > back RTF_LLINFO exactly as it was. My preference is to continue down > the new path without RTF_LLINFO. So, you are saying that applications built on FreeBSD 7 or earlier that use RTF_LLINFO will no longer work properly on FreeBSD 8 after your change? Ignoring everything else, that would be a killer and the one reason to definitely change the current situation. Otherwise, ISVs will need two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux distributions do provide this level of compatibility.) > We still have some time before the 8.0 release. It's straightforward > for me to retain some of the RTF_LLINFO support in the new kernel if > and when the situation becomes necessary. Sounds like that is the case? > Since the affected ports now have the conditional code around > RTF_LLINFO, the updates would allow these ports to compile in > both -current and in the previous releases. emulators/wine still is broken, and upstream Wine has not accepted the patch yet. I believe one reason likely is the above, and the fact that this may break commercial builds of Wine. How are you going to address this? Gerald -- Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ From bms at incunabulum.net Fri Jan 9 19:59:37 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Jan 9 19:59:49 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: <4967ACA5.6080502@incunabulum.net> +1 for introducing RTF_LLINFO backwards compatibility. I had to sneak in a fix to XORP and pretty much broke release protocol to do so. From auryn at zirakzigil.org Sat Jan 10 08:57:43 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Sat Jan 10 08:57:51 2009 Subject: NATT patch on current Message-ID: <49685F15.7080605@zirakzigil.org> I just wanted to report that the nat-traversal patch on HEAD 2008-03-19 fails to apply cleanly. The problem is in the file ipsec.c lines 1847, 1870 Any news for the natt integration in CURRENT? Thanks. From mav at FreeBSD.org Sat Jan 10 09:13:47 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Jan 10 09:13:53 2009 Subject: FreeBSD 7.0R && ADSL In-Reply-To: <1231503783.00057946.1231491001@10.7.7.3> References: <1231503783.00057946.1231491001@10.7.7.3> Message-ID: <496866CE.7050707@FreeBSD.org> Matthias Apitz wrote: > What kind of software I could use in FreeBSD? There is some port > net/rp-pppoe but the man pages speaks about incoming connections? > What else? net/mpd5 -- Alexander Motin From vanhu at FreeBSD.org Sat Jan 10 10:04:00 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Sat Jan 10 10:04:08 2009 Subject: NATT patch on current In-Reply-To: <49685F15.7080605@zirakzigil.org> References: <49685F15.7080605@zirakzigil.org> Message-ID: <20090110100357.GB2718@zeninc.net> Hi. On Sat, Jan 10, 2009 at 09:40:53AM +0100, Giulio Ferro wrote: > I just wanted to report that the nat-traversal patch on HEAD 2008-03-19 > fails to apply cleanly. > The problem is in the file ipsec.c lines 1847, 1870 > > Any news for the natt integration in CURRENT? Thanks for the report. I'm currently working on cleaning the PFKey part of the patch (available on Perforce if you're interested, and I hope our tests to be ok in a few days, so I'll send kernel+userland patch for public test/review), so I don't use anymore the public version of the patch for TRUNK. I'll be mostly AFK for the next 2-3 days, but I'll try to find quickly some time to update the public patch soon. Yvan. From bzeeb-lists at lists.zabbadoz.net Sat Jan 10 10:25:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Jan 10 10:25:14 2009 Subject: NATT patch on current In-Reply-To: <20090110100357.GB2718@zeninc.net> References: <49685F15.7080605@zirakzigil.org> <20090110100357.GB2718@zeninc.net> Message-ID: <20090110102213.Y45399@maildrop.int.zabbadoz.net> On Sat, 10 Jan 2009, VANHULLEBUS Yvan wrote: Hi, > On Sat, Jan 10, 2009 at 09:40:53AM +0100, Giulio Ferro wrote: >> I just wanted to report that the nat-traversal patch on HEAD 2008-03-19 >> fails to apply cleanly. >> The problem is in the file ipsec.c lines 1847, 1870 >> >> Any news for the natt integration in CURRENT? > > Thanks for the report. > I'm currently working on cleaning the PFKey part of the patch > (available on Perforce if you're interested, and I hope our tests to > be ok in a few days, so I'll send kernel+userland patch for public > test/review), so I don't use anymore the public version of the patch > for TRUNK. > > I'll be mostly AFK for the next 2-3 days, but I'll try to find quickly > some time to update the public patch soon. There is more to the patch and current: it failes in in_pcb.h now as well -- there is a 0x2000 (or 0x1000) that is officially used now. I wondered if rrs' generic udp tunnel hack would apply to this as well but I haven't looked at the code yet. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From auryn at zirakzigil.org Sat Jan 10 11:46:23 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Sat Jan 10 11:46:30 2009 Subject: NATT patch on current In-Reply-To: <20090110100357.GB2718@zeninc.net> References: <49685F15.7080605@zirakzigil.org> <20090110100357.GB2718@zeninc.net> Message-ID: <49688A88.4080503@zirakzigil.org> VANHULLEBUS Yvan wrote: > Hi. > > On Sat, Jan 10, 2009 at 09:40:53AM +0100, Giulio Ferro wrote: > >> I just wanted to report that the nat-traversal patch on HEAD 2008-03-19 >> fails to apply cleanly. >> The problem is in the file ipsec.c lines 1847, 1870 >> >> Any news for the natt integration in CURRENT? >> > > Thanks for the report. > I'm currently working on cleaning the PFKey part of the patch > (available on Perforce if you're interested, and I hope our tests to > be ok in a few days, so I'll send kernel+userland patch for public > test/review), so I don't use anymore the public version of the patch > for TRUNK. > > I'll be mostly AFK for the next 2-3 days, but I'll try to find quickly > some time to update the public patch soon. > > Thanks, looking forward to it... :-) From skip at menantico.com Sat Jan 10 11:55:03 2009 From: skip at menantico.com (Skip Ford) Date: Sat Jan 10 11:55:10 2009 Subject: FreeBSD 7.0R && ADSL In-Reply-To: <20090109083642.GA7507@rebelion.Sisis.de> References: <20090109083642.GA7507@rebelion.Sisis.de> Message-ID: <20090110105455.GA932@menantico.com> Matthias Apitz wrote: > What kind of software I could use in FreeBSD? There is some port > net/rp-pppoe but the man pages speaks about incoming connections? > What else? Are you having problems using ppp(8)? PPPoE has been just another dialup connection for years. Example configurations are available in /usr/share/examples/ppp. If you really want a port, net/mpd is the way to go. ppp(8) is userland while mpd is kernel. I wish it was in base. -- Skip From guru at unixarea.de Sat Jan 10 15:35:43 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sat Jan 10 15:35:50 2009 Subject: FreeBSD 7.0R && ADSL In-Reply-To: <20090110105455.GA932@menantico.com> References: <20090109083642.GA7507@rebelion.Sisis.de> <20090110105455.GA932@menantico.com> Message-ID: <20090110152531.GA32657@rebelion.Sisis.de> El d?a Saturday, January 10, 2009 a las 05:54:56AM -0500, Skip Ford escribi?: > Matthias Apitz wrote: > > What kind of software I could use in FreeBSD? There is some port > > net/rp-pppoe but the man pages speaks about incoming connections? > > What else? > > Are you having problems using ppp(8)? PPPoE has been just another > dialup connection for years. Example configurations are available in > /usr/share/examples/ppp. > > If you really want a port, net/mpd is the way to go. ppp(8) is userland > while mpd is kernel. I wish it was in base. Thanks for all the hints. The problem was that for many years I have only used 'normal' pppd connections (over modems, ISDN or UMTS), but never PPPoE. So I went to the ports and did search 'name=pppoe' and ended up in net/rp-pppoe and was confused. It seems that just ppp(8) is what I have to use. Thx again. matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion From skip at menantico.com Sat Jan 10 13:15:26 2009 From: skip at menantico.com (Skip Ford) Date: Sat Jan 10 13:15:33 2009 Subject: FreeBSD 7.0R && ADSL In-Reply-To: <20090110152531.GA32657@rebelion.Sisis.de> References: <20090109083642.GA7507@rebelion.Sisis.de> <20090110105455.GA932@menantico.com> <20090110152531.GA32657@rebelion.Sisis.de> Message-ID: <20090110210250.GA894@menantico.com> Matthias Apitz wrote: > El día Saturday, January 10, 2009 a las 05:54:56AM -0500, Skip Ford escribió: > > Matthias Apitz wrote: > > > What kind of software I could use in FreeBSD? There is some port > > > net/rp-pppoe but the man pages speaks about incoming connections? > > > What else? > > > > Are you having problems using ppp(8)? PPPoE has been just another > > dialup connection for years. Example configurations are available in > > /usr/share/examples/ppp. > > > > If you really want a port, net/mpd is the way to go. ppp(8) is userland > > while mpd is kernel. I wish it was in base. > > Thanks for all the hints. The problem was that for many years I have > only used 'normal' pppd connections (over modems, ISDN or UMTS), but > never PPPoE. So I went to the ports and did search 'name=pppoe' and > ended up in net/rp-pppoe and was confused. It seems that just ppp(8) is > what I have to use. Thx again. Yeah, pppd(8) doesn't do PPPoE AFAIK. In addition to the examples I already posted, there's a PPPoE section in the handbook which covers everything instead of just ppp.conf: http://www.freebsd.org/doc/en/books/handbook/pppoe.html Good luck. -- Skip From smithi at nimnet.asn.au Sat Jan 10 18:44:53 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jan 10 18:45:00 2009 Subject: FreeBSD 7.0R && ADSL In-Reply-To: <20090110210250.GA894@menantico.com> References: <20090109083642.GA7507@rebelion.Sisis.de> <20090110105455.GA932@menantico.com> <20090110152531.GA32657@rebelion.Sisis.de> <20090110210250.GA894@menantico.com> Message-ID: <20090111132334.S21590@sola.nimnet.asn.au> On Sat, 10 Jan 2009, Skip Ford wrote: > Matthias Apitz wrote: > > El día Saturday, January 10, 2009 a las 05:54:56AM -0500, Skip Ford escribió: > > > Matthias Apitz wrote: > > > > What kind of software I could use in FreeBSD? There is some port > > > > net/rp-pppoe but the man pages speaks about incoming connections? > > > > What else? > > > > > > Are you having problems using ppp(8)? PPPoE has been just another > > > dialup connection for years. Example configurations are available in > > > /usr/share/examples/ppp. > > > > > > If you really want a port, net/mpd is the way to go. ppp(8) is userland > > > while mpd is kernel. I wish it was in base. I was going to say that being in ports isn't too far away, but then realised that unless it's in base it can't be used for installation .. so +1 on that wish. > > Thanks for all the hints. The problem was that for many years I have > > only used 'normal' pppd connections (over modems, ISDN or UMTS), but > > never PPPoE. So I went to the ports and did search 'name=pppoe' and > > ended up in net/rp-pppoe and was confused. It seems that just ppp(8) is > > what I have to use. Thx again. > > Yeah, pppd(8) doesn't do PPPoE AFAIK. In addition to the examples I > already posted, there's a PPPoE section in the handbook which covers > everything instead of just ppp.conf: > > http://www.freebsd.org/doc/en/books/handbook/pppoe.html That section maybe could suggest mpd as an alternative, too. When I first was setting up for pppoe Bruce Simpson strongly urged me to try mpd instead, which was advice that I'm still appreciating. Last I heard, pppd(8) was getting close to being deprecated (not to suggest that ppp(8) using pppoe is in any similar state of neglect) cheers, Ian From jd at ods.org Sun Jan 11 12:35:16 2009 From: jd at ods.org (Jason DiCioccio) Date: Sun Jan 11 12:35:47 2009 Subject: Still trying to debug mbuf leak.. Anyone familiar with uma_*? Message-ID: <496A5800.5080506@ods.org> So I've got various vmcores here from kmem_malloc failures.. I already know that it's an excess of mbufs that's causing the crash, I'm just trying to figure out what the mbufs contain so that I can try and figure out where they came from.. Currently I'm able to get at (uma_zone_t)zone_mbuf, but I'm unsure how to get to the actual mbuf data from there. I've tried looking the the uma_keg, etc. No luck so far. Is there anyone familiar with these data structures that could point me in the right direction? (kgdb) p *zone_mbuf $66 = {uz_name = 0xc076d6d1 "mbuf", uz_lock = 0xc1048108, uz_keg = 0xc1048100, uz_link = {le_next = 0xc1047180, le_prev = 0xc104812c}, uz_full_bucket = { lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, uz_ctor = 0xc05068f0 , uz_dtor = 0xc0507040 , uz_init = 0, uz_fini = 0, uz_allocs = 137806761, uz_frees = 136018292, uz_fails = 136, uz_fills = 4, uz_count = 128, uz_cpu = {{ uc_freebucket = 0xc73a8c48, uc_allocbucket = 0x0, uc_allocs = 0, uc_frees = 0}}} Thanks! -JD- From joost at jodocus.org Sun Jan 11 13:31:14 2009 From: joost at jodocus.org (Joost Bekkers) Date: Sun Jan 11 13:31:20 2009 Subject: pxeboot(8) after pxelinux Message-ID: <1694.192.168.100.227.1231708456.squirrel@jodocus.org> Hello I've been playing with chainloading pxeboot after pxelinux and its menu feature. It's working, but I had to do something weird. I'm wondering if anybody can come up with a logical explanation. (and feeding the search engines for people experiencing the same problem is a nice added bonus) After pxeboot starts it first does a dhcp request and proceeds to load /boot/loader.rc, which fails if pxelinux was part of the process. tftp requests leave the host, answers are send back, but are ignored by the client and the download times out. The loader then proceeds to try /boot/boot.conf, this succeeds (read: the client receives a ENOTFOUND and reacts accordingly. It does NOT time-out) The only significant event I could find between the two downloads was the closing and re-opening of the pxe socket (netif_close() and netif_open()) And indeed if I add netif_close() and netif_open() to the dhcp code in pxe_open() everything works. I checked the pxe documentation and didn't see anything about not being allowed to receive packets on different ports, the API looks to have been written to specificaly support it. I don't think pxeboot is at fault here, but I'd really like to know if there is a good explanation for this behaviour. Thanks, Joost Bekkers From rwatson at FreeBSD.org Sun Jan 11 14:54:22 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jan 11 14:54:33 2009 Subject: Still trying to debug mbuf leak.. Anyone familiar with uma_*? In-Reply-To: <496A5800.5080506@ods.org> References: <496A5800.5080506@ods.org> Message-ID: On Sun, 11 Jan 2009, Jason DiCioccio wrote: > So I've got various vmcores here from kmem_malloc failures.. I already know > that it's an excess of mbufs that's causing the crash, I'm just trying to > figure out what the mbufs contain so that I can try and figure out where > they came from.. > > Currently I'm able to get at (uma_zone_t)zone_mbuf, but I'm unsure how to > get to the actual mbuf data from there. I've tried looking the the uma_keg, > etc. No luck so far. Is there anyone familiar with these data structures > that could point me in the right direction? It might require tweaking to work as things have changed a bit, but last time I was futzing with the mbuf allocator I put a UMA state dumper into src/tools/tools/umastat. It inspects /dev/kmem (or a core, I suppose) to print out the layout of cached data across per-cpu caches, etc. I'm not sure it would be all that useful for debugging a leak, but might prove informative for getting a sense of how it fits together, and the source code might be useful similarly. Robert N M Watson Computer Laboratory University of Cambridge > > (kgdb) p *zone_mbuf > $66 = {uz_name = 0xc076d6d1 "mbuf", uz_lock = 0xc1048108, uz_keg = > 0xc1048100, > uz_link = {le_next = 0xc1047180, le_prev = 0xc104812c}, uz_full_bucket = { > lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, > uz_ctor = 0xc05068f0 , uz_dtor = 0xc0507040 , > uz_init = 0, uz_fini = 0, uz_allocs = 137806761, uz_frees = 136018292, > uz_fails = 136, uz_fills = 4, uz_count = 128, uz_cpu = {{ > uc_freebucket = 0xc73a8c48, uc_allocbucket = 0x0, uc_allocs = 0, > uc_frees = 0}}} > > Thanks! > -JD- > _______________________________________________ > 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 bugmaster at FreeBSD.org Mon Jan 12 03:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:08:38 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200901121106.n0CB6t8U092063@freefall.freebsd.org> 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/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes 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/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [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 [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126924 net [an] [patch] printf -> device_printf and simplify prob 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 kern/121983 net [fxp] fxp0 MBUF and PAE 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre 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 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/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/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 205 problems total. From bugmaster at FreeBSD.org Mon Jan 12 03:07:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:09:57 2009 Subject: Current problem reports assigned to net@FreeBSD.org Message-ID: <200901121107.n0CB7p4e093142@freefall.freebsd.org> 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 -------------------------------------------------------------------------------- s kern/117717 net [panic] Kernel panic with Bittorrent client. 1 problem total. From qing.li at bluecoat.com Mon Jan 12 10:25:18 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Jan 12 10:25:26 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: I have revived the RTF_LLINFO definition in route.h. A new kernel option "COMPAT_ROUTE_FLAGS" is introduced, all for providing binary compatibility for existing ports. I could have made the RTF_LLINFO bit only applicable with _KERNEL. Without rehashing the discussion we all had on this topic on both -current@ and -net@ MLs last month, moving forward, all arp-v2 affected ports should continue to be modified and updated with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are obsolete. There are no support for the semantics of these flag bits in the kernel, other than returning these bits to userland for the existing ports. Please sync-up to the following revision: SVN rev 187094 on 2009-01-12 11:24:32Z by qingli Thanks, -- Qing > -----Original Message----- > From: Gerald Pfeifer [mailto:gerald@pfeifer.com] > Sent: Friday, January 09, 2009 1:27 AM > To: Li, Qing > Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd- > current@freebsd.org > Subject: RE: HEADSUP: arp-v2 has been committed > > On Tue, 30 Dec 2008, Li, Qing wrote: > > I don't think we can provide binary compatibility without putting > > back RTF_LLINFO exactly as it was. My preference is to continue down > > the new path without RTF_LLINFO. > > So, you are saying that applications built on FreeBSD 7 or earlier > that use RTF_LLINFO will no longer work properly on FreeBSD 8 after > your change? > > Ignoring everything else, that would be a killer and the one reason > to definitely change the current situation. Otherwise, ISVs will need > two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and > believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux > distributions do provide this level of compatibility.) > > > We still have some time before the 8.0 release. It's straightforward > > for me to retain some of the RTF_LLINFO support in the new kernel if > > and when the situation becomes necessary. > > Sounds like that is the case? > > > Since the affected ports now have the conditional code around > > RTF_LLINFO, the updates would allow these ports to compile in > > both -current and in the previous releases. > > emulators/wine still is broken, and upstream Wine has not accepted > the patch yet. I believe one reason likely is the above, and the > fact that this may break commercial builds of Wine. > > How are you going to address this? > > Gerald > -- > Gerald (Jerry) Pfeifer gerald@pfeifer.com > http://www.pfeifer.com/gerald/ From axel.scheepers at nl.clara.net Mon Jan 12 11:10:04 2009 From: axel.scheepers at nl.clara.net (Axel Scheepers) Date: Mon Jan 12 11:10:10 2009 Subject: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] Message-ID: <200901121910.n0CJA2wT060335@freefall.freebsd.org> The following reply was made to PR kern/119432; it has been noted by GNATS. From: Axel Scheepers To: bug-followup@FreeBSD.org, axel@axel.truedestiny.net Cc: Subject: Re: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] Date: Mon, 12 Jan 2009 19:47:23 +0100 Hi again, Back on FreeBSD(7.1-RELEASE-p1) for my home router ;) I can confirm using -net -netmask 255.255.255.255 -interface -cloning works ok; /etc/rc.conf: ifconfig_fxp0="inet x.x.x.x netmask 255.255.255.255 link0 polling" static_routes="sipspoof default" route_sipspoof="-net 192.168.0.1 -netmask 255.255.255.255 -interface x.x.x.x -cloning" route_default="default 192.168.0.1" taliesin# ping -c 2 69.147.83.33 PING 69.147.83.33 (69.147.83.33): 56 data bytes 64 bytes from 69.147.83.33: icmp_seq=0 ttl=48 time=173.483 ms 64 bytes from 69.147.83.33: icmp_seq=1 ttl=48 time=209.926 ms --- 69.147.83.33 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 173.483/191.704/209.926/18.222 ms Setting defaultrouter will not work since that gets set before the static routes are setup hence the need for the default static route. Kind regards, Axel Scheepers From jchambers at ucla.edu Mon Jan 12 12:37:03 2009 From: jchambers at ucla.edu (Jason Chambers) Date: Mon Jan 12 12:37:10 2009 Subject: Network is unreachable and other related errors Message-ID: <496BA75E.7020309@ucla.edu> Hello all, Wondering if anyone else experiences errors such as "Network is unreachable" and the like when using security auditing tools like nmap, nessus, etc. I found a PR from a long time ago that appears relevant but it was abandoned: http://www.freebsd.org/cgi/query-pr.cgi?pr=102741&cat= As a result of this condition some tools are completely unusable. A nessus scan returns all scanned hosts as dead seconds after starting a scan. Nmap is unable to scan a system because it immediately goes into a loop of the following: sendto in send_ip_packet: sendto(4, packet, 44, 0, xxx.xxx.xxx.xxx, 16) => Network is unreachable Offending packet: TCP xxx.xxx.xxx.xxx:55555 > xxx.xxx.xxx.xxx:80 S ttl=56 id=xxxx iplen=11264 seq=xxxx win=1024 Sleeping 15 seconds then retrying sendto in send_ip_packet: sendto(4, packet, 44, 0, xxx.xxx.xxx.xxx, 16) => Network is unreachable Offending packet: TCP xxx.xxx.xxx.xxx:55555 > xxx.xxx.xxx.xxx:80 S ttl=56 id=xxxx iplen=11264 seq=xxxx win=1024 Sleeping 60 seconds then retrying It's obviously related in part to the hardware configuration of a device however I'm not sure where to look next. The network controller does not seem to make a difference. So far I've not experienced anything related to this issue when running Linux on the same hardware. Any ideas where to look next ? Regards, --Jason From yanefbsd at gmail.com Mon Jan 12 12:37:30 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 12:37:48 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> Message-ID: <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> On Mon, Jan 12, 2009 at 10:25 AM, Li, Qing wrote: > I have revived the RTF_LLINFO definition in route.h. > A new kernel option "COMPAT_ROUTE_FLAGS" is introduced, all > for providing binary compatibility for existing ports. > I could have made the RTF_LLINFO bit only applicable with _KERNEL. > > Without rehashing the discussion we all had on this topic on > both -current@ and -net@ MLs last month, moving forward, all > arp-v2 affected ports should continue to be modified and updated > with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are > obsolete. There are no support for the semantics of these > flag bits in the kernel, other than returning these bits to > userland for the existing ports. > > Please sync-up to the following revision: > > SVN rev 187094 on 2009-01-12 11:24:32Z by qingli > > Thanks, > > -- Qing > > >> -----Original Message----- >> From: Gerald Pfeifer [mailto:gerald@pfeifer.com] >> Sent: Friday, January 09, 2009 1:27 AM >> To: Li, Qing >> Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd- >> current@freebsd.org >> Subject: RE: HEADSUP: arp-v2 has been committed >> >> On Tue, 30 Dec 2008, Li, Qing wrote: >> > I don't think we can provide binary compatibility without putting >> > back RTF_LLINFO exactly as it was. My preference is to continue down >> > the new path without RTF_LLINFO. >> >> So, you are saying that applications built on FreeBSD 7 or earlier >> that use RTF_LLINFO will no longer work properly on FreeBSD 8 after >> your change? >> >> Ignoring everything else, that would be a killer and the one reason >> to definitely change the current situation. Otherwise, ISVs will need >> two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and >> believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux >> distributions do provide this level of compatibility.) >> >> > We still have some time before the 8.0 release. It's straightforward >> > for me to retain some of the RTF_LLINFO support in the new kernel if >> > and when the situation becomes necessary. >> >> Sounds like that is the case? >> >> > Since the affected ports now have the conditional code around >> > RTF_LLINFO, the updates would allow these ports to compile in >> > both -current and in the previous releases. >> >> emulators/wine still is broken, and upstream Wine has not accepted >> the patch yet. I believe one reason likely is the above, and the >> fact that this may break commercial builds of Wine. >> >> How are you going to address this? >> >> Gerald Oh, btw... wine works well when you set the RTF_LLINFO value to 0 with arp-v2, AFAICT. -Garrett From yanefbsd at gmail.com Mon Jan 12 12:47:56 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 12:48:03 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <496BAA26.9010200@elischer.org> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> <496BAA26.9010200@elischer.org> Message-ID: <7d6fde3d0901121247t31ee0d8cp6d46cf9b3b256fad@mail.gmail.com> On Mon, Jan 12, 2009 at 12:37 PM, Julian Elischer wrote: > Garrett Cooper wrote: > > I think setting it to a value of 0 has two good points... > > In code that does: > if (XXX & RTF_LLINFO) { > yyy() > } > the optimiser should simply remove the code, > or at worst give an error messages that makes people go look for > the answer, and secondly, > the conditional > > #if defined(RTF_LLINFO) && (RTF_LLINFO != 0) > > can be easily used to make code conditionally do the right thing > for different versions of freeBSD, > possibly trivially replacing earlier occurances of > > #ifdef RTF_LLINFO > > > >> >> Oh, btw... wine works well when you set the RTF_LLINFO value to 0 >> with arp-v2, AFAICT. >> -Garrett That's basically what I did (2 instances in the file had to be replaced) -- #ifndef RTF_LLINFO /* Insert code here with 0. */ #else /* Insert code here with RTF_LLINFO. */ #endif The code checks to see if sysctl exists, and then defaults to Linux-y behavior, so other OS'es with proper sysctl support could be broken by this change. I tested this out with Steam and wine-doors, but unfortunately I ran into OpenGL issues that prevented me from playing Steam games -_-... Cheers, -Garrett From julian at elischer.org Mon Jan 12 13:06:33 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 12 13:06:39 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> Message-ID: <496BAA26.9010200@elischer.org> Garrett Cooper wrote: I think setting it to a value of 0 has two good points... In code that does: if (XXX & RTF_LLINFO) { yyy() } the optimiser should simply remove the code, or at worst give an error messages that makes people go look for the answer, and secondly, the conditional #if defined(RTF_LLINFO) && (RTF_LLINFO != 0) can be easily used to make code conditionally do the right thing for different versions of freeBSD, possibly trivially replacing earlier occurances of #ifdef RTF_LLINFO > > Oh, btw... wine works well when you set the RTF_LLINFO value to 0 > with arp-v2, AFAICT. > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From psteele at maxiscale.com Mon Jan 12 16:02:14 2009 From: psteele at maxiscale.com (Peter Steele) Date: Mon Jan 12 16:02:20 2009 Subject: Broadcast packet not being sent Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A128@polaris.maxiscale.com> I am using scapy to construct a UDP broadcast packet. The code I'm using is: packet=Ether(dst="ff:ff:ff:ff:ff:ff")/IP(dst="255.255.255.255")/UDP(dpor t=33333)/payload sendp(packet) Send 1 packets. This works fine when I have an IP assigned to the box. However, when no IP is assigned, I get the following messages: The sendp generates these warnings: WARNING: No route found for IPv6 destination :: (no default route?) WARNING: No route found (no default route?) WARNING: No route found (no default route?) WARNING: No route found (no default route?) Sent 1 packets. I assume these warnings are okay, since of course there can't be a route in a scenario like the one I'm using. It's the same environment a DHCP client would face. However, despite scapy saying the packet was sent, it does not in fact leave the machine (I've confirmed this with tcpdump). As I said, if the box has an IP address, then the packet is sent as expected, but that defeats the purpose since we are developing a custom DHCP-like protocol. The only think suspicious that I am seeing is this error in /var/log/messages: Jan 12 16:13:52 kernel: looutput: af=31 unexpected I get one of these each time I try to send a broadcast when no IP is assigned. I did an google search but did not any useful hits on this. If anyone here has any idea what's going on, I'd appreciate some feedback. I think I have the correct packet constructed, but clearly something is wrong, and it may very well be user error. Peter From psteele at maxiscale.com Mon Jan 12 17:11:16 2009 From: psteele at maxiscale.com (Peter Steele) Date: Mon Jan 12 17:11:22 2009 Subject: Broadcast packet not being sent In-Reply-To: <2ACA3DE8F9758A48B8BE2C7A847F91F247A128@polaris.maxiscale.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F247A128@polaris.maxiscale.com> Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A13A@polaris.maxiscale.com> Problem solved. I have to explicitly set cond.iface before sending the packet. User error... -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Peter Steele Sent: Monday, January 12, 2009 4:02 PM To: freebsd-net@freebsd.org Subject: Broadcast packet not being sent I am using scapy to construct a UDP broadcast packet. The code I'm using is: packet=Ether(dst="ff:ff:ff:ff:ff:ff")/IP(dst="255.255.255.255")/UDP(dpor t=33333)/payload sendp(packet) Send 1 packets. This works fine when I have an IP assigned to the box. However, when no IP is assigned, I get the following messages: The sendp generates these warnings: WARNING: No route found for IPv6 destination :: (no default route?) WARNING: No route found (no default route?) WARNING: No route found (no default route?) WARNING: No route found (no default route?) Sent 1 packets. I assume these warnings are okay, since of course there can't be a route in a scenario like the one I'm using. It's the same environment a DHCP client would face. However, despite scapy saying the packet was sent, it does not in fact leave the machine (I've confirmed this with tcpdump). As I said, if the box has an IP address, then the packet is sent as expected, but that defeats the purpose since we are developing a custom DHCP-like protocol. The only think suspicious that I am seeing is this error in /var/log/messages: Jan 12 16:13:52 kernel: looutput: af=31 unexpected I get one of these each time I try to send a broadcast when no IP is assigned. I did an google search but did not any useful hits on this. If anyone here has any idea what's going on, I'd appreciate some feedback. I think I have the correct packet constructed, but clearly something is wrong, and it may very well be user error. Peter _______________________________________________ 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 dimitar.vassilev at gmail.com Mon Jan 12 21:44:01 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Mon Jan 12 21:44:08 2009 Subject: setfib+pf Message-ID: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> Hi, I originally posted my message to questions, however no response for about a week. Therefore I'm reposting here. Original question available at http://lists.freebsd.org/pipermail/freebsd-questions/2009-January/190056.html For those who prefer reading human text, here are my questions: I'd like to ask on the best options for using setfib and pf in a non-BGP environment. I will run 2 uplinks, with VLANs for internal networks and want to fail over external links if one of them fails.(Extended note as of 13.01: Uplink routers will be a WRT54GL with OpenWRT and an Alix box hopefully. Vlan tagging also possible there. Alix will be the controlling router station for failover). Currently pf supports to the best of my knowledge: a) rtable - this means i can create the routing tables with setfib and then use pass from .... rtable N( N >1 <16) or give out directly network ranges b) route-to - pass in/out on X from ... route-to c) packet tagging - i can tag networks and use standalone or through routing tags. Anyone aware if is it ok to use /etc/gateways without running routed or how can i label routes alternatively? If I apply the same for /etc/networks or both /etc/gateways and networks will it be ok? pass in from any to $big_salad via $fridge keep state for example? d) pass in from route N(192.168.1.1 for example) to... - saw this on http://www.mail-archive.com/pf@benzedrine.cx/msg07220.html and requires BGP to make tags speak anything but network numbers. e) use the vlan id's I'd much appreciate if someone thinks with me for the best options of using the setfib features along with pf. Thanks and regards, Dimitar Vassilev From ivoras at freebsd.org Tue Jan 13 02:49:24 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Jan 13 02:49:31 2009 Subject: IPv6, ssh and ipfw Message-ID: Hi, I'm experimenting with IPv6 and so far all is well except one thing: my ssh sessions are dropped/stalled after a few minutes. I'm using ipfw and by monitoring its dynamic/state-keeping rules I see that it's timeouting the rules after 60 seconds (this time is configured in net.inet.ip.fw.dyn_ack_lifetime). The problem is, this is not happening with IPv4 ssh sessions. I see the timeout is counting down for my dynamic/stateful IPv4 ssh session but it's reset before it reaches 0, which is consistent with observed behaviour - on Windows, I can start putty, hybernate or sleep the OS (i.e. the machine practically turns off) and wake it up another day to see the ssh session still alive. Aside from obvious DOS opportunities on the server, I like this behaviour. This is *not* apparently created by using keepalive messages since they are obviously not sent while the machine is sleeping (and they are disabled in sshd_conf). Why is ssh over IPv6 behaving differently than on IPv4? Is there a special hack for ssh on IPv4? This is on 6-STABLE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090113/a8852c27/signature.pgp From yonyossef.lists at gmail.com Tue Jan 13 03:03:44 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Jan 13 03:03:56 2009 Subject: Using device.hints to determine network device unit number Message-ID: <000501c9756e$9563d550$39ed1aac@mtl.com> Hi, I would like to determine the unit number of my network cards, make the device on pci0:16 appear always as mtnic0 and pci0:9 appear always as mtnic1. # pciconf -l | grep mtnic mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 Is it done by /boot/device.hints? if so, how? I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching upon reboot. I'm using FreeBSD 7.0. Thanks Yony From yoniy at mellanox.co.il Tue Jan 13 03:25:19 2009 From: yoniy at mellanox.co.il (Yehonatan Yossef) Date: Tue Jan 13 03:25:30 2009 Subject: Using device.hints to determine network device unit number Message-ID: <5D49E7A8952DC44FB38C38FA0D758EAD01736127@mtlexch01.mtl.com> Hi, I would like to determine the unit number of my network cards, make the device on pci0:16 appear always as mtnic0 and pci0:9 appear always as mtnic1. # pciconf -l | grep mtnic mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 Is it done by /boot/device.hints? if so, how? I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching upon reboot. I'm using FreeBSD 7.0. Thanks Yony From boris.marechal at netasq.com Tue Jan 13 04:40:03 2009 From: boris.marechal at netasq.com (Boris MARECHAL) Date: Tue Jan 13 04:40:15 2009 Subject: kern/123066: [ipsec] [panic] kernel trap with ipsec Message-ID: <200901131240.n0DCe340004788@freefall.freebsd.org> The following reply was made to PR kern/123066; it has been noted by GNATS. From: Boris MARECHAL To: bug-followup@FreeBSD.org, msaf1980@rambler.ru Cc: Subject: Re: kern/123066: [ipsec] [panic] kernel trap with ipsec Date: Tue, 13 Jan 2009 13:38:22 +0100 --Apple-Mail-59-140032122 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit seems linked with kern/124609: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 --Apple-Mail-59-140032122 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFczCCBW8w ggRXoAMCAQICCnDGsUgWa/KQamQwDQYJKoZIhvcNAQEEBQAwgZExCzAJBgNVBAYTAkZSMQ0wCwYD VQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0g U2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTA4MDEwMzExMTIzNFoXDTEwMDEwMjExMTIzNFowgdQxCzAJBgNVBAYU AkZSMQ0wCwYDVQQIFAROb3JkMS4wLAYDVQQKFCVORVRBU1EgLSBTZWN1cmUgSW50ZXJuZXQgQ29u bmVjdGl2aXR5MScwJQYDVQQLFB5ORVRBU1EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxGjAYBgNV BAcUEVZpbGxlbmV1dmUgZCdBc2NxMRcwFQYDVQQDFA5Cb3JpcyBNQVJFQ0hBTDEoMCYGCSqGSIb3 DQEJARYZYm9yaXMubWFyZWNoYWxAbmV0YXNxLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA5GEoHCGB2ZhZx/I7Jq0hetpb+HPf2DKzieLoklK125o3RaSdHELZYnWB2Cvi6xRG5p+wmOl2 ABo0qwxkve2QfdapHXppQo2aNVp++Z528p22ASaQzJnzBT9JTPVxMFopgMbMBgCmMrye6lpI3laW HEoCcIrfD4Vfus4i62JCwvMCAwEAAaOCAgYwggICMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFDIY DOPzGbqvpVtqkCbFSKhMMB2wMIG+BgNVHSMEgbYwgbOAFCcq6x3ZRNo6F3NqCSAgySWo+X+yoYGX pIGUMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBk J0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAl BgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBADAOBgNVHQ8BAf8EBAMCBeAw EQYJYIZIAYb4QgEBBAQDAgWgMIHNBgNVHR8EgcUwgcIwWqBYoFaGVGxkYXA6Ly9wa2kubmV0YXNx LmNvbS9jbj1md2NhLG91PWNhcyxvPW5ldGFzcSxkYz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0O2JpbmFyeTA4oDagNIYyaHR0cDovL2ludHJhbmV0Lm5ldGFzcS5jb20vaW50cmFuZXQvcGtp L25ldGFzcS5jcmwwKqAooCaGJGh0dHA6Ly93d3cubmV0YXNxLmNvbS9wa2kvbmV0YXNxLmNybDAf BglghkgBhvhCAQ0EEhYQVXNlciBDZXJ0aWZpY2F0ZTANBgkqhkiG9w0BAQQFAAOCAQEATwF5SdOw IoofZ5U2A16VEBBstYXne5mBItzdvsU8U2AlPXVXcr3/ZsvM0J9ivjKRge1LHVaOgChpxBN5aGhD QfKrWVYPALiqn8gQYWlJ5hmlJvxeAQOBU/hpLx9Y5bJ+3DQBjyDsghdRCL6/0Ym5Aj/VgEiTI/1t hgK6XNCRyonyTnArtGGhgwEqxOSSQ2zkUvg24DLhzSdUMtC+NydUyatJsHiqVuxuM22wVmCQCbjq M9hjGfae9zD1ieAPyeqEHmyCqwBeYblH3EXxnWwXRdKU2VzH1ZAJr5du5hEmlB5yCSEEqMP6joYJ w0QErq8VZxj1SlbEECPqrYz/muQDRzGCAxIwggMOAgEBMIGgMIGRMQswCQYDVQQGEwJGUjENMAsG A1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAt IFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBqZDAJBgUrDgMCGgUAoIIBxzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAxMTMxMjM4MjJaMCMGCSqGSIb3DQEJBDEWBBQs /AQv77ynpgALw0zBqFApHWO1FDCBsQYJKwYBBAGCNxAEMYGjMIGgMIGRMQswCQYDVQQGEwJGUjEN MAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFT USAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBqZDCBswYLKoZIhvcNAQkQAgsxgaOggaAwgZExCzAJ BgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwG A1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVU QVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgpwxrFIFmvykGpkMA0GCSqGSIb3DQEBAQUABIGA UFUnxt5ghZ6XqG+YvpeOozRotFeS2nQT0A8Dr8y6YYAxOOB0NZXxkDRY7ubWzCt0X8WDunfdu8Oe OO7aGRKMaPr3d3eZp4R2LPTQcf5Vgtu9+D2GyrlEMFeBohpy2PoVHNpIwc44y9r7b8+rvuojFhUo xDwp9XGQYm6Oi4kvpxcAAAAAAAA= --Apple-Mail-59-140032122-- From eitans at mellanox.co.il Tue Jan 13 05:36:31 2009 From: eitans at mellanox.co.il (Eitan Shefi) Date: Tue Jan 13 05:36:39 2009 Subject: When configuring 2 VLANs to be on the same subnet, only one works. Message-ID: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> I'm testing a NIC driver. I use 2 directly connected FreeBSD-7.0 hosts. When I create 2 VLANs for the same interface (mtnic0), on each host, and configure the VLANs on each host to be on the same subnet: ping works only to one of the VLANs. I run: On sw259: /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 /sbin/ifconfig vlan1 91.154.12.5 netmask 255.0.0.0 /sbin/ifconfig vlan2 91.155.12.5 netmask 255.0.0.0 On sw260: /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 /sbin/ifconfig vlan1 91.154.12.6 netmask 255.0.0.0 /sbin/ifconfig vlan2 91.155.12.6 netmask 255.0.0.0 Now on sw259 run: ping 91.154.12.6 - works. ping 91.155.12.6 - does not work. I saw the same behavior also when running via a different NIC. Is this expected ? Thanks, Eitan. From rea-fbsd at codelabs.ru Tue Jan 13 06:09:54 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jan 13 06:10:01 2009 Subject: When configuring 2 VLANs to be on the same subnet, only one works. In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> Message-ID: <+3+JfrHHIEz9xs7kOtLRj9ebGAs@HEwlnNW4tuDdZ1V6ihYwW3pQ/cw> EItan, good day. Tue, Jan 13, 2009 at 03:09:11PM +0200, Eitan Shefi wrote: > I use 2 directly connected FreeBSD-7.0 hosts. > When I create 2 VLANs for the same interface (mtnic0), on each host, and > configure the VLANs on each host to be on the same subnet: > ping works only to one of the VLANs. > > I run: > On sw259: > /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 > /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 > /sbin/ifconfig vlan1 91.154.12.5 netmask 255.0.0.0 > /sbin/ifconfig vlan2 91.155.12.5 netmask 255.0.0.0 > > On sw260: > /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 > /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 > /sbin/ifconfig vlan1 91.154.12.6 netmask 255.0.0.0 > /sbin/ifconfig vlan2 91.155.12.6 netmask 255.0.0.0 > > Now on sw259 run: > ping 91.154.12.6 - works. > ping 91.155.12.6 - does not work. You're running two interfaces on the same /8 subnet at one host. I bet that your routing table specifies that packets both for 91.154.12.6 and 91.155.12.6 should go through the same interface, probably vlan1. Could you show output of 'netstat -rn', 'route get 91.154.12.6' and 'route get 91.155.12.6'? Also try to spawn tcpdump on the interface that packets for 91.154.12.6 are routed to and look for the captured packets when pinging 91.155.12.6. Your local firewall could also prevent packets from being pushed to the network, but this actually depens on your configuration. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From stefan.lambrev at moneybookers.com Tue Jan 13 06:19:23 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Jan 13 06:19:30 2009 Subject: When configuring 2 VLANs to be on the same subnet, only one works. In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> Message-ID: Greetings, For me your configuration looks invalid. Try with netmask 255.255.0.0 The question here is why freebsd allow this. On Jan 13, 2009, at 3:09 PM, Eitan Shefi wrote: > I'm testing a NIC driver. > I use 2 directly connected FreeBSD-7.0 hosts. > When I create 2 VLANs for the same interface (mtnic0), on each host, > and > configure the VLANs on each host to be on the same subnet: > ping works only to one of the VLANs. > > I run: > On sw259: > /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 > /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 > /sbin/ifconfig vlan1 91.154.12.5 netmask 255.0.0.0 > /sbin/ifconfig vlan2 91.155.12.5 netmask 255.0.0.0 > > On sw260: > /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 > /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 > /sbin/ifconfig vlan1 91.154.12.6 netmask 255.0.0.0 > /sbin/ifconfig vlan2 91.155.12.6 netmask 255.0.0.0 > > Now on sw259 run: > ping 91.154.12.6 - works. > ping 91.155.12.6 - does not work. > > I saw the same behavior also when running via a different NIC. > > > Is this expected ? > > > Thanks, > Eitan. > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From aman.jassal at esigetel.fr Tue Jan 13 07:53:21 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Tue Jan 13 07:53:28 2009 Subject: When configuring 2 VLANs to be on the same subnet, only one works. In-Reply-To: References: <5D49E7A8952DC44FB38C38FA0D758EAD0173629B@mtlexch01.mtl.com> Message-ID: <52831.193.49.124.107.1231860901.squirrel@webmail.esigetel.fr> Hello Eitan, I am no expert but I believe Stefan is right, your having a netmask of 255.0.0.0 does look strange. The way I see it, I think you are trying to configure 2 IP addresses belonging to the same subnet (91.0.0.0/8) on your interface, but only the first address is taken into account (91.154.12.5 on sw259 and 91.154.12.6 on sw260). Hence ping 91.154.12.6 from sw259 fails. Setting a netmask of 255.255.0.0 as Stefan suggested should solve your problem. Kind regards, Aman Jassal Le Mar 13 janvier 2009 15:03, Stefan Lambrev a ?crit : > Greetings, > > > For me your configuration looks invalid. Try with netmask 255.255.0.0 > The question here is why freebsd allow this. > > > On Jan 13, 2009, at 3:09 PM, Eitan Shefi wrote: > > >> I'm testing a NIC driver. >> I use 2 directly connected FreeBSD-7.0 hosts. >> When I create 2 VLANs for the same interface (mtnic0), on each host, >> and configure the VLANs on each host to be on the same subnet: ping works >> only to one of the VLANs. >> >> I run: >> On sw259: >> /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 >> /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 >> /sbin/ifconfig vlan1 91.154.12.5 netmask 255.0.0.0 >> /sbin/ifconfig vlan2 91.155.12.5 netmask 255.0.0.0 >> >> >> On sw260: >> /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 >> /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 >> /sbin/ifconfig vlan1 91.154.12.6 netmask 255.0.0.0 >> /sbin/ifconfig vlan2 91.155.12.6 netmask 255.0.0.0 >> >> >> Now on sw259 run: >> ping 91.154.12.6 - works. ping 91.155.12.6 - does not work. >> >> I saw the same behavior also when running via a different NIC. >> >> >> >> Is this expected ? >> >> >> >> Thanks, >> Eitan. >> _______________________________________________ >> 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" >> > > -- > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > > > > > > > _______________________________________________ > 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 julian at elischer.org Tue Jan 13 09:59:05 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Jan 13 09:59:12 2009 Subject: setfib+pf In-Reply-To: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> References: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> Message-ID: <496CCFBF.3010008@elischer.org> Dimitar Vasilev wrote: > Hi, I originally posted my message to questions, however no response for > about a week. Therefore I'm reposting here. Original question available at > http://lists.freebsd.org/pipermail/freebsd-questions/2009-January/190056.html > For those who prefer reading human text, here are my questions: > > I'd like to ask on the best options for using setfib and pf in a non-BGP > environment. I will run 2 uplinks, with VLANs for internal networks and want > to fail over external links if one of them fails.(Extended note as of 13.01: > Uplink routers will be a WRT54GL with OpenWRT and an Alix box hopefully. > Vlan tagging also possible there. Alix will be the controlling router > station for failover). > > Currently pf supports to the best of my knowledge: > > a) rtable - this means i can create the routing tables with setfib and then > use pass from .... rtable N( N >1 <16) or give out directly network ranges ( 0 <= N < 16 ) i.e. 0 through 15 (for now) > b) route-to - pass in/out on X from ... route-to > c) packet tagging - i can tag networks and use standalone or through routing > tags. Anyone aware if is it ok to use /etc/gateways without running routed > or how can i label routes alternatively? If I apply the same for > /etc/networks or both /etc/gateways and networks will it be ok? > > pass in from any to $big_salad via $fridge keep state for example? > > d) pass in from route N(192.168.1.1 for example) to... - saw this on > http://www.mail-archive.com/pf@benzedrine.cx/msg07220.html and requires BGP > to make tags speak anything but network numbers. > e) use the vlan id's > > I'd much appreciate if someone thinks with me for the best options of using > the setfib features along with pf. I know setfib but I don't know pf unfortunately.. I use ipfw (which is why ipfw has fib support :-) possibly Max Lair may know both.. > > Thanks and regards, > Dimitar Vassilev > _______________________________________________ > 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 kitambi at epicsol.org Tue Jan 13 12:10:03 2009 From: kitambi at epicsol.org (Jason Brand) Date: Tue Jan 13 12:10:09 2009 Subject: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Message-ID: <200901132010.n0DKA2o5039812@freefall.freebsd.org> The following reply was made to PR kern/128917; it has been noted by GNATS. From: Jason Brand To: bug-followup@FreeBSD.org;, kitambi@epicsol.org Cc: Subject: Re: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Date: Tue, 13 Jan 2009 15:01:05 -0500 Additional information: I have managed to reproduce this issue on different network that uses WPA+TKIP, with PAP as the phase2 method. Backtrace: Breakpoint 1 at 0xc058bc5c: file pcpu.h, line 196. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc058c347 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc058c652 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc07e34f3 in trap_fatal (frame=0xe6db9ba0, eva=65535) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc07e3750 in trap_pfault (frame=0xe6db9ba0, usermode=0, eva=65535) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc07e4122 in trap (frame=0xe6db9ba0) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc07ca90b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0a17dfc in wpi_ops (arg0=0xc68fe000, pending=1) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2411 #8 0xc05bf795 in taskqueue_run (queue=0xc68f7a00) at /usr/src/sys/kern/subr_taskqueue.c:282 #9 0xc05bf99b in taskqueue_thread_loop (arg=0xc68ff9b4) at /usr/src/sys/kern/subr_taskqueue.c:401 #10 0xc0567eb9 in fork_exit (callout=0xc05bf8e0 , arg=0xc68ff9b4, frame=0xe6db9d38) at /usr/src/sys/kern/kern_fork.c:804 #11 0xc07ca980 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 WPA information: Selected interface 'wpi0' bssid=00:0c:e6:xx:xx:xx ssid= id=2 pairwise_cipher=TKIP group_cipher=TKIP key_mgmt=WPA/IEEE 802.1X/EAP wpa_state=ASSOCIATED ip_address=0.0.0.0 Supplicant PAE state=HELD suppPortStatus=Unauthorized EAP state=FAILURE selectedMethod=21 (EAP-TTLS) EAP TLS cipher=(NONE) EAP-TTLSv0 Phase2 method=PAP From yonyossef.lists at gmail.com Wed Jan 14 00:09:45 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Jan 14 00:09:57 2009 Subject: howto determine network device unit number? device.hints? Message-ID: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony From fazaeli at sepehrs.com Wed Jan 14 08:39:05 2009 From: fazaeli at sepehrs.com (H.fazaeli) Date: Wed Jan 14 08:39:13 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> Message-ID: <496E11B7.3010608@sepehrs.com> you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Yony Yossef wrote: > Hi, > > I would like to determine the unit number of my network cards, e.g. > make the device on pci0:16 be assigned every time with unit number 0 > and pci0:19 with unit number 1. > > Is it done by /boot/device.hints? > if so, how? > > My cards are: > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 > > So I've tried: > > hint.mtnic.0.at="pci0:16" > hint.mtnic.1.at="pci0:19" > > but it doesn't work. They keep switching arbitrarily. > I'm using FreeBSD 7.0. > > Thanks > Yony > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > > > -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From yonyossef.lists at gmail.com Wed Jan 14 13:22:02 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Jan 14 13:22:15 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496E11B7.3010608@sepehrs.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> Message-ID: <000a01c9768e$1ff65240$220f000a@mtl.com> > > you may not change unit numbers as they are strictly > controlled by kernel. > However, on freebsd 5.3+, you may use 'ifconfig name ' > to achieve the same affect > Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony > > Yony Yossef wrote: > > Hi, > > > > I would like to determine the unit number of my network cards, e.g. > > make the device on pci0:16 be assigned every time with unit > number 0 > > and pci0:19 with unit number 1. > > > > Is it done by /boot/device.hints? > > if so, how? > > > > My cards are: > > > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > > > So I've tried: > > > > hint.mtnic.0.at="pci0:16" > > hint.mtnic.1.at="pci0:19" > > > > but it doesn't work. They keep switching arbitrarily. > > I'm using FreeBSD 7.0. > > > > Thanks > > Yony From vwe at FreeBSD.org Wed Jan 14 13:22:56 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:23:07 2009 Subject: i386/45773: [bge] Softboot causes autoconf failure on Broadcom 5703 Message-ID: <200901142122.n0ELMseV049306@freefall.freebsd.org> Synopsis: [bge] Softboot causes autoconf failure on Broadcom 5703 State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:21:47 UTC 2009 State-Changed-Why: Michael, can you please tell us if you're still seeing the issue with late{r|est} releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:21:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=45773 From vwe at FreeBSD.org Wed Jan 14 13:24:10 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:24:23 2009 Subject: kern/73538: [bge] problem with the Broadcom BCM5788 Gigabit Ethernet Message-ID: <200901142124.n0ELO88i049386@freefall.freebsd.org> Synopsis: [bge] problem with the Broadcom BCM5788 Gigabit Ethernet State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:23:10 UTC 2009 State-Changed-Why: Ben, is this still an issue with recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:23:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=73538 From yonyossef.lists at gmail.com Wed Jan 14 13:24:24 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Jan 14 13:24:40 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496E11B7.3010608@sepehrs.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> Message-ID: <000b01c9768e$745aa160$220f000a@mtl.com> > -----Original Message----- > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > Sent: Wednesday, January 14, 2009 6:24 PM > To: Yony Yossef > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org; > Eitan Shefi; Oleg Kats; Liran Liss > Subject: Re: howto determine network device unit number? device.hints? > > > you may not change unit numbers as they are strictly > controlled by kernel. > However, on freebsd 5.3+, you may use 'ifconfig name ' > to achieve the same affect > Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony > > Yony Yossef wrote: > > Hi, > > > > I would like to determine the unit number of my network cards, e.g. > > make the device on pci0:16 be assigned every time with unit > number 0 > > and pci0:19 with unit number 1. > > > > Is it done by /boot/device.hints? > > if so, how? > > > > My cards are: > > > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > > > So I've tried: > > > > hint.mtnic.0.at="pci0:16" > > hint.mtnic.1.at="pci0:19" > > > > but it doesn't work. They keep switching arbitrarily. > > I'm using FreeBSD 7.0. > > > > Thanks > > Yony > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > > > > > > > > -- > > > Best regards. > > Hooman Fazaeli > Sepehr S. T. Co. Ltd. > > Web: http://www.sepehrs.com > Tel: (9821)88975701-2 > Fax: (9821)88983352 > > > > > From vwe at FreeBSD.org Wed Jan 14 13:27:50 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:27:57 2009 Subject: kern/75407: [an] an(4): no carrier after short time Message-ID: <200901142127.n0ELRm9G049456@freefall.freebsd.org> Synopsis: [an] an(4): no carrier after short time State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:27:10 UTC 2009 State-Changed-Why: Joe, is this report still true for recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:27:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=75407 From vwe at FreeBSD.org Wed Jan 14 13:33:09 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:33:17 2009 Subject: kern/79262: [dc] Adaptec ANA-6922 not fully supported Message-ID: <200901142133.n0ELX5F9058176@freefall.freebsd.org> Synopsis: [dc] Adaptec ANA-6922 not fully supported State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:32:23 UTC 2009 State-Changed-Why: Liudas, is this issue still true for recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:32:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=79262 From vwe at FreeBSD.org Wed Jan 14 13:34:13 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:34:25 2009 Subject: kern/81644: [vge] vge(4) does not work properly when loaded as a KLD Message-ID: <200901142134.n0ELYAtk058332@freefall.freebsd.org> Synopsis: [vge] vge(4) does not work properly when loaded as a KLD State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:33:26 UTC 2009 State-Changed-Why: Daniel, is this PR still true for recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:33:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=81644 From vwe at FreeBSD.org Wed Jan 14 13:34:56 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:35:08 2009 Subject: kern/82497: [vge] vge(4) on AMD64 only works when loaded late, not in loader.conf Message-ID: <200901142134.n0ELYsJ3058378@freefall.freebsd.org> Synopsis: [vge] vge(4) on AMD64 only works when loaded late, not in loader.conf Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:34:42 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=82497 From vwe at FreeBSD.org Wed Jan 14 13:36:31 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:36:43 2009 Subject: kern/85266: [xe] [patch] xe(4) driver does not recognise Xircom XE2000 Message-ID: <200901142136.n0ELaSFZ058442@freefall.freebsd.org> Synopsis: [xe] [patch] xe(4) driver does not recognise Xircom XE2000 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:36:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=85266 From vwe at FreeBSD.org Wed Jan 14 13:37:00 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:37:16 2009 Subject: kern/87194: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum Message-ID: <200901142136.n0ELauwd058488@freefall.freebsd.org> Synopsis: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:36:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=87194 From vwe at FreeBSD.org Wed Jan 14 13:40:06 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:40:23 2009 Subject: kern/87506: [vr] [patch] Fix alias support on vr interfaces Message-ID: <200901142140.n0ELe4g4058623@freefall.freebsd.org> Synopsis: [vr] [patch] Fix alias support on vr interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:39:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=87506 From vwe at FreeBSD.org Wed Jan 14 13:42:14 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:42:20 2009 Subject: kern/88082: [ath] [panic] cts protection for ath0 causes panic Message-ID: <200901142142.n0ELg80s065419@freefall.freebsd.org> Synopsis: [ath] [panic] cts protection for ath0 causes panic State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:40:31 UTC 2009 State-Changed-Why: Jake, is this problem still true with later releases? I'm pretty sure I've used CTS on ath myself and have never seen such a panic. Please give us feedback so we don't need to check things which aren't broken. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:40:31 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=88082 From vwe at FreeBSD.org Wed Jan 14 13:42:33 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:42:40 2009 Subject: kern/90890: [vr] Problems with network: vr0: tx shutdown timeout Message-ID: <200901142142.n0ELgVL6065468@freefall.freebsd.org> Synopsis: [vr] Problems with network: vr0: tx shutdown timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:42:21 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=90890 From vwe at FreeBSD.org Wed Jan 14 13:43:33 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:43:39 2009 Subject: kern/91311: [aue] aue interface hanging Message-ID: <200901142143.n0ELhVMe065546@freefall.freebsd.org> Synopsis: [aue] aue interface hanging Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:42:54 UTC 2009 Responsible-Changed-Why: probably more usb related? someone might check that. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=91311 From vwe at FreeBSD.org Wed Jan 14 13:43:58 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:44:05 2009 Subject: kern/91364: [ral] [wep] WF-511 RT2500 Card PCI and WEP Message-ID: <200901142143.n0ELht9g065592@freefall.freebsd.org> Synopsis: [ral] [wep] WF-511 RT2500 Card PCI and WEP Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:43:46 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=91364 From vwe at FreeBSD.org Wed Jan 14 13:45:29 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:45:36 2009 Subject: kern/91859: [ndis] if_ndis does not work with Asus WL-138 Message-ID: <200901142145.n0ELjR5U065656@freefall.freebsd.org> Synopsis: [ndis] if_ndis does not work with Asus WL-138 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:45:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=91859 From vwe at FreeBSD.org Wed Jan 14 13:48:56 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:49:08 2009 Subject: kern/92279: [dc] Core faults everytime I reboot, possible NIC issue. Message-ID: <200901142148.n0ELmspT065725@freefall.freebsd.org> Synopsis: [dc] Core faults everytime I reboot, possible NIC issue. State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 21:47:07 UTC 2009 State-Changed-Why: Paul, by any chance, do you have a backtrace for us? w/o a backtrace, I don't see a chance to imagine the call path and thus we don't know where it breaks. If you don't have one handy and can't reprodruce the panic, please give us feedback so we can close the PR - thanks. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:47:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92279 From vwe at FreeBSD.org Wed Jan 14 13:50:08 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:50:20 2009 Subject: kern/92675: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure Message-ID: <200901142150.n0ELo7eR065848@freefall.freebsd.org> Synopsis: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:49:57 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92675 From vwe at FreeBSD.org Wed Jan 14 13:50:44 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:50:51 2009 Subject: kern/93886: [ath] Atheros/D-Link DWL-G650 long delay to associate on 6.1-PRERELEASE Message-ID: <200901142150.n0ELognp070581@freefall.freebsd.org> Synopsis: [ath] Atheros/D-Link DWL-G650 long delay to associate on 6.1-PRERELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:50:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=93886 From vwe at FreeBSD.org Wed Jan 14 13:51:17 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:51:29 2009 Subject: kern/94162: [bge] 6.x kenel stale with bge(4) Message-ID: <200901142151.n0ELpFIf072666@freefall.freebsd.org> Synopsis: [bge] 6.x kenel stale with bge(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:51:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94162 From vwe at FreeBSD.org Wed Jan 14 13:51:54 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:52:01 2009 Subject: kern/94863: [bge] [patch] hack to get bge(4) working on IBM e326m Message-ID: <200901142151.n0ELppqL072712@freefall.freebsd.org> Synopsis: [bge] [patch] hack to get bge(4) working on IBM e326m Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:51:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94863 From vwe at FreeBSD.org Wed Jan 14 13:52:21 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 13:52:27 2009 Subject: kern/95519: [ral] ral0 could not map mbuf Message-ID: <200901142152.n0ELqJYB072758@freefall.freebsd.org> Synopsis: [ral] ral0 could not map mbuf Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 21:52:09 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=95519 From onemda at gmail.com Wed Jan 14 14:13:03 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Jan 14 14:13:13 2009 Subject: kern/91859: [ndis] if_ndis does not work with Asus WL-138 In-Reply-To: <200901142145.n0ELjR5U065656@freefall.freebsd.org> References: <200901142145.n0ELjR5U065656@freefall.freebsd.org> Message-ID: <3a142e750901141412l10dd16cax6c82903f74350eff@mail.gmail.com> If I'm not mistaken this report is bogus. Correct way to make ndis miniport module is via ndisgen which is shell script for ndiscvt. Report is bogus because OP did not kldload module which have been created with ndiscvt: kldload ndis kldload if_ndis kldload ./created_module_sys.ko -- Paul From vwe at freebsd.org Wed Jan 14 14:16:39 2009 From: vwe at freebsd.org (vwe) Date: Wed Jan 14 14:16:46 2009 Subject: sorry for the noise ;) Message-ID: <1231971383.53310.8.camel@dardanos.sz.vwsoft.com> I'm currently in the process of reassigning a lot of network related PRs from bugs@ to net@. Most of these are old, some are still valid. Please don't hesitate to take a look at them and fix or close them if you think these are outdated and already fixed. Please be sure the number of PRs assigned to net@ will grow further ;) This is in preparation of our next bugathon (not yet officially announced) being held from 2009-01-30 to 2009-02-01. We're going to have a network bugathon then. An official announcement will be send the in a few days. If you're uncomfortable with the number of PRs... well... we'll be happy to see you fixing these issues! :) Thanks Volker From vwe at FreeBSD.org Wed Jan 14 14:19:24 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:19:31 2009 Subject: kern/75407: [an] an(4): no carrier after short time Message-ID: <200901142219.n0EMJNtE088101@freefall.freebsd.org> Synopsis: [an] an(4): no carrier after short time State-Changed-From-To: feedback->suspended State-Changed-By: vwe State-Changed-When: Wed Jan 14 22:19:07 UTC 2009 State-Changed-Why: mail to submitter bounces http://www.freebsd.org/cgi/query-pr.cgi?pr=75407 From vwe at FreeBSD.org Wed Jan 14 14:20:05 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:20:11 2009 Subject: kern/92279: [dc] Core faults everytime I reboot, possible NIC issue. Message-ID: <200901142220.n0EMK49Q088154@freefall.freebsd.org> Synopsis: [dc] Core faults everytime I reboot, possible NIC issue. State-Changed-From-To: feedback->suspended State-Changed-By: vwe State-Changed-When: Wed Jan 14 22:19:53 UTC 2009 State-Changed-Why: mail to submitter bounces http://www.freebsd.org/cgi/query-pr.cgi?pr=92279 From vwe at FreeBSD.org Wed Jan 14 14:22:51 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:23:03 2009 Subject: kern/100839: [txp] txp driver inconsistently stops working when the interface is brought down and back up Message-ID: <200901142222.n0EMMoZJ095097@freefall.freebsd.org> Synopsis: [txp] txp driver inconsistently stops working when the interface is brought down and back up Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:22:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=100839 From vwe at FreeBSD.org Wed Jan 14 14:24:21 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:24:27 2009 Subject: kern/103059: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch) Message-ID: <200901142224.n0EMOLC6095162@freefall.freebsd.org> Synopsis: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:24:09 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=103059 From vwe at FreeBSD.org Wed Jan 14 14:24:55 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:25:02 2009 Subject: kern/103135: [ipsec] ipsec with ipfw divert (not NAT) encodes a packet twice breaking PMTUD Message-ID: <200901142224.n0EMOrWF095208@freefall.freebsd.org> Synopsis: [ipsec] ipsec with ipfw divert (not NAT) encodes a packet twice breaking PMTUD Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:24:42 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=103135 From vwe at FreeBSD.org Wed Jan 14 14:25:49 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:25:56 2009 Subject: kern/103191: Unpredictable reboot Message-ID: <200901142225.n0EMPmTZ095266@freefall.freebsd.org> Synopsis: Unpredictable reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:25:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=103191 From vwe at FreeBSD.org Wed Jan 14 14:27:16 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:27:22 2009 Subject: kern/104485: [bge] Broadcom BCM5704C: Intermittent on newer chip version: CS0424 P20 Message-ID: <200901142227.n0EMRE5W095409@freefall.freebsd.org> Synopsis: [bge] Broadcom BCM5704C: Intermittent on newer chip version: CS0424 P20 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:27:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104485 From vwe at FreeBSD.org Wed Jan 14 14:27:59 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:28:05 2009 Subject: kern/105945: Address can disappear from network interface Message-ID: <200901142227.n0EMRvWN095456@freefall.freebsd.org> Synopsis: Address can disappear from network interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:27:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=105945 From vwe at FreeBSD.org Wed Jan 14 14:28:26 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:28:32 2009 Subject: kern/106243: [nve] double fault panic in if_nve.c on high loads Message-ID: <200901142228.n0EMSPhf095510@freefall.freebsd.org> Synopsis: [nve] double fault panic in if_nve.c on high loads Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:28:15 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=106243 From vwe at FreeBSD.org Wed Jan 14 14:43:01 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 14:43:13 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx Message-ID: <200901142242.n0EMgxsR011302@freefall.freebsd.org> Synopsis: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 22:41:48 UTC 2009 State-Changed-Why: Doichin, the patch isn't available for download anymore, so we're unable to check that issue. Can you please give us the patch so a maintainer can take a look? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 22:41:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 From vwe at FreeBSD.org Wed Jan 14 15:22:25 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:22:32 2009 Subject: kern/90086: [hang] 5.4p8 on supermicro P8SCT hangs during boot if connected to ethernet Message-ID: <200901142322.n0ENMOuR040083@freefall.freebsd.org> Synopsis: [hang] 5.4p8 on supermicro P8SCT hangs during boot if connected to ethernet State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 23:21:21 UTC 2009 State-Changed-Why: Kurt, can you still reproduce the reported problem? sounds like fun! ;) If it's solved, please feed back so we might close that PR. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:21:21 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=90086 From vwe at FreeBSD.org Wed Jan 14 15:23:37 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:23:49 2009 Subject: kern/93019: [ppp] ppp and tunX problems: no traffic after restarting ppp Message-ID: <200901142323.n0ENNavF040133@freefall.freebsd.org> Synopsis: [ppp] ppp and tunX problems: no traffic after restarting ppp Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:23:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=93019 From vwe at FreeBSD.org Wed Jan 14 15:24:59 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:25:10 2009 Subject: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Message-ID: <200901142324.n0ENOvTK040197@freefall.freebsd.org> Synopsis: [socket] TCP socket performance drops by 3000% if packets are split at the first byte State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 23:24:23 UTC 2009 State-Changed-Why: Jost, do you still see this issue with recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:24:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=96268 From vwe at FreeBSD.org Wed Jan 14 15:26:05 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:26:19 2009 Subject: kern/97306: [netgraph] NG_L2TP locks after connection with failed authentication Message-ID: <200901142326.n0ENQ4CW040269@freefall.freebsd.org> Synopsis: [netgraph] NG_L2TP locks after connection with failed authentication Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:25:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=97306 From vwe at FreeBSD.org Wed Jan 14 15:27:10 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:27:21 2009 Subject: bin/97392: ppp(8) hangs instead terminating Message-ID: <200901142327.n0ENR7vM040322@freefall.freebsd.org> Synopsis: ppp(8) hangs instead terminating State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 23:26:38 UTC 2009 State-Changed-Why: Eddy, is this still an issue with recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:26:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=97392 From vwe at FreeBSD.org Wed Jan 14 15:27:43 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:27:49 2009 Subject: bin/98218: wpa_supplicant(8) blacklist not working Message-ID: <200901142327.n0ENRg5F040369@freefall.freebsd.org> Synopsis: wpa_supplicant(8) blacklist not working Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:27:31 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 From vwe at FreeBSD.org Wed Jan 14 15:30:25 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:30:32 2009 Subject: kern/104751: [netgraph] kernel panic, when getting info about my traffic by module ng_ipacct and oppenning www page in browser Message-ID: <200901142330.n0ENUP14042980@freefall.freebsd.org> Synopsis: [netgraph] kernel panic, when getting info about my traffic by module ng_ipacct and oppenning www page in browser Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:30:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104751 From vwe at FreeBSD.org Wed Jan 14 15:31:39 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:31:51 2009 Subject: kern/105348: [ath] ath device stopps TX Message-ID: <200901142331.n0ENVb4v048403@freefall.freebsd.org> Synopsis: [ath] ath device stopps TX Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:31:27 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=105348 From vwe at FreeBSD.org Wed Jan 14 15:32:37 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:32:49 2009 Subject: kern/106974: [bge] packet loose and linkup problem Message-ID: <200901142332.n0ENWaqI048687@freefall.freebsd.org> Synopsis: [bge] packet loose and linkup problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:32:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=106974 From vwe at FreeBSD.org Wed Jan 14 15:33:03 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:33:14 2009 Subject: kern/107850: [bce] bce driver link negotiation is faulty Message-ID: <200901142333.n0ENX1CK049040@freefall.freebsd.org> Synopsis: [bce] bce driver link negotiation is faulty Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:32:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=107850 From vwe at FreeBSD.org Wed Jan 14 15:33:54 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:34:07 2009 Subject: kern/109251: [re] [patch] if_re cardbus card won't attach Message-ID: <200901142333.n0ENXr93049316@freefall.freebsd.org> Synopsis: [re] [patch] if_re cardbus card won't attach Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:33:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109251 From vwe at FreeBSD.org Wed Jan 14 15:34:48 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:34:59 2009 Subject: kern/110140: [ipw] ipw fails under load Message-ID: <200901142334.n0ENYkmB049364@freefall.freebsd.org> Synopsis: [ipw] ipw fails under load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:34:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=110140 From vwe at FreeBSD.org Wed Jan 14 15:35:19 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:35:31 2009 Subject: kern/111457: [ral] ral(4) freeze Message-ID: <200901142335.n0ENZIKe049413@freefall.freebsd.org> Synopsis: [ral] ral(4) freeze Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:35:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=111457 From vwe at FreeBSD.org Wed Jan 14 15:35:44 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:35:51 2009 Subject: kern/112570: [bge] packet loss with bge driver on BCM5704 chipset Message-ID: <200901142335.n0ENZhOH049459@freefall.freebsd.org> Synopsis: [bge] packet loss with bge driver on BCM5704 chipset Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:35:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=112570 From vwe at FreeBSD.org Wed Jan 14 15:36:38 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:36:45 2009 Subject: kern/113895: [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-RELEASE [regression] Message-ID: <200901142336.n0ENabgJ049520@freefall.freebsd.org> Synopsis: [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-RELEASE [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:36:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=113895 From vwe at FreeBSD.org Wed Jan 14 15:37:48 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:37:54 2009 Subject: kern/114899: [bge] bge0: watchdog timeout -- resetting Message-ID: <200901142337.n0ENblYH049570@freefall.freebsd.org> Synopsis: [bge] bge0: watchdog timeout -- resetting State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed Jan 14 23:37:14 UTC 2009 State-Changed-Why: Stefano, do you still experience that issue with recent releases? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:37:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=114899 From vwe at FreeBSD.org Wed Jan 14 15:43:55 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:44:06 2009 Subject: kern/116444: [ath] Atheros 5005G (AR5212) miniPCI: unable to attach device hal status 3 Message-ID: <200901142343.n0ENhrg5056495@freefall.freebsd.org> Synopsis: [ath] Atheros 5005G (AR5212) miniPCI: unable to attach device hal status 3 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:43:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116444 From vwe at FreeBSD.org Wed Jan 14 15:51:11 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:51:17 2009 Subject: kern/118897: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard Message-ID: <200901142351.n0ENpA2k063392@freefall.freebsd.org> Synopsis: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed Jan 14 23:51:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=118897 From vwe at FreeBSD.org Wed Jan 14 15:56:26 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Wed Jan 14 15:56:33 2009 Subject: kern/90086: [hang] 5.4p8 on supermicro P8SCT hangs during boot if connected to ethernet Message-ID: <200901142356.n0ENuPw1063482@freefall.freebsd.org> Synopsis: [hang] 5.4p8 on supermicro P8SCT hangs during boot if connected to ethernet State-Changed-From-To: feedback->suspended State-Changed-By: vwe State-Changed-When: Wed Jan 14 23:56:09 UTC 2009 State-Changed-Why: mail to submitter bounces http://www.freebsd.org/cgi/query-pr.cgi?pr=90086 From doconnor at gsoft.com.au Wed Jan 14 16:30:04 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Jan 14 16:30:11 2009 Subject: kern/81644: [vge] vge(4) does not work properly when loaded as a KLD Message-ID: <200901150030.n0F0U3kb085521@freefall.freebsd.org> The following reply was made to PR kern/81644; it has been noted by GNATS. From: "Daniel O'Connor" To: bug-followup@freebsd.org, doconnor@gsoft.com.au Cc: Subject: Re: kern/81644: [vge] vge(4) does not work properly when loaded as a KLD Date: Thu, 15 Jan 2009 10:44:19 +1030 I don't have any test hardware handy anymore, sorry. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From tom at tomjudge.com Wed Jan 14 17:40:03 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Jan 14 17:40:14 2009 Subject: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Message-ID: <200901150140.n0F1e2Pe039595@freefall.freebsd.org> The following reply was made to PR kern/96268; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, jost2345@users.sourceforge.net Cc: Subject: Re: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Date: Wed, 14 Jan 2009 19:31:11 -0600 I have seen this issue on 7.0-RELEASE. It seems to be related to the nagle algorithm being enable by default on connections on the loop back interface. One application level work around is to set the TCP_NODELAY option on the socket so that the nagle algorithem is disabled. This bug affects users of php java bridge as newer release talk to a JVM over a tcp socket bound to localhost, and the typical packets passing back and forward are very small. It is also possible to reproduce this bug using PHP 5. I can attach test scripts if required. Tom From tom at tomjudge.com Wed Jan 14 17:40:05 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Jan 14 17:40:15 2009 Subject: kern/87194: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum Message-ID: <200901150140.n0F1e47H039626@freefall.freebsd.org> The following reply was made to PR kern/87194; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, green@freebsd.org Cc: Subject: Re: kern/87194: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum Date: Wed, 14 Jan 2009 19:22:17 -0600 Can you add the output of ifconfig bridge0 as if_bridge should downgrade the active hardware features to match the other members in the bridge. Also have you tried "ifconfig fxp0 -txsum -rxsum" to disable the hardware checksumming? I have a number of bridges with all fxp members working fine under 6.2 and 7.0 do you still have these problems on a newer release than 6.0? Tom From yongari at FreeBSD.org Wed Jan 14 18:08:18 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Wed Jan 14 18:08:25 2009 Subject: kern/118897: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard Message-ID: <200901150208.n0F28Hud060636@freefall.freebsd.org> Synopsis: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Jan 15 02:06:33 UTC 2009 State-Changed-Why: I think all known bugs in bfe(4) were fixed. Can you still reproduce the issue on 6.4-RELEASE or 7.1-RELEASE? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Jan 15 02:06:33 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=118897 From yongari at FreeBSD.org Wed Jan 14 18:14:44 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Wed Jan 14 18:14:50 2009 Subject: kern/92675: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure Message-ID: <200901150214.n0F2EhRi068687@freefall.freebsd.org> Synopsis: [fxp] [patch] fxp(4) unable to recover from occasional receiver unit allocation failure State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Jan 15 02:13:36 UTC 2009 State-Changed-Why: fxp(4) in CURRENT has more robust code to cope with resource exhaustion. I think you can use fxp(4) in CURRENT without problems on 7.1-RELEASE or stable/7. Would you give it try? Also fxp(4) in HEAD supports Rx checksum offloading for 82559 so you may get slightly better performance. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Jan 15 02:13:36 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=92675 From dimitar.vassilev at gmail.com Wed Jan 14 20:32:32 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Wed Jan 14 20:32:38 2009 Subject: setfib+pf In-Reply-To: <496CCFBF.3010008@elischer.org> References: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> <496CCFBF.3010008@elischer.org> Message-ID: <59adc1a0901142032u5c6bb08y5c8768aa43d1d56a@mail.gmail.com> > > >> >> I'd much appreciate if someone thinks with me for the best options of >> using >> the setfib features along with pf. >> > > I know setfib but I don't know pf unfortunately.. I use ipfw > (which is why ipfw has fib support :-) > > > possibly Max Lair may know both.. > > Hi Julian, Could you sched some light on the ipfw and setfib as an example. Seems the person you're referring to is busy. The rest I will figure out on my own. If there are results - I will share back. Thanks, Dimitar From julian at elischer.org Wed Jan 14 22:04:44 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Jan 14 22:04:50 2009 Subject: setfib+pf In-Reply-To: <59adc1a0901142032u5c6bb08y5c8768aa43d1d56a@mail.gmail.com> References: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> <496CCFBF.3010008@elischer.org> <59adc1a0901142032u5c6bb08y5c8768aa43d1d56a@mail.gmail.com> Message-ID: <496ECB47.4060005@elischer.org> Dimitar Vasilev wrote: > > > I'd much appreciate if someone thinks with me for the best > options of using > the setfib features along with pf. > > > I know setfib but I don't know pf unfortunately.. I use ipfw > (which is why ipfw has fib support :-) > > > possibly Max Lair may know both.. > > Hi Julian, > Could you sched some light on the ipfw and setfib as an example. Seems > the person you're referring to is busy. The rest I will figure out on my > own. If there are results - I will share back. > Thanks, > Dimitar well, you need to tell me a little more about what you want to do. From sonicy at otenet.gr Wed Jan 14 22:56:15 2009 From: sonicy at otenet.gr (Manolis Kiagias) Date: Wed Jan 14 22:56:23 2009 Subject: kern/118897: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard In-Reply-To: <200901150208.n0F28Hud060636@freefall.freebsd.org> References: <200901150208.n0F28Hud060636@freefall.freebsd.org> Message-ID: <496ED3BD.3040906@otenet.gr> yongari@FreeBSD.org wrote: > Synopsis: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Thu Jan 15 02:06:33 UTC 2009 > State-Changed-Why: > I think all known bugs in bfe(4) were fixed. > Can you still reproduce the issue on 6.4-RELEASE or 7.1-RELEASE? > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Thu Jan 15 02:06:33 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118897 > > > I'll give it a try this afternoon and let you know. From fazaeli at sepehrs.com Thu Jan 15 00:26:34 2009 From: fazaeli at sepehrs.com (H.fazaeli) Date: Thu Jan 15 00:26:41 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <000b01c9768e$745aa160$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> Message-ID: <496EF30E.4010304@sepehrs.com> for example, say you have 2 interface em0 and em1 which you like to swap their minor numbers: ifconfig em0 name tmp ifconfig em1 name em0 ifconfig em0 name em1 or to assign cisco-like names to you interfaces: ifconfig xl0 name fastEthernet0 ifconfig em0 name gigaEthernet0 ifconfig fastEthernet0 192.168.1.0/24 Yony Yossef wrote: -----Original Message----- From: H.fazaeli [[1]mailto:fazaeli@sepehrs.com] Sent: Wednesday, January 14, 2009 6:24 PM To: Yony Yossef Cc: [2]freebsd-net@freebsd.org; [3]freebsd-questions@freebsd.org; Eitan Shefi; Oleg Kats; Liran Liss Subject: Re: howto determine network device unit number? device.hints? you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony Yony Yossef wrote: Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony _______________________________________________ [4]freebsd-questions@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [6]"freebsd-questions-unsubscribe@freebsd.org" -- Best regards. Hooman Fazaeli [7] Sepehr S. T. Co. Ltd. Web: [8]http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 _______________________________________________ [9]freebsd-net@freebsd.org mailing list [10]http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [11]"freebsd-net-unsubscribe@freebsd.org" -- Best regards. Hooman Fazaeli [12] Sepehr S. T. Co. Ltd. Web: [13]http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 References 1. mailto:fazaeli@sepehrs.com 2. mailto:freebsd-net@freebsd.org 3. mailto:freebsd-questions@freebsd.org 4. mailto:freebsd-questions@freebsd.org 5. http://lists.freebsd.org/mailman/listinfo/freebsd-questions 6. mailto:freebsd-questions-unsubscribe@freebsd.org 7. mailto:hf@sepehrs.com 8. http://www.sepehrs.com/ 9. mailto:freebsd-net@freebsd.org 10. http://lists.freebsd.org/mailman/listinfo/freebsd-net 11. mailto:freebsd-net-unsubscribe@freebsd.org 12. mailto:hf@sepehrs.com 13. http://www.sepehrs.com/ From yonyossef.lists at gmail.com Thu Jan 15 00:37:46 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 00:37:59 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496EF30E.4010304@sepehrs.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> Message-ID: <000c01c976ec$87e040b0$220f000a@mtl.com> Thanks for the explanation. So there's no way to determine this in advance.. I must build a script that contains my own mapping between MAC addresses and the wanted interface names and run it after each driver load, rename the interfaces if necessary. It seems quite wrong, don't you agree? And how come the unit number is given an arbitrary value? Is there a good reason for that? Yony _____ From: H.fazaeli [mailto:fazaeli@sepehrs.com] Sent: Thursday, January 15, 2009 10:26 AM To: Yony Yossef Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org Subject: Re: howto determine network device unit number? device.hints? for example, say you have 2 interface em0 and em1 which you like to swap their minor numbers: ifconfig em0 name tmp ifconfig em1 name em0 ifconfig em0 name em1 or to assign cisco-like names to you interfaces: ifconfig xl0 name fastEthernet0 ifconfig em0 name gigaEthernet0 ifconfig fastEthernet0 192.168.1.0/24 Yony Yossef wrote: -----Original Message----- From: H.fazaeli [mailto:fazaeli@sepehrs.com] Sent: Wednesday, January 14, 2009 6:24 PM To: Yony Yossef Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org; Eitan Shefi; Oleg Kats; Liran Liss Subject: Re: howto determine network device unit number? device.hints? you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony Yony Yossef wrote: Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 _______________________________________________ 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" -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From julian at elischer.org Thu Jan 15 00:48:11 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Jan 15 00:48:19 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <000c01c976ec$87e040b0$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> Message-ID: <496EF849.7040909@elischer.org> Yony Yossef wrote: > Thanks for the explanation. > > So there's no way to determine this in advance.. > I must build a script that contains my own mapping between MAC addresses and > the wanted interface names and run it after each driver load, rename the > interfaces if necessary. you must agree it's flexible. > It seems quite wrong, don't you agree? > > And how come the unit number is given an arbitrary value? Is there a good > reason for that? device discovery depends on what slot you put the card into. so if you move it, it's number may change. also, how do you identify the particular card you want to have a particular unit number? considering it may move (and for example USB network interfaces WILL move if you add a keyboard or any other device.. also to do as you want would take 2 passes. first one to find the numbers needed and another to do what's left. > > Yony > > > > _____ > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > Sent: Thursday, January 15, 2009 10:26 AM > To: Yony Yossef > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org > Subject: Re: howto determine network device unit number? device.hints? > > > > for example, say you have 2 interface em0 and em1 which > you like to swap their minor numbers: > > ifconfig em0 name tmp > ifconfig em1 name em0 > ifconfig em0 name em1 > > or to assign cisco-like names to you interfaces: > > ifconfig xl0 name fastEthernet0 > ifconfig em0 name gigaEthernet0 > ifconfig fastEthernet0 192.168.1.0/24 > > > Yony Yossef wrote: > > > > > > > > -----Original Message----- > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > > Sent: Wednesday, January 14, 2009 6:24 PM > > To: Yony Yossef > > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org; > > Eitan Shefi; Oleg Kats; Liran Liss > > Subject: Re: howto determine network device unit number? device.hints? > > > > > > you may not change unit numbers as they are strictly > > controlled by kernel. > > However, on freebsd 5.3+, you may use 'ifconfig name ' > > to achieve the same affect > > > > > > > > Sorry, I don't understand the usage of ifconfig you suggested and the effect > > it will cause. > > Can you please explain it? > > Yony > > > > > > Yony Yossef wrote: > > > > Hi, > > > > I would like to determine the unit number of my network cards, e.g. > > make the device on pci0:16 be assigned every time with unit > > > > number 0 > > > > and pci0:19 with unit number 1. > > > > Is it done by /boot/device.hints? > > if so, how? > > > > My cards are: > > > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > > > > chip=0x636815b3 > > > > rev=0xa0 hdr=0x00 > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > > > > chip=0x636815b3 > > > > rev=0xa0 hdr=0x00 > > > > So I've tried: > > > > hint.mtnic.0.at="pci0:16" > > hint.mtnic.1.at="pci0:19" > > > > but it doesn't work. They keep switching arbitrarily. > > I'm using FreeBSD 7.0. > > > > Thanks > > Yony > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > > > "freebsd-questions-unsubscribe@freebsd.org" > > > > > > > > From root at net1.cc Thu Jan 15 01:25:53 2009 From: root at net1.cc (NetOne - Doichin Dokov) Date: Thu Jan 15 01:26:00 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx In-Reply-To: <200901142242.n0EMgxsR011302@freefall.freebsd.org> References: <200901142242.n0EMgxsR011302@freefall.freebsd.org> Message-ID: <496EFB53.80609@net1.cc> vwe@FreeBSD.org ??????: > Synopsis: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Wed Jan 14 22:41:48 UTC 2009 > State-Changed-Why: > Doichin, > the patch isn't available for download anymore, so we're unable to > check that issue. Can you please give us the patch so a maintainer > can take a look? > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Wed Jan 14 22:41:48 UTC 2009 > Responsible-Changed-Why: > > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 > > Unfortunately it's been a while since I had the need to run those two txp cards I have, and eventually have abandoned the idea of using them at all. I do not keep the patch, but as long as i remember the main thing in it was copying the newest firmware available from the linux's txp (or whatever it was named) driver. I do still keep those cards, and can test them under the latest FBSD and report back later today on the status of the problem. Kind regards, Doichin From yonyossef.lists at gmail.com Thu Jan 15 01:26:38 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 01:26:51 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496EF849.7040909@elischer.org> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496EF849.7040909@elischer.org> Message-ID: <001501c976f3$5d7a81d0$220f000a@mtl.com> > Yony Yossef wrote: > > Thanks for the explanation. > > > > So there's no way to determine this in advance.. > > I must build a script that contains my own mapping between MAC > > addresses and the wanted interface names and run it after > each driver > > load, rename the interfaces if necessary. > > you must agree it's flexible. > > > It seems quite wrong, don't you agree? > > > > And how come the unit number is given an arbitrary value? > Is there a > > good reason for that? > > device discovery depends on what slot you put the card into. > so if you move it, it's number may change. > > also, how do you identify the particular card you want to > have a particular unit number? considering it may move (and > for example USB network interfaces WILL move if you add a > keyboard or any other device.. > > also to do as you want would take 2 passes. > first one to find the numbers needed and another to do what's left. > Julian, I'm not talking about the case where I'm physically switching card locations on the PCI bus. All I'm doing is unloading and reloading the driver. Unit numbers change and it makes my automatic subnet configuration (/etc/rc.conf) assign bad IPs. I still don't get the reason for this arbitrarily assigned unit numbers and what is the common solution for it. Except post load rename of the interfaces. Yony > > > > > Yony > > > > > > > > _____ > > > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > > Sent: Thursday, January 15, 2009 10:26 AM > > To: Yony Yossef > > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org > > Subject: Re: howto determine network device unit number? > device.hints? > > > > > > > > for example, say you have 2 interface em0 and em1 which you like to > > swap their minor numbers: > > > > ifconfig em0 name tmp > > ifconfig em1 name em0 > > ifconfig em0 name em1 > > > > or to assign cisco-like names to you interfaces: > > > > ifconfig xl0 name fastEthernet0 > > ifconfig em0 name gigaEthernet0 > > ifconfig fastEthernet0 192.168.1.0/24 > > > > > > Yony Yossef wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > > > > Sent: Wednesday, January 14, 2009 6:24 PM > > > > To: Yony Yossef > > > > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org; > > > > Eitan Shefi; Oleg Kats; Liran Liss > > > > Subject: Re: howto determine network device unit number? > device.hints? > > > > > > > > > > > > you may not change unit numbers as they are strictly > > > > controlled by kernel. > > > > However, on freebsd 5.3+, you may use 'ifconfig name > ' > > > > to achieve the same affect > > > > > > > > > > > > > > > > Sorry, I don't understand the usage of ifconfig you > suggested and the > > effect > > > > it will cause. > > > > Can you please explain it? > > > > Yony > > > > > > > > > > > > Yony Yossef wrote: > > > > > > > > Hi, > > > > > > > > I would like to determine the unit number of my network cards, e.g. > > > > make the device on pci0:16 be assigned every time with unit > > > > > > > > number 0 > > > > > > > > and pci0:19 with unit number 1. > > > > > > > > Is it done by /boot/device.hints? > > > > if so, how? > > > > > > > > My cards are: > > > > > > > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > > > > > > > > chip=0x636815b3 > > > > > > > > rev=0xa0 hdr=0x00 > > > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > > > > > > > > chip=0x636815b3 > > > > > > > > rev=0xa0 hdr=0x00 > > > > > > > > So I've tried: > > > > > > > > hint.mtnic.0.at="pci0:16" > > > > hint.mtnic.1.at="pci0:19" > > > > > > > > but it doesn't work. They keep switching arbitrarily. > > > > I'm using FreeBSD 7.0. > > > > > > > > Thanks > > > > Yony > > > > _______________________________________________ > > > > freebsd-questions@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > > To unsubscribe, send any mail to > > > > > > > > "freebsd-questions-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > From fazaeli at sepehrs.com Thu Jan 15 01:38:56 2009 From: fazaeli at sepehrs.com (H.fazaeli) Date: Thu Jan 15 01:39:09 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <000c01c976ec$87e040b0$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> Message-ID: <496F012A.2040807@sepehrs.com> Yony Yossef wrote: > Thanks for the explanation. > > So there's no way to determine this in advance.. > What do you mean by 'in advance'? Assuming a fixed hardware configuration, when the kernel is loaded, you know all the interface names and can rename them, i.e., in rc.local. > I must build a script that contains my own mapping between MAC addresses and > the wanted interface names and run it after each driver load, rename the > interfaces if necessary. > I do not quite understand your requirement. Can you please explain? Do you need a script that works on multiple machines with different hardwares? > It seems quite wrong, don't you agree? > > And how come the unit number is given an arbitrary value? Is there a good > reason for that? > > Yony > > > > _____ > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > Sent: Thursday, January 15, 2009 10:26 AM > To: Yony Yossef > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org > Subject: Re: howto determine network device unit number? device.hints? > > > > for example, say you have 2 interface em0 and em1 which > you like to swap their minor numbers: > > ifconfig em0 name tmp > ifconfig em1 name em0 > ifconfig em0 name em1 > > or to assign cisco-like names to you interfaces: > > ifconfig xl0 name fastEthernet0 > ifconfig em0 name gigaEthernet0 > ifconfig fastEthernet0 192.168.1.0/24 > > > Yony Yossef wrote: > > > > > > > > -----Original Message----- > > From: H.fazaeli [mailto:fazaeli@sepehrs.com] > > Sent: Wednesday, January 14, 2009 6:24 PM > > To: Yony Yossef > > Cc: freebsd-net@freebsd.org; freebsd-questions@freebsd.org; > > Eitan Shefi; Oleg Kats; Liran Liss > > Subject: Re: howto determine network device unit number? device.hints? > > > > > > you may not change unit numbers as they are strictly > > controlled by kernel. > > However, on freebsd 5.3+, you may use 'ifconfig name ' > > to achieve the same affect > > > > > > > > Sorry, I don't understand the usage of ifconfig you suggested and the effect > > it will cause. > > Can you please explain it? > > Yony > > > > > > Yony Yossef wrote: > > > > Hi, > > > > I would like to determine the unit number of my network cards, e.g. > > make the device on pci0:16 be assigned every time with unit > > > > number 0 > > > > and pci0:19 with unit number 1. > > > > Is it done by /boot/device.hints? > > if so, how? > > > > My cards are: > > > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > > > > chip=0x636815b3 > > > > rev=0xa0 hdr=0x00 > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > > > > chip=0x636815b3 > > > > rev=0xa0 hdr=0x00 > > > > So I've tried: > > > > hint.mtnic.0.at="pci0:16" > > hint.mtnic.1.at="pci0:19" > > > > but it doesn't work. They keep switching arbitrarily. > > I'm using FreeBSD 7.0. > > > > Thanks > > Yony > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > > > "freebsd-questions-unsubscribe@freebsd.org" > > > > > > > > > -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From yonyossef.lists at gmail.com Thu Jan 15 01:43:38 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 01:43:50 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496F012A.2040807@sepehrs.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F012A.2040807@sepehrs.com> Message-ID: <001601c976f5$c015f7a0$220f000a@mtl.com> > Yony Yossef wrote: > > Thanks for the explanation. > > > > So there's no way to determine this in advance.. > > > What do you mean by 'in advance'? Assuming a fixed hardware > configuration, when the kernel is loaded, you know all the > interface names and can rename them, i.e., in rc.local. >From the beginning: I have a FreeBSD7 machine with two network cards, both carry the same device name "mtnic". My driver is a kernel module loaded manualy using kldload. Upon load, the driver registers the net device by the name "mtnic", that is what you see in ifconfig. Problem is, this unit number is not constant and changing arbitrarily every time I reload the driver (card A unit number=0 & card B un=1 or the other way around). Therefore, IP assignment to mtnic0 by /etc/rc.conf may assign an interface with an IP belongs to another subnet, since rc.conf is not changing. Of course I can keep my own MAC-to-interface mapping and rename the interfaces after I load the driver. It doesn't sound like a reasonable solution though. Plus, I still don't understand why the unit number should change at all, instead of being determined according to the card PCI location or some other constant. Yony > > > I must build a script that contains my own mapping between MAC > > addresses and the wanted interface names and run it after > each driver > > load, rename the interfaces if necessary. > > > I do not quite understand your requirement. Can you please explain? > Do you need a script that works on multiple machines with > different hardwares? > > > It seems quite wrong, don't you agree? > > > > And how come the unit number is given an arbitrary value? > Is there a > > good reason for that? > > > > Yony From rea-fbsd at codelabs.ru Thu Jan 15 02:01:20 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jan 15 02:01:27 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <001501c976f3$5d7a81d0$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496EF849.7040909@elischer.org> <001501c976f3$5d7a81d0$220f000a@mtl.com> Message-ID: Yony, good day. Thu, Jan 15, 2009 at 11:26:34AM +0200, Yony Yossef wrote: > All I'm doing is unloading and reloading the driver. > Unit numbers change and it makes my automatic subnet configuration > (/etc/rc.conf) assign bad IPs. You're using your own driver, aren't you? If yes, could you show your device_method_t structure and the corresponding identify, probe, attach and detach routines? You're setting the unit numbers via 'if_initname(ifp, device_get_name(dev), device_get_unit(dev))' or alike? > I still don't get the reason for this arbitrarily assigned unit numbers and > what is the common solution for it. Except post load rename of the > interfaces. I was under impression that the unit number are coming from the parent busses and they should be stable, at least for the case when the parent bus driver isn't unloaded (and for PCI it should be the case). So, either the driver sets device unit names weirdly or you hit some bug. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From on at cs.ait.ac.th Thu Jan 15 02:29:11 2009 From: on at cs.ait.ac.th (Olivier Nicole) Date: Thu Jan 15 02:29:18 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <001601c976f5$c015f7a0$220f000a@mtl.com> (yonyossef.lists@gmail.com) References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F012A.2040807@sepehrs.com> <001601c976f5$c015f7a0$220f000a@mtl.com> Message-ID: <200901150949.n0F9nCWt065667@banyan.cs.ait.ac.th> Hi, Sorry to jump in but... > Problem is, this unit number is not constant and changing arbitrarily every > time I reload the driver (card A unit number=0 & card B un=1 or the other > way around). Since I have been using FreeBSD, the NIC had always been given the same unit number (that is, unless I play and swap the hardware inside the machine). And that is the normal behaviour. Of course at each boot the interface em0 remains interface em0 and ithe interface em1 remains interface em1, else it would be a headache. > Plus, I still don't understand why the unit number should change at all, > instead of being determined according to the card PCI location or some other > constant. Not only it should not change, but you are the first person I ever see mentioning that it change at each boot. Bests, Olivier From freebsd at levsha.org.ua Thu Jan 15 02:47:32 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Thu Jan 15 02:47:44 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496EF30E.4010304@sepehrs.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> Message-ID: <20090115101306.GG39618@expo.ukrweb.net> H.fazaeli wrote: > > for example, say you have 2 interface em0 and em1 which > you like to swap their minor numbers: > ifconfig em0 name tmp > ifconfig em1 name em0 > ifconfig em0 name em1 > or to assign cisco-like names to you interfaces: > ifconfig xl0 name fastEthernet0 > ifconfig em0 name gigaEthernet0 > ifconfig fastEthernet0 192.168.1.0/24 > Yony Yossef wrote: Interface renaming is complex when you use ng_ether: if ng_ether loaded before renaming, then ng_ether node name remain unchanged after ifconfig ... name -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua From yonyossef.lists at gmail.com Thu Jan 15 03:15:45 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 03:15:50 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496EF849.7040909@elischer.org> <001501c976f3$5d7a81d0$220f000a@mtl.com> Message-ID: <001701c97702$a301bd90$220f000a@mtl.com> > -----Original Message----- > From: rea-fbsd@codelabs.ru [mailto:rea-fbsd@codelabs.ru] > Sent: Thursday, January 15, 2009 12:01 PM > To: Yony Yossef > Cc: 'Julian Elischer'; Liran Liss; freebsd-net@freebsd.org; > Oleg Kats; 'H.fazaeli'; Eitan Shefi; freebsd-questions@freebsd.org > Subject: Re: howto determine network device unit number? device.hints? > > Yony, good day. > > Thu, Jan 15, 2009 at 11:26:34AM +0200, Yony Yossef wrote: > > All I'm doing is unloading and reloading the driver. > > Unit numbers change and it makes my automatic subnet configuration > > (/etc/rc.conf) assign bad IPs. > > You're using your own driver, aren't you? If yes, could you > show your device_method_t structure and the corresponding > identify, probe, attach and detach routines? You're setting > the unit numbers via 'if_initname(ifp, device_get_name(dev), > device_get_unit(dev))' or alike? My device has 2 ports, therefore my if_initname is that: if_initname(dev, device_get_name(mdev->pdev), port + 2 * device_get_unit(mdev->pdev)); > > I still don't get the reason for this arbitrarily assigned unit > > numbers and what is the common solution for it. Except post load > > rename of the interfaces. > > I was under impression that the unit number are coming from > the parent busses and they should be stable, at least for the > case when the parent bus driver isn't unloaded (and for PCI > it should be the case). So, either the driver sets device > unit names weirdly or you hit some bug. > -- > Eygene This is what I captured the last time it happened. # pciconf -l | grep mtnic mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 # kldunload if_mtnic # kldload if_mtnic # pciconf -l | grep mtnic mtnic1@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic0@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 From dimitar.vassilev at gmail.com Thu Jan 15 03:37:43 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Thu Jan 15 03:37:49 2009 Subject: setfib+pf In-Reply-To: <496ECB47.4060005@elischer.org> References: <59adc1a0901122114v15efa47ahba8beef6ace4ddb0@mail.gmail.com> <496CCFBF.3010008@elischer.org> <59adc1a0901142032u5c6bb08y5c8768aa43d1d56a@mail.gmail.com> <496ECB47.4060005@elischer.org> Message-ID: <59adc1a0901150337n5fa35de0vd079f8e764d13b31@mail.gmail.com> 2009/1/15 Julian Elischer > Dimitar Vasilev wrote: > >> >> >> I'd much appreciate if someone thinks with me for the best >> options of using >> the setfib features along with pf. >> >> >> I know setfib but I don't know pf unfortunately.. I use ipfw >> (which is why ipfw has fib support :-) >> >> >> possibly Max Lair may know both.. >> >> Hi Julian, >> Could you sched some light on the ipfw and setfib as an example. Seems the >> person you're referring to is busy. The rest I will figure out on my own. If >> there are results - I will share back. >> Thanks, >> Dimitar >> > > > well, you need to tell me a little more about what you want to do. Thanks - here is the schema: Lan1(browsing clients) | -------------- ---------------- | WRT |-------------| ALIX |-----------Lan2 (DMZ stuff, splitted into various networks, vlans,etc) -------------- --------------- | | ----------- ---------------- | Uplink| | Uplink | ------------ ---------------- I will have two uplinks and would like to failover uplink of clients from lan 1 and lan 2 depending on which link is up, keeping Lan2 accessible via the both uplinks, using something like tunnel1.foobar and tunnel2.foobar, as well as keeping LAN2 isolated from the clients via vlan and firewall rules allowing ssh mostly. As will have various private networks,tunnels,etc and no BGP, I would like to take advantage of setfib. Thanks. Best regards, Dimitar Vassilev From rea-fbsd at codelabs.ru Thu Jan 15 04:35:17 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jan 15 04:35:30 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <001701c97702$a301bd90$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496EF849.7040909@elischer.org> <001501c976f3$5d7a81d0$220f000a@mtl.com> <001701c97702$a301bd90$220f000a@mtl.com> Message-ID: Thu, Jan 15, 2009 at 01:15:53PM +0200, Yony Yossef wrote: > > You're using your own driver, aren't you? If yes, could you > > show your device_method_t structure and the corresponding > > identify, probe, attach and detach routines? You're setting > > the unit numbers via 'if_initname(ifp, device_get_name(dev), > > device_get_unit(dev))' or alike? > > My device has 2 ports, therefore my if_initname is that: > > if_initname(dev, device_get_name(mdev->pdev), > port + 2 * device_get_unit(mdev->pdev)); So, you totally have four network interfaces -- two for each PCI device? > This is what I captured the last time it happened. > > # pciconf -l | grep mtnic > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 > > # kldunload if_mtnic > # kldload if_mtnic > > # pciconf -l | grep mtnic > mtnic1@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 > mtnic0@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 > rev=0xa0 hdr=0x00 Could you do the following: 1. Boot with verbose kernel mode (push '5' on the boot screen). 2. Kldload your module and provide the full list of kernel messages you will see after this action. 3. Kldunload and again, provide all messages kernel will print for this. 4. Kldload again and supply all messages for the last time. This will show the PCI enumeration sequence and probe order for your driver pci device units. This might shed some light on the problem. Thanks. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From bms at FreeBSD.org Thu Jan 15 05:06:31 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jan 15 05:08:31 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <000c01c976ec$87e040b0$220f000a@mtl.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> Message-ID: <496F34D2.7050605@FreeBSD.org> Yony Yossef wrote: > Thanks for the explanation. > > So there's no way to determine this in advance.. > I must build a script that contains my own mapping between MAC addresses and > the wanted interface names and run it after each driver load, rename the > interfaces if necessary. > It seems quite wrong, don't you agree? > > And how come the unit number is given an arbitrary value? Is there a good > reason for that? > Normally the PCI probe runs in the opposite direction from that of Linux. It's largely to do with how the NEWBUS code walks the PCI bus. From a systems management point of view, yeah, it's irritating, however it would probably take more effort (i.e. kernel code) to try to patch it to work differently, and not everyone has free time to sit down and patch the kernel. That and (unlike Solaris) there is no *direct* mapping between the card's driver number on the bus and its network driver number. In your case I'm not sure why your two cards would flip order. Could it be how your BIOS and hardware set up the PCI IDSEL lines at boot? From root at net1.cc Thu Jan 15 05:16:12 2009 From: root at net1.cc (NetOne - Doichin Dokov) Date: Thu Jan 15 05:16:25 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx In-Reply-To: <496EFB53.80609@net1.cc> References: <200901142242.n0EMgxsR011302@freefall.freebsd.org> <496EFB53.80609@net1.cc> Message-ID: <496F3710.2090205@net1.cc> NetOne - Doichin Dokov ??????: > vwe@FreeBSD.org ??????: >> Synopsis: [txp] [patch] txp driver doesn't work with latest firmware >> 03.xxx.xxx >> >> State-Changed-From-To: open->feedback >> State-Changed-By: vwe >> State-Changed-When: Wed Jan 14 22:41:48 UTC 2009 >> State-Changed-Why: Doichin, >> the patch isn't available for download anymore, so we're unable to >> check that issue. Can you please give us the patch so a maintainer >> can take a look? >> >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >> Responsible-Changed-By: vwe >> Responsible-Changed-When: Wed Jan 14 22:41:48 UTC 2009 >> Responsible-Changed-Why: >> Over to maintainer(s). >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 >> >> > Unfortunately it's been a while since I had the need to run those two > txp cards I have, and eventually have abandoned the idea of using them > at all. I do not keep the patch, but as long as i remember the main > thing in it was copying the newest firmware available from the linux's > txp (or whatever it was named) driver. > > I do still keep those cards, and can test them under the latest FBSD > and report back later today on the status of the problem. > > Kind regards, > Doichin > I've now placed one of the cards I have in a FreeBSD 7.0 machine - it's still not recognized (booted) properly. Here's the boot log: ... Jan 15 15:08:41 test kernel: txp0: <3Com 3cR990B-TXM Etherlink with 3XP Processor> port 0x2080-0x20ff mem 0x42000000-0x4200007f irq 11 at device 14.0 on pci0 Jan 15 15:08:41 test kernel: txp0: not waiting for boot Jan 15 15:08:41 test kernel: device_attach: txp0 attach returned -1 ... Here's the related pciconf: txp0@pci0:0:14:0: class=0x020000 card=0x100010b7 chip=0x990410b7 rev=0x03 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3CR990B-TM-X Etherlink 10/100 with 3XP Processor' class = network subclass = ethernet If you're interested in fixing this problem, you might have a look at the driver included in the Linux kernel - it works fine with this card. Unfortunately I no longer need to use those cards, and can afford to spend any time on this issue, what I could help is with testing. I could also provide an SSH access to a machine with this card installed, if this would be of any help resolving the issue. Kind regards, Doichin From bms at FreeBSD.org Thu Jan 15 07:01:43 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jan 15 07:01:50 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496F34D2.7050605@FreeBSD.org> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org> Message-ID: <496F4FD1.4080602@FreeBSD.org> Yony, Bruce M. Simpson wrote: >> >> And how come the unit number is given an arbitrary value? Is there a >> good >> reason for that? >> > ... > > In your case I'm not sure why your two cards would flip order. Could > it be how your BIOS and hardware set up the PCI IDSEL lines at boot? If this is the case on your system, then you really need to provide more data about your hardware, i.e. motherboard, BIOS, vendor information etc. as others point out. Based on the data you've provided about the issue to date, my best guess is that something in the above is different on your system (which is why I mentioned IDSEL lines -- the mechanism PCI uses to actually assign bus numbers electrically). Normally the behaviour of FreeBSD's bus probes is well known -- nexus is walked for child buses, then these buses are plumbed into NEWBUS, e.g. cpu0...cpuN on nexus itself, PCI buses, and PCI subordinate buses in that order. * You mention you don't encounter the issue with Linux, but you may already be aware that udev can tie driver instance number(s) to specific MAC addresses, although this process isn't fully automatic and any given distro may or may not create the persistent udev rules on a first run -- so this is comparing apples with oranges. * [PCI-Express is a special case though, and I've had to sit down and do some work with commercial clients to make sure their appliance was able to detect devices being in particular slot numbers. Again, though, it's just as subject to the PCI enumeration order further up on the bus hierarchy as non-PCI-Express drivers.] So your issue may not be a simple matter of "this seems wrong, this doesn't work", though I am sorry to hear it isn't working for you right now. There are a lot of dynamic factors in the overall picture of the system, and what seems to work as expected for many users, may not be working for you, and we really need basic hardware information, when folk see things like this happening, for any volunteer(s) out there to come up with the right solution, let alone the true picture of what's actually going on in your specific case. thanks BMS From rea-fbsd at codelabs.ru Thu Jan 15 08:48:24 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jan 15 08:48:31 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496F4FD1.4080602@FreeBSD.org> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org> <496F4FD1.4080602@FreeBSD.org> Message-ID: <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> Bruce, good day. Thu, Jan 15, 2009 at 03:01:37PM +0000, Bruce M. Simpson wrote: > Bruce M. Simpson wrote: > > In your case I'm not sure why your two cards would flip order. Could > > it be how your BIOS and hardware set up the PCI IDSEL lines at boot? > > If this is the case on your system, then you really need to provide more > data about your hardware, i.e. motherboard, BIOS, vendor information > etc. as others point out. I wanted to stress only one point: simple 'kldunload ' and 'kldload ' makes devices to flip for Yony's case. This means that unless some PCI hotplug stuff is here (which I don't believe to be present, because no physical cards are touched and there is actually a small amount of PCI hotplug support in FreeBSD), no physical PCI devices get added or removed from the PCI child tree. It looks like that something goes wrong during the PCI tree reprobe on the driver module loading. Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c will invoke device_get_children() to get the list of the attached devices, and for PCI case the list should be static. Here is what I get for the 'kldload if_em' with verbose boot: ----- pci0: driver added found-> vendor=0x8086, dev=0x283e, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added pci1: driver added pci2: driver added pci3: driver added pci4: driver added pci5: driver added found-> vendor=0x8086, dev=0x1010, revid=0x01 domain=0, bus=5, slot=3, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:5:3:0: reprobing on driver added em0: port 0xb880-0xb8bf mem 0xff7c0000-0xff7dffff irq 16 at device 3.0 on pci5 pcib5: em0 requested memory range 0xff7c0000-0xff7dffff: good pcib5: em0 requested I/O range 0xb880-0xb8bf: in range em0: [FILTER] em0: bpf attached em0: Ethernet address: NN:NN:NN:NN:NN:NN found-> vendor=0x8086, dev=0x1010, revid=0x01 domain=0, bus=5, slot=3, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:5:3:1: reprobing on driver added em1: port 0xbc00-0xbc3f mem 0xff7e0000-0xff7fffff irq 17 at device 3.1 on pci5 pcib5: em1 requested memory range 0xff7e0000-0xff7fffff: good pcib5: em1 requested I/O range 0xbc00-0xbc3f: in range em1: [FILTER] em1: bpf attached em1: Ethernet address: NN:NN:NN:NN:NN:NN ----- And this message is stable across repeated kldunload/kldload. I guess that when Yony will enable verbose boot and will show us kernel messages from two successive kldunload/kldload sequences, we will get some additional information about what's going on. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From yonyossef.lists at gmail.com Thu Jan 15 09:39:57 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 09:40:04 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496EF849.7040909@elischer.org> <001501c976f3$5d7a81d0$220f000a@mtl.com> <001701c97702$a301bd90$220f000a@mtl.com> Message-ID: <20def4870901150939h69f8826cobfd46bc99941dcf3@mail.gmail.com> > Thu, Jan 15, 2009 at 01:15:53PM +0200, Yony Yossef wrote: > > > You're using your own driver, aren't you? If yes, could you show > > > your device_method_t structure and the corresponding identify, > > > probe, attach and detach routines? You're setting the > unit numbers > > > via 'if_initname(ifp, device_get_name(dev), > device_get_unit(dev))' > > > or alike? > > > > My device has 2 ports, therefore my if_initname is that: > > > > if_initname(dev, device_get_name(mdev->pdev), > > port + 2 * device_get_unit(mdev->pdev)); > > So, you totally have four network interfaces -- two for each > PCI device? > > > This is what I captured the last time it happened. > > > > # pciconf -l | grep mtnic > > mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > > > # kldunload if_mtnic > > # kldload if_mtnic > > > > # pciconf -l | grep mtnic > > mtnic1@pci0:19:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > mtnic0@pci0:16:0:0: class=0x020000 card=0x001715b3 > chip=0x636815b3 > > rev=0xa0 hdr=0x00 > > Could you do the following: > > 1. Boot with verbose kernel mode (push '5' on the boot screen). > 2. Kldload your module and provide the full list of kernel messages > you will see after this action. > 3. Kldunload and again, provide all messages kernel will print > for this. > 4. Kldload again and supply all messages for the last time. > > This will show the PCI enumeration sequence and probe order > for your driver pci device units. This might shed some light > on the problem. > This is the flow I've done, you can see the swapping happened again: [root@sw247 ~]# pciconf -l | grep mtnic mtnic0@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic1@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 [root@sw247 ~]# kldunload if_mtnic [root@sw247 ~]# kldload if_mtnic [root@sw247 ~]# pciconf -l | grep mtnic mtnic1@pci0:19:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtnic0@pci0:16:0:0: class=0x020000 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 /var/log/messages during this flow (the brackets are my addition ofcourse): [kldunload if_mtnic] Jan 15 19:27:46 sw247 kernel: mtnic0: Destroying netdev on port:0 Jan 15 19:27:46 sw247 kernel: mtnic0: Destroying netdev on port:1 Jan 15 19:27:46 sw247 kernel: mtnic0: Reseting device... Jan 15 19:27:46 sw247 kernel: mtnic0: Reset complete. Jan 15 19:27:46 sw247 kernel: mtnic0: detached Jan 15 19:27:46 sw247 kernel: mtnic1: Destroying netdev on port:0 Jan 15 19:27:46 sw247 kernel: mtnic1: Destroying netdev on port:1 Jan 15 19:27:47 sw247 kernel: mtnic1: Reseting device... Jan 15 19:27:47 sw247 kernel: mtnic1: Reset complete. Jan 15 19:27:47 sw247 kernel: mtnic1: detached [kldload if_mtnic] Jan 15 19:28:04 sw247 kernel: pci0: driver added Jan 15 19:28:04 sw247 kernel: found-> vendor=0x0e11, dev=0xb203, revid=0x03 Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=0 Jan 15 19:28:04 sw247 kernel: class=08-80-00, hdrtype=0x00, mfdev=1 Jan 15 19:28:04 sw247 kernel: cmdreg=0x0103, statreg=0x0290, cachelnsz=0 (dwords) Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jan 15 19:28:04 sw247 kernel: intpin=a, irq=25 Jan 15 19:28:04 sw247 kernel: powerspec 3 supports D0 D3 current D0 Jan 15 19:28:04 sw247 kernel: pci0:0:4:0: reprobing on driver added Jan 15 19:28:04 sw247 kernel: found-> vendor=0x0e11, dev=0xb204, revid=0x03 Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=2 Jan 15 19:28:04 sw247 kernel: class=08-80-00, hdrtype=0x00, mfdev=1 Jan 15 19:28:04 sw247 kernel: cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) Jan 15 19:28:04 sw247 kernel: lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jan 15 19:28:04 sw247 kernel: intpin=b, irq=26 Jan 15 19:28:04 sw247 kernel: powerspec 3 supports D0 D3 current D0 Jan 15 19:28:04 sw247 kernel: pci0:0:4:2: reprobing on driver added Jan 15 19:28:04 sw247 kernel: found-> vendor=0x103c, dev=0x3302, revid=0x00 Jan 15 19:28:04 sw247 kernel: domain=0, bus=0, slot=4, func=6 Jan 15 19:28:04 sw247 kernel: class=0c-07-01, hdrtype=0x00, mfdev=1 Jan 15 19:28:04 sw247 kernel: cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jan 15 19:28:04 sw247 kernel: intpin=a, irq=25 Jan 15 19:28:04 sw247 kernel: powerspec 3 supports D0 D3 current D0 Jan 15 19:28:04 sw247 kernel: pci0:0:4:6: reprobing on driver added Jan 15 19:28:04 sw247 kernel: pci1: driver added Jan 15 19:28:04 sw247 kernel: pci2: driver added Jan 15 19:28:04 sw247 kernel: pci8: driver added Jan 15 19:28:04 sw247 kernel: pci9: driver added Jan 15 19:28:04 sw247 kernel: pci10: driver added Jan 15 19:28:04 sw247 kernel: pci11: driver added Jan 15 19:28:04 sw247 kernel: pci12: driver added Jan 15 19:28:04 sw247 kernel: pci13: driver added Jan 15 19:28:04 sw247 kernel: pci14: driver added Jan 15 19:28:04 sw247 kernel: pci15: driver added Jan 15 19:28:04 sw247 kernel: pci16: driver added Jan 15 19:28:04 sw247 kernel: found-> vendor=0x15b3, dev=0x6368, revid=0xa0 Jan 15 19:28:04 sw247 kernel: domain=0, bus=16, slot=0, func=0 Jan 15 19:28:04 sw247 kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Jan 15 19:28:04 sw247 kernel: cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jan 15 19:28:04 sw247 kernel: intpin=a, irq=20 Jan 15 19:28:04 sw247 kernel: powerspec 3 supports D0 D3 current D0 Jan 15 19:28:04 sw247 kernel: MSI-X supports 256 messages in map 0x10 Jan 15 19:28:04 sw247 kernel: pci0:16:0:0: reprobing on driver added Jan 15 19:28:04 sw247 kernel: mtnic0: mem 0xfde00000-0xfdefffff,0xf7000000-0xf77fffff irq 20 at device 0.0 onpci16 Jan 15 19:28:04 sw247 kernel: mtnic: Mellanox NIC driver v1.2.0 (20090112-1316) Jan 15 19:28:04 sw247 kernel: mtnic0: Initializing mtnic Jan 15 19:28:04 sw247 kernel: pcib5: mtnic0 requested memory range 0xfde00000-0xfdefffff: good Jan 15 19:28:04 sw247 kernel: pcib5: mtnic0 requested memory range 0xf7000000-0xf77fffff: good Jan 15 19:28:04 sw247 kernel: mtnic0: Number of LRO sessions per ring: 32 Jan 15 19:28:04 sw247 kernel: mtnic0: Reseting device... Jan 15 19:28:04 sw247 kernel: mtnic0: Reset complete. Jan 15 19:28:04 sw247 kernel: mtnic0: FW version:2.6.0 Jan 15 19:28:04 sw247 kernel: mtnic0: Board ID: Jan 15 19:28:04 sw247 kernel: mtnic0: Using 1 tx rings for port:1 [4096] Jan 15 19:28:04 sw247 kernel: mtnic0: Using 4 rx rings for port:1 [1024] Jan 15 19:28:04 sw247 kernel: mtnic0: Using 1 tx rings for port:2 [4096] Jan 15 19:28:04 sw247 kernel: mtnic0: Using 4 rx rings for port:2 [1024] Jan 15 19:28:04 sw247 kernel: mtnic0: Initializing MSIX Jan 15 19:28:04 sw247 kernel: mtnic0: Enabling MSI-X (11 vectors) Jan 15 19:28:04 sw247 kernel: mtnic0: attempting to allocate 11 MSI-X vectors (256 supported) Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 256 to vector 53 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 257 to vector 54 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 258 to vector 55 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 259 to vector 56 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 260 to vector 57 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 261 to vector 58 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 262 to vector 59 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 263 to vector 60 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 264 to vector 61 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 265 to vector 62 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 266 to vector 63 Jan 15 19:28:04 sw247 kernel: mtnic0: using IRQs 256-266 for MSI-X Jan 15 19:28:04 sw247 kernel: mtnic0: Board ID:MT_0920110004 Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 256 to local APIC 1 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: mtnic0: Activating port:1 Jan 15 19:28:04 sw247 kernel: mtnic0: Allocated 5 CQs on port:0 name:mtnic unit:0 ifc:0 Jan 15 19:28:04 sw247 kernel: mtnic0: bpf attached Jan 15 19:28:04 sw247 kernel: mtnic0: Ethernet address: 00:02:c9:02:13:2d Jan 15 19:28:04 sw247 kernel: mtnic0: Activating port:2 Jan 15 19:28:04 sw247 kernel: mtnic0: Allocated 5 CQs on port:1 name:mtnic unit:0 ifc:1 Jan 15 19:28:04 sw247 kernel: mtnic1: bpf attached Jan 15 19:28:04 sw247 kernel: mtnic1: Ethernet address: 00:02:c9:02:13:2e Jan 15 19:28:04 sw247 kernel: pci19: driver added Jan 15 19:28:04 sw247 kernel: found-> vendor=0x15b3, dev=0x6368, revid=0xa0 Jan 15 19:28:04 sw247 kernel: domain=0, bus=19, slot=0, func=0 Jan 15 19:28:04 sw247 kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Jan 15 19:28:04 sw247 kernel: cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) Jan 15 19:28:04 sw247 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jan 15 19:28:04 sw247 kernel: intpin=a, irq=16 Jan 15 19:28:04 sw247 kernel: powerspec 3 supports D0 D3 current D0 Jan 15 19:28:04 sw247 kernel: MSI-X supports 256 messages in map 0x10 Jan 15 19:28:04 sw247 kernel: pci0:19:0:0: reprobing on driver added Jan 15 19:28:04 sw247 kernel: mtnic1: mem 0xfdf00000-0xfdffffff,0xf7800000-0xf7ffffff irq 16 at device 0.0 onpci19 Jan 15 19:28:04 sw247 kernel: mtnic1: Initializing mtnic Jan 15 19:28:04 sw247 kernel: pcib4: mtnic1 requested memory range 0xfdf00000-0xfdffffff: good Jan 15 19:28:04 sw247 kernel: pcib4: mtnic1 requested memory range 0xf7800000-0xf7ffffff: good Jan 15 19:28:04 sw247 kernel: mtnic1: Number of LRO sessions per ring: 32 Jan 15 19:28:04 sw247 kernel: mtnic1: Reseting device... Jan 15 19:28:04 sw247 kernel: mtnic1: Reset complete. Jan 15 19:28:04 sw247 kernel: mtnic1: FW version:2.6.0 Jan 15 19:28:04 sw247 kernel: mtnic1: Board ID: Jan 15 19:28:04 sw247 kernel: mtnic1: Using 1 tx rings for port:1 [4096] Jan 15 19:28:04 sw247 kernel: mtnic1: Using 4 rx rings for port:1 [1024] Jan 15 19:28:04 sw247 kernel: mtnic1: Using 1 tx rings for port:2 [4096] Jan 15 19:28:04 sw247 kernel: mtnic1: Using 4 rx rings for port:2 [1024] Jan 15 19:28:04 sw247 kernel: mtnic1: Initializing MSIX Jan 15 19:28:04 sw247 kernel: mtnic1: Enabling MSI-X (11 vectors) Jan 15 19:28:04 sw247 kernel: mtnic1: attempting to allocate 11 MSI-X vectors (256 supported) Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 267 to vector 64 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 268 to vector 65 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 269 to vector 66 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 270 to vector 67 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 271 to vector 68 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 272 to vector 69 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 273 to vector 70 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 274 to vector 71 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 275 to vector 72 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 276 to vector 73 Jan 15 19:28:04 sw247 kernel: msi: routing MSI-X IRQ 277 to vector 74 Jan 15 19:28:04 sw247 kernel: mtnic1: using IRQs 267-277 for MSI-X Jan 15 19:28:04 sw247 kernel: mtnic1: Board ID:MT_0920110004 Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 267 to local APIC 2 Jan 15 19:28:04 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:04 sw247 kernel: mtnic1: Activating port:1 Jan 15 19:28:04 sw247 kernel: mtnic1: Allocated 5 CQs on port:0 name:mtnic unit:1 ifc:2 Jan 15 19:28:04 sw247 kernel: mtnic2: bpf attached Jan 15 19:28:04 sw247 kernel: mtnic2: Ethernet address: 00:02:c9:02:17:f7 Jan 15 19:28:04 sw247 kernel: mtnic1: Activating port:2 Jan 15 19:28:04 sw247 kernel: mtnic1: Allocated 5 CQs on port:1 name:mtnic unit:1 ifc:3 Jan 15 19:28:04 sw247 kernel: mtnic3: bpf attached Jan 15 19:28:04 sw247 kernel: mtnic3: Ethernet address: 00:02:c9:02:17:f8 Jan 15 19:28:04 sw247 kernel: mtnic0: Port is down, ignoring multicast change. Jan 15 19:28:04 sw247 kernel: mtnic0: Change MTU called, driver is not running. flags:0x0 Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 257 to local APIC 3 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 258 to local APIC 0 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 259 to local APIC 1 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 260 to local APIC 2 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: msi: Assigning MSI-X IRQ 261 to local APIC 3 Jan 15 19:28:04 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:04 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:04 sw247 kernel: mtnic0: Port 1 - link up Jan 15 19:28:05 sw247 kernel: mtnic0: Port is down, ignoring multicast change. Jan 15 19:28:05 sw247 kernel: mtnic0: Change MTU called, driver is not running. flags:0x0 Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 262 to local APIC 0 Jan 15 19:28:05 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 263 to local APIC 1 Jan 15 19:28:05 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 264 to local APIC 2 Jan 15 19:28:05 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 265 to local APIC 3 Jan 15 19:28:05 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 266 to local APIC 0 Jan 15 19:28:05 sw247 kernel: mtnic0: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic0: [ITHREAD] Jan 15 19:28:05 sw247 kernel: mtnic0: Port 2 - link up Jan 15 19:28:05 sw247 kernel: mtnic1: Port is down, ignoring multicast change. Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: Change MTU called, driver is not running. flags:0x0 Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 268 to local APIC 1 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 269 to local APIC 2 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 270 to local APIC 3 Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 271 to local APIC 0 Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 272 to local APIC 1 Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic Jan 15 19:28:05 sw247 kernel: 1: [ Jan 15 19:28:05 sw247 kernel: MPSAF Jan 15 19:28:05 sw247 kernel: E] Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: Jan 15 19:28:05 sw247 kernel: [ITH Jan 15 19:28:05 sw247 kernel: READ] Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: Port is down, ignoring multicast change. Jan 15 19:28:05 sw247 kernel: mtnic1: Change MTU called, driver is not running. flags:0x0 Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 273 to local APIC 2 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 274 to local APIC 3 Jan 15 19:28:05 sw247 kernel: Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 275 to local APIC 0 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 276 to local APIC 1 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] Jan 15 19:28:05 sw247 kernel: msi: Assigning MSI-X IRQ 277 to local APIC 2 Jan 15 19:28:05 sw247 kernel: mtnic1: [MPSAFE] Jan 15 19:28:05 sw247 kernel: mtnic1: [ITHREAD] From bms at FreeBSD.org Thu Jan 15 09:48:56 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jan 15 09:49:04 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org> <496F4FD1.4080602@FreeBSD.org> <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> Message-ID: <496F7618.8050809@FreeBSD.org> Eygene Ryabinkin wrote: > ... > I wanted to stress only one point: simple 'kldunload ' and > 'kldload ' makes devices to flip for Yony's case. This means > that unless some PCI hotplug stuff is here (which I don't believe to be > present, because no physical cards are touched and there is actually a > small amount of PCI hotplug support in FreeBSD), no physical PCI devices > get added or removed from the PCI child tree. It looks like that > something goes wrong during the PCI tree reprobe on the driver module > loading. > BTW: Thanks for looking further at the software layer first. VIM is a wee bit easier to use than a bus analyzer. Most motherboards don't support PCI geographical addressing, so... I wager it's the network driver code which may be the source of the problem, based on your analysis! If this code just doing a blind bump of an instance count and using that as a "unit number"... well, that's OK and expected for software virtual devices, but is counter-intuitive for something like hardware. But I don't have any mtnic source, so this is pure speculation on my part. > Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c will > invoke device_get_children() to get the list of the attached devices, > and for PCI case the list should be static. > Yup, that's right. > I guess that when Yony will enable verbose boot and will show us kernel > messages from two successive kldunload/kldload sequences, we will get > some additional information about what's going on. > Hopefully he will chime in... [bms does some google searching *before* he thinks about throwing his toys out of the pram at the Orignal.Poster.] ding :-) [a light bulb above bms' head] So... Yony. you're writing a driver. Maybe there's a bug in it? That's cool, dude. Hope it's a nice card and you plan on sharing the sweets with the rest of the class. ;-) But seriously, please mention that you are writing a driver in general questions you might ask about the whole system, otherwise, FreeBSD volunteers will run around going "Is core code broken?" and that's not so good for community stress levels as a whole. with lemonade, BMS From yonyossef.lists at gmail.com Thu Jan 15 10:07:38 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jan 15 10:07:45 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <496F7618.8050809@FreeBSD.org> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org> <496F4FD1.4080602@FreeBSD.org> <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> <496F7618.8050809@FreeBSD.org> Message-ID: <20def4870901151007s643f6910h1f6dca058852e4b1@mail.gmail.com> > Eygene Ryabinkin wrote: > > ... > > I wanted to stress only one point: simple 'kldunload ' and > > 'kldload ' makes devices to flip for Yony's case. > This means > > that unless some PCI hotplug stuff is here (which I don't > believe to > > be present, because no physical cards are touched and there is > > actually a small amount of PCI hotplug support in FreeBSD), no > > physical PCI devices get added or removed from the PCI > child tree. It > > looks like that something goes wrong during the PCI tree reprobe on > > the driver module loading. > > > > BTW: Thanks for looking further at the software layer first. > > VIM is a wee bit easier to use than a bus analyzer. > > Most motherboards don't support PCI geographical addressing, > so... I wager it's the network driver code which may be the > source of the problem, based on your analysis! > > If this code just doing a blind bump of an instance count and > using that as a "unit number"... well, that's OK and expected > for software virtual devices, but is counter-intuitive for > something like hardware. > > But I don't have any mtnic source, so this is pure > speculation on my part. > > > Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c > > will invoke device_get_children() to get the list of the attached > > devices, and for PCI case the list should be static. > > > > Yup, that's right. > > > I guess that when Yony will enable verbose boot and will show us > > kernel messages from two successive kldunload/kldload sequences, we > > will get some additional information about what's going on. > > > > Hopefully he will chime in... > > [bms does some google searching *before* he thinks about > throwing his toys out of the pram at the Orignal.Poster.] > > ding :-) [a light bulb above bms' head] > > So... Yony. you're writing a driver. > Maybe there's a bug in it? > That's cool, dude. > Hope it's a nice card and you plan on sharing the sweets with > the rest of the class. ;-) > > But seriously, please mention that you are writing a driver > in general questions you might ask about the whole system, > otherwise, FreeBSD volunteers will run around going "Is core > code broken?" and that's not so good for community stress > levels as a whole. > > with lemonade, > BMS Sorry for risking the whole community with a massive heart attack Bruce :) Yes, I am writing a driver and yes, it still has a bug or two I guess.. About sharing it with the rest of the class, that's something I wanted to ask you guys: what's the procedure for a 10GigE driver to apply for the FreeBSD kernel? Mellanox has started porting it's products to FreeBSD about a year ago, hoping to see our 10GigE and InfiniBand drivers inbox next year. Yony From brooks at freebsd.org Thu Jan 15 10:37:44 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jan 15 10:37:59 2009 Subject: howto determine network device unit number? device.hints? In-Reply-To: <20def4870901151007s643f6910h1f6dca058852e4b1@mail.gmail.com> References: <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com> <496E11B7.3010608@sepehrs.com> <000b01c9768e$745aa160$220f000a@mtl.com> <496EF30E.4010304@sepehrs.com> <000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org> <496F4FD1.4080602@FreeBSD.org> <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> <496F7618.8050809@FreeBSD.org> <20def4870901151007s643f6910h1f6dca058852e4b1@mail.gmail.com> Message-ID: <20090115181211.GA81115@lor.one-eyed-alien.net> On Thu, Jan 15, 2009 at 08:07:35PM +0200, Yony Yossef wrote: > > Eygene Ryabinkin wrote: > > > ... > > > I wanted to stress only one point: simple 'kldunload ' and > > > 'kldload ' makes devices to flip for Yony's case. > > This means > > > that unless some PCI hotplug stuff is here (which I don't > > believe to > > > be present, because no physical cards are touched and there is > > > actually a small amount of PCI hotplug support in FreeBSD), no > > > physical PCI devices get added or removed from the PCI > > child tree. It > > > looks like that something goes wrong during the PCI tree reprobe on > > > the driver module loading. > > > > > > > BTW: Thanks for looking further at the software layer first. > > > > VIM is a wee bit easier to use than a bus analyzer. > > > > Most motherboards don't support PCI geographical addressing, > > so... I wager it's the network driver code which may be the > > source of the problem, based on your analysis! > > > > If this code just doing a blind bump of an instance count and > > using that as a "unit number"... well, that's OK and expected > > for software virtual devices, but is counter-intuitive for > > something like hardware. > > > > But I don't have any mtnic source, so this is pure > > speculation on my part. > > > > > Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c > > > will invoke device_get_children() to get the list of the attached > > > devices, and for PCI case the list should be static. > > > > > > > Yup, that's right. > > > > > I guess that when Yony will enable verbose boot and will show us > > > kernel messages from two successive kldunload/kldload sequences, we > > > will get some additional information about what's going on. > > > > > > > Hopefully he will chime in... > > > > [bms does some google searching *before* he thinks about > > throwing his toys out of the pram at the Orignal.Poster.] > > > > ding :-) [a light bulb above bms' head] > > > > So... Yony. you're writing a driver. > > Maybe there's a bug in it? > > That's cool, dude. > > Hope it's a nice card and you plan on sharing the sweets with > > the rest of the class. ;-) > > > > But seriously, please mention that you are writing a driver > > in general questions you might ask about the whole system, > > otherwise, FreeBSD volunteers will run around going "Is core > > code broken?" and that's not so good for community stress > > levels as a whole. > > > > with lemonade, > > BMS > > Sorry for risking the whole community with a massive heart attack Bruce :) > Yes, I am writing a driver and yes, it still has a bug or two I guess.. > About sharing it with the rest of the class, that's something I wanted > to ask you guys: what's the procedure for a 10GigE driver to apply > for the FreeBSD kernel? Pretty much just get it working, make sure it's licensed under a BSD, MIT, or ISC license (ideally, others are possible, but require more approval), and then find someone to review and commit it or sponsor the maintainer for a commit bit. > Mellanox has started porting it's products to FreeBSD about a year > ago, hoping to see our 10GigE and InfiniBand drivers inbox next year. Excellent. -- Brooks > > Yony > _______________________________________________ > 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" > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090115/915111f5/attachment.pgp From sonicy at otenet.gr Thu Jan 15 13:11:19 2009 From: sonicy at otenet.gr (Manolis Kiagias) Date: Thu Jan 15 13:11:28 2009 Subject: kern/118897: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard In-Reply-To: <496ED3BD.3040906@otenet.gr> References: <200901150208.n0F28Hud060636@freefall.freebsd.org> <496ED3BD.3040906@otenet.gr> Message-ID: <496FA674.20002@otenet.gr> Manolis Kiagias wrote: > yongari@FreeBSD.org wrote: > >> Synopsis: [bfe] Kernel Panic acquiring IP address from DHCP server on newly enabled netcard >> >> State-Changed-From-To: open->feedback >> State-Changed-By: yongari >> State-Changed-When: Thu Jan 15 02:06:33 UTC 2009 >> State-Changed-Why: >> I think all known bugs in bfe(4) were fixed. >> Can you still reproduce the issue on 6.4-RELEASE or 7.1-RELEASE? >> >> >> Responsible-Changed-From-To: freebsd-net->yongari >> Responsible-Changed-By: yongari >> Responsible-Changed-When: Thu Jan 15 02:06:33 UTC 2009 >> Responsible-Changed-Why: >> Grab. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=118897 >> >> >> >> > I'll give it a try this afternoon and let you know. > > Continuing with this, I just realized that the machine that replaced the one exhibiting this, does not have a bfe(4) but a bge(4). I no longer have access to any machine with bfe. FWIW, bge(4) works fine performing the same steps. Please feel free to close this report. From linimon at FreeBSD.org Thu Jan 15 13:38:37 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jan 15 13:38:44 2009 Subject: misc/130586: [re] if_re doesn't always attach to Realtek 8111C Message-ID: <200901152138.n0FLcaCm079974@freefall.freebsd.org> Old Synopsis: if_re doesn't always attach to Realtek 8111C New Synopsis: [re] if_re doesn't always attach to Realtek 8111C Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 15 21:38:20 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130586 From jostb2345 at yahoo.de Thu Jan 15 13:59:13 2009 From: jostb2345 at yahoo.de (Jost Boekemeier) Date: Thu Jan 15 13:59:25 2009 Subject: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte In-Reply-To: <200901142324.n0ENOvTK040197@freefall.freebsd.org> Message-ID: <577907.44747.qm@web27006.mail.ukl.yahoo.com> Hi, from my point of view this issue can be closed. TCP write/write/read sequences are bad on any operating system, it's just that other OS are a little bit smarter. -- I think Jon Nagle has had a proposal to fix/remove this unconditional delay, but I don't know if it has been implemented. Furthermore this problem has been fixed on application level. And I think Patrick van Staveren maintains a FreeBSD port which uses unix domain- instead of TCP socket communication. Regards, Jost B?kemeier From qing.li at bluecoat.com Thu Jan 15 16:46:39 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Jan 15 16:46:53 2009 Subject: Bacula: VERY SLOW on SAME host In-Reply-To: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> References: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> Message-ID: This is a known issue and it's easily reproducible using the netperf tool. I am working on a permanent solution. In the meantime you can use the following workaround, as suggested by Kip: route add -host (if-ip) -iface lo0 -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Kip Macy > Sent: Wednesday, January 14, 2009 8:47 PM > To: Larry Rosenman > Cc: freebsd-current@freebsd.org > Subject: Re: Bacula: VERY SLOW on SAME host > > arpv2 - add an localhost interface route as a workaround > > -Kip > > On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman wrote: > > Greetings, > > Somethings changed (Around the 1st of the year?) where my bacula > jobs > > take FOREVER to backup on the same host > > with the StorageDaemon and Director. If I change it to use 127.0.0.1 > > instead of the address on the em card, it's fine. > > > > If I use the address on the em nics, it's like 4kb/sec as opposed to > > multi-megabytes/sec. > > > > I'm looking for how to find what broke. > > > > Other networking to the host is fine, but this is TCP within the same > host, > > but using the IP address on the em interface. > > > > I see the TCP Send-Q fill up, and it's extremely slow. > > > > What data do you need to help debug this? > > > > > > > > -- > > Larry Rosenman http://www.lerctr.org/~ler > > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From yongari at FreeBSD.org Thu Jan 15 18:16:07 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Thu Jan 15 18:16:13 2009 Subject: kern/130586: [re] if_re doesn't always attach to Realtek 8111C Message-ID: <200901160216.n0G2G7Sv089836@freefall.freebsd.org> Synopsis: [re] if_re doesn't always attach to Realtek 8111C State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jan 16 02:14:46 UTC 2009 State-Changed-Why: I believe HEAD has fix for the issue. Would you try re(4) in HEAD? To get the re(4) of HEAD you may have to get following files from HEAD and rebuild kernel. 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_rlreg.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jan 16 02:14:46 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=130586 From tom at tomjudge.com Thu Jan 15 18:30:24 2009 From: tom at tomjudge.com (Tom Judge) Date: Thu Jan 15 18:30:36 2009 Subject: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte In-Reply-To: <577907.44747.qm@web27006.mail.ukl.yahoo.com> References: <577907.44747.qm@web27006.mail.ukl.yahoo.com> Message-ID: <496FED82.3000303@tomjudge.com> Jost Boekemeier wrote: > Hi, > > from my point of view this issue can be closed. > > TCP write/write/read sequences are bad on any operating system, it's just that other OS are a little bit smarter. -- I think Jon Nagle has had a proposal to fix/remove this unconditional delay, but I don't know if it has been implemented. > > Furthermore this problem has been fixed on application level. And I think Patrick van Staveren maintains a FreeBSD port which uses unix domain- instead of TCP socket communication. > > > Regards, > Jost B?kemeier > Hi Jost, I'm not sure if Patrick (I work with him) has a port using unix domain sockets in production. I do know however that patches to PHP (That add the no delay socket option to the sockets API) where submitted after we found the work around for this issue and they where accepted. And that we have a patched php java bridge client running in production. My response was just to say that I have also seen this bug on a more recent release. Regards Tom From ler at lerctr.org Thu Jan 15 20:24:19 2009 From: ler at lerctr.org (Larry Rosenman) Date: Thu Jan 15 20:24:25 2009 Subject: Bacula: VERY SLOW on SAME host In-Reply-To: References: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> Message-ID: On Thu, January 15, 2009 6:46 pm, Li, Qing wrote: > This is a known issue and it's easily reproducible using the > netperf tool. > > I am working on a permanent solution. > > In the meantime you can use the following workaround, as suggested > by Kip: > > route add -host (if-ip) -iface lo0 > Thanks, Qing! If you have code you'd like me to test, feel free. On a related note, is the arp table supposed to be empty now? $ arp -an $ ping 192.168.200.5 PING 192.168.200.5 (192.168.200.5): 56 data bytes 64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms 64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms ^C --- 192.168.200.5 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms $ arp -an $ uname -a FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14 17:16:03 CST 2009 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG amd64 $ > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Kip Macy >> Sent: Wednesday, January 14, 2009 8:47 PM >> To: Larry Rosenman >> Cc: freebsd-current@freebsd.org >> Subject: Re: Bacula: VERY SLOW on SAME host >> >> arpv2 - add an localhost interface route as a workaround >> >> -Kip >> >> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman > wrote: >> > Greetings, >> > Somethings changed (Around the 1st of the year?) where my bacula >> jobs >> > take FOREVER to backup on the same host >> > with the StorageDaemon and Director. If I change it to use > 127.0.0.1 >> > instead of the address on the em card, it's fine. >> > >> > If I use the address on the em nics, it's like 4kb/sec as opposed to >> > multi-megabytes/sec. >> > >> > I'm looking for how to find what broke. >> > >> > Other networking to the host is fine, but this is TCP within the > same >> host, >> > but using the IP address on the em interface. >> > >> > I see the TCP Send-Q fill up, and it's extremely slow. >> > >> > What data do you need to help debug this? >> > >> > >> > >> > -- >> > Larry Rosenman http://www.lerctr.org/~ler >> > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From qing.li at bluecoat.com Thu Jan 15 21:05:01 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Jan 15 21:05:11 2009 Subject: Bacula: VERY SLOW on SAME host References: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> Message-ID: Hi Larry, This empty arp output issue appears to be a recent breakage on amd64. The world+kernel built on Jan. 12 out of my last commit for i386 (r187094) appears to be fine. The problem is being investigated ... -- Qing -----Original Message----- From: Larry Rosenman [mailto:ler@lerctr.org] Sent: Thu 1/15/2009 8:07 PM To: Li, Qing Cc: freebsd-current@freebsd.org; freebsd-net@freebsd.org Subject: RE: Bacula: VERY SLOW on SAME host On Thu, January 15, 2009 6:46 pm, Li, Qing wrote: > This is a known issue and it's easily reproducible using the > netperf tool. > > I am working on a permanent solution. > > In the meantime you can use the following workaround, as suggested > by Kip: > > route add -host (if-ip) -iface lo0 > Thanks, Qing! If you have code you'd like me to test, feel free. On a related note, is the arp table supposed to be empty now? $ arp -an $ ping 192.168.200.5 PING 192.168.200.5 (192.168.200.5): 56 data bytes 64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms 64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms ^C --- 192.168.200.5 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms $ arp -an $ uname -a FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14 17:16:03 CST 2009 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG amd64 $ > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Kip Macy >> Sent: Wednesday, January 14, 2009 8:47 PM >> To: Larry Rosenman >> Cc: freebsd-current@freebsd.org >> Subject: Re: Bacula: VERY SLOW on SAME host >> >> arpv2 - add an localhost interface route as a workaround >> >> -Kip >> >> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman > wrote: >> > Greetings, >> > Somethings changed (Around the 1st of the year?) where my bacula >> jobs >> > take FOREVER to backup on the same host >> > with the StorageDaemon and Director. If I change it to use > 127.0.0.1 >> > instead of the address on the em card, it's fine. >> > >> > If I use the address on the em nics, it's like 4kb/sec as opposed to >> > multi-megabytes/sec. >> > >> > I'm looking for how to find what broke. >> > >> > Other networking to the host is fine, but this is TCP within the > same >> host, >> > but using the IP address on the em interface. >> > >> > I see the TCP Send-Q fill up, and it's extremely slow. >> > >> > What data do you need to help debug this? >> > >> > >> > >> > -- >> > Larry Rosenman http://www.lerctr.org/~ler >> > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From linimon at FreeBSD.org Fri Jan 16 00:29:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 16 00:29:13 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Message-ID: <200901160829.n0G8T0f1005941@freefall.freebsd.org> Old Synopsis: Certain hardware produces "Network is unreachable" errors for scanning tools New Synopsis: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 16 08:22:56 UTC 2009 Responsible-Changed-Why: I'm guessing this is a driver problem rather than 'tcp', but I'll use that as a placeholder for now. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130605 From invite+ke5r5rmn at facebookmail.com Fri Jan 16 00:59:31 2009 From: invite+ke5r5rmn at facebookmail.com (Dima Antipov) Date: Fri Jan 16 00:59:37 2009 Subject: =?utf-8?q?D=C3=A9couvrez_mon_profil_Facebook?= Message-ID: <5e20420639e9f7c14343f571febd5f68@localhost.localdomain> Bonjour Freebsd-net, J'ai cr?? mon profil Facebook sur lequel je peux publier mes photos, mes vid?os et des ?v?nements. Je souhaite vous ajouter ? mes amis pour que vous puissiez y acc?der. Pour cela, vous devez d'abord vous inscrire ? Facebook ! Vous pourrez ensuite cr?er votre propre profil. Merci, Dima Pour vous inscrire ? Facebook, suivez le lien ci-dessous : http://www.facebook.com/p.php?i=1186987124&k=6YF4Q4WYPYVM5CEIXFY6X3&r From qing.li at bluecoat.com Fri Jan 16 01:10:52 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Jan 16 01:11:03 2009 Subject: Bacula: VERY SLOW on SAME host References: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> Message-ID: Thanks to Pawel Jakub Dawidek, I found the empty "arp -an" output bug. The bug was introduced in my last commit that attempted at providing some level of binary compatibility. Please sync file ./src/sys/net/rtsock.c to svn r187328 Thanks, -- Qing -----Original Message----- From: Larry Rosenman [mailto:ler@lerctr.org] Sent: Thu 1/15/2009 8:07 PM To: Li, Qing Cc: freebsd-current@freebsd.org; freebsd-net@freebsd.org Subject: RE: Bacula: VERY SLOW on SAME host On Thu, January 15, 2009 6:46 pm, Li, Qing wrote: > This is a known issue and it's easily reproducible using the > netperf tool. > > I am working on a permanent solution. > > In the meantime you can use the following workaround, as suggested > by Kip: > > route add -host (if-ip) -iface lo0 > Thanks, Qing! If you have code you'd like me to test, feel free. On a related note, is the arp table supposed to be empty now? $ arp -an $ ping 192.168.200.5 PING 192.168.200.5 (192.168.200.5): 56 data bytes 64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms 64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms ^C --- 192.168.200.5 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms $ arp -an $ uname -a FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14 17:16:03 CST 2009 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG amd64 $ > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Kip Macy >> Sent: Wednesday, January 14, 2009 8:47 PM >> To: Larry Rosenman >> Cc: freebsd-current@freebsd.org >> Subject: Re: Bacula: VERY SLOW on SAME host >> >> arpv2 - add an localhost interface route as a workaround >> >> -Kip >> >> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman > wrote: >> > Greetings, >> > Somethings changed (Around the 1st of the year?) where my bacula >> jobs >> > take FOREVER to backup on the same host >> > with the StorageDaemon and Director. If I change it to use > 127.0.0.1 >> > instead of the address on the em card, it's fine. >> > >> > If I use the address on the em nics, it's like 4kb/sec as opposed to >> > multi-megabytes/sec. >> > >> > I'm looking for how to find what broke. >> > >> > Other networking to the host is fine, but this is TCP within the > same >> host, >> > but using the IP address on the em interface. >> > >> > I see the TCP Send-Q fill up, and it's extremely slow. >> > >> > What data do you need to help debug this? >> > >> > >> > >> > -- >> > Larry Rosenman http://www.lerctr.org/~ler >> > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From need4spam at bk.ru Fri Jan 16 01:20:23 2009 From: need4spam at bk.ru (Alexey Ivanov) Date: Fri Jan 16 01:20:34 2009 Subject: TARPIT for pf/ipfw Message-ID: Is there any command identical to: iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT If no, does anyone ever tried to implement this feature? From ivo.vachkov at gmail.com Fri Jan 16 01:54:25 2009 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Fri Jan 16 01:54:32 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: what does TARPIT do ? On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: > Is there any command identical to: > iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > > If no, does anyone ever tried to implement this feature? > > _______________________________________________ > 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" > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From vanhu at FreeBSD.org Fri Jan 16 02:06:31 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Jan 16 02:06:39 2009 Subject: NATT patch on current In-Reply-To: <49688A88.4080503@zirakzigil.org> References: <49685F15.7080605@zirakzigil.org> <20090110100357.GB2718@zeninc.net> <49688A88.4080503@zirakzigil.org> Message-ID: <20090116101139.GA19489@zeninc.net> Hi. The netipsec.c patch should not have been present, it has probably been generated either by a manipulation error from myself or by some race condition between a svn up and a svn diff to produce the patch. Please test the following patch: http://people.freebsd.org/~vanhu/NAT-T/patch-natt-test-TRUNK-2009-01-16.diff It also have updated values for INP_ESPINUDP* flags, so you DO NEED to also recompile ipsec-tools !!! The patch has been generated from a new svn diff, so it will apply cleanly. It seems to compile, but I could NOT test it as I have strange compilation issues with some other part of kernel's sources (in ata/atapci/chipsets, on which I do not have any modifications...), even with a tree without modifications and a GENERIC kernel... If that patch is ok, I'll remove soon the previous patch (http://people.freebsd.org/~vanhu/NAT-T/patch-natt-test-HEAD-2008-07-21.diff) as it contains at least one wrong patch. Yvan. From dudu at dudu.ro Fri Jan 16 02:21:56 2009 From: dudu at dudu.ro (Vlad GALU) Date: Fri Jan 16 02:22:05 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: This particular iptables module keeps the incoming connection up and running, but it sends ACKs advertising a window size of 0 bytes, so that the remote end can't send any data until the local process has decided it's ok to do so. Basically it's used to slow down spammers and worms. On Fri, Jan 16, 2009 at 11:31 AM, Ivo Vachkov wrote: > what does TARPIT do ? > > On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: >> Is there any command identical to: >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT >> >> If no, does anyone ever tried to implement this feature? >> >> _______________________________________________ >> 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" >> > > > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to understand the simplicity." Dennis Ritchie > _______________________________________________ > 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" > -- ~/.signature: no such file or directory From dimitar.vassilev at gmail.com Fri Jan 16 02:53:59 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Fri Jan 16 02:54:14 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: <59adc1a0901160252w2f4c47bbs66db4ab377024784@mail.gmail.com> see spamd for mail and you may use the don't peer list of sbl . 2009/1/16 Vlad GALU > This particular iptables module keeps the incoming connection up and > running, but it sends ACKs advertising a window size of 0 bytes, so > that the remote end can't send any data until the local process has > decided it's ok to do so. Basically it's used to slow down spammers > and worms. > > On Fri, Jan 16, 2009 at 11:31 AM, Ivo Vachkov > wrote: > > what does TARPIT do ? > > > > On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: > >> Is there any command identical to: > >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > >> > >> If no, does anyone ever tried to implement this feature? > >> > >> _______________________________________________ > >> 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" > >> > > > > > > > > -- > > "UNIX is basically a simple operating system, but you have to be a > > genius to understand the simplicity." Dennis Ritchie > > _______________________________________________ > > 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" > > > > > > -- > ~/.signature: no such file or directory > _______________________________________________ > 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 dimitar.vassilev at gmail.com Fri Jan 16 02:54:00 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Fri Jan 16 02:54:15 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: <59adc1a0901160253me54571cl1799cafbf9634273@mail.gmail.com> see spamd for mail and you may use the don't peer list of sbl . 2009/1/16 Vlad GALU > This particular iptables module keeps the incoming connection up and > running, but it sends ACKs advertising a window size of 0 bytes, so > that the remote end can't send any data until the local process has > decided it's ok to do so. Basically it's used to slow down spammers > and worms. > > On Fri, Jan 16, 2009 at 11:31 AM, Ivo Vachkov > wrote: > > what does TARPIT do ? > > > > On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: > >> Is there any command identical to: > >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > >> > >> If no, does anyone ever tried to implement this feature? > >> > >> _______________________________________________ > >> 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" > >> > > > > > > > > -- > > "UNIX is basically a simple operating system, but you have to be a > > genius to understand the simplicity." Dennis Ritchie > > _______________________________________________ > > 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" > > > > > > -- > ~/.signature: no such file or directory > _______________________________________________ > 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 dimitar.vassilev at gmail.com Fri Jan 16 03:07:46 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Fri Jan 16 03:07:53 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: <59adc1a0901160252w2f4c47bbs66db4ab377024784@mail.gmail.com> see spamd for mail and you may use the don't peer list of sbl . 2009/1/16 Vlad GALU > This particular iptables module keeps the incoming connection up and > running, but it sends ACKs advertising a window size of 0 bytes, so > that the remote end can't send any data until the local process has > decided it's ok to do so. Basically it's used to slow down spammers > and worms. > > On Fri, Jan 16, 2009 at 11:31 AM, Ivo Vachkov > wrote: > > what does TARPIT do ? > > > > On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: > >> Is there any command identical to: > >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > >> > >> If no, does anyone ever tried to implement this feature? > >> > >> _______________________________________________ > >> 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" > >> > > > > > > > > -- > > "UNIX is basically a simple operating system, but you have to be a > > genius to understand the simplicity." Dennis Ritchie > > _______________________________________________ > > 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" > > > > > > -- > ~/.signature: no such file or directory > _______________________________________________ > 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 dimitar.vassilev at gmail.com Fri Jan 16 03:09:47 2009 From: dimitar.vassilev at gmail.com (Dimitar Vasilev) Date: Fri Jan 16 03:09:55 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: <59adc1a0901160252w2f4c47bbs66db4ab377024784@mail.gmail.com> see spamd for mail and you may use the don't peer list of sbl . 2009/1/16 Vlad GALU > This particular iptables module keeps the incoming connection up and > running, but it sends ACKs advertising a window size of 0 bytes, so > that the remote end can't send any data until the local process has > decided it's ok to do so. Basically it's used to slow down spammers > and worms. > > On Fri, Jan 16, 2009 at 11:31 AM, Ivo Vachkov > wrote: > > what does TARPIT do ? > > > > On Fri, Jan 16, 2009 at 11:20 AM, Alexey Ivanov wrote: > >> Is there any command identical to: > >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > >> > >> If no, does anyone ever tried to implement this feature? > >> > >> _______________________________________________ > >> 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" > >> > > > > > > > > -- > > "UNIX is basically a simple operating system, but you have to be a > > genius to understand the simplicity." Dennis Ritchie > > _______________________________________________ > > 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" > > > > > > -- > ~/.signature: no such file or directory > _______________________________________________ > 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 john at dnepro.net Fri Jan 16 04:06:06 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Fri Jan 16 04:06:17 2009 Subject: TARPIT for pf/ipfw In-Reply-To: References: Message-ID: <20090116115026.GA98057@roof1.dnepro.net> On Fri, Jan 16, 2009 at 12:20:21PM +0300, Alexey Ivanov wrote: > Is there any command identical to: > iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > > If no, does anyone ever tried to implement this feature? I'm thinking on implementing it in ipfw but it'll be a week or two later, when I will have some free time. Eugene Perevyazko From dudu.meyer at gmail.com Fri Jan 16 04:40:26 2009 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Fri Jan 16 04:40:32 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected Message-ID: Hello, I am trying the new FIB stuff on -STABLE with IPFW, I made many tests and it did not work as I expected. Quick testing: # lynx -dump http://www.whatismyip.org 200.165.75.10 # setfib -1 lynx -dump http://www.whatismyip.org 189.52.141.2 # setfib -2 lynx -dump http://www.whatismyip.org 201.91.92.154 # ipfw -q flush # ipfw add 1 setfib 1 all from any to any 00001 setfib 1 ip from any to any # lynx -dump http://www.whatismyip.org 200.165.75.10 Check for counters: # ipfw -q add 2 allow all from any to any fib 1 # ipfw show 00001 388599 139653215 setfib 1 ip from any to any 00002 4253 2221474 allow ip from any to any fib 1 65535 2419650 983279227 allow ip from any to any # lynx -dump http://www.whatismyip.org 200.165.75.10 # setfib -1 lynx -dump http://www.whatismyip.org 189.52.141.2 Is anything wrong with my concepts? I would like to know if -CURRENT has the same behavior, can someone please test? -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From marc at sanity.de Fri Jan 16 05:00:04 2009 From: marc at sanity.de (Marc Peters) Date: Fri Jan 16 05:00:10 2009 Subject: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Message-ID: <200901161300.n0GD03ea007747@freefall.freebsd.org> The following reply was made to PR kern/128917; it has been noted by GNATS. From: Marc Peters To: bug-followup@FreeBSD.org, kitambi@epicsol.org Cc: Subject: Re: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Date: Fri, 16 Jan 2009 13:34:29 +0100 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am hitting this too on a network with an airport extreme access point when it uses "WPA/WPA2". With these Security Setting Apple just uses TKIP and trying to force FreeBSD to use AES-CCMP in /etc/wpa_supplicant.conf doesn't work, e.g. wpi cannot connect to the network. Using only WPA2 on this access point will provide AES and no more panics. here is some additional information as suggested on the STABLE-ML: from a textdump: msgbuf.txt: [snipping dmesg and startup-messages] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xffff fault code = supervisor read, page not present instruction pointer = 0x20:0xc0e70dfc stack pointer = 0x28:0xe58bbbe0 frame pointer = 0x28:0xe58bbc9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 25 (wpi0 taskq) ddb.txt (just bt output here): db> bt Tracing pid 25 tid 100024 td 0xc5189af0 wpi_ops(c52c5000,1,c0b7cf36,0,0,...) at wpi_ops+0x89c taskqueue_run(c52ab200,c52ab21c,0,c0b7cf36,0,...) at taskqueue_run+0x175 taskqueue_thread_loop(c52c69b4,e58bbd38,0,0,0,...) at taskqueue_thread_loop+0xbb fork_exit(c07fb2b0,c52c69b4,e58bbd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 - --- trap 0, eip = 0, esp = 0xe58bbd70, ebp = 0 --- version.txt: FreeBSD 7.1-STABLE #0: Thu Jan 15 13:51:12 CET 2009 root@lappi.agentur.local:/usr/obj/usr/src/sys/DEBUG_DRM gdb gdb> file /boot/YOUR_KERNEL/if_wpi.ko Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done. gdb> l *wpi_ops+0x89c 0x9dfc is in wpi_ops (/usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2411). 2406 /* update adapter's configuration */ 2407 sc->config.associd = 0; 2408 sc->config.filter &= ~htole32(WPI_FILTER_BSS); 2409 IEEE80211_ADDR_COPY(sc->config.bssid, ni->ni_bssid); 2410 sc->config.chan = ieee80211_chan2ieee(ic, ni->ni_chan); 2411 if (IEEE80211_IS_CHAN_2GHZ(ni->ni_chan)) { 2412 sc->config.flags |= htole32(WPI_CONFIG_AUTO | 2413 WPI_CONFIG_24GHZ); 2414 } 2415 switch (ic->ic_curmode) { -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAklwftUACgkQCnBgS+kUGEtEDwCeLB9z3ynmx9yyXcl3+DTJqTyk 5XQAnRY2PTpFlWrF+5bQqN7ygkV9tMch =XAks -----END PGP SIGNATURE----- From lists.br at gmail.com Fri Jan 16 05:12:17 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Fri Jan 16 05:36:46 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected References: Message-ID: <43745E4B2C034B1F8657F115B9E5DDA8@adnote989> > Hello, > > I am trying the new FIB stuff on -STABLE with IPFW, I made many tests > and it did not work as I expected. > > Quick testing: > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > # setfib -1 lynx -dump http://www.whatismyip.org > 189.52.141.2 > > # setfib -2 lynx -dump http://www.whatismyip.org > 201.91.92.154 > > # ipfw -q flush > # ipfw add 1 setfib 1 all from any to any > 00001 setfib 1 ip from any to any > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > Check for counters: > > # ipfw -q add 2 allow all from any to any fib 1 > # ipfw show > 00001 388599 139653215 setfib 1 ip from any to any > 00002 4253 2221474 allow ip from any to any fib 1 > 65535 2419650 983279227 allow ip from any to any > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > # setfib -1 lynx -dump http://www.whatismyip.org > 189.52.141.2 > > Is anything wrong with my concepts? I would like to know if -CURRENT > has the same behavior, can someone please test? > > -- > =========== > Eduardo Meyer > pessoal: dudu.meyer@gmail.com > profissional: ddm.farmaciap@saude.gov.br Eduardo, This will not work this way... The socket used by lynx (in this case) get its data is routed by the default fib table (1) before ipfw can see the packet. When ipfw rule is applied the packet is already routed and you wont get what you want. As far as i know (not too much :)) you will need to use the fwd rules to redirect the local packets. Setfib rules work for packets that are comming from an interface and need to be routed to another (non local traffic). Setfib will not re-route the packet. Luiz From julian at elischer.org Fri Jan 16 11:37:53 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Jan 16 11:38:06 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected In-Reply-To: References: Message-ID: <4970DB6C.4030200@elischer.org> Eduardo Meyer wrote: > Hello, > > I am trying the new FIB stuff on -STABLE with IPFW, I made many tests > and it did not work as I expected. > > Quick testing: > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > # setfib -1 lynx -dump http://www.whatismyip.org > 189.52.141.2 > > # setfib -2 lynx -dump http://www.whatismyip.org > 201.91.92.154 > so you have 3 tables with different default routes? > # ipfw -q flush > # ipfw add 1 setfib 1 all from any to any > 00001 setfib 1 ip from any to any > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > Check for counters: > > # ipfw -q add 2 allow all from any to any fib 1 > # ipfw show obviously you did some other commands here.. something generated 2 million packets.. > 00001 388599 139653215 setfib 1 ip from any to any > 00002 4253 2221474 allow ip from any to any fib 1 > 65535 2419650 983279227 allow ip from any to any > > # lynx -dump http://www.whatismyip.org > 200.165.75.10 > > # setfib -1 lynx -dump http://www.whatismyip.org > 189.52.141.2 > > Is anything wrong with my concepts? I would like to know if -CURRENT > has the same behavior, can someone please test? this is expected.. setfib in the firewall can only change the fib on an outgoing packet AFTER it has already done its routing decision. setfib in ipfw is basically for packets that you are ROUTING, (i.e. you are a gateway) and is expected to be run in INCOMING packets before they make their routing decision.. I was thinking of adding a 'reroute' ipfw keyword.. kind of like 'fwd {original dest} ip from any to any' because 'fwd' does cause the routing decision to be redone. The fib of the process that opens the socket controls where packets from the local machine are sent. From gavin at FreeBSD.org Fri Jan 16 11:58:18 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Jan 16 11:58:29 2009 Subject: kern/130628: NFS / rpc.lockd deadlock on 7.1-R Message-ID: <200901161958.n0GJwHui021012@freefall.freebsd.org> Synopsis: NFS / rpc.lockd deadlock on 7.1-R Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Jan 16 19:55:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). Looks like there should be pretty much all the info here necessary to figure this out. To submitter: are you using TCP or UDP NFS mounts? http://www.freebsd.org/cgi/query-pr.cgi?pr=130628 From ler at lerctr.org Fri Jan 16 12:24:17 2009 From: ler at lerctr.org (Larry Rosenman) Date: Fri Jan 16 12:24:27 2009 Subject: Bacula: VERY SLOW on SAME host In-Reply-To: References: <3c1674c90901142046n6cd3c328kc0936190c2516a2a@mail.gmail.com> Message-ID: <006501c97818$64f732c0$2ee59840$@org> verified to fix the arp problem! Thanks, Qing! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Li, Qing Sent: Friday, January 16, 2009 3:11 AM To: Larry Rosenman; ato@iem.pw.edu.pl Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: RE: Bacula: VERY SLOW on SAME host Thanks to Pawel Jakub Dawidek, I found the empty "arp -an" output bug. The bug was introduced in my last commit that attempted at providing some level of binary compatibility. Please sync file ./src/sys/net/rtsock.c to svn r187328 Thanks, -- Qing -----Original Message----- From: Larry Rosenman [mailto:ler@lerctr.org] Sent: Thu 1/15/2009 8:07 PM To: Li, Qing Cc: freebsd-current@freebsd.org; freebsd-net@freebsd.org Subject: RE: Bacula: VERY SLOW on SAME host On Thu, January 15, 2009 6:46 pm, Li, Qing wrote: > This is a known issue and it's easily reproducible using the > netperf tool. > > I am working on a permanent solution. > > In the meantime you can use the following workaround, as suggested > by Kip: > > route add -host (if-ip) -iface lo0 > Thanks, Qing! If you have code you'd like me to test, feel free. On a related note, is the arp table supposed to be empty now? $ arp -an $ ping 192.168.200.5 PING 192.168.200.5 (192.168.200.5): 56 data bytes 64 bytes from 192.168.200.5: icmp_seq=0 ttl=255 time=0.810 ms 64 bytes from 192.168.200.5: icmp_seq=1 ttl=255 time=0.292 ms ^C --- 192.168.200.5 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.292/0.551/0.810/0.259 ms $ arp -an $ uname -a FreeBSD borg.lerctr.org 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Jan 14 17:16:03 CST 2009 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG amd64 $ > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Kip Macy >> Sent: Wednesday, January 14, 2009 8:47 PM >> To: Larry Rosenman >> Cc: freebsd-current@freebsd.org >> Subject: Re: Bacula: VERY SLOW on SAME host >> >> arpv2 - add an localhost interface route as a workaround >> >> -Kip >> >> On Wed, Jan 14, 2009 at 8:35 PM, Larry Rosenman > wrote: >> > Greetings, >> > Somethings changed (Around the 1st of the year?) where my bacula >> jobs >> > take FOREVER to backup on the same host >> > with the StorageDaemon and Director. If I change it to use > 127.0.0.1 >> > instead of the address on the em card, it's fine. >> > >> > If I use the address on the em nics, it's like 4kb/sec as opposed to >> > multi-megabytes/sec. >> > >> > I'm looking for how to find what broke. >> > >> > Other networking to the host is fine, but this is TCP within the > same >> host, >> > but using the IP address on the em interface. >> > >> > I see the TCP Send-Q fill up, and it's extremely slow. >> > >> > What data do you need to help debug this? >> > >> > >> > >> > -- >> > Larry Rosenman http://www.lerctr.org/~ler >> > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From cswiger at mac.com Fri Jan 16 13:37:58 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jan 16 13:38:05 2009 Subject: TARPIT for pf/ipfw In-Reply-To: <20090116115026.GA98057@roof1.dnepro.net> References: <20090116115026.GA98057@roof1.dnepro.net> Message-ID: <06EC1210-8D3E-4F47-A1DE-F0AE038929D9@mac.com> On Jan 16, 2009, at 3:50 AM, Eugene Perevyazko wrote: > On Fri, Jan 16, 2009 at 12:20:21PM +0300, Alexey Ivanov wrote: >> Is there any command identical to: >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT >> >> If no, does anyone ever tried to implement this feature? > > I'm thinking on implementing it in ipfw but it'll be a week or two > later, > when I will have some free time. Note that net/honeyd and security/labrea offer somewhat similar functionality. -- -Chuck From linimon at FreeBSD.org Fri Jan 16 14:45:56 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 16 14:46:03 2009 Subject: conf/130555: [rc.d] [patch] No good way to set ipfilter variables at boot time Message-ID: <200901162245.n0GMjteM049821@freefall.freebsd.org> Old Synopsis: [patch] No good way to set ipfilter variables at boot time New Synopsis: [rc.d] [patch] No good way to set ipfilter variables at boot time Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 16 22:44:56 UTC 2009 Responsible-Changed-Why: Perhaps the folks on -net can evaluate this. http://www.freebsd.org/cgi/query-pr.cgi?pr=130555 From jd at ods.org Fri Jan 16 16:50:33 2009 From: jd at ods.org (Jason DiCioccio) Date: Fri Jan 16 16:50:40 2009 Subject: kern/130059: [panic] Leaking 50k mbufs/hour In-Reply-To: References: <200812311353.mBVDraLJ042040@freefall.freebsd.org> Message-ID: I narrowed this bug down to the following patch to djb's ucspi-tcp (adds ipv6 functionality): http://www.fefe.de/ucspi/ I don't think that userland processes should be able to wreak that much havoc on the network stack. Another thing of note is that even if I kill the processes causing the problem, the mbufs are never reclaimed. Seems like a permanent leak. When I got rid of the ipv6 patch, the mbufs stopped building up and everything has been fine.. Note that the ipv6 traffic for this process was fairly minimal. From jd at ods.org Fri Jan 16 17:00:15 2009 From: jd at ods.org (Jason DiCioccio) Date: Fri Jan 16 17:00:21 2009 Subject: kern/130059: [panic] Leaking 50k mbufs/hour Message-ID: <200901170100.n0H105sr047005@freefall.freebsd.org> The following reply was made to PR kern/130059; it has been noted by GNATS. From: "Jason DiCioccio" To: bug-followup@freebsd.org Cc: Subject: Re: kern/130059: [panic] Leaking 50k mbufs/hour Date: Fri, 16 Jan 2009 16:51:47 -0800 I narrowed this bug down to the following patch to djb's ucspi-tcp (adds ipv6 functionality): http://www.fefe.de/ucspi/ I don't think that userland processes should be able to wreak that much havoc on the network stack. Another thing of note is that even if I kill the processes causing the problem, the mbufs are never reclaimed. Seems like a permanent leak. When I got rid of the ipv6 patch, the mbufs stopped building up and everything has been fine.. Note that the ipv6 traffic for this process was fairly minimal. From kostikbel at gmail.com Sat Jan 17 07:50:56 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Jan 17 07:51:02 2009 Subject: age(4) corrupts packets Message-ID: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> I have to use a machine with ASUS motherboard, that has age(4) ethernet adapter. It seems that active use of the net causes corrupted frames, like the following ssh disconnect (after doing find / in the shell): Disconnecting: Corrupted MAC on input. Machine runs reasonably latest stable/7. Any advice ? Anything I should try to tweak ? Do you need additional information ? I can test patches on this box. age0: mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 age0: Reserved 0x40000 bytes for rid 0x10 type 3 at 0xfeac0000 age0: PCI device revision : 0x00b0 age0: Chip id/revision : 0x9006 age0: 1280 Tx FIFO, 2364 Rx FIFO age0: MSIX count : 0 age0: MSI count : 1 age0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 52 age0: using IRQ 256 for MSI age0: Using 1 MSI messages. age0: Read request size : 512 bytes. age0: TLP payload size : 128 bytes. age0: PCI VPD capability not found! miibus0: on age0 atphy0: PHY 0 on miibus0 atphy0: OUI 0x001374, model 0x0001, rev. 5 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto age0: bpf attached age0: Ethernet address: 00:1f:c6:b9:cc:a7 msi: Assigning MSI IRQ 256 to local APIC 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090117/4f9f1151/attachment.pgp From barney_cordoba at yahoo.com Sat Jan 17 09:25:18 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sat Jan 17 09:25:25 2009 Subject: age(4) corrupts packets In-Reply-To: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> Message-ID: <144876.14982.qm@web63908.mail.re1.yahoo.com> Use a plug in card. ASUS always puts junk on their MBs. --- On Sat, 1/17/09, Kostik Belousov wrote: > From: Kostik Belousov > Subject: age(4) corrupts packets > To: yongari@freebsd.org > Cc: freebsd-net@freebsd.org > Date: Saturday, January 17, 2009, 10:25 AM > I have to use a machine with ASUS motherboard, that has > age(4) ethernet > adapter. It seems that active use of the net causes > corrupted frames, > like the following ssh disconnect (after doing find / in > the shell): > Disconnecting: Corrupted MAC on input. > > Machine runs reasonably latest stable/7. > > Any advice ? Anything I should try to tweak ? Do you need > additional > information ? > > I can test patches on this box. > > age0: > mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 > age0: Reserved 0x40000 bytes for rid 0x10 type 3 at > 0xfeac0000 > age0: PCI device revision : 0x00b0 > age0: Chip id/revision : 0x9006 > age0: 1280 Tx FIFO, 2364 Rx FIFO > age0: MSIX count : 0 > age0: MSI count : 1 > age0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to vector 52 > age0: using IRQ 256 for MSI > age0: Using 1 MSI messages. > age0: Read request size : 512 bytes. > age0: TLP payload size : 128 bytes. > age0: PCI VPD capability not found! > miibus0: on age0 > atphy0: PHY 0 on miibus0 > atphy0: OUI 0x001374, model 0x0001, rev. 5 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, auto > age0: bpf attached > age0: Ethernet address: 00:1f:c6:b9:cc:a7 > msi: Assigning MSI IRQ 256 to local APIC 0 From prt at prt.org Sat Jan 17 12:28:52 2009 From: prt at prt.org (Paul Thornton) Date: Sat Jan 17 12:28:59 2009 Subject: pppoed problem with reconnections Message-ID: <49723ABE.6010409@prt.org> Hi folks, I am currently doing some lab testing with 6.3-release and a pppoe setup where each user has their own VLAN. On the termination box have an em interface with about 200 VLANs configured on it, and have a ppp.conf looking like this: default: set log Chat Command Phase enable pap enable chap allow mode direct set mru 1462 set mtu 1462 set timeout 0 enable lqr accept dns set dns 192.168.1.1 192.168.1.2 set radius /etc/ppp/radius.conf set ifaddr 192.168.254.254/32 cv1001e: set device PPPoE:vlan1001:cv1001 cv1002e: set device PPPoE:vlan1002:cv1002 cv1003e: set device PPPoE:vlan1003:cv1003 cv1004e: set device PPPoE:vlan1004:cv1004 (and so on for several pages) There are multiple pppoed processes running, one for each VLAN (this might seem wasteful but there are other reasons for doing it this way). All user authentication and IP address assignment is handled by the radius server, and each user ID has a static IP address. The problem I'm seeing is as follows: - PPPoE connection comes in, is authenticated, and a ppp process is exec()ed by pppoed. - This connection has the user's IP address, say 192.168.254.1. - Everything works as expected. This is a Good Thing. - The PPPoE connection is then not disconnected cleanly (say network cable pulled out, or machine reboots, etc) - Back on the termination box, there is still a ppp process running using that address. - When you try and reconnect as the original user, it fails because the address cannot be assigned (already in use). Things then stay like this for ever until I kill the ppp process that was connected with the pppoed running on that VLAN. I don't want to set a timeout as I want these sessions to be always on. Is there any way to configure pppoed to kill the old ppp process before trying to launch the new one, so the IP address is released? I guess I'm asking the reverse of the age old "how do I deny multiple logins" question - how do I allow it, but have the new one boot the old one off? Thanks, Paul. From linimon at FreeBSD.org Sat Jan 17 13:32:25 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Jan 17 13:32:37 2009 Subject: kern/130652: [kernel] [patch] Possible deadlock in rt_check() (sys/net/route.c) Message-ID: <200901172132.n0HLWOpg036904@freefall.freebsd.org> Old Synopsis: Possible deadlock in rt_check() (sys/net/route.c) New Synopsis: [kernel] [patch] Possible deadlock in rt_check() (sys/net/route.c) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 17 21:31:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130652 From miroslav at svishtov.net Sat Jan 17 16:40:38 2009 From: miroslav at svishtov.net (Miroslav Slavkov) Date: Sat Jan 17 16:40:46 2009 Subject: dummynet high cpu load Message-ID: <20090118021115.53633c6a@mail.svishtov.net> Hello, I have a strange thing going on with dummynet. I'm loading around 11000 pipes. The machine does not forward, generate or receive any traffic. The only running service is ssh. It's for developing purposes. The thing happening is when loading more than 10700 pipes. The dummynet process begins to eat around %50 of cpu. If i load only 10000 pipes, it is using 0% cpu. Some output: # ipfw show 65535 612000 126865054 allow ip from any to any # ipfw pipe show| wc -l 10001 # top -Sd 2 last pid: 35787; load averages: 0.11, 0.17, 0.16 up 0+11:29:29 01:53:51 73 processes: 6 running, 53 sleeping, 14 waiting CPU: 0.0% user, 0.0% nice, 25.1% system, 0.2% interrupt, 74.7% idle Mem: 23M Active, 20M Inact, 156M Wired, 48K Cache, 38M Buf, 781M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 0 566:04 99.37% idle: cpu0 11 root 1 171 ki31 0K 16K RUN 1 459:35 99.07% idle: cpu1 36 root 1 -68 - 0K 16K CPU0 0 343:55 0.00% dummynet Still.. while loading the rules (one row per pipe config, with script for pipe counting...) the dummynet process begins to raise the usage after 4000 or some pipes. It gets to 0% after 10-20 secs. # ipfw pipe show | wc -l 10701 # top -Sd2 last pid: 57219; load averages: 0.32, 0.23, 0.18 up 0+11:37:13 02:01:35 73 processes: 5 running, 54 sleeping, 14 waiting CPU: 0.0% user, 0.0% nice, 25.2% system, 0.0% interrupt, 74.8% idle Mem: 23M Active, 21M Inact, 156M Wired, 48K Cache, 38M Buf, 781M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K RUN 1 465:48 91.26% idle: cpu1 12 root 1 171 ki31 0K 16K RUN 0 568:09 59.38% idle: cpu0 36 root 1 -68 - 0K 16K CPU0 0 350:22 51.56% dummynet # uname -rp 7.1-STABLE amd64 The system is last updated on 15 Jan 2009. The pipes are simple enough: ipfw pipe X config bw ????Kbit/s Seems strange, because no rules are applied. The load is still around 50% even if the firewall is turned off with the sysctl option. Any clues? From linimon at FreeBSD.org Sat Jan 17 18:36:00 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Jan 17 18:36:07 2009 Subject: kern/130525: [ndis] [panic] 64 bit ar5008 ndisgen-erated driver causes kernel panic on kldload Message-ID: <200901180235.n0I2ZxTF067677@freefall.freebsd.org> Old Synopsis: 64 bit ar5008 ndisgen-erated driver causes kernel panic on kldload New Synopsis: [ndis] [panic] 64 bit ar5008 ndisgen-erated driver causes kernel panic on kldload Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 18 02:33:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130525 From tejblum at yandex-team.ru Sun Jan 18 00:52:38 2009 From: tejblum at yandex-team.ru (Dmitrij Tejblum) Date: Sun Jan 18 00:52:59 2009 Subject: age(4) corrupts packets In-Reply-To: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> References: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> Message-ID: <4972EB41.5070601@yandex-team.ru> Kostik Belousov wrote: > I have to use a machine with ASUS motherboard, that has age(4) ethernet > adapter. It seems that active use of the net causes corrupted frames, > like the following ssh disconnect (after doing find / in the shell): > Disconnecting: Corrupted MAC on input. It can't be just a packet corruption, since TCP has checksums, and corrupted packets should have been dropped and retransmitted. Try to turn off checksum offloading. > > Machine runs reasonably latest stable/7. > > Any advice ? Anything I should try to tweak ? Do you need additional > information ? > > I can test patches on this box. > > age0: mem > 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 > age0: Reserved 0x40000 bytes for rid 0x10 type 3 at 0xfeac0000 > age0: PCI device revision : 0x00b0 > age0: Chip id/revision : 0x9006 > age0: 1280 Tx FIFO, 2364 Rx FIFO > age0: MSIX count : 0 > age0: MSI count : 1 > age0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to vector 52 > age0: using IRQ 256 for MSI > age0: Using 1 MSI messages. > age0: Read request size : 512 bytes. > age0: TLP payload size : 128 bytes. > age0: PCI VPD capability not found! > miibus0: on age0 > atphy0: PHY 0 on miibus0 > atphy0: OUI 0x001374, model 0x0001, rev. 5 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto > age0: bpf attached > age0: Ethernet address: 00:1f:c6:b9:cc:a7 > msi: Assigning MSI IRQ 256 to local APIC 0 > From john at dnepro.net Sun Jan 18 03:04:57 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Sun Jan 18 03:05:04 2009 Subject: TARPIT for pf/ipfw In-Reply-To: <06EC1210-8D3E-4F47-A1DE-F0AE038929D9@mac.com> References: <20090116115026.GA98057@roof1.dnepro.net> <06EC1210-8D3E-4F47-A1DE-F0AE038929D9@mac.com> Message-ID: <20090118110453.GA88606@roof1.dnepro.net> On Fri, Jan 16, 2009 at 01:21:15PM -0800, Chuck Swiger wrote: > On Jan 16, 2009, at 3:50 AM, Eugene Perevyazko wrote: > >On Fri, Jan 16, 2009 at 12:20:21PM +0300, Alexey Ivanov wrote: > >>Is there any command identical to: > >> iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT > >> > >>If no, does anyone ever tried to implement this feature? > > > >I'm thinking on implementing it in ipfw but it'll be a week or two > >later, > >when I will have some free time. > > Note that net/honeyd and security/labrea offer somewhat similar > functionality. > The main aim for tarpit in firewall is IMHO to lock out "crime in progress". For example to slow down somebody brutforcing your ftp/pop/ssh/whatever. Script kiddies are hammering to well-known services almost constantly and denying nor resetting is effective to slow them down. I often see in logs that after host starts to reset connection from one IP bruteforcing continues from another IP just from the same place in wordlist. And if I'll use something like "fwd localhost,labreaport tcp from badip to me" I'm not sure it will succeed with already established connection. Eugene Perevyazko From siquijorphilips at gmail.com Sun Jan 18 03:08:41 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Sun Jan 18 03:08:48 2009 Subject: PF with TSO Message-ID: Hi, FreeBSD-7.1 is shipped with TCP segmentation offload (TSO) feature to some network interface cards by default such as Intel and Broadcom. I would like to know if there's any impact when PF is enabled together with TSO in terms of performance and packet inspection? Thank you, Regards, Siquijor From john at dnepro.net Sun Jan 18 03:35:28 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Sun Jan 18 03:35:34 2009 Subject: pppoed problem with reconnections In-Reply-To: <49723ABE.6010409@prt.org> References: <49723ABE.6010409@prt.org> Message-ID: <20090118113520.GA97691@roof1.dnepro.net> On Sat, Jan 17, 2009 at 08:08:30PM +0000, Paul Thornton wrote: > - The PPPoE connection is then not disconnected cleanly (say network > cable pulled out, or machine reboots, etc) > - Back on the termination box, there is still a ppp process running > using that address. > - When you try and reconnect as the original user, it fails because the > address cannot be assigned (already in use). Things then stay like this > for ever until I kill the ppp process that was connected with the pppoed > running on that VLAN. You have to look at keep-alive settings to terminate dead connections. And why don't you try an mpd (/usr/ports/net/mpd) that is perfectly suited to manage hundreds and thousands of simultaneous ppp (and PPPoE in particular) connections? It's fast, flexible and easy to setup both as server and client. Eugene Perevyazko From lists.br at gmail.com Sun Jan 18 02:58:05 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Sun Jan 18 04:13:21 2009 Subject: pppoed problem with reconnections References: <49723ABE.6010409@prt.org> Message-ID: <0E1FF7303AD34D2193A1E399643020B9@adnote989> > Hi folks, > > I am currently doing some lab testing with 6.3-release and a pppoe setup > where each user has their own VLAN. On the termination box have an em > interface with about 200 VLANs configured on it, and have a ppp.conf > looking like this: > > default: > set log Chat Command Phase > enable pap > enable chap > allow mode direct > set mru 1462 > set mtu 1462 > set timeout 0 > enable lqr > accept dns > set dns 192.168.1.1 192.168.1.2 > set radius /etc/ppp/radius.conf > set ifaddr 192.168.254.254/32 Change the enable lqr to: enable lqr echo set echoperiod 5 The ppp will check the remote peer at echoperiod and after five consecutive fails the ppp link will be closed. Luiz From prt at prt.org Sun Jan 18 08:13:51 2009 From: prt at prt.org (Paul Thornton) Date: Sun Jan 18 08:13:58 2009 Subject: pppoed problem with reconnections In-Reply-To: <0E1FF7303AD34D2193A1E399643020B9@adnote989> References: <49723ABE.6010409@prt.org> <0E1FF7303AD34D2193A1E399643020B9@adnote989> Message-ID: <4973553B.6070301@prt.org> Hi Luiz, Luiz Otavio O Souza wrote: > Change the enable lqr to: > > enable lqr echo > set echoperiod 5 > > The ppp will check the remote peer at echoperiod and after five > consecutive fails the ppp link will be closed. That does exactly what I want, thank you. Paul. From prt at prt.org Sun Jan 18 08:16:56 2009 From: prt at prt.org (Paul Thornton) Date: Sun Jan 18 08:17:02 2009 Subject: pppoed problem with reconnections In-Reply-To: <20090118113520.GA97691@roof1.dnepro.net> References: <49723ABE.6010409@prt.org> <20090118113520.GA97691@roof1.dnepro.net> Message-ID: <497355F6.4090400@prt.org> Hi, Eugene Perevyazko wrote: > You have to look at keep-alive settings to terminate dead connections. > And why don't you try an mpd (/usr/ports/net/mpd) that is perfectly suited > to manage hundreds and thousands of simultaneous ppp (and PPPoE in particular) > connections? It's fast, flexible and easy to setup both as server and client. As Luiz suggested, I've changed the config to: enable lqr echo set echoperiod 5 which sorts my problem out just fine. I did look into using mpd - mainly to compare which works best for our situation. However, I was having trouble making any PPPoE connections come up when using mpd; I suspect that this is me not fully understanding what I'm doing - and although I've done quite a bit of looking, I can't find any good example configurations for a PPPoE server using mpd (I'm sure they exist!). Do you have any pointers for this? Regards, Paul. From pyunyh at gmail.com Sun Jan 18 17:52:39 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Jan 18 17:52:45 2009 Subject: age(4) corrupts packets In-Reply-To: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> References: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> Message-ID: <20090119015225.GC75541@cdnetworks.co.kr> On Sat, Jan 17, 2009 at 05:25:59PM +0200, Kostik Belousov wrote: > I have to use a machine with ASUS motherboard, that has age(4) ethernet > adapter. It seems that active use of the net causes corrupted frames, > like the following ssh disconnect (after doing find / in the shell): > Disconnecting: Corrupted MAC on input. > > Machine runs reasonably latest stable/7. > > Any advice ? Anything I should try to tweak ? Do you need additional > information ? > Would you show me the output of "sysctl dev.age.0.stats=1"? Also try disabling Rx checksum offload(ifconfig age0 -rxcsum). > I can test patches on this box. > > age0: mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 > age0: Reserved 0x40000 bytes for rid 0x10 type 3 at 0xfeac0000 > age0: PCI device revision : 0x00b0 > age0: Chip id/revision : 0x9006 > age0: 1280 Tx FIFO, 2364 Rx FIFO > age0: MSIX count : 0 > age0: MSI count : 1 > age0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to vector 52 > age0: using IRQ 256 for MSI > age0: Using 1 MSI messages. > age0: Read request size : 512 bytes. > age0: TLP payload size : 128 bytes. > age0: PCI VPD capability not found! > miibus0: on age0 > atphy0: PHY 0 on miibus0 > atphy0: OUI 0x001374, model 0x0001, rev. 5 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto > age0: bpf attached > age0: Ethernet address: 00:1f:c6:b9:cc:a7 > msi: Assigning MSI IRQ 256 to local APIC 0 > -- Regards, Pyun YongHyeon From bugmaster at FreeBSD.org Mon Jan 19 03:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:08:30 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200901191107.n0JB711i063037@freefall.freebsd.org> 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/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130605 net [tcp] Certain hardware produces "Network is unreachabl 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 bin/130159 net [patch] ppp(8) fails to correctly set routes 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/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [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 [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126924 net [an] [patch] printf -> device_printf and simplify prob 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 kern/121983 net [fxp] fxp0 MBUF and PAE 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116444 net [ath] Atheros 5005G (AR5212) miniPCI: unable to attach o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [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 interface given in rc.conf not taking a o kern/106974 net [bge] packet loose and linkup problem 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/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/103059 net [bce] [patch] "Error mapping mbuf into TX chain!" (ten o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/100839 net [txp] txp driver inconsistently stops working when the 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 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 o 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 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/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter 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 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/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 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/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 254 problems total. From bugmaster at FreeBSD.org Mon Jan 19 03:08:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:09:59 2009 Subject: Current problem reports assigned to net@FreeBSD.org Message-ID: <200901191107.n0JB7wua064130@freefall.freebsd.org> 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 -------------------------------------------------------------------------------- s kern/117717 net [panic] Kernel panic with Bittorrent client. 1 problem total. From lists.br at gmail.com Mon Jan 19 03:43:54 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Mon Jan 19 03:44:01 2009 Subject: arp_proxy: ignoring request References: <4973F9AE.8080209@psg.com> <6B3AC73E801141BFB11EE7CA33E74D94@adnote989> <49745F92.90806@psg.com> Message-ID: <57035D79EA5741B58D56B9C514B934EA@adnote989> > On 09.01.19 20:05, Luiz Otavio O Souza wrote: >>> soekris 5501 8-current Jan 15 13:08 GMT, post arp changes >>> >>> FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Thu Jan 15 >>> 14:15:24 UTC 2009 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 i386 >>> >>> Jan 18 00:00:04 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:02:10 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:02:23 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:08:06 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.12 via wlan0, expecting bridge0 >>> Jan 18 00:08:10 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:12:22 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.30 via wlan0, expecting bridge0 >>> Jan 18 00:14:10 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:19:26 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:19:39 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.28 via vr3, expecting bridge0 >>> Jan 18 00:20:10 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> Jan 18 00:23:13 soek0 kernel: arp_proxy: ignoring request from >>> 192.168.0.10 via vr2, expecting bridge0 >>> >>> .----------------. >>> | | >>> | b --wlan0| >>> | r | 192.168.0.0/24 >>> ext iij | i --- vr1| LAN hosts, >>> PPP/NAT ---|vr0--- d | DHCP Clients >>> WAN | g --- vr2| pptp 200-209 >>> | e | ,.. >>> | 0 --- vr3| >>> | | >>> `----------------' >>> >>> wlans_ath0=wlan0 >>> create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep >>> wepkey yourekidding weptxkey 1 media autoselect mode 11g up" >>> cloned_interfaces=bridge0 >>> ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 >>> addm wlan1 up" >>> ifconfig_vr1=up >>> ifconfig_vr2=up >>> ifconfig_vr3=up >>> gateway_enable=YES >>> pptpd_enable=YES >>> arpproxy_all=YES >> >> Why are you using arpproxy with bridge ? the bridge shoudn't do it ? > > blindly following poptop instructions i found somewhere. should i nuke > it? > > randy Yeah, this is not need in an environment like yours. You need the proxy arp only for pptp connections (vpns). this will make the peer address looks like it is on your local network. As long as i know, the proxy arp for ppp(8) is broken, but you can use this as a workaround for this. This bug is on my todo list... Create these two scripts: # cat /usr/local/sbin/vpn_on.sh #!/bin/sh /usr/sbin/arp -s "${1}" 00:15:17:1c:91:a8 pub # cat /usr/local/sbin/vpn_off.sh #!/bin/sh /usr/sbin/arp -d "${1}" And set these two files: # cat /etc/ppp/ppp.linkup pptp: !bg /usr/local/sbin/vpn_on.sh HISADDR # cat /etc/ppp/ppp.linkdown pptp: !bg /usr/local/sbin/vpn_off.sh HISADDR Set the correct label on ppp.linkup and ppp.linkdown files and the bridge0 mac address on vpn_on. the 00:15:17:1c:91:a8 is my internal nic. Anyway put the enable proxy on /etc/ppp.conf (it is not working now, but i expect to see this working soon). Luiz ps: redirecting to freebsd-net@ as this has nothing to do with current. From bz at FreeBSD.org Mon Jan 19 04:08:51 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Jan 19 04:09:04 2009 Subject: kern/117717: [panic] Kernel panic with Bittorrent client. Message-ID: <200901191208.n0JC8XOU011099@freefall.freebsd.org> Synopsis: [panic] Kernel panic with Bittorrent client. Responsible-Changed-From-To: net->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Mon Jan 19 12:08:07 UTC 2009 Responsible-Changed-Why: Re-assigne to freebsd-net so there will only be only weekly mail. http://www.freebsd.org/cgi/query-pr.cgi?pr=117717 From bz at FreeBSD.org Mon Jan 19 04:08:51 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Jan 19 04:09:07 2009 Subject: kern/117717: [panic] Kernel panic with Bittorrent client. Message-ID: <200901191208.n0JC8XOU011099@freefall.freebsd.org> Synopsis: [panic] Kernel panic with Bittorrent client. Responsible-Changed-From-To: net->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Mon Jan 19 12:08:07 UTC 2009 Responsible-Changed-Why: Re-assigne to freebsd-net so there will only be only weekly mail. http://www.freebsd.org/cgi/query-pr.cgi?pr=117717 From dudu.meyer at gmail.com Mon Jan 19 07:40:42 2009 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Mon Jan 19 07:40:54 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected In-Reply-To: <4970DB6C.4030200@elischer.org> References: <4970DB6C.4030200@elischer.org> Message-ID: > obviously you did some other commands here.. > something generated 2 million packets.. Julian, its a production enviroment, firewall was up for a few minutes. Thats the reason. > I was thinking of adding a 'reroute' ipfw keyword.. kind of like > 'fwd {original dest} ip from any to any' > because 'fwd' does cause the routing decision to be redone. > > The fib of the process that opens the socket controls where packets from the > local machine are sent. divert does cause this too, not "not fib X" seems to work fine... I wish you could make the "setfib" action be kept in state with keep-state only for the static rules, but I guess it will be done for all dynamic rules too, since keep-state makes dynamic rules repeat the static one, right? would something like ipfw add prob 0.5 setfib 1 all from X to any out keep-state be used to balance (per session) between FIB tables? > > > > > -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From kostikbel at gmail.com Mon Jan 19 07:45:03 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Jan 19 07:45:16 2009 Subject: age(4) corrupts packets In-Reply-To: <20090119015225.GC75541@cdnetworks.co.kr> References: <20090117152559.GN48057@deviant.kiev.zoral.com.ua> <20090119015225.GC75541@cdnetworks.co.kr> Message-ID: <20090119154433.GA2068@deviant.kiev.zoral.com.ua> On Mon, Jan 19, 2009 at 10:52:25AM +0900, Pyun YongHyeon wrote: > On Sat, Jan 17, 2009 at 05:25:59PM +0200, Kostik Belousov wrote: > > I have to use a machine with ASUS motherboard, that has age(4) ethernet > > adapter. It seems that active use of the net causes corrupted frames, > > like the following ssh disconnect (after doing find / in the shell): > > Disconnecting: Corrupted MAC on input. > > > > Machine runs reasonably latest stable/7. > > > > Any advice ? Anything I should try to tweak ? Do you need additional > > information ? > > > > Would you show me the output of "sysctl dev.age.0.stats=1"? > Also try disabling Rx checksum offload(ifconfig age0 -rxcsum). From the quick test, -rxcsum helped. age0 statistics: Transmit good frames : 758324 Transmit good broadcast frames : 8 Transmit good multicast frames : 0 Transmit pause control frames : 0 Transmit control frames : 0 Transmit frames with excessive deferrals : 0 Transmit deferrals : 0 Transmit good octets : 138644293 Transmit good broadcast octets : 480 Transmit good multicast octets : 0 Transmit frames 64 bytes : 7912 Transmit frames 65 to 127 bytes : 231717 Transmit frames 128 to 255 bytes : 431502 Transmit frames 256 to 511 bytes : 60564 Transmit frames 512 to 1024 bytes : 11121 Transmit frames 1024 to 1518 bytes : 15508 Transmit frames 1519 to MTU bytes : 0 Transmit single collisions : 0 Transmit multiple collisions : 0 Transmit late collisions : 0 Transmit abort due to excessive collisions : 0 Transmit underruns due to FIFO underruns : 0 Transmit descriptor write-back errors : 0 Transmit frames with length mismatched frame size : 0 Transmit frames with truncated due to MTU size : 0 Receive good frames : 1160903 Receive good broadcast frames : 557046 Receive good multicast frames : 1386 Receive pause control frames : 0 Receive control frames : 0 Receive CRC errors : 0 Receive frames with length errors : 0 Receive good octets : 480137225 Receive good broadcast octets : 63406156 Receive good multicast octets : 119196 Receive frames too short : 0 Receive fragmented frames : 0 Receive frames 64 bytes : 178796 Receive frames 65 to 127 bytes : 837139 Receive frames 128 to 255 bytes : 141222 Receive frames 256 to 511 bytes : 79755 Receive frames 512 to 1024 bytes : 21326 Receive frames 1024 to 1518 bytes : 542337 Receive frames 1519 to MTU bytes : 0 Receive frames too long : 0 Receive frames with FIFO overflow : 0 Receive frames with return descriptor overflow : 0 Receive frames with alignment errors : 0 Receive frames dropped due to address filtering : 639672 > > > I can test patches on this box. > > > > age0: mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 > > age0: Reserved 0x40000 bytes for rid 0x10 type 3 at 0xfeac0000 > > age0: PCI device revision : 0x00b0 > > age0: Chip id/revision : 0x9006 > > age0: 1280 Tx FIFO, 2364 Rx FIFO > > age0: MSIX count : 0 > > age0: MSI count : 1 > > age0: attempting to allocate 1 MSI vectors (1 supported) > > msi: routing MSI IRQ 256 to vector 52 > > age0: using IRQ 256 for MSI > > age0: Using 1 MSI messages. > > age0: Read request size : 512 bytes. > > age0: TLP payload size : 128 bytes. > > age0: PCI VPD capability not found! > > miibus0: on age0 > > atphy0: PHY 0 on miibus0 > > atphy0: OUI 0x001374, model 0x0001, rev. 5 > > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto > > age0: bpf attached > > age0: Ethernet address: 00:1f:c6:b9:cc:a7 > > msi: Assigning MSI IRQ 256 to local APIC 0 > > > > -- > Regards, > Pyun YongHyeon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090119/37f95749/attachment.pgp From lists.br at gmail.com Mon Jan 19 08:24:49 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Mon Jan 19 08:35:51 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected References: <4970DB6C.4030200@elischer.org> Message-ID: <8461C1DA26D349A7B4AA821D8461A923@adnote989> >> obviously you did some other commands here.. >> something generated 2 million packets.. > > Julian, its a production enviroment, firewall was up for a few > minutes. Thats the reason. > >> I was thinking of adding a 'reroute' ipfw keyword.. kind of like >> 'fwd {original dest} ip from any to any' >> because 'fwd' does cause the routing decision to be redone. >> >> The fib of the process that opens the socket controls where packets from >> the >> local machine are sent. > > divert does cause this too, not "not fib X" seems to work fine... > > I wish you could make the "setfib" action be kept in state with > keep-state only for the static rules, but I guess it will be done for > all dynamic rules too, since keep-state makes dynamic rules repeat the > static one, right? > > would something like > > ipfw add prob 0.5 setfib 1 all from X to any out keep-state > > be used to balance (per session) between FIB tables? divert ? i think you want to say natd... Again... you are using setfib after the route table decisions... To use natd with setfib you need to setup two instances of natd, one for each uplink interface: ipfw add divert 8668 all from any to any via ${outnic1} ipfw add divert 8669 all from any to any via ${outnic2} And on internal nic: ipfw add setfib 1 tcp from ${inet} to any 80 IN VIA ${iif} So the http traffic will be routed thru fib 1 and should appear on correct uplink interface, and natd can do his the dirty work. I don't known about prob... you will need to send the connection setup packets (for tcp) and subsequent packets through the same link. i don't know if you can achive this with prob + keep-state. Luiz From bvowk at math.ualberta.ca Mon Jan 19 10:00:07 2009 From: bvowk at math.ualberta.ca (Barkley Vowk) Date: Mon Jan 19 10:00:13 2009 Subject: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Message-ID: <200901191800.n0JI06NI074891@freefall.freebsd.org> The following reply was made to PR kern/130628; it has been noted by GNATS. From: Barkley Vowk To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Date: Mon, 19 Jan 2009 10:24:38 -0700 (MST) I'm using UDP mounts. From linimon at FreeBSD.org Mon Jan 19 17:05:50 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Jan 19 17:05:56 2009 Subject: kern/126561: [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stalls Mac OS X Finder, iTunes, etc?) Message-ID: <200901200105.n0K15nSb029467@freefall.freebsd.org> Synopsis: [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stalls Mac OS X Finder, iTunes, etc?) State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Tue Jan 20 01:05:21 UTC 2009 State-Changed-Why: Patched and MFCed to 7. http://www.freebsd.org/cgi/query-pr.cgi?pr=126561 From stef-list at memberwebs.com Mon Jan 19 17:40:19 2009 From: stef-list at memberwebs.com (Stef) Date: Mon Jan 19 17:40:26 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap Message-ID: <20090120012053.4D5358C2A76@mx.npubs.com> Figured this may be interesting for folks... I've released a bsnmp module which can monitor arbitrary traffic flows and expose them as SNMP counters. FreeBSD port attached, more info here: http://memberwebs.com/stef/software/bsnmp-pcap/ Cheers, Stef Walter From shteryana at gmail.com Tue Jan 20 02:29:21 2009 From: shteryana at gmail.com (Shteryana Shopova) Date: Tue Jan 20 02:29:27 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap In-Reply-To: <20090120012053.4D5358C2A76@mx.npubs.com> References: <20090120012053.4D5358C2A76@mx.npubs.com> Message-ID: <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> Hi, On Tue, Jan 20, 2009 at 3:20 AM, Stef wrote: > Figured this may be interesting for folks... > > I've released a bsnmp module which can monitor arbitrary traffic flows > and expose them as SNMP counters. > This is indeed interesting :) One thing to point out is that { begemot 206 } is already allocated for begemotVlan - and the two modules will conflict - you might want to contact harti for a free OID under begemot. cheers, Shteryana > FreeBSD port attached, more info here: > > http://memberwebs.com/stef/software/bsnmp-pcap/ > > Cheers, > > Stef Walter > > _______________________________________________ > 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 hartmut.brandt at dlr.de Tue Jan 20 04:47:06 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Jan 20 04:47:13 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap In-Reply-To: <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> References: <20090120012053.4D5358C2A76@mx.npubs.com> <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> Message-ID: <20090120134230.U58797@beagle.kn.op.dlr.de> On Tue, 20 Jan 2009, Shteryana Shopova wrote: SS>Hi, SS> SS>On Tue, Jan 20, 2009 at 3:20 AM, Stef wrote: SS>> Figured this may be interesting for folks... SS>> SS>> I've released a bsnmp module which can monitor arbitrary traffic flows SS>> and expose them as SNMP counters. SS>> SS> SS>This is indeed interesting :) SS>One thing to point out is that { begemot 206 } is already allocated SS>for begemotVlan - and the two modules will conflict - you might want SS>to contact harti for a free OID under begemot. Argh. Sorry. He contacted me and I messed probably up. I checked my mailing archive whether I've allocated those oids, but did not find anything. My actual oid-list file is $Begemot: trunk/oid-list 440 2009-01-18 14:51:55Z brandt_h $ enterprises 12325 FOKUS 1 BEGEMOT 1 BEGEMOT-SNMPD 2 BEGEMOT-NETGRAPH snmpd netgraph module 3 BEGEMOT-IP snmpd IP related stuff. 100 BEGEMOT-ILMID snmpd ILMID module 101 BEGEMOT-ATM snmpd ATM module 200 BEGEMOT-PF snmpd PF module (phillip@freebsd.org) 201 BEGEMOT-NTP snmpd NTP module 202 BEGEMOT-HOSTRES snmpd HOSTRES module private stuff 203 regexData bsnmp-regex (Nate Nielsen ) 204 pingData bsnmp-ping (Nate Nielsen ) 205 bsnmp-jails per jail networking, cpu, disk, memory statistics 206 bsnmp-pcap monitor traffic for specific network flows 300 BEGEMOT-ACM DLR ACM project 405 mysql (vanilla@fatpipi.com) 406 varnish (vanilla@fatpipi.com) I probably missed something here. Any other conflicts? Can we move bsnmp-pcap to 207? And does bsnmp-jails conflict with something? Perhaps I should put this list somewhere more public. harti SS>cheers, SS>Shteryana SS> SS>> FreeBSD port attached, more info here: SS>> SS>> http://memberwebs.com/stef/software/bsnmp-pcap/ SS>> SS>> Cheers, SS>> SS>> Stef Walter SS>> SS>> _______________________________________________ SS>> freebsd-net@freebsd.org mailing list SS>> http://lists.freebsd.org/mailman/listinfo/freebsd-net SS>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" SS>> SS>_______________________________________________ SS>freebsd-net@freebsd.org mailing list SS>http://lists.freebsd.org/mailman/listinfo/freebsd-net SS>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" SS> SS> From shteryana at gmail.com Tue Jan 20 05:32:51 2009 From: shteryana at gmail.com (Shteryana Shopova) Date: Tue Jan 20 05:32:58 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap In-Reply-To: <20090120134230.U58797@beagle.kn.op.dlr.de> References: <20090120012053.4D5358C2A76@mx.npubs.com> <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> <20090120134230.U58797@beagle.kn.op.dlr.de> Message-ID: <61b573980901200523r14e8a71fyf6462a21199ca62@mail.gmail.com> HI, > SS> > SS>This is indeed interesting :) > SS>One thing to point out is that { begemot 206 } is already allocated > SS>for begemotVlan - and the two modules will conflict - you might want > SS>to contact harti for a free OID under begemot. > > Argh. Sorry. He contacted me and I messed probably up. I checked my > mailing archive whether I've allocated those oids, but did not find > anything. > Maybe check 10 Jul 2006? > My actual oid-list file is > > $Begemot: trunk/oid-list 440 2009-01-18 14:51:55Z brandt_h $ > > enterprises > 12325 FOKUS > 1 BEGEMOT > 1 BEGEMOT-SNMPD > 2 BEGEMOT-NETGRAPH snmpd netgraph module > 3 BEGEMOT-IP snmpd IP related stuff. > 100 BEGEMOT-ILMID snmpd ILMID module > 101 BEGEMOT-ATM snmpd ATM module > 200 BEGEMOT-PF snmpd PF module (phillip@freebsd.org) > 201 BEGEMOT-NTP snmpd NTP module > 202 BEGEMOT-HOSTRES snmpd HOSTRES module private stuff > 203 regexData bsnmp-regex (Nate Nielsen ) > 204 pingData bsnmp-ping (Nate Nielsen ) > 205 bsnmp-jails per jail networking, cpu, disk, memory statistics > 206 bsnmp-pcap monitor traffic for specific network flows > > 300 BEGEMOT-ACM DLR ACM project > 405 mysql (vanilla@fatpipi.com) > 406 varnish (vanilla@fatpipi.com) > > I probably missed something here. Any other conflicts? Can we move bsnmp-pcap > to 207? And does bsnmp-jails conflict with something? > begemot.205 BRIDGE begemot.206 VLAN > Perhaps I should put this list somewhere more public. > Hmm, I thought src/contrib/bsnmp/oid-list served the purpose - I guess keeping that list up-to-date in CVS/SVN is the best thing to do :)) cheers, Shteryana From need4spam at bk.ru Tue Jan 20 06:30:42 2009 From: need4spam at bk.ru (Alexey Ivanov) Date: Tue Jan 20 06:30:50 2009 Subject: CARP IP level load balancing Message-ID: In FreeBSD there is only ARP level LB, that is in some cases just not enough for load balancing. Is there any plans to port IP level LB from OpenBSD, and, if yes, will it be ported to 7x and 6x? In my opinion, full CARP realization is one step towards LVS-equal functionality. From dudu.meyer at gmail.com Tue Jan 20 07:43:23 2009 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Tue Jan 20 07:43:30 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected In-Reply-To: <8461C1DA26D349A7B4AA821D8461A923@adnote989> References: <4970DB6C.4030200@elischer.org> <8461C1DA26D349A7B4AA821D8461A923@adnote989> Message-ID: On Mon, Jan 19, 2009 at 2:24 PM, Luiz Otavio O Souza wrote: >>> obviously you did some other commands here.. >>> something generated 2 million packets.. >> >> Julian, its a production enviroment, firewall was up for a few >> minutes. Thats the reason. >> >>> I was thinking of adding a 'reroute' ipfw keyword.. kind of like >>> 'fwd {original dest} ip from any to any' >>> because 'fwd' does cause the routing decision to be redone. >>> >>> The fib of the process that opens the socket controls where packets from >>> the >>> local machine are sent. >> >> divert does cause this too, not "not fib X" seems to work fine... >> >> I wish you could make the "setfib" action be kept in state with >> keep-state only for the static rules, but I guess it will be done for >> all dynamic rules too, since keep-state makes dynamic rules repeat the >> static one, right? >> >> would something like >> >> ipfw add prob 0.5 setfib 1 all from X to any out keep-state >> >> be used to balance (per session) between FIB tables? > > divert ? i think you want to say natd... > > Again... you are using setfib after the route table decisions... > > To use natd with setfib you need to setup two instances of natd, one for > each uplink interface: > > ipfw add divert 8668 all from any to any via ${outnic1} > ipfw add divert 8669 all from any to any via ${outnic2} > > And on internal nic: > > ipfw add setfib 1 tcp from ${inet} to any 80 IN VIA ${iif} > > So the http traffic will be routed thru fib 1 and should appear on correct > uplink interface, and natd can do his the dirty work. > > I don't known about prob... you will need to send the connection setup > packets (for tcp) and subsequent packets through the same link. i don't know > if you can achive this with prob + keep-state. > > Luiz > Yes, you are right. Now its way easier to do policy routing and advanced PBR. However Im still trying to balance outgoing traffic throught multiple FIBs, per session. But add prob 0.5 setfib 1 tcp from ${inet} to any 80 in via ${iif} setup keep-state is not working as I expected... Some sessions just fail. I guess I need some special behavior on the "keep-state" action. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From arkadietz at yahoo.com Tue Jan 20 08:07:25 2009 From: arkadietz at yahoo.com (Kiril Georgiev) Date: Tue Jan 20 09:18:26 2009 Subject: Question :) Message-ID: <252793.48085.qm@web51910.mail.re2.yahoo.com> Hello! I want to ask you have equivalent commands in FreeBSD and if what they are. Commands that are talking ip rou, ip roule.Also want to know if FreeBSD is doing better than Linux Kernel 2.6.8 in the role of Bridge, Router, VPN and quality of some PPOE hub. Interested if FreeBSD is doing better than Linux. And say how pps / mbit / gigabyte packages may adopt or failure for a second. The idea is this to say that I have internet service provider and have a link from 500mb / s if FreeBSD will cope better with this. Example of one of the things that are referred to ask below.If you can do some tests and comparisons will be very grateful.This is very important to me and is of great importance. Example: ip rou add 192.168.0.0/24 via 10.0.0.1 table fake ip rule add from 192.168.0.0/24 table fake ip rule add from 192.168.0.0/24 table fake pref 12000 These examples say what will appear to IPFW. If you can do something. --- When you dream there are no rules, people can fly, anything can happen. Sometimes there is a moment as you are awakening when you become aware of the real world around you, but you are still dreaming. You may think you can fly but you do better not try. People can fly. Arkadietz cOrp. ? 2000-2008, Inc. From stef-list at memberwebs.com Tue Jan 20 18:13:34 2009 From: stef-list at memberwebs.com (Stef) Date: Tue Jan 20 18:13:41 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap References: <20090120012053.4D5358C2A76@mx.npubs.com> <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> <20090120134230.U58797@beagle.kn.op.dlr.de> Message-ID: <20090121021333.421DE8C2AB9@mx.npubs.com> Harti Brandt wrote: > I probably missed something here. Any other conflicts? Can we move bsnmp-pcap > to 207? And does bsnmp-jails conflict with something? Like Shteryana said, it seems like it does conflict... Would it work to have 1111 and 1112? I used those while the software was in development (blush) and it's deployed as such on a couple dozen production servers I've been running bsnmp-jails and bsnmp-pcap on. If not, then any other two numbers are fine. Once I hear officially, I'll roll new releases. Cheers, Stef Walter From stef at memberwebs.com Tue Jan 20 18:40:23 2009 From: stef at memberwebs.com (Stef Walter) Date: Tue Jan 20 18:40:30 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap References: <20090120012053.4D5358C2A76@mx.npubs.com> <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> <20090120134230.U58797@beagle.kn.op.dlr.de> Message-ID: <20090121021331.E82348C2A65@mx.npubs.com> Harti Brandt wrote: > I probably missed something here. Any other conflicts? Can we move bsnmp-pcap > to 207? And does bsnmp-jails conflict with something? Like Shteryana said, it seems like it does conflict... Would it work to have 1111 and 1112? I used those while the software was in development (blush) and it's deployed as such on a couple dozen production servers I've been running bsnmp-jails and bsnmp-pcap on. If not, then any other two numbers are fine. Once I hear officially, I'll roll new releases. Cheers, Stef Walter From fbsdmail at dnswatch.com Tue Jan 20 19:13:50 2009 From: fbsdmail at dnswatch.com (fbsdmail@dnswatch.com) Date: Tue Jan 20 19:13:56 2009 Subject: Is connecting/binding com port(s) to modem/router, switch possible? Message-ID: Greetings, Back in the 3.x days of FreeBSD, if I installed it while my COM ports were attached to my cablemodem, and switch port(s), a VC was automatically attached to it. I'm not sure what has changed in that area in the more recent versions of FBSD, but my previous experiences no longer prevail. SO, is there any way to achive this same behavior? If not, is there any way to achieve a /similar/ behavior? I really miss this. It was /great/ to be able to switch VC's type in IOS commands into my cablemodem/router. But now I find myself unable to connect to it, or my switches command port over the computers serial port. Thank you for all your time and consideration. --Chris From vanhu at FreeBSD.org Wed Jan 21 01:48:27 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Wed Jan 21 01:48:34 2009 Subject: [Patch for review] Experimental NAT-T + PFKey cleanup Message-ID: <20090121095507.GB36716@zeninc.net> [same mail sent both on ipsec-tools-devel and freebsd-net, please use respective MLs for potential issues on each side] Hi all. Here is a beta patch which cleans the way PFKey exchanges NAT-T ports between kernel and userland, available at: http://people.freebsd.org/~vanhu/NAT-T/experimental/ patch-FreeBSD-TRUNK-NATT-pfkey-clean-.diff is the whole FreeBSD NAT-T patchset (also available on perforce.freebsd.org for those who have access). patch-ipsec-tools-HEAD-NATT-pfkey-cleanup-.diff applies on ipsec-tools CVS HEAD. With those patches, NAT-T ports are now always sent via SADB_X_EXT_NAT_T_[S|D]PORT, and never as ports in SADB_EXT_ADDRESS_[SRC|DST] (which is not RFC2367 compliant) Both ways are more or less used actually. Basic tests with those patches works (a tunnel with NAT-T negociates and works), but please note those patches are in a directory called "experimental". At least, setkey hasn't be updated yet, and some cleanups will need to be done before commiting. Compatibility with existing IPsec+NAT-T stacks is also an issue (if you compile without NAT-T support, you'll have NO issue at all) : - racoon + patch won't work correctly on FreeBSD + old NAT-T patch (I'll generate at least an updated patch for FreeBSD 7.x). - racoon + patch won't work correctly on NetBSD + NAT-T enabled. - racoon + patch may work as good or even better on Linux... or not... - racoon without patch won't work correctly on FreeBSD + new NAT-T patch. - racoon without patch won't work correctly on updated NetBSD + NAT-T (no NetBSD patch yet). Ipsec-tools team has still not decided how such compatibility issues will be handled (or not...), any (good) idea is welcome ! Please send feedbacks/bug reports/patches/anything else directly on ipsec-tools-devel or freebsd-net MLs (for respective patches), so everyone interested will have the info. Yvan. From onemda at gmail.com Wed Jan 21 01:59:01 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Jan 21 01:59:07 2009 Subject: VLAN interface management - unloading carrying driver hangs the machine In-Reply-To: <2a41acea0901080109l6189b379q4a348cc80527e90e@mail.gmail.com> References: <000001c970a8$3fa45240$220f000a@mtl.com> <4964C2E9.1060301@bestunion.it> <000001c970d9$4403e590$220f000a@mtl.com> <4964EC4F.8030507@freebsd.org> <2a41acea0901071359w3f41465ajb8206cdef5b7b680@mail.gmail.com> <49652E25.9030705@freebsd.org> <000601c97169$b85717b0$220f000a@mtl.com> <2a41acea0901080109l6189b379q4a348cc80527e90e@mail.gmail.com> Message-ID: <3a142e750901210158p75ee5606oa83275f343b93b86@mail.gmail.com> On 1/8/09, Jack Vogel wrote: > Fine with me, go do it and I'll take the driver code out :) > > Jack > > > On Thu, Jan 8, 2009 at 12:18 AM, Yony Yossef > wrote: > >> > Jack Vogel wrote: >> > > >> > > >> > > On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler > > > > wrote: >> > > >> > > Yony Yossef wrote: >> > > >> > > Yony Yossef wrote: >> > > >> > > >> > > /sbin/ifconfig vlan3653 create >> > > >> > > Problem is when I assign an IP to the vlan >> > interface. >> > > In that case, unloading the driver results >> > in hanging >> > > the host. >> > > Does it sound familiar to anybody? >> > > >> > > >> > > Well, surely I'd expect problems by doing so. >> > > The correct way is to >> > > >> > > /sbin/ifconfig vlan3653 destroy >> > > >> > > before unloading the driver. >> > > >> > > Angelo. >> > > >> > > >> > > >> > > Thanks, I didn't know freebsd does not allow it. >> > > >> > > >> > > >> > > This seems wrong. Someone should disallow the driver >> > > detach/unload. Please file a PR about this so the issue >> > is not lost. >> > > >> > > Sam >> > > >> > > >> > > In many drivers, ahem, like mine, there is a test at detach and it >> > > will not allow it if there is a non-NULL trunk. >> > > >> > > Sounds like a broken driver needs to be fixed is all... >> > > >> > I don't agree; drivers should not be required to deal with >> > this. If someone files a PR and assigns it to me I'll look at it. >> > >> > Sam >> > >> >> I agree with Sam. There's no reason to leave this check to the driver. >> >> Yony >> >> > _______________________________________________ > 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" > What's the state of this issue? It is fixed or not? -- Paul From bzeeb-lists at lists.zabbadoz.net Wed Jan 21 02:15:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jan 21 02:15:15 2009 Subject: [Patch for review] Experimental NAT-T + PFKey cleanup In-Reply-To: <20090121095507.GB36716@zeninc.net> References: <20090121095507.GB36716@zeninc.net> Message-ID: <20090121100244.M45399@maildrop.int.zabbadoz.net> On Wed, 21 Jan 2009, VANHULLEBUS Yvan wrote: Hi, > [same mail sent both on ipsec-tools-devel and freebsd-net, please use > respective MLs for potential issues on each side] > > Hi all. > > Here is a beta patch which cleans the way PFKey exchanges NAT-T ports > between kernel and userland, available at: > http://people.freebsd.org/~vanhu/NAT-T/experimental/ ... > > With those patches, NAT-T ports are now always sent via > SADB_X_EXT_NAT_T_[S|D]PORT, and never as ports in > SADB_EXT_ADDRESS_[SRC|DST] (which is not RFC2367 compliant) > Both ways are more or less used actually. ... > > Ipsec-tools team has still not decided how such compatibility issues > will be handled (or not...), any (good) idea is welcome ! While this seems to be a big concern and there is compat breakage with this patchset already, could we just finish the thing and also add the second OA to not have to go through another round of breakage at a later time? I checked the patch and I still can only see one NAT_T_OA which does not work in the double NAT scenario as I have stated multiple times in the past. See RFC3947, 5.2., Example 2. As said before I am currently caring less that the functionality behind this is implemented but want to make sure we do not need to break APIs again at a later time to add this and thus giving us way more pain then. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From barney_cordoba at yahoo.com Wed Jan 21 05:37:58 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Jan 21 05:38:04 2009 Subject: CARP IP level load balancing In-Reply-To: Message-ID: <400557.75901.qm@web63903.mail.re1.yahoo.com> --- On Tue, 1/20/09, Alexey Ivanov wrote: > From: Alexey Ivanov > Subject: CARP IP level load balancing > To: freebsd-net@freebsd.org > Date: Tuesday, January 20, 2009, 9:30 AM > In FreeBSD there is only ARP level LB, that is in some cases > just not enough for load balancing. > Is there any plans to port IP level LB from OpenBSD, and, > if yes, will it be ported to 7x and 6x? > > In my opinion, full CARP realization is one step towards > LVS-equal functionality. Curious as to your specific needs. Is LAGG load balancing of no use at IP level? Barney From votdev at gmx.de Wed Jan 21 05:38:36 2009 From: votdev at gmx.de (votdev@gmx.de) Date: Wed Jan 21 05:39:09 2009 Subject: Cannot resolve hostname; DNS problem when using DHCP Message-ID: <20090121131151.150540@gmx.net> Hello, i have a strange DNS problem. If i use DHCP i'm not able to ping myself using the hostname (and hostname+domain). The strange thing is that i can't reproduce this on my 'real' system (with Fritzbox router) but in a VM (VMWare Player). Also some FreeNAS users have the same problem with 'real' hardware, too. I can ping the VM from the host system without problems using the VM hostname 'freenasl.local', so there is no problem with the internal VMWare DNS server. Below i've listed everything i think it's necessary to find out what's wrong. Can anyone give me some hints or tipps? Maybe i'm totally blind. Regards Volker freenas:~# hostname freenas.local freenas:~# cat /etc/resolv.conf search localdomain nameserver 172.16.194.2 freenas:~# cat /etc/hosts ::1 localhost localhost.local 127.0.0.1 localhost localhost.local freenas:~# netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.194.2 UGS 0 0 em0 localhost localhost UH 0 10 lo0 freenas:~# cat /etc/hosts.allow ALL : ALL : allow freenas:~# cat /etc/nsswitch.conf group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files freenas:~# ping freenas ping: cannot resolve freenas: Host name lookup failure freenas:~# ping freenas.local ping: cannot resolve freenas.local: Unknown host -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNXCQQRVm5zo0XcQRArr0AJsG4kOOYIJZq3JFLFYPzI15Qb3EhwCeN8IY Cegr732xUv0FcHCaEGVUePQ= =7wNc -----END PGP SIGNATURE----- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From fbsdmail at dnswatch.com Wed Jan 21 06:03:35 2009 From: fbsdmail at dnswatch.com (fbsdmail@dnswatch.com) Date: Wed Jan 21 06:03:42 2009 Subject: Cannot resolve hostname; DNS problem when using DHCP In-Reply-To: <20090121131151.150540@gmx.net> References: <20090121131151.150540@gmx.net> Message-ID: <2253907a4c901ac606155f1da61286c7.dnswclient@webmail.dnswatch.com> Hello, I can't help notice that in /etc/resolv.conf you have: search localdomain Yet you make no mention or definition of/for localdomain in any other place. So, you'll either need to create a CNAME for localdomain in a DNS zone file - or better; search: localhost, or local in your resolv.conf file. :) Best wishes. --Chris On Wed, January 21, 2009 5:11 am, votdev@gmx.de wrote: > Hello, > > > i have a strange DNS problem. If i use DHCP i'm not able to ping myself > using the hostname (and hostname+domain). The strange thing is that i > can't reproduce this on my 'real' system (with Fritzbox router) but in a > VM (VMWare Player). Also some FreeNAS users have the same problem with > 'real' hardware, too. > I can ping the VM from the host system without problems using the VM > hostname 'freenasl.local', so there is no problem with the internal > VMWare DNS server. > > > Below i've listed everything i think it's necessary to find out what's > wrong. > > Can anyone give me some hints or tipps? Maybe i'm totally blind. > > > Regards > Volker > > > freenas:~# hostname > freenas.local > > freenas:~# cat /etc/resolv.conf > search localdomain nameserver 172.16.194.2 > > freenas:~# cat /etc/hosts > ::1 localhost localhost.local > 127.0.0.1 localhost search localdomain > > > freenas:~# netstat -r > Routing tables > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.194.2 UGS 0 0 em0 > localhost localhost UH 0 10 lo0 > > freenas:~# cat /etc/hosts.allow > ALL : ALL : allow > > > freenas:~# cat /etc/nsswitch.conf > group: compat > group_compat: nis > hosts: files dns > networks: files > passwd: compat > passwd_compat: nis > shells: files > services: compat > services_compat: nis > protocols: files > rpc: files > > > freenas:~# ping freenas > ping: cannot resolve freenas: Host name lookup failure > > > freenas:~# ping freenas.local > ping: cannot resolve freenas.local: Unknown host > > > -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > iD8DBQFHNXCQQRVm5zo0XcQRArr0AJsG4kOOYIJZq3JFLFYPzI15Qb3EhwCeN8IY > Cegr732xUv0FcHCaEGVUePQ= > =7wNc > -----END PGP SIGNATURE----- > > > > Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > _______________________________________________ > 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 lists.br at gmail.com Wed Jan 21 07:03:52 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Wed Jan 21 08:34:58 2009 Subject: CARP IP level load balancing References: <400557.75901.qm@web63903.mail.re1.yahoo.com> Message-ID: <9488116E9B3E48789DB4B688BBEFED13@adnote989> >> Date: Tuesday, January 20, 2009, 9:30 AM >> In FreeBSD there is only ARP level LB, that is in some cases >> just not enough for load balancing. >> Is there any plans to port IP level LB from OpenBSD, and, >> if yes, will it be ported to 7x and 6x? >> >> In my opinion, full CARP realization is one step towards >> LVS-equal functionality. > > Curious as to your specific needs. Is LAGG load balancing of no use at IP > level? > > Barney > hmm... with lagg you have two (or more) phisical connections sharing the same ip, with carp you will have two (or more) servers sharing the same ip. i think lagg will not help. i would like to give a try on carp ip balance, but i dont have the time for now. i also like to known if someone else is working on this. Luiz From hartmut.brandt at dlr.de Wed Jan 21 08:53:02 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Wed Jan 21 08:53:10 2009 Subject: bsnmp module for monitoring network flows: bsnmp-pcap In-Reply-To: <61b573980901200523r14e8a71fyf6462a21199ca62@mail.gmail.com> References: <20090120012053.4D5358C2A76@mx.npubs.com> <61b573980901200200g4ff6ff16r39c2e07c5459406@mail.gmail.com> <20090120134230.U58797@beagle.kn.op.dlr.de> <61b573980901200523r14e8a71fyf6462a21199ca62@mail.gmail.com> Message-ID: <20090121174910.M62168@beagle.kn.op.dlr.de> On Tue, 20 Jan 2009, Shteryana Shopova wrote: SS>> SS> SS>> SS>This is indeed interesting :) SS>> SS>One thing to point out is that { begemot 206 } is already allocated SS>> SS>for begemotVlan - and the two modules will conflict - you might want SS>> SS>to contact harti for a free OID under begemot. SS>> SS>> Argh. Sorry. He contacted me and I messed probably up. I checked my SS>> mailing archive whether I've allocated those oids, but did not find SS>> anything. SS>> SS> SS>Maybe check 10 Jul 2006? Hmmm. A mail from you, but no OIDs there. Maybe I stuck it somewhere else... SS>> I probably missed something here. Any other conflicts? Can we move bsnmp-pcap SS>> to 207? And does bsnmp-jails conflict with something? SS>> SS> SS>begemot.205 BRIDGE SS>begemot.206 VLAN Ok. I've added these now and committed the file. SS>> Perhaps I should put this list somewhere more public. SS>> SS> SS>Hmm, I thought src/contrib/bsnmp/oid-list served the purpose - I guess SS>keeping that list up-to-date in CVS/SVN is the best thing to do :)) Yeah, well. I was hoping to move the bsnmp repo to the FreeBSD servers, but I want my own revision number space... No luck so far. harti From lists.br at gmail.com Wed Jan 21 09:34:09 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Wed Jan 21 09:42:09 2009 Subject: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected References: <4970DB6C.4030200@elischer.org> <8461C1DA26D349A7B4AA821D8461A923@adnote989> Message-ID: >>>> obviously you did some other commands here.. >>>> something generated 2 million packets.. >>> >>> Julian, its a production enviroment, firewall was up for a few >>> minutes. Thats the reason. >>> >>>> I was thinking of adding a 'reroute' ipfw keyword.. kind of like >>>> 'fwd {original dest} ip from any to any' >>>> because 'fwd' does cause the routing decision to be redone. >>>> >>>> The fib of the process that opens the socket controls where packets >>>> from >>>> the >>>> local machine are sent. >>> >>> divert does cause this too, not "not fib X" seems to work fine... >>> >>> I wish you could make the "setfib" action be kept in state with >>> keep-state only for the static rules, but I guess it will be done for >>> all dynamic rules too, since keep-state makes dynamic rules repeat the >>> static one, right? >>> >>> would something like >>> >>> ipfw add prob 0.5 setfib 1 all from X to any out keep-state >>> >>> be used to balance (per session) between FIB tables? >> >> divert ? i think you want to say natd... >> >> Again... you are using setfib after the route table decisions... >> >> To use natd with setfib you need to setup two instances of natd, one for >> each uplink interface: >> >> ipfw add divert 8668 all from any to any via ${outnic1} >> ipfw add divert 8669 all from any to any via ${outnic2} >> >> And on internal nic: >> >> ipfw add setfib 1 tcp from ${inet} to any 80 IN VIA ${iif} >> >> So the http traffic will be routed thru fib 1 and should appear on >> correct >> uplink interface, and natd can do his the dirty work. >> >> I don't known about prob... you will need to send the connection setup >> packets (for tcp) and subsequent packets through the same link. i don't >> know >> if you can achive this with prob + keep-state. >> >> Luiz >> > > Yes, you are right. Now its way easier to do policy routing and > advanced PBR. However Im still trying to balance outgoing traffic > throught multiple FIBs, per session. But > > add prob 0.5 setfib 1 tcp from ${inet} to any 80 in via ${iif} setup > keep-state > > is not working as I expected... > > Some sessions just fail. I guess I need some special behavior on the > "keep-state" action. > Have you tried the check-state rule ? just an educated guess... no real clue about that... sorry. You will need to dig by yourself on this... take a closer look at dynamics rules created by your rule and try to determine the better way to achive what you want. Luiz From linimon at FreeBSD.org Wed Jan 21 10:30:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Jan 21 10:30:50 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Message-ID: <200901211830.n0LIUhWj083106@freefall.freebsd.org> Old Synopsis: wpa_supplicant returns 'no space on device' New Synopsis: [ndis] wpa_supplicant(8) returns 'no space on device' Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 21 18:29:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130820 From msch at snafu.de Wed Jan 21 11:49:27 2009 From: msch at snafu.de (Matthias Schuendehuette) Date: Wed Jan 21 11:49:35 2009 Subject: NFS-Locking problem with 6.4/7.1-RELEASE Message-ID: <5523A7AD-6A64-4A40-B46F-8208BEA87C0A@snafu.de> Hi, one of our FreeBSD-Servers is acting as NFS-Server for $HOME for approx. 50 HP-UX Workstations, since the WS itself and the disks in there become quite old in the meantime. That works quite good with FreeBSD 6.3-RELEASE-pxx but doesn't work with 6.4/7.1 any more. I looked with 'wireshark' on the problem and it seems to be a locking problen, probably related to PR 'kern/130628', but I'm not sure. Here what I know so far: Server-OS: FreeBSD 6.4-RELEASE/7.1-RELEASE (same problems) Workstation-OS: HP-UX 11iv1 (11.11) NFS-Version: V3/tcp or V3/udp (NFS-V2 works!) I found no records of the problem on the client side (HP-UX) whereas on FreeBSD 'rpc.lockd -d 3' produces the following entries in /var/log/messages: Jan 21 12:07:33 bsd1dw kernel: NLM: new host hp13 (sysid 5) Jan 21 12:07:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:07:53 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:13 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:32 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:08:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:08:43 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:08:53 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:09:03 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:13 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) Jan 21 12:09:13 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:23 bsd1dw kernel: nlm_do_lock(): caller_name = hp13 (sysid = 5) Jan 21 12:09:33 bsd1dw kernel: nlm_do_cancel(): caller_name = hp13 (sysid = 5) What happens is as follows: When logging in to an account with the home directory on the NFS- Server, the shell reads '.profile' and the tries to get a lock on '.sh_history'. From a FreeBSD 6.3 server the shell gets the lock whereas a 6.4/7.1 server replies with "V4 LOCK_RES Call NLM_FAILED". Of course the HP-UX shell assumes the file is already locked, waits some time and tries again. This game leads to a complete lock of the account... :-( This does not happen if commandline-history is disabled but nontheless it's an error anyway. I have recorded the network traffic for a NFSv2 session, a NFSv3/tcp session with a 6.3 server and a NFSv3/tcp session with a 7-STABLE server. If the wireshark dumps are of interest beyond of what I described here they are available on request. I hope my informations help those who are able to fix it... Matthew -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) From tom at tomjudge.com Wed Jan 21 12:46:52 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Jan 21 12:47:23 2009 Subject: CARP IP level load balancing In-Reply-To: <9488116E9B3E48789DB4B688BBEFED13@adnote989> References: <400557.75901.qm@web63903.mail.re1.yahoo.com> <9488116E9B3E48789DB4B688BBEFED13@adnote989> Message-ID: <49778503.80506@tomjudge.com> Luiz Otavio O Souza wrote: >>> Date: Tuesday, January 20, 2009, 9:30 AM >>> In FreeBSD there is only ARP level LB, that is in some cases >>> just not enough for load balancing. >>> Is there any plans to port IP level LB from OpenBSD, and, >>> if yes, will it be ported to 7x and 6x? >>> >>> In my opinion, full CARP realization is one step towards >>> LVS-equal functionality. >> >> Curious as to your specific needs. Is LAGG load balancing of no use >> at IP level? >> >> Barney >> > > hmm... with lagg you have two (or more) phisical connections sharing > the same ip, with carp you will have two (or more) servers sharing the > same ip. > > i think lagg will not help. > > i would like to give a try on carp ip balance, but i dont have the > time for now. i also like to known if someone else is working on this. > > Luiz > The way that we deploy IP level load balancing, we have 2 PF firewall routers on the network edge that handle the IP load balancing using round robin route to. (We are using direct sender reply) Then we have 2+ nodes with a carp address for each node, with backups on the other nodes. These carp addresses are the addresses used in the route to rule. The public IP's are assigned to the loop back interfaces of the application nodes and the default gateway of the application nodes is back out the PF firewalls. Here is a diagram to help explain: http://www.tomjudge.com/tmp/Diagram1.png AFAIK there is no Layer 3 load balancing support built in to carp in FreeBSD, however this solution will work if you have firewalls that can help you out with the distribution. Tom From linimon at FreeBSD.org Wed Jan 21 16:20:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Jan 21 16:20:41 2009 Subject: kern/130846: [vge] vge0 not autonegotiating to 1000baseTX full duplex in 7.1 Message-ID: <200901220020.n0M0KYxO048023@freefall.freebsd.org> Old Synopsis: vge0 not autonegotiating to 1000baseTX full duplex in 7.1 New Synopsis: [vge] vge0 not autonegotiating to 1000baseTX full duplex in 7.1 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 22 00:20:11 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=130846 From onemda at gmail.com Wed Jan 21 16:32:28 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Jan 21 16:32:40 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: <200901211830.n0LIUhWj083106@freefall.freebsd.org> References: <200901211830.n0LIUhWj083106@freefall.freebsd.org> Message-ID: <3a142e750901211632i7bdda4f2jfdf0d0940860cbfc@mail.gmail.com> On 1/21/09, linimon@freebsd.org wrote: > Old Synopsis: wpa_supplicant returns 'no space on device' > New Synopsis: [ndis] wpa_supplicant(8) returns 'no space on device' > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Jan 21 18:29:51 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130820 > _______________________________________________ > 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" > Yet another invalid bug report. OP should use -Dndis and not -Dbsd -- Paul From sandiegobiker at gmail.com Wed Jan 21 19:29:32 2009 From: sandiegobiker at gmail.com (Len Gross) Date: Wed Jan 21 19:29:39 2009 Subject: Proxy arp on a router? Message-ID: <27cb3ada0901211907o47f7a145o1e32017b73e8f13a@mail.gmail.com> I have done extensive experimentation on my network and extensive Googling and and am confused as to whether you can use proxy arp in the following situation. I have a router at 192.168.0.200/16 that also has an interface to 192.168.1.1/24. I want to proxy arp the 192.168.1.1 so that requests that come in on the 192.168.9.200/16 interface are given that interface's MAC address and when data arrives for 192.168.1.1/24 it is sent out the proprer interface. In many of the web pages I've examined, this appears to be a pretty standard proxy arp appication, but these are CIsco or Linux references. It appears I can only get this working on FreeBSD when I: ifconfig 192.169.1.1/24 -arp This pretty much makes the subnet useless. I have tried setting up: arp -s permanent entries with the real MAC address for 192.169.1.1/24, but still no luck. >From the FreeBSD documentation, it isn't clear that you can proxy arp on a router. So, two questions: a) Is there a way to make this work? b) If not, how can I help make the documentation clearer? -- Len From sclark46 at earthlink.net Thu Jan 22 11:20:28 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Jan 22 11:20:35 2009 Subject: FreeBSD 6.3 clear ethernet interface counter Message-ID: <4978C42D.7010701@earthlink.net> Hello, I googled and didn't find an answer on how to clear the interface stats that are displayed by netstat -ibndh could someone point in the right direction? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From sclark46 at earthlink.net Thu Jan 22 13:35:10 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Jan 22 13:35:25 2009 Subject: FreeBSD 6.3 clear ethernet interface counter In-Reply-To: <54994.216.241.167.212.1232652975.squirrel@webmail.pknet.net> References: <54994.216.241.167.212.1232652975.squirrel@webmail.pknet.net> Message-ID: <4978E68B.20100@earthlink.net> Peter wrote: >> Hello, >> >> I googled and didn't find an answer on how to clear the interface stats >> that are >> displayed by >> netstat -ibndh >> >> could someone point in the right direction? >> >> Thanks, >> Steve >> -- >> >> "They that give up essential liberty to obtain temporary safety, >> deserve neither liberty nor safety." (Ben Franklin) >> >> "The course of history shows that as a government grows, liberty >> decreases." (Thomas Jefferson) > > http://www.google.com/search?q=clear+netstat+interface+counters&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a > > $man netstat |grep -B1 -i counter > in and out. If -d is also present, show the number of dropped > packets. If -h is also present, print all counters in human > -- > particular protocol_family, or for a single protocol. If -s is > repeated, counters with a value of zero are suppressed. If > -z is > also present, reset statistic counters after displaying them > Sigh ... you obviously didn't try using the -z option. [root@sclark ~]# netstat -iz Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll rl0 1500 00:e0:7d:9b:f7:a3 10187060 0 2681169 0 0 rl0 1500 192.168.198 192.168.198.50 3567132 - 2582751 - - rl0 1500 10.254.150/24 10.254.150.10 108113 - 75684 - - rl1 1500 00:e0:7d:9b:f7:9d 18584893 0 9470823 1 0 rl1 1500 10.0.128/17 sclark 11450836 - 9461523 - - vr0 1500 00:11:5b:15:5a:4d 9068 0 18004 0 0 vr0 1500 10.3.1/24 10.3.1.1 9068 - 9068 - - plip0 1500 0 0 0 0 0 lo0 16384 6196166 0 6196166 0 0 lo0 16384 your-net localhost 6196154 - 6196154 - - [root@sclark ~]# netstat -iz Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll rl0 1500 00:e0:7d:9b:f7:a3 10187069 0 2681171 0 0 rl0 1500 192.168.198 192.168.198.50 3567136 - 2582753 - - rl0 1500 10.254.150/24 10.254.150.10 108113 - 75684 - - rl1 1500 00:e0:7d:9b:f7:9d 18584947 0 9470852 1 0 rl1 1500 10.0.128/17 sclark 11450884 - 9461552 - - vr0 1500 00:11:5b:15:5a:4d 9068 0 18004 0 0 vr0 1500 10.3.1/24 10.3.1.1 9068 - 9068 - - plip0 1500 0 0 0 0 0 lo0 16384 6196207 0 6196207 0 0 lo0 16384 your-net localhost 6196195 - 6196195 - - also from the man page: netstat -i | -I interface [-abdhntW] [-f address_family] [-M core] [-N system] notice no "-z" -z is for clearing protocol stats. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From bzeeb-lists at lists.zabbadoz.net Thu Jan 22 15:05:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Jan 22 15:05:16 2009 Subject: Need testers for a network cleanup patch Message-ID: <20090122225404.U45399@maildrop.int.zabbadoz.net> Hi, while cleaning up protosw things I found that rip6_output was most likely never called from pr_output and after a short talk with Robert the conclusion was that the same had been true for rip_output. Before I am going to remove the initializations I made the two rip{,6}_output functions calling panic(). I have a patch for HEAD here: http://people.freebsd.org/~bz/20090122-03-pr_output.diff and one for 7-STABLE here (compiled but not booted): http://people.freebsd.org/~bz/20090122-04-pr_output-7STABLE.diff I am confident it will not panic (at least for HEAD;) but not 100% sure so you can run this on your test or devel machine but I'd not run it on a production machine. If you are going to use the 7-STABLE patch make sure to have debugging support in your kernel as well so we could get backtraces in the unlikely event of panic. Please reply directly to me if you have (un)successfully run the patch and do NOT to the lists. In case you think you run it successfully mail me after a 2-3 days, and _not_ with an "it booted" message! ;-) Thanks for your help. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From sazzad at ou.edu Thu Jan 22 16:26:37 2009 From: sazzad at ou.edu (Rahman, Md Sazzadur) Date: Thu Jan 22 16:26:47 2009 Subject: A query regarding SCTP congestion control In-Reply-To: <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> <48060748.1090807@cisco.com> <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> Message-ID: <7059EA19D7837E44A3BA7DAB464944B39BA45E03AB@XMAIL5.sooner.net.ou.edu> Hi Randall, Thanks for your suggestions. I could collect congestion window data from SCTP sender using SCTP_LOCAL_TRACE_BUF on FreeBSD7.1 kernel using the tools you provided (dump_apple_log.c, prtcwndlog.c etc.). Now, in the log, I found that tsn (Transmission Sequence Number) never changes and remains fixed which is not supposed to happen, I believe. Do you have any idea what could go wrong? For example, in the log below, tsn is always 28170ae0. //-From Log------------------------------- 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) .............. ............. 2592.987776 1543168861292865 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) //---------------------------------------------- Steps I have followed: //---------------------------------------------- 1. Recompiled FreeBSD7.1 kernel by enabling SCTP_LOCAL_TRACE_BUF #define SCTP_LOCAL_TRACE_BUF 1 2. Enalble desired loging using sysctl; Sysctl -w "net.inet.sctp.log_level=0x00000004 3. Run application that sends SCTP data to the network 4. ./Dump_apple_log > data.txt 5. ./Prtcwdlog -l data.txt> cwnd.txt //---------------------------------------------- I have attached the log file herewith this mail. It would be great if you can give me any hint to resolve this issue. Thanks, Sazzad -----Original Message----- From: Randy Stewart [mailto:randall@lakerest.net] Sent: Thursday, August 28, 2008 6:39 AM To: sazzadur rahman Cc: freebsd-net; Atiquzzaman, Mohammed; Rahman, Md Sazzadur Subject: Re: A query regarding SCTP congestion control Remember a lot has changed between the book and now. 1) The initial window is now different 2) labc variable may influence how the cwnd responds are just 2 off the top of my head. You also may want to use a local trace buffer (as I mentioned earlier) since turning KTR on really really skew's things time wise.. its a resource pig. We added the local trace buffer for this very reason. Contact me directly if you need guidance on this. Also you may want to pick up the latest update that I just put up on www.sctp.org It gets the 7.0 stack current to 8.0's code.. .and there have been at least 1 CC fix in the last few months.. R On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: > Hello, > I need to get SCTP congestion window data for research purpose. I > collected > cwnd data from SCTP sender running on FreeBSD 7.0 machine by using KTR > kernel log. After that, I tried to plot cwnd vs. time and generated > graph. > But I am unable to explain the graph and it is very different > compared to > the graph as shown in the book "Stream Control Transmission Protocol > (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP > congestion window. An typical entry from the log looks like: > > 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 > flight:0 pq:0 > atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) > > I have used 749199232185105 in x axis as time and cwnd:25140 in y > axis. I > have attached the image file of the graph herewith this mail. > >> From the log, I found that cwnd varies very frequently accross >> time. Does > anyone have any idea regarding this issue? > Please let me know if you have any questions further. > > Thanks in advance. > > Best regards, > Md Sazzadur Rahman > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, Oklahoma, USA > > Steps for getting kernel log > > ------------------------------------------ > > 1. Add options: > > options KTR > > options KTR_ENTRIES=65536 > > options KTR_MASK=KTR_SUBSYS > > > 2. Recompile kernel > > config CUSTOM_KERNEL_9_6 > > cd ../compile/ CUSTOM_KERNEL_9_6 > > make cleandepend;make depend; > > make all install > > 3. Tried to enable trace point by: > > Sysctl -w "net.inet.sctp.log_level=0x00000004" > > 4. run SCTP sender. > > 5. pull out data: > > Ktrdump -q -t -o file_name > > Prtcwndlog -l filename > cwnd.txt > > --------------------------------------------------- > > > > On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart > wrote: > >> Rahman, Md Sazzadur wrote: >> >>> Hi, I would like to get the values of SCTP congestion control >>> algorithm variables (cwnd, ssthresh, flightsize and pba) from any >>> SCTP based application in runtime for research purpose. Does any API >>> exist in SCTP for that? Do I need to dig the SCTP code in kernel to >>> get the values? >>> >> >> There is a socket option to get the cwnd. >> >> However, I think what you really want is some of the researchish >> tracing stuff that SCTP provides. >> >> You can actually get a real time trace of the cwnd/flight etc via the >> various logging functions. >> >> You basically must compile this as an option.. have to go look >> at the options.. >> >> And then you can either use ktrace (which I don't recommend since >> it turns on to much overhead in the kernel) or you can >> use SCTP_LOCAL_TRACE_BUF >> >> This will put it into a piece of memory only for SCTP and >> not turn on all the other ktrace points. >> >> After you enable the logging in your compile you must turn >> on the logging level.. >> >> SCTP_CWND_LOGGING_ENABLE >> >> woudl be my recommendation. >> >> It gives you a real time up/down growth of the cwnd/flight/rwnd >> >> I think I wrote a "how to" somewhere.. let me go look.. >> >> R >> >> >> >>> I will appreciate any help in this regard. >>> >>> Best Regards, Md Sazzadur Rahman Graduate Student, School of >>> Computer >>> Science, University of Oklahoma, Norman, Oklahoma, USA >>> >>> _______________________________________________ freebsd-net@freebsd.orgmailing >>> list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To >>> unsubscribe, >>> send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >> >> -- >> Randall Stewart >> NSSTG - Cisco Systems Inc. >> 803-345-0369 803-317-4952 (cell) >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ----- Randall Stewart randall@lakerest.net -------------- next part -------------- Send completes sending 672598752 (sendcnt:191,strcnt:191) Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 0.0 1543161847380270 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 0.0 1543161847380270 Send completes sending 672598752 (sendcnt:191,strcnt:191) 0.0 1543161847380270 Send completes sending 672598752 (sendcnt:191,strcnt:191) 0.1290 1543161847381515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 0.2535 1543161849671700 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 2.146992 1543161849674145 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:11344 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 2.149437 1543161849684375: Net:0xc463aaf0 Cwnd:13063 flt:11344 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 2.149437 1543161849684375 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 2.159667 1543161849687630 fill_outqueue called on net:0xc463aaf0 cwnd:13063 flight:11344 (sendcnt:191,strcnt:191) 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.199837 1543161849725655 Send completes sending 672598752 (sendcnt:191,strcnt:191) 2.199837 1543161849725655 fill_outqueue called on net:0xc463aaf0 cwnd:13063 flight:12762 (sendcnt:191,strcnt:191) 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.228382 1543161849754110 Send completes sending 672598752 (sendcnt:191,strcnt:191) 2.229402 1543161849755115 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.229402 1543161849755115 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 2.229402 1543161849755115 Send completes sending 672598752 (sendcnt:191,strcnt:191) 2.230407 1543161849756255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 2.230407 1543161849756255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 2.231547 1543161861413190 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 13.354146 1543161861415230 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:11344 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 13.356186 1543161861428580: Net:0xc463aaf0 Cwnd:13063 flt:11344 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 13.356186 1543161861428580 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 13.369536 1543161861432720 fill_outqueue called on net:0xc463aaf0 cwnd:13063 flight:11344 (sendcnt:191,strcnt:191) 13.373676 1543161861468900 Network:0xc463aaf0 cwnd:13063 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.373676 1543161861468900 Network:0xc463aaf0 cwnd:13063 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.409856 1543161861470025 Send completes sending 672598752 (sendcnt:191,strcnt:191) 13.409856 1543161861470025 fill_outqueue called on net:0xc463aaf0 cwnd:13063 flight:12762 (sendcnt:191,strcnt:191) 13.410981 1543161861508890 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.410981 1543161861508890 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.449846 1543161861509985 Send completes sending 672598752 (sendcnt:191,strcnt:191) 13.450941 1543161861510990 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.450941 1543161861510990 Network:0xc463aaf0 cwnd:13063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 13.450941 1543161861510990 Send completes sending 672598752 (sendcnt:191,strcnt:191) 13.451946 1543161861512130 Send completes sending 672598752 (sendcnt:191,strcnt:191) 13.451946 1543161861512130 Send completes sending 672598752 (sendcnt:191,strcnt:191) 13.453086 1543161869785410 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 21.337758 1543161869791020 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:13063 flight:11344 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 21.343368 1543161869801535 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 21.353883 1543161869804745 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:11344 (sendcnt:191,strcnt:191) 21.357093 1543161869838165 Network:0xc463aaf0 cwnd:14563 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.357093 1543161869838165 Network:0xc463aaf0 cwnd:14563 flight:12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.390513 1543161869839245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.390513 1543161869839245 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:12762 (sendcnt:191,strcnt:191) 21.391593 1543161869867220 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.391593 1543161869867220 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.391593 1543161869867220 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.419568 1543161869892000 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.419568 1543161869892000 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.419568 1543161869892000 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.444348 1543161869893800 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.444348 1543161869893800 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 21.444348 1543161869893800 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.446148 1543161869894925 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.446148 1543161869894925 Send completes sending 672598752 (sendcnt:191,strcnt:191) 21.447273 1543161899778135 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 49.970355 1543161899780355 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 49.972575 1543161899790600: Net:0xc463aaf0 Cwnd:14563 flt:12762 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 49.972575 1543161899790600 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 49.982820 1543161899794500 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:12762 (sendcnt:191,strcnt:191) 49.986720 1543161899830755 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 49.986720 1543161899830755 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 49.986720 1543161899830755 Send completes sending 672598752 (sendcnt:191,strcnt:191) 50.22975 1543161899832540 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:14180 (sendcnt:191,strcnt:191) 50.24760 1543161899867205 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 50.24760 1543161899867205 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 50.24760 1543161899867205 Send completes sending 672598752 (sendcnt:191,strcnt:191) 50.59425 1543161899869065 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 50.59425 1543161899869065 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 50.59425 1543161899869065 Send completes sending 672598752 (sendcnt:191,strcnt:191) 50.61285 1543161899870355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 50.61285 1543161899870355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 50.62575 1543161906306285 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 56.158473 1543161906312045 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 56.164233 1543161906322410: Net:0xc463aaf0 Cwnd:14563 flt:12762 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 56.164233 1543161906322410 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 56.174598 1543161906326700 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:12762 (sendcnt:191,strcnt:191) 56.178888 1543161906361095 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.178888 1543161906361095 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.213283 1543161906362115 Send completes sending 672598752 (sendcnt:191,strcnt:191) 56.213283 1543161906362115 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:14180 (sendcnt:191,strcnt:191) 56.214303 1543161906405405 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.214303 1543161906405405 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.257593 1543161906406470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 56.258658 1543161906407475 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.258658 1543161906407475 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 56.258658 1543161906407475 Send completes sending 672598752 (sendcnt:191,strcnt:191) 56.259663 1543161906408705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 56.259663 1543161906408705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 56.260893 1543161924545190 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 73.571586 1543161924547500 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 73.573896 1543161924557730: Net:0xc463aaf0 Cwnd:14563 flt:12762 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 73.573896 1543161924557730 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 73.584126 1543161924561555 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:12762 (sendcnt:191,strcnt:191) 73.587951 1543161924600795 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.587951 1543161924600795 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.627191 1543161924601845 Send completes sending 672598752 (sendcnt:191,strcnt:191) 73.627191 1543161924601845 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:14180 (sendcnt:191,strcnt:191) 73.628241 1543161924628905 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.628241 1543161924628905 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.655301 1543161924629925 Send completes sending 672598752 (sendcnt:191,strcnt:191) 73.655301 1543161924629925 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.656321 1543161924631185 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 73.656321 1543161924631185 Send completes sending 672598752 (sendcnt:191,strcnt:191) 73.656321 1543161924631185 Send completes sending 672598752 (sendcnt:191,strcnt:191) 73.657581 1543161924632355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 73.658751 1543161935164635 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 83.705271 1543161935166855 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 83.707491 1543161935177235: Net:0xc463aaf0 Cwnd:14563 flt:12762 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 83.707491 1543161935177235 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 83.717871 1543161935180985 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:12762 (sendcnt:191,strcnt:191) 83.721621 1543161935214240 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.721621 1543161935214240 Network:0xc463aaf0 cwnd:14563 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.754876 1543161935215290 Send completes sending 672598752 (sendcnt:191,strcnt:191) 83.754876 1543161935215290 fill_outqueue called on net:0xc463aaf0 cwnd:14563 flight:14180 (sendcnt:191,strcnt:191) 83.755926 1543161935245230 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.755926 1543161935245230 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.785866 1543161935246265 Send completes sending 672598752 (sendcnt:191,strcnt:191) 83.786901 1543161935247315 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.786901 1543161935247315 Network:0xc463aaf0 cwnd:14563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 83.786901 1543161935247315 Send completes sending 672598752 (sendcnt:191,strcnt:191) 83.787951 1543161935248500 Send completes sending 672598752 (sendcnt:191,strcnt:191) 83.787951 1543161935248500 Send completes sending 672598752 (sendcnt:191,strcnt:191) 83.789136 1543161943189095 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 91.341123 1543161943191420 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:14563 flight:12762 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 91.343448 1543161943202505 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 91.354533 1543161943206015 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:12762 (sendcnt:191,strcnt:191) 91.358043 1543161943243785 Network:0xc463aaf0 cwnd:16063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.358043 1543161943243785 Network:0xc463aaf0 cwnd:16063 flight:14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.358043 1543161943243785 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.395813 1543161943245630 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:14180 (sendcnt:191,strcnt:191) 91.397658 1543161943271895 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.397658 1543161943271895 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.423923 1543161943273020 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.425048 1543161943295985 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.425048 1543161943295985 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.425048 1543161943295985 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.448013 1543161943297725 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.448013 1543161943297725 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 91.448013 1543161943297725 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.449753 1543161943298970 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.449753 1543161943298970 Send completes sending 672598752 (sendcnt:191,strcnt:191) 91.450998 1543161962169195 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 109.446855 1543161962171490 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 109.449150 1543161962181810: Net:0xc463aaf0 Cwnd:16063 flt:14180 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 109.449150 1543161962181810 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 109.459470 1543161962185920 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:14180 (sendcnt:191,strcnt:191) 109.463580 1543161962217840 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.463580 1543161962217840 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.463580 1543161962217840 Send completes sending 672598752 (sendcnt:191,strcnt:191) 109.495500 1543161962219700 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:15598 (sendcnt:191,strcnt:191) 109.497360 1543161962249130 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.526790 1543161962250135 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.526790 1543161962250135 Send completes sending 672598752 (sendcnt:191,strcnt:191) 109.527795 1543161962251485 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.527795 1543161962251485 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 109.527795 1543161962251485 Send completes sending 672598752 (sendcnt:191,strcnt:191) 109.529145 1543161962252670 Send completes sending 672598752 (sendcnt:191,strcnt:191) 109.529145 1543161962252670 Send completes sending 672598752 (sendcnt:191,strcnt:191) 109.530330 1543161974064990 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 120.808314 1543161974067300 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 120.810624 1543161974077770: Net:0xc463aaf0 Cwnd:16063 flt:14180 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 120.810624 1543161974077770 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 120.821094 1543161974081490 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:14180 (sendcnt:191,strcnt:191) 120.824814 1543161974119515 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.824814 1543161974119515 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.862839 1543161974120520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 120.862839 1543161974120520 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:15598 (sendcnt:191,strcnt:191) 120.863844 1543161974147730 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.863844 1543161974147730 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.863844 1543161974147730 Send completes sending 672598752 (sendcnt:191,strcnt:191) 120.891054 1543161974149590 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.891054 1543161974149590 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 120.891054 1543161974149590 Send completes sending 672598752 (sendcnt:191,strcnt:191) 120.892914 1543161974150730 Send completes sending 672598752 (sendcnt:191,strcnt:191) 120.892914 1543161974150730 Send completes sending 672598752 (sendcnt:191,strcnt:191) 120.894054 1543161992937405 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 138.806361 1543161992939700 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 138.808656 1543161992952150: Net:0xc463aaf0 Cwnd:16063 flt:14180 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 138.808656 1543161992952150 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 138.821106 1543161992955975 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:14180 (sendcnt:191,strcnt:191) 138.824931 1543161992992275 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.824931 1543161992992275 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.861231 1543161992993400 Send completes sending 672598752 (sendcnt:191,strcnt:191) 138.861231 1543161992993400 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:15598 (sendcnt:191,strcnt:191) 138.862356 1543161993019065 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.862356 1543161993019065 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.888021 1543161993020100 Send completes sending 672598752 (sendcnt:191,strcnt:191) 138.889056 1543161993021225 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.889056 1543161993021225 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 138.889056 1543161993021225 Send completes sending 672598752 (sendcnt:191,strcnt:191) 138.890181 1543161993022515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 138.890181 1543161993022515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 138.891471 1543162003517100 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 148.900296 1543162003519335 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 148.902531 1543162003530015: Net:0xc463aaf0 Cwnd:16063 flt:14180 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 148.902531 1543162003530015 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 148.913211 1543162003533915 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:14180 (sendcnt:191,strcnt:191) 148.917111 1543162003568580 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.917111 1543162003568580 Network:0xc463aaf0 cwnd:16063 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.951776 1543162003569585 Send completes sending 672598752 (sendcnt:191,strcnt:191) 148.951776 1543162003569585 fill_outqueue called on net:0xc463aaf0 cwnd:16063 flight:15598 (sendcnt:191,strcnt:191) 148.952781 1543162003601220 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.952781 1543162003601220 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.952781 1543162003601220 Send completes sending 672598752 (sendcnt:191,strcnt:191) 148.984416 1543162003603245 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.984416 1543162003603245 Network:0xc463aaf0 cwnd:16063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 148.984416 1543162003603245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 148.986441 1543162003604520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 148.986441 1543162003604520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 148.987716 1543162047969675 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 191.264103 1543162047972030 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:16063 flight:14180 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 191.266458 1543162047982485 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 191.276913 1543162047986370 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:14180 (sendcnt:191,strcnt:191) 191.280798 1543162048019925 Network:0xc463aaf0 cwnd:17563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.280798 1543162048019925 Network:0xc463aaf0 cwnd:17563 flight:15598 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.314353 1543162048021005 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.314353 1543162048021005 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 191.315433 1543162048046775 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.315433 1543162048046775 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.315433 1543162048046775 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.341203 1543162048069620 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.341203 1543162048069620 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.341203 1543162048069620 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.364048 1543162048071060 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.364048 1543162048071060 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 191.364048 1543162048071060 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.365488 1543162048072305 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.365488 1543162048072305 Send completes sending 672598752 (sendcnt:191,strcnt:191) 191.366733 1543162062975150 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 205.589514 1543162062977235 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 205.591599 1543162062987615: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 205.591599 1543162062987615 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 205.601979 1543162062991590 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 205.605954 1543162063026510 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.605954 1543162063026510 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.605954 1543162063026510 Send completes sending 672598752 (sendcnt:191,strcnt:191) 205.640874 1543162063028355 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 205.642719 1543162063059675 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.642719 1543162063059675 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.674039 1543162063060725 Send completes sending 672598752 (sendcnt:191,strcnt:191) 205.674039 1543162063060725 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.675089 1543162063062030 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 205.675089 1543162063062030 Send completes sending 672598752 (sendcnt:191,strcnt:191) 205.675089 1543162063062030 Send completes sending 672598752 (sendcnt:191,strcnt:191) 205.676394 1543162063063170 Send completes sending 672598752 (sendcnt:191,strcnt:191) 205.677534 1543162085594085 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 227.139777 1543162085596230 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 227.141922 1543162085606895: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 227.141922 1543162085606895 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 227.152587 1543162085610915 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 227.156607 1543162085644920 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.156607 1543162085644920 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.156607 1543162085644920 Send completes sending 672598752 (sendcnt:191,strcnt:191) 227.190612 1543162085646750 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 227.192442 1543162085678400 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.192442 1543162085678400 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.192442 1543162085678400 Send completes sending 672598752 (sendcnt:191,strcnt:191) 227.224092 1543162085680395 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.224092 1543162085680395 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 227.224092 1543162085680395 Send completes sending 672598752 (sendcnt:191,strcnt:191) 227.226087 1543162085681610 Send completes sending 672598752 (sendcnt:191,strcnt:191) 227.226087 1543162085681610 Send completes sending 672598752 (sendcnt:191,strcnt:191) 227.227302 1543162091458620 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 232.761432 1543162091460870 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 232.763682 1543162091471370: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 232.763682 1543162091471370 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 232.774182 1543162091477670 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 232.780482 1543162091511660 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.780482 1543162091511660 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.780482 1543162091511660 Send completes sending 672598752 (sendcnt:191,strcnt:191) 232.814472 1543162091513475 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 232.816287 1543162091541825 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.816287 1543162091541825 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.844637 1543162091542875 Send completes sending 672598752 (sendcnt:191,strcnt:191) 232.845687 1543162091543940 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.845687 1543162091543940 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 232.845687 1543162091543940 Send completes sending 672598752 (sendcnt:191,strcnt:191) 232.846752 1543162091545155 Send completes sending 672598752 (sendcnt:191,strcnt:191) 232.846752 1543162091545155 Send completes sending 672598752 (sendcnt:191,strcnt:191) 232.847967 1543162158505740 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 296.699688 1543162158507975 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 296.701923 1543162158518445: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 296.701923 1543162158518445 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 296.712393 1543162158525690 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 296.719638 1543162158558675 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.719638 1543162158558675 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.752623 1543162158559755 Send completes sending 672598752 (sendcnt:191,strcnt:191) 296.752623 1543162158559755 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 296.753703 1543162158586170 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.753703 1543162158586170 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.780118 1543162158587235 Send completes sending 672598752 (sendcnt:191,strcnt:191) 296.781183 1543162158588255 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.781183 1543162158588255 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 296.781183 1543162158588255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 296.782203 1543162158589470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 296.782203 1543162158589470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 296.783418 1543162168936350 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 306.644538 1543162168938615 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 306.646803 1543162168949115: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 306.646803 1543162168949115 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 306.657303 1543162168952700 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 306.660888 1543162168989765 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.660888 1543162168989765 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.660888 1543162168989765 Send completes sending 672598752 (sendcnt:191,strcnt:191) 306.697953 1543162168991625 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 306.699813 1543162169021205 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.699813 1543162169021205 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.729393 1543162169022225 Send completes sending 672598752 (sendcnt:191,strcnt:191) 306.730413 1543162169023440 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.730413 1543162169023440 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 306.730413 1543162169023440 Send completes sending 672598752 (sendcnt:191,strcnt:191) 306.731628 1543162169024610 Send completes sending 672598752 (sendcnt:191,strcnt:191) 306.731628 1543162169024610 Send completes sending 672598752 (sendcnt:191,strcnt:191) 306.732798 1543162173271635 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 310.785519 1543162173274125 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 310.788009 1543162173284685: Net:0xc463aaf0 Cwnd:17563 flt:15598 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 310.788009 1543162173284685 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 310.798569 1543162173288285 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:15598 (sendcnt:191,strcnt:191) 310.802169 1543162173324615 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.802169 1543162173324615 Network:0xc463aaf0 cwnd:17563 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.838499 1543162173325680 Send completes sending 672598752 (sendcnt:191,strcnt:191) 310.838499 1543162173325680 fill_outqueue called on net:0xc463aaf0 cwnd:17563 flight:17016 (sendcnt:191,strcnt:191) 310.839564 1543162173359970 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.839564 1543162173359970 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.873854 1543162173361005 Send completes sending 672598752 (sendcnt:191,strcnt:191) 310.874889 1543162173362085 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.874889 1543162173362085 Network:0xc463aaf0 cwnd:17563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 310.874889 1543162173362085 Send completes sending 672598752 (sendcnt:191,strcnt:191) 310.875969 1543162173363315 Send completes sending 672598752 (sendcnt:191,strcnt:191) 310.875969 1543162173363315 Send completes sending 672598752 (sendcnt:191,strcnt:191) 310.877199 1543162187899395 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 324.733215 1543162187901915 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:17563 flight:15598 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 324.735735 1543162187916660 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 324.750480 1543162187919795 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:15598 (sendcnt:191,strcnt:191) 324.753615 1543162187954520 Network:0xc463aaf0 cwnd:19063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.753615 1543162187954520 Network:0xc463aaf0 cwnd:19063 flight:17016 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.753615 1543162187954520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.788340 1543162187956395 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 324.790215 1543162187982915 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.790215 1543162187982915 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.816735 1543162187983980 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.817800 1543162188003720 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.817800 1543162188003720 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.817800 1543162188003720 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.837540 1543162188005520 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.837540 1543162188005520 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 324.837540 1543162188005520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.839340 1543162188006705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.839340 1543162188006705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 324.840525 1543162198689360 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 335.37420 1543162198691715 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 335.39775 1543162198702380: Net:0xc463aaf0 Cwnd:19063 flt:17016 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 335.39775 1543162198702380 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 335.50440 1543162198706595 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 335.54655 1543162198743480 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.54655 1543162198743480 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.54655 1543162198743480 Send completes sending 672598752 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:18434 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 335.91540 1543162198745355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 335.93415 1543162205403765 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 341.411793 1543162205409615 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 341.417643 1543162205419980: Net:0xc463aaf0 Cwnd:19063 flt:17016 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 341.417643 1543162205419980 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 341.428008 1543162205423940 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 341.431968 1543162205459145 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.431968 1543162205459145 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.467173 1543162205460195 Send completes sending 672598752 (sendcnt:191,strcnt:191) 341.467173 1543162205460195 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:18434 (sendcnt:191,strcnt:191) 341.468223 1543162205488185 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.468223 1543162205488185 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.496213 1543162205489355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 341.497383 1543162205490405 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.497383 1543162205490405 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 341.497383 1543162205490405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 341.498433 1543162205491680 Send completes sending 672598752 (sendcnt:191,strcnt:191) 341.498433 1543162205491680 Send completes sending 672598752 (sendcnt:191,strcnt:191) 341.499708 1543162241398335 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 375.754779 1543162241400510 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 375.756954 1543162241410635: Net:0xc463aaf0 Cwnd:19063 flt:17016 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 375.756954 1543162241410635 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 375.767079 1543162241414820 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 375.771264 1543162241453775 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.771264 1543162241453775 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.810219 1543162241454825 Send completes sending 672598752 (sendcnt:191,strcnt:191) 375.810219 1543162241454825 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:18434 (sendcnt:191,strcnt:191) 375.811269 1543162241483070 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.811269 1543162241483070 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.839514 1543162241484150 Send completes sending 672598752 (sendcnt:191,strcnt:191) 375.840594 1543162241485155 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.840594 1543162241485155 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 375.840594 1543162241485155 Send completes sending 672598752 (sendcnt:191,strcnt:191) 375.841599 1543162241486370 Send completes sending 672598752 (sendcnt:191,strcnt:191) 375.841599 1543162241486370 Send completes sending 672598752 (sendcnt:191,strcnt:191) 375.842814 1543162292299305 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 424.275525 1543162292301780 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 424.278000 1543162292312505: Net:0xc463aaf0 Cwnd:19063 flt:17016 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 424.278000 1543162292312505 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 424.288725 1543162292316690 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 424.292910 1543162292356905 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.292910 1543162292356905 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.292910 1543162292356905 Send completes sending 672598752 (sendcnt:191,strcnt:191) 424.333125 1543162292358750 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:18434 (sendcnt:191,strcnt:191) 424.334970 1543162292385240 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.334970 1543162292385240 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.334970 1543162292385240 Send completes sending 672598752 (sendcnt:191,strcnt:191) 424.361460 1543162292387145 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.361460 1543162292387145 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 424.361460 1543162292387145 Send completes sending 672598752 (sendcnt:191,strcnt:191) 424.363365 1543162292388450 Send completes sending 672598752 (sendcnt:191,strcnt:191) 424.363365 1543162292388450 Send completes sending 672598752 (sendcnt:191,strcnt:191) 424.364670 1543162309113405 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 440.312409 1543162309115820 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 440.314824 1543162309126320: Net:0xc463aaf0 Cwnd:19063 flt:17016 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 440.314824 1543162309126320 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 440.325324 1543162309129965 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:17016 (sendcnt:191,strcnt:191) 440.328969 1543162309167780 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.328969 1543162309167780 Network:0xc463aaf0 cwnd:19063 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.328969 1543162309167780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 440.366784 1543162309169640 fill_outqueue called on net:0xc463aaf0 cwnd:19063 flight:18434 (sendcnt:191,strcnt:191) 440.368644 1543162309196760 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.368644 1543162309196760 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.395764 1543162309197795 Send completes sending 672598752 (sendcnt:191,strcnt:191) 440.396799 1543162309198860 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.396799 1543162309198860 Network:0xc463aaf0 cwnd:19063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 440.396799 1543162309198860 Send completes sending 672598752 (sendcnt:191,strcnt:191) 440.397864 1543162309200045 Send completes sending 672598752 (sendcnt:191,strcnt:191) 440.397864 1543162309200045 Send completes sending 672598752 (sendcnt:191,strcnt:191) 440.399049 1543162325645685 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 456.67473 1543162325647860 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:19063 flight:17016 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 456.69648 1543162325658420 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 456.80208 1543162325661540 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:17016 (sendcnt:191,strcnt:191) 456.83328 1543162325696475 Network:0xc463aaf0 cwnd:20563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.83328 1543162325696475 Network:0xc463aaf0 cwnd:20563 flight:18434 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.118263 1543162325697555 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.118263 1543162325697555 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 456.119343 1543162325728815 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.119343 1543162325728815 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.150603 1543162325729925 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.151713 1543162325751450 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.151713 1543162325751450 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.151713 1543162325751450 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.173238 1543162325753280 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.173238 1543162325753280 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 456.173238 1543162325753280 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.175068 1543162325754465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.175068 1543162325754465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 456.176253 1543162327393350 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 457.766562 1543162327395705 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 457.768917 1543162327405695: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 457.768917 1543162327405695 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 457.778907 1543162327409100 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 457.782312 1543162327448370 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.782312 1543162327448370 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.782312 1543162327448370 Send completes sending 672598752 (sendcnt:191,strcnt:191) 457.821582 1543162327450200 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 457.823412 1543162327477335 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.823412 1543162327477335 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.850547 1543162327478355 Send completes sending 672598752 (sendcnt:191,strcnt:191) 457.851567 1543162327479405 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.851567 1543162327479405 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 457.851567 1543162327479405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 457.852617 1543162327480605 Send completes sending 672598752 (sendcnt:191,strcnt:191) 457.852617 1543162327480605 Send completes sending 672598752 (sendcnt:191,strcnt:191) 457.853817 1543162389846465 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 517.305117 1543162389849030 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 517.307682 1543162389859725: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 517.307682 1543162389859725 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 517.318377 1543162389864150 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 517.322802 1543162389897390 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.322802 1543162389897390 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.322802 1543162389897390 Send completes sending 672598752 (sendcnt:191,strcnt:191) 517.356042 1543162389899265 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 517.357917 1543162389930315 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.357917 1543162389930315 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.357917 1543162389930315 Send completes sending 672598752 (sendcnt:191,strcnt:191) 517.388967 1543162389932235 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.388967 1543162389932235 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 517.388967 1543162389932235 Send completes sending 672598752 (sendcnt:191,strcnt:191) 517.390887 1543162389933465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 517.390887 1543162389933465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 517.392117 1543162430331795 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 555.944559 1543162430334015 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 555.946779 1543162430344620: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 555.946779 1543162430344620 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 555.957384 1543162430348415 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 555.961179 1543162430380830 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 555.961179 1543162430380830 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 555.961179 1543162430380830 Send completes sending 672598752 (sendcnt:191,strcnt:191) 555.993594 1543162430382690 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 555.995454 1543162430408520 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 555.995454 1543162430408520 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 556.21284 1543162430409570 Send completes sending 672598752 (sendcnt:191,strcnt:191) 556.22334 1543162430410590 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 556.22334 1543162430410590 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 556.22334 1543162430410590 Send completes sending 672598752 (sendcnt:191,strcnt:191) 556.23354 1543162430411730 Send completes sending 672598752 (sendcnt:191,strcnt:191) 556.23354 1543162430411730 Send completes sending 672598752 (sendcnt:191,strcnt:191) 556.24494 1543162440915240 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 566.42244 1543162440917295 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 566.44299 1543162440927330: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 566.44299 1543162440927330 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 566.54334 1543162440930660 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 566.57664 1543162440962325 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.57664 1543162440962325 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.57664 1543162440962325 Send completes sending 672598752 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 566.89329 1543162440964245 Send completes sending 672598752 (sendcnt:191,strcnt:191) 566.91249 1543162442589795 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 567.619647 1543162442592255 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 567.622107 1543162442603820: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 567.622107 1543162442603820 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 567.633672 1543162442607060 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 567.636912 1543162442641845 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.636912 1543162442641845 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.636912 1543162442641845 Send completes sending 672598752 (sendcnt:191,strcnt:191) 567.671697 1543162442643630 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 567.673482 1543162442670600 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.673482 1543162442670600 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.700452 1543162442671830 Send completes sending 672598752 (sendcnt:191,strcnt:191) 567.700452 1543162442671830 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.701682 1543162442673135 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 567.701682 1543162442673135 Send completes sending 672598752 (sendcnt:191,strcnt:191) 567.701682 1543162442673135 Send completes sending 672598752 (sendcnt:191,strcnt:191) 567.702987 1543162442674290 Send completes sending 672598752 (sendcnt:191,strcnt:191) 567.704142 1543162459853535 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 584.57595 1543162459855530 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 584.59590 1543162459866000: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 584.59590 1543162459866000 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 584.70060 1543162459870215 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 584.74275 1543162459909305 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.74275 1543162459909305 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.74275 1543162459909305 Send completes sending 672598752 (sendcnt:191,strcnt:191) 584.113365 1543162459911120 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 584.115180 1543162459938360 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.115180 1543162459938360 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.142420 1543162459939425 Send completes sending 672598752 (sendcnt:191,strcnt:191) 584.143485 1543162459940460 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.143485 1543162459940460 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 584.143485 1543162459940460 Send completes sending 672598752 (sendcnt:191,strcnt:191) 584.144520 1543162459941705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 584.144520 1543162459941705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 584.145765 1543162475280060 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 598.804056 1543162475282100 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 598.806096 1543162475292795: Net:0xc463aaf0 Cwnd:20563 flt:18434 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 598.806096 1543162475292795 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 598.816791 1543162475296485 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:18434 (sendcnt:191,strcnt:191) 598.820481 1543162475334465 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.820481 1543162475334465 Network:0xc463aaf0 cwnd:20563 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.820481 1543162475334465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 598.858461 1543162475336355 fill_outqueue called on net:0xc463aaf0 cwnd:20563 flight:19852 (sendcnt:191,strcnt:191) 598.860351 1543162475361465 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.860351 1543162475361465 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.860351 1543162475361465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 598.885461 1543162475363235 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.885461 1543162475363235 Network:0xc463aaf0 cwnd:20563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 598.885461 1543162475363235 Send completes sending 672598752 (sendcnt:191,strcnt:191) 598.887231 1543162475364465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 598.887231 1543162475364465 Send completes sending 672598752 (sendcnt:191,strcnt:191) 598.888461 1543162483157985 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 606.293373 1543162483160160 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:20563 flight:18434 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 606.295548 1543162483171020 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 606.306408 1543162483174500 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:18434 (sendcnt:191,strcnt:191) 606.309888 1543162483207545 Network:0xc463aaf0 cwnd:22063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.309888 1543162483207545 Network:0xc463aaf0 cwnd:22063 flight:19852 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.309888 1543162483207545 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.342933 1543162483209480 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 606.344868 1543162483235340 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.344868 1543162483235340 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.370728 1543162483236435 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.371823 1543162483256340 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.371823 1543162483256340 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.371823 1543162483256340 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.391728 1543162483258125 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.391728 1543162483258125 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 606.391728 1543162483258125 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.393513 1543162483259325 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.393513 1543162483259325 Send completes sending 672598752 (sendcnt:191,strcnt:191) 606.394713 1543162500669780 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 623.27952 1543162500671655 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 623.29827 1543162500682455: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 623.29827 1543162500682455 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 623.40627 1543162500686535 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 623.44707 1543162500725760 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.44707 1543162500725760 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 623.83932 1543162500726780 Send completes sending 672598752 (sendcnt:191,strcnt:191) 623.84952 1543162542762825 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 663.129381 1543162542764670 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 663.131226 1543162542774585: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 663.131226 1543162542774585 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 663.141141 1543162542778785 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 663.145341 1543162542816240 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.145341 1543162542816240 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.145341 1543162542816240 Send completes sending 672598752 (sendcnt:191,strcnt:191) 663.182796 1543162542818055 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 663.184611 1543162542847650 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.184611 1543162542847650 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.184611 1543162542847650 Send completes sending 672598752 (sendcnt:191,strcnt:191) 663.214206 1543162542849525 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.214206 1543162542849525 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 663.214206 1543162542849525 Send completes sending 672598752 (sendcnt:191,strcnt:191) 663.216081 1543162542850800 Send completes sending 672598752 (sendcnt:191,strcnt:191) 663.216081 1543162542850800 Send completes sending 672598752 (sendcnt:191,strcnt:191) 663.217356 1543162549453785 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 669.528885 1543162549455840 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 669.530940 1543162549466520: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 669.530940 1543162549466520 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 669.541620 1543162549470195 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 669.545295 1543162549505430 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.545295 1543162549505430 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.545295 1543162549505430 Send completes sending 672598752 (sendcnt:191,strcnt:191) 669.580530 1543162549507275 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 669.582375 1543162549536390 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.582375 1543162549536390 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.611490 1543162549537515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 669.612615 1543162549538535 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.612615 1543162549538535 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 669.612615 1543162549538535 Send completes sending 672598752 (sendcnt:191,strcnt:191) 669.613635 1543162549539735 Send completes sending 672598752 (sendcnt:191,strcnt:191) 669.613635 1543162549539735 Send completes sending 672598752 (sendcnt:191,strcnt:191) 669.614835 1543162578900390 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 697.615362 1543162578902610 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 697.617582 1543162578913470: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 697.617582 1543162578913470 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 697.628442 1543162578917625 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 697.632597 1543162578949125 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.632597 1543162578949125 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.632597 1543162578949125 Send completes sending 672598752 (sendcnt:191,strcnt:191) 697.664097 1543162578950970 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 697.665942 1543162578978270 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.665942 1543162578978270 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.693242 1543162578979290 Send completes sending 672598752 (sendcnt:191,strcnt:191) 697.694262 1543162578980490 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.694262 1543162578980490 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 697.694262 1543162578980490 Send completes sending 672598752 (sendcnt:191,strcnt:191) 697.695462 1543162578981705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 697.695462 1543162578981705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 697.696677 1543162581200805 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 699.818625 1543162581202920 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 699.820740 1543162581213945: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 699.820740 1543162581213945 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 699.831765 1543162581229890 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 699.847710 1543162581262770 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.847710 1543162581262770 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.847710 1543162581262770 Send completes sending 672598752 (sendcnt:191,strcnt:191) 699.880590 1543162581264600 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 699.882420 1543162581289650 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.882420 1543162581289650 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.882420 1543162581289650 Send completes sending 672598752 (sendcnt:191,strcnt:191) 699.907470 1543162581291495 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.907470 1543162581291495 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 699.907470 1543162581291495 Send completes sending 672598752 (sendcnt:191,strcnt:191) 699.909315 1543162581292800 Send completes sending 672598752 (sendcnt:191,strcnt:191) 699.909315 1543162581292800 Send completes sending 672598752 (sendcnt:191,strcnt:191) 699.910620 1543162593359655 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 711.394563 1543162593362100 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 711.397008 1543162593372660: Net:0xc463aaf0 Cwnd:22063 flt:19852 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 711.397008 1543162593372660 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 711.407568 1543162593376395 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:19852 (sendcnt:191,strcnt:191) 711.411303 1543162593411450 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.411303 1543162593411450 Network:0xc463aaf0 cwnd:22063 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.446358 1543162593412455 Send completes sending 672598752 (sendcnt:191,strcnt:191) 711.446358 1543162593412455 fill_outqueue called on net:0xc463aaf0 cwnd:22063 flight:21270 (sendcnt:191,strcnt:191) 711.447363 1543162593443580 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.447363 1543162593443580 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.478488 1543162593444630 Send completes sending 672598752 (sendcnt:191,strcnt:191) 711.479538 1543162593445635 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.479538 1543162593445635 Network:0xc463aaf0 cwnd:22063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 711.479538 1543162593445635 Send completes sending 672598752 (sendcnt:191,strcnt:191) 711.480543 1543162593446805 Send completes sending 672598752 (sendcnt:191,strcnt:191) 711.480543 1543162593446805 Send completes sending 672598752 (sendcnt:191,strcnt:191) 711.481713 1543162603926120 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 721.475268 1543162603928640 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:22063 flight:19852 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 721.477788 1543162603939365 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 721.488513 1543162603942545 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:19852 (sendcnt:191,strcnt:191) 721.491693 1543162603975305 Network:0xc463aaf0 cwnd:23563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.491693 1543162603975305 Network:0xc463aaf0 cwnd:23563 flight:21270 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.491693 1543162603975305 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.524453 1543162603977120 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 721.526268 1543162604008005 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.526268 1543162604008005 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.557153 1543162604009055 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.558203 1543162604031705 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.558203 1543162604031705 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.558203 1543162604031705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.580853 1543162604033130 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.580853 1543162604033130 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 721.580853 1543162604033130 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.582278 1543162604034255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.582278 1543162604034255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 721.583403 1543162612102380 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 729.262920 1543162612104675 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 729.265215 1543162612114785: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 729.265215 1543162612114785 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 729.275325 1543162612118700 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 729.279240 1543162612154505 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.279240 1543162612154505 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.279240 1543162612154505 Send completes sending 672598752 (sendcnt:191,strcnt:191) 729.315045 1543162612156365 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 729.316905 1543162612181220 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.316905 1543162612181220 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.341760 1543162612182285 Send completes sending 672598752 (sendcnt:191,strcnt:191) 729.342825 1543162612183290 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.342825 1543162612183290 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 729.342825 1543162612183290 Send completes sending 672598752 (sendcnt:191,strcnt:191) 729.343830 1543162612184535 Send completes sending 672598752 (sendcnt:191,strcnt:191) 729.343830 1543162612184535 Send completes sending 672598752 (sendcnt:191,strcnt:191) 729.345075 1543162626882510 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 743.362986 1543162626884880 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 743.365356 1543162626895545: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 743.365356 1543162626895545 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 743.376021 1543162626899550 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 743.380026 1543162626938010 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.380026 1543162626938010 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.380026 1543162626938010 Send completes sending 672598752 (sendcnt:191,strcnt:191) 743.418486 1543162626939855 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 743.420331 1543162626968400 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.420331 1543162626968400 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.448876 1543162626969420 Send completes sending 672598752 (sendcnt:191,strcnt:191) 743.449896 1543162626970440 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.449896 1543162626970440 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 743.449896 1543162626970440 Send completes sending 672598752 (sendcnt:191,strcnt:191) 743.450916 1543162626971640 Send completes sending 672598752 (sendcnt:191,strcnt:191) 743.450916 1543162626971640 Send completes sending 672598752 (sendcnt:191,strcnt:191) 743.452116 1543162628276400 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 744.708300 1543162628279310 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 744.711210 1543162628289645: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 744.711210 1543162628289645 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 744.721545 1543162628292780 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 744.724680 1543162628324940 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.724680 1543162628324940 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.724680 1543162628324940 Send completes sending 672598752 (sendcnt:191,strcnt:191) 744.756840 1543162628326800 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 744.758700 1543162628357010 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.758700 1543162628357010 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.758700 1543162628357010 Send completes sending 672598752 (sendcnt:191,strcnt:191) 744.788910 1543162628359065 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.788910 1543162628359065 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 744.788910 1543162628359065 Send completes sending 672598752 (sendcnt:191,strcnt:191) 744.790965 1543162628360295 Send completes sending 672598752 (sendcnt:191,strcnt:191) 744.790965 1543162628360295 Send completes sending 672598752 (sendcnt:191,strcnt:191) 744.792195 1543162647680055 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 763.189011 1543162647682245 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 763.191201 1543162647692835: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 763.191201 1543162647692835 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 763.201791 1543162647696900 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 763.205856 1543162647734490 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.205856 1543162647734490 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.205856 1543162647734490 Send completes sending 672598752 (sendcnt:191,strcnt:191) 763.243446 1543162647736290 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 763.245246 1543162647762255 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.245246 1543162647762255 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.245246 1543162647762255 Send completes sending 672598752 (sendcnt:191,strcnt:191) 763.271211 1543162647764190 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.271211 1543162647764190 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 763.271211 1543162647764190 Send completes sending 672598752 (sendcnt:191,strcnt:191) 763.273146 1543162647765405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 763.273146 1543162647765405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 763.274361 1543162666290750 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 780.973914 1543162666293060 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 780.976224 1543162666303440: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 780.976224 1543162666303440 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 780.986604 1543162666307325 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 780.990489 1543162666342605 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 780.990489 1543162666342605 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 781.25769 1543162666343640 Send completes sending 672598752 (sendcnt:191,strcnt:191) 781.25769 1543162666343640 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 781.26804 1543162666374405 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 781.26804 1543162666374405 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 781.57569 1543162666375560 Send completes sending 672598752 (sendcnt:191,strcnt:191) 781.58724 1543162666376565 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 781.58724 1543162666376565 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 781.58724 1543162666376565 Send completes sending 672598752 (sendcnt:191,strcnt:191) 781.59729 1543162666377840 Send completes sending 672598752 (sendcnt:191,strcnt:191) 781.59729 1543162666377840 Send completes sending 672598752 (sendcnt:191,strcnt:191) 781.61004 1543162668170325 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 782.756337 1543162668172950 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 782.758962 1543162668187050: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 782.758962 1543162668187050 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 782.773062 1543162668190635 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 782.776647 1543162668223200 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.776647 1543162668223200 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.776647 1543162668223200 Send completes sending 672598752 (sendcnt:191,strcnt:191) 782.809212 1543162668225045 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 782.811057 1543162668251910 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.811057 1543162668251910 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.837922 1543162668252945 Send completes sending 672598752 (sendcnt:191,strcnt:191) 782.838957 1543162668254010 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.838957 1543162668254010 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 782.838957 1543162668254010 Send completes sending 672598752 (sendcnt:191,strcnt:191) 782.840022 1543162668255210 Send completes sending 672598752 (sendcnt:191,strcnt:191) 782.840022 1543162668255210 Send completes sending 672598752 (sendcnt:191,strcnt:191) 782.841222 1543162670771985 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 785.212269 1543162670774220 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 785.214504 1543162670784765: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 785.214504 1543162670784765 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 785.225049 1543162670788650 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 785.228934 1543162670824080 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.228934 1543162670824080 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.228934 1543162670824080 Send completes sending 672598752 (sendcnt:191,strcnt:191) 785.264364 1543162670826165 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 785.266449 1543162670854290 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.266449 1543162670854290 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.266449 1543162670854290 Send completes sending 672598752 (sendcnt:191,strcnt:191) 785.294574 1543162670856330 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.294574 1543162670856330 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 785.294574 1543162670856330 Send completes sending 672598752 (sendcnt:191,strcnt:191) 785.296614 1543162670857515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 785.296614 1543162670857515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 785.297799 1543162683699345 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 797.556717 1543162683701520 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 797.558892 1543162683711450: Net:0xc463aaf0 Cwnd:23563 flt:21270 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 797.558892 1543162683711450 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 797.568822 1543162683715035 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:21270 (sendcnt:191,strcnt:191) 797.572407 1543162683750960 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.572407 1543162683750960 Network:0xc463aaf0 cwnd:23563 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.572407 1543162683750960 Send completes sending 672598752 (sendcnt:191,strcnt:191) 797.608332 1543162683752790 fill_outqueue called on net:0xc463aaf0 cwnd:23563 flight:22688 (sendcnt:191,strcnt:191) 797.610162 1543162683782205 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.610162 1543162683782205 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.639577 1543162683783270 Send completes sending 672598752 (sendcnt:191,strcnt:191) 797.640642 1543162683784275 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.640642 1543162683784275 Network:0xc463aaf0 cwnd:23563 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 797.640642 1543162683784275 Send completes sending 672598752 (sendcnt:191,strcnt:191) 797.641647 1543162683785520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 797.641647 1543162683785520 Send completes sending 672598752 (sendcnt:191,strcnt:191) 797.642892 1543162695964740 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 809.239200 1543162695967095 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:23563 flight:21270 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 809.241555 1543162695977595 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 809.252055 1543162695980745 fill_outqueue called on net:0xc463aaf0 cwnd:25063 flight:21270 (sendcnt:191,strcnt:191) 809.255205 1543162696016955 Network:0xc463aaf0 cwnd:25063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.255205 1543162696016955 Network:0xc463aaf0 cwnd:25063 flight:22688 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.291415 1543162696018095 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.291415 1543162696018095 fill_outqueue called on net:0xc463aaf0 cwnd:25063 flight:22688 (sendcnt:191,strcnt:191) 809.292555 1543162696044720 Network:0xc463aaf0 cwnd:25063 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.292555 1543162696044720 Network:0xc463aaf0 cwnd:25063 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.319180 1543162696045845 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.320305 1543162696066935 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.320305 1543162696066935 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.320305 1543162696066935 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.341395 1543162696068360 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.341395 1543162696068360 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 809.341395 1543162696068360 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.342820 1543162696069485 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.342820 1543162696069485 Send completes sending 672598752 (sendcnt:191,strcnt:191) 809.343945 1543162702519890 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:24106 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 815.502894 1543162702522065 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:22688 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 815.505069 1543162702532670: Net:0xc463aaf0 Cwnd:25063 flt:22688 flt+acked:672598752 (atpc:24 npc:237) No Cwnd advance from CA (pc=f4f72484, sendcnt:191,strcnt:191) 815.505069 1543162702532670 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 815.515674 1543162702536420 fill_outqueue called on net:0xc463aaf0 cwnd:25063 flight:22688 (sendcnt:191,strcnt:191) 815.519424 1543162702574010 Network:0xc463aaf0 cwnd:25063 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.519424 1543162702574010 Network:0xc463aaf0 cwnd:25063 flight:24106 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.557014 1543162702575015 Send completes sending 672598752 (sendcnt:191,strcnt:191) 815.557014 1543162702575015 fill_outqueue called on net:0xc463aaf0 cwnd:25063 flight:24106 (sendcnt:191,strcnt:191) 815.558019 1543162702601505 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.558019 1543162702601505 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.584509 1543162702602510 Send completes sending 672598752 (sendcnt:191,strcnt:191) 815.585514 1543162702603575 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.585514 1543162702603575 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 815.585514 1543162702603575 Send completes sending 672598752 (sendcnt:191,strcnt:191) 815.586579 1543162702604775 Send completes sending 672598752 (sendcnt:191,strcnt:191) 815.586579 1543162702604775 Send completes sending 672598752 (sendcnt:191,strcnt:191) 815.587779 1543162707558555 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:25524 pq:f4f72484 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 815.587779 1543162707558555 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 820.298679 1543162707563820 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 820.298679 1543162707563820 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 820.298679 1543162707563820 Send completes sending 672598752 (sendcnt:191,strcnt:191) 820.303944 1543162707565155 Send completes sending 672598752 (sendcnt:191,strcnt:191) 820.303944 1543162707565155 Send completes sending 672598752 (sendcnt:191,strcnt:191) 820.305279 1543162721876580 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:25524 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 833.985216 1543162721879775:CWND No new cumack net:0xc463aaf0 cwnd:25063 flight:24106 aug:672598752 (sendcnt:191,strcnt:191) 833.985216 1543162721879775 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 833.988411 1543162721883525 fill_outqueue called on net:0xc463aaf0 cwnd:25063 flight:24106 (sendcnt:191,strcnt:191) 833.992161 1543162721917335 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 833.992161 1543162721917335 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 834.25971 1543162721918475 Send completes sending 672598752 (sendcnt:191,strcnt:191) 834.27111 1543162721919705 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 834.27111 1543162721919705 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 834.27111 1543162721919705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 834.27111 1543162721919705 Send completes sending 672598752 (sendcnt:191,strcnt:191) 834.28341 1543162721920965 Send completes sending 672598752 (sendcnt:191,strcnt:191) 834.29601 1543162758254895 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:25524 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 868.663371 1543162758258060:CWND No new cumack net:0xc463aaf0 cwnd:25063 flight:24106 aug:672598752 (sendcnt:191,strcnt:191) 868.663371 1543162758258060 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 868.666536 1543162758284280 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 868.666536 1543162758284280 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 868.692756 1543162758285360 Send completes sending 672598752 (sendcnt:191,strcnt:191) 868.692756 1543162758285360 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 868.693836 1543162758286470 Network:0xc463aaf0 cwnd:25063 flight:25524 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 868.693836 1543162758286470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 868.693836 1543162758286470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 868.693836 1543162758286470 Send completes sending 672598752 (sendcnt:191,strcnt:191) 868.694946 1543162759268055 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:25063 flight:25524 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 869.627955 1543162759270275:CWND No new cumack net:0xc463aaf0 cwnd:25063 flight:24106 aug:672598752 (sendcnt:191,strcnt:191) 869.627955 1543162759270275 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 869.630175 1543162759303305 Network:0xc463aaf0 cwnd:12531 flight:24106 pq:f4f7250d Log from a re-transmission tsn:28170ae0 (sendcnt:191,strcnt:191) 869.663205 1543162759304910 Network:0xc463aaf0 cwnd:12531 flight:24106 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 869.663205 1543162759304910 Network:0xc463aaf0 cwnd:12531 flight:24106 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 869.663205 1543162759304910 Send completes sending 672598752 (sendcnt:191,strcnt:191) 869.664810 1543162759305975 Send completes sending 672598752 (sendcnt:191,strcnt:191) 869.664810 1543162759305975 Send completes sending 672598752 (sendcnt:191,strcnt:191) 869.665875 1543162826230200 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:24106 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 933.481236 1543162826233140 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 933.484176 1543162826237025 Network:0xc463aaf0 cwnd:12531 flight:22688 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 933.484176 1543162826237025 Network:0xc463aaf0 cwnd:12531 flight:22688 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 933.484176 1543162826237025 Send completes sending 672598752 (sendcnt:191,strcnt:191) 933.488061 1543162826238075 Send completes sending 672598752 (sendcnt:191,strcnt:191) 933.488061 1543162826238075 Send completes sending 672598752 (sendcnt:191,strcnt:191) 933.489111 1543162839480315 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:22688 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 946.99863 1543162839483420 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 946.102968 1543162839487515 Network:0xc463aaf0 cwnd:12531 flight:21270 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 946.102968 1543162839487515 Network:0xc463aaf0 cwnd:12531 flight:21270 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 946.102968 1543162839487515 Send completes sending 672598752 (sendcnt:191,strcnt:191) 946.107063 1543162839488625 Send completes sending 672598752 (sendcnt:191,strcnt:191) 946.107063 1543162839488625 Send completes sending 672598752 (sendcnt:191,strcnt:191) 946.108173 1543162841379030 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:21270 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 947.950002 1543162841381835 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 947.952807 1543162841385765 Network:0xc463aaf0 cwnd:12531 flight:19852 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 947.952807 1543162841385765 Network:0xc463aaf0 cwnd:12531 flight:19852 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 947.952807 1543162841385765 Send completes sending 672598752 (sendcnt:191,strcnt:191) 947.956737 1543162841386830 Send completes sending 672598752 (sendcnt:191,strcnt:191) 947.956737 1543162841386830 Send completes sending 672598752 (sendcnt:191,strcnt:191) 947.957802 1543162847795265 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:19852 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 954.74781 1543162847797890 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 954.77406 1543162847801865 Network:0xc463aaf0 cwnd:12531 flight:18434 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 954.77406 1543162847801865 Network:0xc463aaf0 cwnd:12531 flight:18434 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 954.77406 1543162847801865 Send completes sending 672598752 (sendcnt:191,strcnt:191) 954.81381 1543162847802930 Send completes sending 672598752 (sendcnt:191,strcnt:191) 954.81381 1543162847802930 Send completes sending 672598752 (sendcnt:191,strcnt:191) 954.82446 1543162860475770 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:18434 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 966.123798 1543162860481050 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 966.129078 1543162860485055 Network:0xc463aaf0 cwnd:12531 flight:17016 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 966.129078 1543162860485055 Network:0xc463aaf0 cwnd:12531 flight:17016 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 966.129078 1543162860485055 Send completes sending 672598752 (sendcnt:191,strcnt:191) 966.133083 1543162860486075 Send completes sending 672598752 (sendcnt:191,strcnt:191) 966.133083 1543162860486075 Send completes sending 672598752 (sendcnt:191,strcnt:191) 966.134103 1543162863275325 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:17016 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 968.826201 1543162863277905 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 968.828781 1543162863281670 Network:0xc463aaf0 cwnd:12531 flight:15598 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 968.828781 1543162863281670 Network:0xc463aaf0 cwnd:12531 flight:15598 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 968.828781 1543162863281670 Send completes sending 672598752 (sendcnt:191,strcnt:191) 968.832546 1543162863282690 Send completes sending 672598752 (sendcnt:191,strcnt:191) 968.832546 1543162863282690 Send completes sending 672598752 (sendcnt:191,strcnt:191) 968.833566 1543162865953965 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:15598 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 971.359113 1543162865956875 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 971.362023 1543162865960670 Network:0xc463aaf0 cwnd:12531 flight:14180 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 971.362023 1543162865960670 Network:0xc463aaf0 cwnd:12531 flight:14180 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 971.362023 1543162865960670 Send completes sending 672598752 (sendcnt:191,strcnt:191) 971.365818 1543162865961735 Send completes sending 672598752 (sendcnt:191,strcnt:191) 971.365818 1543162865961735 Send completes sending 672598752 (sendcnt:191,strcnt:191) 971.366883 1543162869085140 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:14180 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 974.344560 1543162869087885 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 974.347305 1543162869091710 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 974.347305 1543162869091710 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 974.347305 1543162869091710 Send completes sending 672598752 (sendcnt:191,strcnt:191) 974.351130 1543162869092775 Send completes sending 672598752 (sendcnt:191,strcnt:191) 974.351130 1543162869092775 Send completes sending 672598752 (sendcnt:191,strcnt:191) 974.352195 1543162870771800 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:12762 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 975.982644 1543162870774365 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 975.985209 1543162870801140 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 975.985209 1543162870801140 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.11984 1543162870802280 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.13124 1543162870803405 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.13124 1543162870803405 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.13124 1543162870803405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.13124 1543162870803405 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.14249 1543162870804620 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.15464 1543162871790840 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:12762 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 976.953108 1543162871793900 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 976.956168 1543162871820525 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.956168 1543162871820525 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.982793 1543162871821620 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.983888 1543162871822685 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.983888 1543162871822685 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 976.983888 1543162871822685 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.983888 1543162871822685 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.984953 1543162871823990 Send completes sending 672598752 (sendcnt:191,strcnt:191) 976.986258 1543162885860540 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:12762 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 990.342744 1543162885863870 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 990.346074 1543162885890345 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 990.346074 1543162885890345 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 990.372549 1543162885891365 Send completes sending 672598752 (sendcnt:191,strcnt:191) 990.373569 1543162885892475 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 990.373569 1543162885892475 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 990.373569 1543162885892475 Send completes sending 672598752 (sendcnt:191,strcnt:191) 990.373569 1543162885892475 Send completes sending 672598752 (sendcnt:191,strcnt:191) 990.374679 1543162885893720 Send completes sending 672598752 (sendcnt:191,strcnt:191) 990.375924 1543162895420145 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:12762 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 999.465165 1543162895423235 Net:0xc463a000 at cwnd_event (SACK) cwnd:6000 flight:0 pq:f4f6f610 atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) 999.468255 1543162895449440 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 999.468255 1543162895449440 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 999.494460 1543162895450505 Send completes sending 672598752 (sendcnt:191,strcnt:191) 999.495525 1543162895451615 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 999.495525 1543162895451615 Network:0xc463aaf0 cwnd:12531 flight:12762 pq:f4f7250d Log from a Send tsn:28170ae0 (sendcnt:191,strcnt:191) 999.495525 1543162895451615 Send completes sending 672598752 (sendcnt:191,strcnt:191) 999.495525 1543162895451615 Send completes sending 672598752 (sendcnt:191,strcnt:191) 999.496635 1543162895452875 Send completes sending 672598752 (sendcnt:191,strcnt:191) 999.497895 1543162897833675 Net:0xc463aaf0 at cwnd_event (SACK) cwnd:12531 flight:12762 pq:f4f7250d atpc:24 needpc:237 (tsn:28170ae0,sendcnt:191,strcnt:191) From sandiegobiker at gmail.com Fri Jan 23 09:13:23 2009 From: sandiegobiker at gmail.com (Len Gross) Date: Fri Jan 23 09:13:29 2009 Subject: Proxy arp on a router? Message-ID: <27cb3ada0901230913g6ffe3beag90e0e103ebcf7af9@mail.gmail.com> A bit of a follow up. I was able to get proxying to work through use of sysctl, setting net.link.ether.inet.proxyall=1 This is mentioned in man 4 arp , not the usual man 8 arp, pages However, I never could get it working with individual apr -s commands. It could be I had a setup problem but I really tried MANY combinations of things. -- Len From per.hurtig at kau.se Sat Jan 24 02:18:38 2009 From: per.hurtig at kau.se (Per Hurtig (work)) Date: Sat Jan 24 02:18:46 2009 Subject: Dummynet modification causes watchdog timeout Message-ID: Hi, I've recently modified the dummynet soure code to perform some additional tasks (e.g. deterministic reordering support). However, while testing my modification, the following kernel message occurs: xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP The thing is, that this happens AFTER the whole experiment has been successfully conducted. Any ideas what might be the reason for this to happen? The code I've written is not very time consuming, and it does not "lock" the execution either. BR, Per H From lev at FreeBSD.org Sat Jan 24 02:53:51 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Sat Jan 24 02:54:04 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address Message-ID: <11410349378.20090124133733@serebryakov.spb.ru> Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured IP addresses are RANDOM and DIFFERENT on every restart. These IP addresses are not mentioned in ANY config file on my computer, and addresses on my network interfaces IS NOT from these networks. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! -- // Black Lion AKA Lev Serebryakov From lev at FreeBSD.org Sat Jan 24 03:29:26 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Sat Jan 24 03:29:32 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: <873658171.20090124142920@serebryakov.spb.ru> Hello, Lev. You wrote 24 ?????? 2009 ?., 13:37:33: > IP addresses are RANDOM and DIFFERENT on every restart. These IP > addresses are not mentioned in ANY config file on my computer, and > addresses on my network interfaces IS NOT from these networks. Ok, I'm stupid, it is root servers. Ok. But this knowledge doesn't help to fix problem :( > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( -- // Black Lion AKA Lev Serebryakov From doconnor at gsoft.com.au Sat Jan 24 04:23:52 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Jan 24 04:24:06 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: <200901242240.33321.doconnor@gsoft.com.au> On Saturday 24 January 2009 21:07:33 Lev Serebryakov wrote: > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: > > Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: > unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: > 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:11 >1: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert > errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway ... > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect > to two providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I think this is an mpd problem - I had the same issue and I couldn't find a solution. In the end I switched to userland PPP (which has an issue with PF but you can work around that). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090124/2888b106/attachment.pgp From yonyossef.lists at gmail.com Sat Jan 24 04:55:42 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Sat Jan 24 04:55:49 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available Message-ID: <000001c97e23$0d81df20$39ed1aac@mtl.com> Hi All, I'm facing a temporary network hang on my interfaces following a flood ping/stress udp test. I'm running a netperf UDP test which is giving results but does not return to the shell. client output: UDP UNIDIRECTIONAL SEND TEST from fe80::202:c9ff:fe02:e1fe%mtnic0 (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to fe80::202:c9ff:fe02:e1f4%mt nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 32768 1472 10.02 547428 1694280 643.60 32768 10.02 25089 29.50 (HANG) After a minute or two it returns to the shell with the following message: shutdown_control: no response received errno 55 20 minutes later (!!) the interface is working again. netstat -m and vmstat -z outputs during the hang time: # netstat -m 25687/6578/32265 mbufs in use (current/cache/total) 17404/2438/19842/65536 mbuf clusters in use (current/cache/total/max) 0/1024 mbuf+clusters out of packet secondary zone in use (current/cache) 2071/1369/3440/65536 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 49513K/11996K/61510K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines You have new mail in /var/mail/root # vmstat -z | grep mbuf ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256, 0, 0, 1024, 1497, 0 mbuf: 256, 0, 25687, 5554, 21208920, 0 mbuf_cluster: 2048, 65536, 18428, 1414, 149349, 0 mbuf_jumbo_pagesize: 4096, 65536, 2071, 1369, 17050312, 0 mbuf_jumbo_9k: 9216, 65536, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 # uname -a FreeBSD sw260.lab.mtl.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Dec 29 11:00:24 UTC 2008 root@sw259.lab.mtl.com:/usr/obj/usr/src.dbg/sys/GENERIC.KDB amd64 The fact that the interface is coming back to life without any driver activity indicates an OS bug. Thanks, Yony From lev at FreeBSD.org Sat Jan 24 05:24:11 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Sat Jan 24 05:24:18 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901242240.33321.doconnor@gsoft.com.au> References: <11410349378.20090124133733@serebryakov.spb.ru> <200901242240.33321.doconnor@gsoft.com.au> Message-ID: <1708297021.20090124162408@serebryakov.spb.ru> Hello, Daniel. You wrote 24 ?????? 2009 ?., 15:10:24: >> Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect >> to two providers. >> >> But previous installation (on faster hardware) doesn't show these >> errors at all! > I think this is an mpd problem - I had the same issue and I couldn't find a > solution. In the end I switched to userland PPP (which has an issue with PF > but you can work around that). userland ppp doesn't support l2tp :( -- // Black Lion AKA Lev Serebryakov From rpaulo at freebsd.org Sat Jan 24 08:20:12 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Jan 24 08:20:43 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available In-Reply-To: <000001c97e23$0d81df20$39ed1aac@mtl.com> References: <000001c97e23$0d81df20$39ed1aac@mtl.com> Message-ID: On 24 Jan 2009, at 12:54, Yony Yossef wrote: > Hi All, > > I'm facing a temporary network hang on my interfaces following a flood > ping/stress udp test. > > I'm running a netperf UDP test which is giving results but does not > return > to the shell. > client output: > > UDP UNIDIRECTIONAL SEND TEST from fe80::202:c9ff:fe02:e1fe%mtnic0 > (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to > fe80::202:c9ff:fe02:e1f4%mt > nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6 > Socket Message Elapsed Messages > Size Size Time Okay Errors Throughput > bytes bytes secs # # 10^6bits/sec > > 32768 1472 10.02 547428 1694280 643.60 > 32768 10.02 25089 29.50 > > > (HANG) > > After a minute or two it returns to the shell with the following > message: > shutdown_control: no response received errno 55 > > 20 minutes later (!!) the interface is working again. > > netstat -m and vmstat -z outputs during the hang time: > > # netstat -m > 25687/6578/32265 mbufs in use (current/cache/total) > 17404/2438/19842/65536 mbuf clusters in use (current/cache/total/max) > 0/1024 mbuf+clusters out of packet secondary zone in use (current/ > cache) > 2071/1369/3440/65536 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 49513K/11996K/61510K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines I think there are too many mbufs in use. You're probably facing an mbuf leakage and that causes an interface hang. -- Rui Paulo From mg at fork.pl Sat Jan 24 14:45:55 2009 From: mg at fork.pl (Marcin Gryszkalis) Date: Sat Jan 24 14:46:03 2009 Subject: FreeBSD 7.1 - syncache, tcp queue Message-ID: <200901242326.20595.mg@fork.pl> I upgraded 2 machines to 7.1 (i386 and amd64) - both are running nginx web server and both are experiencing problem with resetting connections. c -> s TCP 56473 > 80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=173160194 TSER=0 WS=6 s -> c TCP 80 > 56473 [SYN, ACK] Seq=0 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=3 TSV=2680138265 TSER=173160194 c -> s TCP 56473 > 80 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=173160239 TSER=2680138265 s -> c TCP 80 > 56473 [RST] Seq=1 Win=0 [TCP CHECKSUM INCORRECT] Len=0 s -> c HTTP GET / HTTP/1.0 ... on the i386 I can see in debug log: kernel: TCP: [83.6.208.139]:1909 to [62.233.226.70]:80; syncache_socket: Socket create failed due to limits or memory shortage kernel: TCP: [83.6.208.139]:1909 to [62.233.226.70]:80 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST syncache.count is 0: 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 and it seems that reason for the problem is that listen queue is overflown: Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 193/0/128 10.2.3.1.80 I increased kern.ipc.somaxconn as temporary solution. netstat shows many (~193 - like the queue length) connections, mostly in CLOSED state (why aren't they purged?) I found some discussions about syncache changes in freebsd-net and other places but I'm not sure if my problem is known. Is there and reasoning and solution? regards -- Marcin Gryszkalis, PGP 0x9F183FA3 jabber jid:mg@fork.pl, gg:2532994 http://the.fork.pl From dougb at FreeBSD.org Sat Jan 24 15:10:17 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Jan 24 15:10:23 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: <497B9FF4.30605@FreeBSD.org> Lev Serebryakov wrote: > Hello, Freebsd-stable. > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > fake addresses to vr2 and vr3 doesn't help at all. > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two > providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named Doug -- This .signature sanitized for your protection From Mark_Andrews at isc.org Sat Jan 24 17:13:54 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat Jan 24 17:14:00 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: Your message of "Sat, 24 Jan 2009 15:10:44 -0800." <497B9FF4.30605@FreeBSD.org> Message-ID: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> In message <497B9FF4.30605@FreeBSD.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From doconnor at gsoft.com.au Sat Jan 24 21:07:19 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Jan 24 21:07:42 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> Message-ID: <200901251537.07249.doconnor@gsoft.com.au> On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: > > I've never used mpd myself, but you might want to try adding the > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > # BEFORE: named > > mpd should also be fixed as the error code being returned is not > approprate. network unreachable is what should be returned. I'm not sure that is the whole problem - I found that it would return device not configured 'permanently' when I was using it. The link would be up (apparently) but nothing passes. Sometimes restarting it would fix it but other times it just persistently said the same thing. It seemed like there was some kernel state that was incorrect and even restarting mpd would not fix it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090125/4999bf11/attachment.pgp From Michael.Tuexen at lurchi.franken.de Sun Jan 25 03:14:26 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Sun Jan 25 03:15:02 2009 Subject: A query regarding SCTP congestion control In-Reply-To: <7059EA19D7837E44A3BA7DAB464944B39BA45E03AB@XMAIL5.sooner.net.ou.edu> References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> <48060748.1090807@cisco.com> <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> <7059EA19D7837E44A3BA7DAB464944B39BA45E03AB@XMAIL5.sooner.net.ou.edu> Message-ID: Hi Sazzad, what is the value of the from field i the structure sctp_cwnd_log? Best reards Michael On Jan 23, 2009, at 1:16 AM, Rahman, Md Sazzadur wrote: > Hi Randall, > > Thanks for your suggestions. I could collect congestion window data > from SCTP sender using SCTP_LOCAL_TRACE_BUF on FreeBSD7.1 kernel > using the tools you provided (dump_apple_log.c, prtcwndlog.c etc.). > Now, in the log, I found that tsn (Transmission Sequence Number) > never changes and remains fixed which is not supposed to happen, I > believe. Do you have any idea what could go wrong? > > > For example, in the log below, tsn is always 28170ae0. > > //-From Log------------------------------- > 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight: > 12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight: > 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > .............. > ............. > 2592.987776 1543168861292865 Network:0xc463aaf0 cwnd:13063 flight: > 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > > //---------------------------------------------- > > Steps I have followed: > > //---------------------------------------------- > 1. Recompiled FreeBSD7.1 kernel by enabling SCTP_LOCAL_TRACE_BUF > #define SCTP_LOCAL_TRACE_BUF 1 > > 2. Enalble desired loging using sysctl; > Sysctl -w "net.inet.sctp.log_level=0x00000004 > > 3. Run application that sends SCTP data to the network > > 4. ./Dump_apple_log > data.txt > > 5. ./Prtcwdlog -l data.txt> cwnd.txt > //---------------------------------------------- > > I have attached the log file herewith this mail. > > It would be great if you can give me any hint to resolve this issue. > > > > Thanks, > Sazzad > > -----Original Message----- > From: Randy Stewart [mailto:randall@lakerest.net] > Sent: Thursday, August 28, 2008 6:39 AM > To: sazzadur rahman > Cc: freebsd-net; Atiquzzaman, Mohammed; Rahman, Md Sazzadur > Subject: Re: A query regarding SCTP congestion control > > Remember a lot has changed between the book and now. > > 1) The initial window is now different > 2) labc variable may influence how the cwnd responds > > are just 2 off the top of my head. > > You also may want to use a local trace buffer (as I mentioned earlier) > since > turning KTR on really really skew's things time wise.. its a resource > pig. > > We added the local trace buffer for this very reason. > > Contact me directly if you need guidance on this. Also you may want > to pick up the latest update that I just put up on www.sctp.org > > It gets the 7.0 stack current to 8.0's code.. .and there have > been at least 1 CC fix in the last few months.. > > R > On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: > >> Hello, >> I need to get SCTP congestion window data for research purpose. I >> collected >> cwnd data from SCTP sender running on FreeBSD 7.0 machine by using >> KTR >> kernel log. After that, I tried to plot cwnd vs. time and generated >> graph. >> But I am unable to explain the graph and it is very different >> compared to >> the graph as shown in the book "Stream Control Transmission Protocol >> (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP >> congestion window. An typical entry from the log looks like: >> >> 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 >> flight:0 pq:0 >> atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) >> >> I have used 749199232185105 in x axis as time and cwnd:25140 in y >> axis. I >> have attached the image file of the graph herewith this mail. >> >>> From the log, I found that cwnd varies very frequently accross >>> time. Does >> anyone have any idea regarding this issue? >> Please let me know if you have any questions further. >> >> Thanks in advance. >> >> Best regards, >> Md Sazzadur Rahman >> Graduate Student, >> School of Computer Science, >> University of Oklahoma, >> Norman, Oklahoma, USA >> >> Steps for getting kernel log >> >> ------------------------------------------ >> >> 1. Add options: >> >> options KTR >> >> options KTR_ENTRIES=65536 >> >> options KTR_MASK=KTR_SUBSYS >> >> >> 2. Recompile kernel >> >> config CUSTOM_KERNEL_9_6 >> >> cd ../compile/ CUSTOM_KERNEL_9_6 >> >> make cleandepend;make depend; >> >> make all install >> >> 3. Tried to enable trace point by: >> >> Sysctl -w "net.inet.sctp.log_level=0x00000004" >> >> 4. run SCTP sender. >> >> 5. pull out data: >> >> Ktrdump -q -t -o file_name >> >> Prtcwndlog -l filename > cwnd.txt >> >> --------------------------------------------------- >> >> >> >> On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart >> wrote: >> >>> Rahman, Md Sazzadur wrote: >>> >>>> Hi, I would like to get the values of SCTP congestion control >>>> algorithm variables (cwnd, ssthresh, flightsize and pba) from any >>>> SCTP based application in runtime for research purpose. Does any >>>> API >>>> exist in SCTP for that? Do I need to dig the SCTP code in kernel >>>> to >>>> get the values? >>>> >>> >>> There is a socket option to get the cwnd. >>> >>> However, I think what you really want is some of the researchish >>> tracing stuff that SCTP provides. >>> >>> You can actually get a real time trace of the cwnd/flight etc via >>> the >>> various logging functions. >>> >>> You basically must compile this as an option.. have to go look >>> at the options.. >>> >>> And then you can either use ktrace (which I don't recommend since >>> it turns on to much overhead in the kernel) or you can >>> use SCTP_LOCAL_TRACE_BUF >>> >>> This will put it into a piece of memory only for SCTP and >>> not turn on all the other ktrace points. >>> >>> After you enable the logging in your compile you must turn >>> on the logging level.. >>> >>> SCTP_CWND_LOGGING_ENABLE >>> >>> woudl be my recommendation. >>> >>> It gives you a real time up/down growth of the cwnd/flight/rwnd >>> >>> I think I wrote a "how to" somewhere.. let me go look.. >>> >>> R >>> >>> >>> >>>> I will appreciate any help in this regard. >>>> >>>> Best Regards, Md Sazzadur Rahman Graduate Student, School of >>>> Computer >>>> Science, University of Oklahoma, Norman, Oklahoma, USA >>>> >>>> _______________________________________________ freebsd-net@freebsd.orgmailing >>>> list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To >>>> unsubscribe, >>>> send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>>> >>> >>> -- >>> Randall Stewart >>> NSSTG - Cisco Systems Inc. >>> 803-345-0369 803-317-4952 (cell) >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" > > ----- > Randall Stewart > randall@lakerest.net > > > > > _______________________________________________ > 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 lists.br at gmail.com Sun Jan 25 04:31:46 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Sun Jan 25 04:33:59 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address References: <11410349378.20090124133733@serebryakov.spb.ru><200901242240.33321.doconnor@gsoft.com.au> <1708297021.20090124162408@serebryakov.spb.ru> Message-ID: > > Hello, Daniel. > You wrote 24 ?????? 2009 ?., 15:10:24: > >>> Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to >>> connect >>> to two providers. >>> >>> But previous installation (on faster hardware) doesn't show these >>> errors at all! >> I think this is an mpd problem - I had the same issue and I couldn't find >> a >> solution. In the end I switched to userland PPP (which has an issue with >> PF >> but you can work around that). > userland ppp doesn't support l2tp :( Lev, you can try the net/pptpclient port. server side works fine with net/poptop port. eventually some workaround is needed, but nothing scary. luiz From smithi at nimnet.asn.au Sun Jan 25 07:30:18 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Jan 25 07:30:25 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901251537.07249.doconnor@gsoft.com.au> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> <200901251537.07249.doconnor@gsoft.com.au> Message-ID: <20090126002703.J90458@sola.nimnet.asn.au> On Sun, 25 Jan 2009, Daniel O'Connor wrote: > On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: Doug Barton wrote: > > > I've never used mpd myself, but you might want to try adding the > > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > > > # BEFORE: named This doesn't help in the case where mpd may take seconds to negotiate with $provider for a link; always the case on ADSL here anyway, moreso for dialup. The rc.d script exits after launching mpd, so named will still start 'right away' while mpd - or ppp - is still negotiating. I 'solved' this chicken-and-egg by adding an ugly sleep 7 after starting (mpd &) before exiting the script. Haven't bothered refining what works once a month or two, but the sleep could be killed by pid from an mpd-up script as soon as there's a working link. (mpd 4.1 if it matters) > > mpd should also be fixed as the error code being returned is not > > approprate. network unreachable is what should be returned. It's not mpd's error, or message; named knows nothing about mpd, but does like its specified listen and *-source addresses to exist. This one looks more like a ill-worded 'no route to host' indication perhaps? Or trying to listen on the address of the (yet to exist) ng interface? > I'm not sure that is the whole problem - I found that it would return device > not configured 'permanently' when I was using it. The link would be up > (apparently) but nothing passes. Sometimes restarting it would fix it but > other times it just persistently said the same thing. > > It seemed like there was some kernel state that was incorrect and even > restarting mpd would not fix it. I've found named requires a proper /etc/rc.d/named stop / start cycle after all required interfaces are up and there's a default route, here, and that sleep 7 obviates that for me .. but it's hardly elegant. cheers, Ian From sandiegobiker at gmail.com Sun Jan 25 10:09:46 2009 From: sandiegobiker at gmail.com (Len Gross) Date: Sun Jan 25 10:09:53 2009 Subject: MTU or Fragmentation Problems on 7.0? Message-ID: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> The following configuration works fine _until_ I make a change in MTU setting on the link between FreeBSD1 and FreeBSD2 Internet | Router x.x.x.x 192.168.0.1/16 | FreeBSD #1 192.168.0.202 /16 6.3 192.168.1.1/ 24 | FreeBSD #2 192.168.1.2/24 7.0 192.168.1.5/24 | FreeBSD #3 192.168.5.2/24 7.0 All connections are Ethernet. If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to work, BUT browsing on FreeBSD3 "fails" (mostly.) On FreeBSD 3 Ping and nslookup work fine from FreeBSD3 I can get to Google but virtually no other web sites Using tcpdump there is lots of unusual stuff, some relating to fragmentation ICMP? If I put a Web Proxy on FreeBSD 1, everything works fine. I have tried putting mtu = 1450 using route change on all the routes, but that didn't help. When I did this I verified all routes had 1450 mtu via netstat ?arW So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or ??? Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox runs fine there (There was a thread in October about mtu issues in 7.0 but it didn't seem to help my problem.) (I run 1450 MTU to support testing of an experimental protocol., but all the above is with straight out of the box FreeBSD.) -- Len From webadmin at users.com Sun Jan 25 10:52:00 2009 From: webadmin at users.com (WEBMAIL MANAGEMENT TEAM) Date: Sun Jan 25 10:52:07 2009 Subject: WEBMASTER ADMIN (ANTI SPAM UPDATE) Message-ID: <200901251818.n0PIIl1k020744@web2.psoft.rentech.net> Dear Webmail User, ANTI SPAM UPDATE This message is from WEBMAIL MANAGEMENT MESSAGING CENTER to all Webmail account users. We are currently upgrading our data base and webmail account center. This is to enable your webmail account take a new look with new functions and help protect against spam e-mails. We are therefore deleting all unused email account to create more space for new accounts and updates. To help us fight spam and to prevent your account from closing you will have to update it below so that we will know that it's an active account. CONFIRM YOUR EMAIL IDENTITY BELOW Email Username: EMAIL Password: Date of Birth: Alternative Email: WARNING!!! All account owner that refuses to comply with this update will lose his or her within three days of receiving this notice. Thank you for your understanding. Bringing communication closer to you. WEBMAIL ADMIN From sazzad at ou.edu Sun Jan 25 11:03:02 2009 From: sazzad at ou.edu (Rahman, Md Sazzadur) Date: Sun Jan 25 11:03:09 2009 Subject: A query regarding SCTP congestion control In-Reply-To: References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> <48060748.1090807@cisco.com> <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> <7059EA19D7837E44A3BA7DAB464944B39BA45E03AB@XMAIL5.sooner.net.ou.edu> Message-ID: <7059EA19D7837E44A3BA7DAB464944B39BA45E041A@XMAIL5.sooner.net.ou.edu> Hi Michael, Thanks for your reply. From the log, I found that the values of from field of sctp_cwnd_log are: /* 32 */ "No Cwnd advance from CA", /* 61 */ "Log from a Send", /* 64 */ "Log from SACK", /* 68 */ "chunk output completes", /* 69 */ "fill_out_queue_called", I have only tried to investigate the cwnd value when the from field value is: /* 61 */ "Log from a Send" and found that tsn never changes :( although cwnd and flight size values change over time. Please let me know if you have any hint to resolve this problem. Thanks, Sazzad. -----Original Message----- From: Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] Sent: Sunday, January 25, 2009 5:14 AM To: Rahman, Md Sazzadur Cc: Randy Stewart; freebsd-net; Atiquzzaman, Mohammed Subject: Re: A query regarding SCTP congestion control Hi Sazzad, what is the value of the from field i the structure sctp_cwnd_log? Best reards Michael On Jan 23, 2009, at 1:16 AM, Rahman, Md Sazzadur wrote: > Hi Randall, > > Thanks for your suggestions. I could collect congestion window data > from SCTP sender using SCTP_LOCAL_TRACE_BUF on FreeBSD7.1 kernel > using the tools you provided (dump_apple_log.c, prtcwndlog.c etc.). > Now, in the log, I found that tsn (Transmission Sequence Number) > never changes and remains fixed which is not supposed to happen, I > believe. Do you have any idea what could go wrong? > > > For example, in the log below, tsn is always 28170ae0. > > //-From Log------------------------------- > 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight: > 12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight: > 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > .............. > ............. > 2592.987776 1543168861292865 Network:0xc463aaf0 cwnd:13063 flight: > 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: > 191) > > //---------------------------------------------- > > Steps I have followed: > > //---------------------------------------------- > 1. Recompiled FreeBSD7.1 kernel by enabling SCTP_LOCAL_TRACE_BUF > #define SCTP_LOCAL_TRACE_BUF 1 > > 2. Enalble desired loging using sysctl; > Sysctl -w "net.inet.sctp.log_level=0x00000004 > > 3. Run application that sends SCTP data to the network > > 4. ./Dump_apple_log > data.txt > > 5. ./Prtcwdlog -l data.txt> cwnd.txt > //---------------------------------------------- > > I have attached the log file herewith this mail. > > It would be great if you can give me any hint to resolve this issue. > > > > Thanks, > Sazzad > > -----Original Message----- > From: Randy Stewart [mailto:randall@lakerest.net] > Sent: Thursday, August 28, 2008 6:39 AM > To: sazzadur rahman > Cc: freebsd-net; Atiquzzaman, Mohammed; Rahman, Md Sazzadur > Subject: Re: A query regarding SCTP congestion control > > Remember a lot has changed between the book and now. > > 1) The initial window is now different > 2) labc variable may influence how the cwnd responds > > are just 2 off the top of my head. > > You also may want to use a local trace buffer (as I mentioned earlier) > since > turning KTR on really really skew's things time wise.. its a resource > pig. > > We added the local trace buffer for this very reason. > > Contact me directly if you need guidance on this. Also you may want > to pick up the latest update that I just put up on www.sctp.org > > It gets the 7.0 stack current to 8.0's code.. .and there have > been at least 1 CC fix in the last few months.. > > R > On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: > >> Hello, >> I need to get SCTP congestion window data for research purpose. I >> collected >> cwnd data from SCTP sender running on FreeBSD 7.0 machine by using >> KTR >> kernel log. After that, I tried to plot cwnd vs. time and generated >> graph. >> But I am unable to explain the graph and it is very different >> compared to >> the graph as shown in the book "Stream Control Transmission Protocol >> (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP >> congestion window. An typical entry from the log looks like: >> >> 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 >> flight:0 pq:0 >> atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) >> >> I have used 749199232185105 in x axis as time and cwnd:25140 in y >> axis. I >> have attached the image file of the graph herewith this mail. >> >>> From the log, I found that cwnd varies very frequently accross >>> time. Does >> anyone have any idea regarding this issue? >> Please let me know if you have any questions further. >> >> Thanks in advance. >> >> Best regards, >> Md Sazzadur Rahman >> Graduate Student, >> School of Computer Science, >> University of Oklahoma, >> Norman, Oklahoma, USA >> >> Steps for getting kernel log >> >> ------------------------------------------ >> >> 1. Add options: >> >> options KTR >> >> options KTR_ENTRIES=65536 >> >> options KTR_MASK=KTR_SUBSYS >> >> >> 2. Recompile kernel >> >> config CUSTOM_KERNEL_9_6 >> >> cd ../compile/ CUSTOM_KERNEL_9_6 >> >> make cleandepend;make depend; >> >> make all install >> >> 3. Tried to enable trace point by: >> >> Sysctl -w "net.inet.sctp.log_level=0x00000004" >> >> 4. run SCTP sender. >> >> 5. pull out data: >> >> Ktrdump -q -t -o file_name >> >> Prtcwndlog -l filename > cwnd.txt >> >> --------------------------------------------------- >> >> >> >> On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart >> wrote: >> >>> Rahman, Md Sazzadur wrote: >>> >>>> Hi, I would like to get the values of SCTP congestion control >>>> algorithm variables (cwnd, ssthresh, flightsize and pba) from any >>>> SCTP based application in runtime for research purpose. Does any >>>> API >>>> exist in SCTP for that? Do I need to dig the SCTP code in kernel >>>> to >>>> get the values? >>>> >>> >>> There is a socket option to get the cwnd. >>> >>> However, I think what you really want is some of the researchish >>> tracing stuff that SCTP provides. >>> >>> You can actually get a real time trace of the cwnd/flight etc via >>> the >>> various logging functions. >>> >>> You basically must compile this as an option.. have to go look >>> at the options.. >>> >>> And then you can either use ktrace (which I don't recommend since >>> it turns on to much overhead in the kernel) or you can >>> use SCTP_LOCAL_TRACE_BUF >>> >>> This will put it into a piece of memory only for SCTP and >>> not turn on all the other ktrace points. >>> >>> After you enable the logging in your compile you must turn >>> on the logging level.. >>> >>> SCTP_CWND_LOGGING_ENABLE >>> >>> woudl be my recommendation. >>> >>> It gives you a real time up/down growth of the cwnd/flight/rwnd >>> >>> I think I wrote a "how to" somewhere.. let me go look.. >>> >>> R >>> >>> >>> >>>> I will appreciate any help in this regard. >>>> >>>> Best Regards, Md Sazzadur Rahman Graduate Student, School of >>>> Computer >>>> Science, University of Oklahoma, Norman, Oklahoma, USA >>>> >>>> _______________________________________________ freebsd-net@freebsd.orgmailing >>>> list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To >>>> unsubscribe, >>>> send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>>> >>> >>> -- >>> Randall Stewart >>> NSSTG - Cisco Systems Inc. >>> 803-345-0369 803-317-4952 (cell) >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net- >>> unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" > > ----- > Randall Stewart > randall@lakerest.net > > > > > _______________________________________________ > 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 freebsd at chrisbuechler.com Sun Jan 25 15:54:52 2009 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Sun Jan 25 15:54:59 2009 Subject: Blackberry Bold on FreeBSD ath AP not working In-Reply-To: <496171A3.8030000@chrisbuechler.com> References: <496171A3.8030000@chrisbuechler.com> Message-ID: <497CF755.1070602@chrisbuechler.com> Chris Buechler wrote: > Has anyone ever tried connecting a Blackberry Bold to a FreeBSD access > point using an Atheros card? The card is an Atheros 5212, using > FreeBSD 7.0. Every other wireless device that has been tried on this > network works fine, but this Blackberry connects, gets a DHCP lease, > and then sends ARP requests that get no reply. Update: this is caused by powersave being broken. Fix posted by Bill Paul here: http://thread.gmane.org/gmane.os.freebsd.current/110707 fixes this problem. Chris From smithi at nimnet.asn.au Sun Jan 25 21:51:48 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Jan 25 21:51:56 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> Message-ID: <20090126164357.F90458@sola.nimnet.asn.au> On Sun, 25 Jan 2009, Len Gross wrote: > The following configuration works fine _until_ I make a change in MTU > setting on the link between FreeBSD1 and FreeBSD2 > > Internet > | > Router x.x.x.x > 192.168.0.1/16 > | > FreeBSD #1 192.168.0.202 /16 > 6.3 192.168.1.1/ 24 > | > FreeBSD #2 192.168.1.2/24 > 7.0 192.168.1.5/24 > | > FreeBSD #3 192.168.5.2/24 > 7.0 > > All connections are Ethernet. > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > work, BUT browsing on FreeBSD3 "fails" (mostly.) > > On FreeBSD 3 > Ping and nslookup work fine from FreeBSD3 > I can get to Google but virtually no other web sites > Using tcpdump there is lots of unusual stuff, some relating to > fragmentation ICMP? Do any of these machines have a firewall rule blocking ICMP? You want to be sure at least icmptypes 3,11 are flowing freely to/from FreeBSD3, as well as pings (icmptypes 0,8) which are apparently permitted. cheers, Ian > If I put a Web Proxy on FreeBSD 1, everything works fine. > > I have tried putting mtu = 1450 using route change on all the routes, > but that didn't help. > When I did this I verified all routes had 1450 mtu via netstat ?arW > > So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or ??? > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > runs fine there > > (There was a thread in October about mtu issues in 7.0 but it didn't > seem to help my problem.) > (I run 1450 MTU to support testing of an experimental protocol., but > all the above is with straight out of the box FreeBSD.) > > -- Len From bzeeb-lists at lists.zabbadoz.net Mon Jan 26 01:40:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jan 26 01:40:20 2009 Subject: Need testers for a network cleanup patch In-Reply-To: <20090122225404.U45399@maildrop.int.zabbadoz.net> References: <20090122225404.U45399@maildrop.int.zabbadoz.net> Message-ID: <20090126093817.H45399@maildrop.int.zabbadoz.net> On Thu, 22 Jan 2009, Bjoern A. Zeeb wrote: Hi, > while cleaning up protosw things I found that rip6_output was most > likely never called from pr_output and after a short talk with Robert > the conclusion was that the same had been true for rip_output. > > Before I am going to remove the initializations I made the two > rip{,6}_output functions calling panic(). > > I have a patch for HEAD here: > http://people.freebsd.org/~bz/20090122-03-pr_output.diff > > and one for 7-STABLE here (compiled but not booted): > http://people.freebsd.org/~bz/20090122-04-pr_output-7STABLE.diff > > > I am confident it will not panic (at least for HEAD;) but not 100% > sure so you can run this on your test or devel machine but I'd not > run it on a production machine. > > If you are going to use the 7-STABLE patch make sure to have debugging > support in your kernel as well so we could get backtraces in the > unlikely event of panic. > > > Please reply directly to me if you have (un)successfully run the > patch and do NOT to the lists. > In case you think you run it successfully mail me after a > 2-3 days, and _not_ with an "it booted" message! ;-) In case you tested, please let me know. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bugmaster at FreeBSD.org Mon Jan 26 03:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 26 03:08:31 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200901261106.n0QB6xRb024331@freefall.freebsd.org> 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/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130605 net [tcp] Certain hardware produces "Network is unreachabl 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 bin/130159 net [patch] ppp(8) fails to correctly set routes 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/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [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 [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126924 net [an] [patch] printf -> device_printf and simplify prob 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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] internet control accesses beyond end of structu 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 kern/121983 net [fxp] fxp0 MBUF and PAE 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116444 net [ath] Atheros 5005G (AR5212) miniPCI: unable to attach o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [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 interface given in rc.conf not taking a o kern/106974 net [bge] packet loose and linkup problem 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/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/103059 net [bce] [patch] "Error mapping mbuf into TX chain!" (ten o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/100839 net [txp] txp driver inconsistently stops working when the 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 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 o 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 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/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter 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 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/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 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/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 256 problems total. From vanhu at FreeBSD.org Mon Jan 26 05:45:13 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Mon Jan 26 05:45:21 2009 Subject: [Patch for review] Experimental NAT-T + PFKey cleanup In-Reply-To: <20090121100244.M45399@maildrop.int.zabbadoz.net> References: <20090121095507.GB36716@zeninc.net> <20090121100244.M45399@maildrop.int.zabbadoz.net> Message-ID: <20090126135327.GA35595@zeninc.net> On Wed, Jan 21, 2009 at 10:12:32AM +0000, Bjoern A. Zeeb wrote: [....] > >Ipsec-tools team has still not decided how such compatibility issues > >will be handled (or not...), any (good) idea is welcome ! > > While this seems to be a big concern and there is compat breakage with > this patchset already, could we just finish the thing and also add the > second OA to not have to go through another round of breakage at a > later time? > > I checked the patch and I still can only see one NAT_T_OA which does > not work in the double NAT scenario as I have stated multiple times in > the past. See RFC3947, 5.2., Example 2. I guess that part didn't changed because quite no one (including myself) really worked on providing a full and working patch (on userland and on at least one kernel implementation) for NAT-OA. But yes, reading RFC3947 is enough to see that we do need TWO NAT-OA sent from userland to kernel, so we can at least have an API ready to carry them. > As said before I am currently caring less that the functionality > behind this is implemented but want to make sure we do not need to > break APIs again at a later time to add this and thus giving us way > more pain then. I agree. Breaking a probably unused part of the API is probably not as important as breaking a widely used other part of the API, but as we do already known the issue, we can at least fix the API part, even if there is still no code which uses it. And this may have a side effect: helping us detect NAT-T code at comile time: if (for example) SADB_X_EXT_NAT_T_OAI and SADB_X_EXT_NAT_T_OAR do exist, we do have an "up to date" NAT-T kernel code, and if they don't exist we do know that we are using an older version of the code (well, may not be so easy on Linux, as none of ipsec-tools devs has commit bit on Linux). Yvan. From gnn at freebsd.org Mon Jan 26 09:53:16 2009 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Jan 26 09:53:59 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available In-Reply-To: References: <000001c97e23$0d81df20$39ed1aac@mtl.com> Message-ID: <7iocxu7y4x.wl%gnn@neville-neil.com> At Sat, 24 Jan 2009 16:20:06 +0000, Rui Paulo wrote: > > > On 24 Jan 2009, at 12:54, Yony Yossef wrote: > > > Hi All, > > > > I'm facing a temporary network hang on my interfaces following a flood > > ping/stress udp test. > > > > I'm running a netperf UDP test which is giving results but does not > > return > > to the shell. > > client output: > > > > UDP UNIDIRECTIONAL SEND TEST from fe80::202:c9ff:fe02:e1fe%mtnic0 > > (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to > > fe80::202:c9ff:fe02:e1f4%mt > > nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6 > > Socket Message Elapsed Messages > > Size Size Time Okay Errors Throughput > > bytes bytes secs # # 10^6bits/sec > > > > 32768 1472 10.02 547428 1694280 643.60 > > 32768 10.02 25089 29.50 > > > > > > (HANG) > > > > After a minute or two it returns to the shell with the following > > message: > > shutdown_control: no response received errno 55 > > > > 20 minutes later (!!) the interface is working again. > > > > netstat -m and vmstat -z outputs during the hang time: > > > > # netstat -m > > 25687/6578/32265 mbufs in use (current/cache/total) > > 17404/2438/19842/65536 mbuf clusters in use (current/cache/total/max) > > 0/1024 mbuf+clusters out of packet secondary zone in use (current/ > > cache) > > 2071/1369/3440/65536 4k (page size) jumbo clusters in use > > (current/cache/total/max) > > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > 49513K/11996K/61510K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/0/0 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > 0 calls to protocol drain routines > > I think there are too many mbufs in use. You're probably facing an > mbuf leakage and that causes an interface hang. > If this is a large memory machine try upping the number of clusters and mbufs. On 64 bit systems with large memories 1,000,000 mbufs is not unheard of. kern.ipc.nmbclusters: 1000000 Also, with UDP you can easily overrun different buffers within the system. You might also look at: netstat -id and see if the driver is dropping packets, and if so you might up its send queue. Best, George From doconnor at gsoft.com.au Mon Jan 26 10:33:39 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Jan 26 10:33:53 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> Message-ID: <45fe2314-36e7-4ac2-ab8a-959a3ebdf52a@exchange01.ecp.noc> On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: > > I've never used mpd myself, but you might want to try adding the > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > # BEFORE: named > > mpd should also be fixed as the error code being returned is not > approprate. network unreachable is what should be returned. I'm not sure that is the whole problem - I found that it would return device not configured 'permanently' when I was using it. The link would be up (apparently) but nothing passes. Sometimes restarting it would fix it but other times it just persistently said the same thing. It seemed like there was some kernel state that was incorrect and even restarting mpd would not fix it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090126/773b281b/attachment.pgp From lev at FreeBSD.org Mon Jan 26 10:41:47 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon Jan 26 10:42:18 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901242240.33321.doconnor@gsoft.com.au> References: <11410349378.20090124133733@serebryakov.spb.ru> <200901242240.33321.doconnor@gsoft.com.au> Message-ID: <83bd6b61-83b8-4609-a7e9-86c7c1ca8060@exchange01.ecp.noc> Hello, Daniel. You wrote 24 ?????? 2009 ?., 15:10:24: >> Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect >> to two providers. >> >> But previous installation (on faster hardware) doesn't show these >> errors at all! > I think this is an mpd problem - I had the same issue and I couldn't find a > solution. In the end I switched to userland PPP (which has an issue with PF > but you can work around that). userland ppp doesn't support l2tp :( -- // Black Lion AKA Lev Serebryakov _______________________________________________ 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 dougb at FreeBSD.org Mon Jan 26 10:44:01 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jan 26 10:44:17 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: <094e4b57-5b03-4c05-ac4f-a33ee3ee2a4b@exchange01.ecp.noc> Lev Serebryakov wrote: > Hello, Freebsd-stable. > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > fake addresses to vr2 and vr3 doesn't help at all. > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two > providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named Doug -- This .signature sanitized for your protection _______________________________________________ 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 doconnor at gsoft.com.au Mon Jan 26 10:45:10 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Jan 26 10:45:16 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: <7e7a2143-af12-4368-a79a-d2a89cc8cc57@exchange01.ecp.noc> On Saturday 24 January 2009 21:07:33 Lev Serebryakov wrote: > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: > > Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: > unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: > 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:11 >1: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert > errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway ... > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect > to two providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I think this is an mpd problem - I had the same issue and I couldn't find a solution. In the end I switched to userland PPP (which has an issue with PF but you can work around that). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090126/5cf88eab/attachment.pgp From smithi at nimnet.asn.au Mon Jan 26 10:46:40 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Jan 26 10:47:09 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901251537.07249.doconnor@gsoft.com.au> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> <200901251537.07249.doconnor@gsoft.com.au> Message-ID: On Sun, 25 Jan 2009, Daniel O'Connor wrote: > On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: Doug Barton wrote: > > > I've never used mpd myself, but you might want to try adding the > > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > > > # BEFORE: named This doesn't help in the case where mpd may take seconds to negotiate with $provider for a link; always the case on ADSL here anyway, moreso for dialup. The rc.d script exits after launching mpd, so named will still start 'right away' while mpd - or ppp - is still negotiating. I 'solved' this chicken-and-egg by adding an ugly sleep 7 after starting (mpd &) before exiting the script. Haven't bothered refining what works once a month or two, but the sleep could be killed by pid from an mpd-up script as soon as there's a working link. (mpd 4.1 if it matters) > > mpd should also be fixed as the error code being returned is not > > approprate. network unreachable is what should be returned. It's not mpd's error, or message; named knows nothing about mpd, but does like its specified listen and *-source addresses to exist. This one looks more like a ill-worded 'no route to host' indication perhaps? Or trying to listen on the address of the (yet to exist) ng interface? > I'm not sure that is the whole problem - I found that it would return device > not configured 'permanently' when I was using it. The link would be up > (apparently) but nothing passes. Sometimes restarting it would fix it but > other times it just persistently said the same thing. > > It seemed like there was some kernel state that was incorrect and even > restarting mpd would not fix it. I've found named requires a proper /etc/rc.d/named stop / start cycle after all required interfaces are up and there's a default route, here, and that sleep 7 obviates that for me .. but it's hardly elegant. cheers, Ian _______________________________________________ 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 lev at FreeBSD.org Mon Jan 26 10:56:31 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon Jan 26 10:56:37 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <11410349378.20090124133733@serebryakov.spb.ru> References: <11410349378.20090124133733@serebryakov.spb.ru> Message-ID: Hello, Lev. You wrote 24 ?????? 2009 ?., 13:37:33: > IP addresses are RANDOM and DIFFERENT on every restart. These IP > addresses are not mentioned in ANY config file on my computer, and > addresses on my network interfaces IS NOT from these networks. Ok, I'm stupid, it is root servers. Ok. But this knowledge doesn't help to fix problem :( > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( -- // Black Lion AKA Lev Serebryakov _______________________________________________ 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 lev at FreeBSD.org Mon Jan 26 10:59:32 2009 From: lev at FreeBSD.org (Lev Serebryakov) Date: Mon Jan 26 10:59:39 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address Message-ID: <21aae7b3-0f43-47ed-a71e-3ca99afbcfb4@exchange01.ecp.noc> Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured IP addresses are RANDOM and DIFFERENT on every restart. These IP addresses are not mentioned in ANY config file on my computer, and addresses on my network interfaces IS NOT from these networks. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! -- // Black Lion AKA Lev Serebryakov _______________________________________________ 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 Mark_Andrews at isc.org Mon Jan 26 11:01:37 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Jan 26 11:02:08 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address In-Reply-To: Your message of "Sat, 24 Jan 2009 15:10:44 -0800." <497B9FF4.30605@FreeBSD.org> Message-ID: <8f2c566f-ecdc-4cb3-aa8a-f7e2243c2d97@exchange01.ecp.noc> In message <497B9FF4.30605@FreeBSD.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.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 barney_cordoba at yahoo.com Mon Jan 26 11:13:20 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Mon Jan 26 11:13:27 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available In-Reply-To: <7iocxu7y4x.wl%gnn@neville-neil.com> Message-ID: <618776.52345.qm@web63907.mail.re1.yahoo.com> --- On Mon, 1/26/09, gnn@freebsd.org wrote: > From: gnn@freebsd.org > Subject: Re: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available > To: "Rui Paulo" > Cc: "Liran Liss" , freebsd-net@freebsd.org, "Yony Yossef" , johan@nocrew.org, "Amit Krig" , "Eitan Shefi" > Date: Monday, January 26, 2009, 12:52 PM > At Sat, 24 Jan 2009 16:20:06 +0000, > Rui Paulo wrote: > > > > > > On 24 Jan 2009, at 12:54, Yony Yossef wrote: > > > > > Hi All, > > > > > > I'm facing a temporary network hang on my > interfaces following a flood > > > ping/stress udp test. > > > > > > I'm running a netperf UDP test which is > giving results but does not > > > return > > > to the shell. > > > client output: > > > > > > UDP UNIDIRECTIONAL SEND TEST from > fe80::202:c9ff:fe02:e1fe%mtnic0 > > > (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to > > > fe80::202:c9ff:fe02:e1f4%mt > > > nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6 > > > Socket Message Elapsed Messages > > > Size Size Time Okay Errors > Throughput > > > bytes bytes secs # # > 10^6bits/sec > > > > > > 32768 1472 10.02 547428 1694280 > 643.60 > > > 32768 10.02 25089 > 29.50 > > > > > > > > > (HANG) > > > > > > After a minute or two it returns to the shell > with the following > > > message: > > > shutdown_control: no response received errno 55 > > > > > > 20 minutes later (!!) the interface is working > again. > > > > > > netstat -m and vmstat -z outputs during the hang > time: > > > > > > # netstat -m > > > 25687/6578/32265 mbufs in use > (current/cache/total) > > > 17404/2438/19842/65536 mbuf clusters in use > (current/cache/total/max) > > > 0/1024 mbuf+clusters out of packet secondary zone > in use (current/ > > > cache) > > > 2071/1369/3440/65536 4k (page size) jumbo > clusters in use > > > (current/cache/total/max) > > > 0/0/0/65536 9k jumbo clusters in use > (current/cache/total/max) > > > 0/0/0/3200 16k jumbo clusters in use > (current/cache/total/max) > > > 49513K/11996K/61510K bytes allocated to network > (current/cache/total) > > > 0/0/0 requests for mbufs denied > (mbufs/clusters/mbuf+clusters) > > > 0/0/0 requests for jumbo clusters denied > (4k/9k/16k) > > > 0/0/0 sfbufs in use (current/peak/max) > > > 0 requests for sfbufs denied > > > 0 requests for sfbufs delayed > > > 0 requests for I/O initiated by sendfile > > > 0 calls to protocol drain routines > > > > I think there are too many mbufs in use. You're > probably facing an > > mbuf leakage and that causes an interface hang. > > > If this is a large memory machine try upping the number of > clusters > and mbufs. On 64 bit systems with large memories 1,000,000 > mbufs is > not unheard of. > > kern.ipc.nmbclusters: 1000000 > > Also, with UDP you can easily overrun different buffers > within the > system. You might also look at: > > netstat -id > > and see if the driver is dropping packets, and if so you > might up its > send queue. > > Best, > George The clusters problem is an artifact of the buffers problem. You tend to get the "No buffer space" when a send queue gets clogged. Sometimes its difficult to get unclogged. For example if you look at some of the ethernet drivers, they will queue the packet when a send error occurs, hoping to send it when the problem clears. But if you have a problem that doesnt resolve those buffers get stuck in the queue. The only clean way I've found to free them in that case is to unload the driver and reload it. Barney From kmacy at freebsd.org Mon Jan 26 12:12:33 2009 From: kmacy at freebsd.org (Kip Macy) Date: Mon Jan 26 12:12:47 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available In-Reply-To: <000001c97e23$0d81df20$39ed1aac@mtl.com> References: <000001c97e23$0d81df20$39ed1aac@mtl.com> Message-ID: <3c1674c90901261212l5432b99fpd77bcff96883bd21@mail.gmail.com> "No buffer space available" is ENOBUFS. This error is returned when the ifq is full - see IFQ_ENQUEUE in if_var.h. You'll almost certainly want to set ifq_len to larger than the default for a 10 gigabit driver. This most likely to be a combination of ifq_len being too small and inadequate txq overflow handling. However, without the code to look at I can only guess. Cheers, Kip On Sat, Jan 24, 2009 at 12:54 PM, Yony Yossef wrote: > Hi All, > > I'm facing a temporary network hang on my interfaces following a flood > ping/stress udp test. > > I'm running a netperf UDP test which is giving results but does not return > to the shell. > client output: > > UDP UNIDIRECTIONAL SEND TEST from fe80::202:c9ff:fe02:e1fe%mtnic0 > (fe80::202:c9ff:fe02:e1fe) port 0 AF_INET6 to fe80::202:c9ff:fe02:e1f4%mt > nic0 (fe80::202:c9ff:fe02:e1f4) port 0 AF_INET6 > Socket Message Elapsed Messages > Size Size Time Okay Errors Throughput > bytes bytes secs # # 10^6bits/sec > > 32768 1472 10.02 547428 1694280 643.60 > 32768 10.02 25089 29.50 > > > (HANG) > > After a minute or two it returns to the shell with the following message: > shutdown_control: no response received errno 55 > > 20 minutes later (!!) the interface is working again. > > netstat -m and vmstat -z outputs during the hang time: > > # netstat -m > 25687/6578/32265 mbufs in use (current/cache/total) > 17404/2438/19842/65536 mbuf clusters in use (current/cache/total/max) > 0/1024 mbuf+clusters out of packet secondary zone in use (current/cache) > 2071/1369/3440/65536 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 49513K/11996K/61510K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > You have new mail in /var/mail/root > > # vmstat -z | grep mbuf > ITEM SIZE LIMIT USED FREE REQUESTS > FAILURES > mbuf_packet: 256, 0, 0, 1024, 1497, > 0 > mbuf: 256, 0, 25687, 5554, 21208920, > 0 > mbuf_cluster: 2048, 65536, 18428, 1414, 149349, > 0 > mbuf_jumbo_pagesize: 4096, 65536, 2071, 1369, 17050312, > 0 > mbuf_jumbo_9k: 9216, 65536, 0, 0, 0, > 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, > 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, > 0 > > # uname -a > FreeBSD sw260.lab.mtl.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Dec 29 > 11:00:24 UTC 2008 > root@sw259.lab.mtl.com:/usr/obj/usr/src.dbg/sys/GENERIC.KDB amd64 > > The fact that the interface is coming back to life without any driver > activity indicates an OS bug. > > Thanks, > Yony > > _______________________________________________ > 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 mav at FreeBSD.org Mon Jan 26 12:41:08 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Jan 26 12:41:15 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <1232806983.00065540.1232794801@10.7.7.3> References: <1232806983.00065540.1232794801@10.7.7.3> Message-ID: <497E1FE6.8050108@FreeBSD.org> Lev Serebryakov wrote: > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: > Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two > providers. ENXIO reported by many netgraph nodes if they receiving data while not configured. I have found small time window in mpd5 operation when interface is UP and configured, but IP flow is not enabled yet. I have made small change in mpd5 CVS which should close that window. I hope it will help you. -- Alexander Motin From sandiegobiker at gmail.com Mon Jan 26 18:03:54 2009 From: sandiegobiker at gmail.com (Len Gross) Date: Mon Jan 26 18:04:02 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <20090126164357.F90458@sola.nimnet.asn.au> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> <20090126164357.F90458@sola.nimnet.asn.au> Message-ID: <27cb3ada0901261803h301c8cd4xbf5dafcde1f6ff7c@mail.gmail.com> Ian, Thanks so much for taking the time to look at this problem. I do not have any firewall running on any of the machines, unless something "auto enables." The only rc.conf entries are ifconfig and routing. The thing that is most puzzling to me is that everything is fine on FreeBSD #2 even though it is "behind" a link with 1450 MTU. This sounds like it must be a "bug" on FreeBSD #2 (version 7.0) routing from the 1450 route to the 1500 route to FreeBSD 3. But if that were true, why would running a Web Proxy on FreeBSD #1 work? Some other data. I get the same problem if I replace FreeBSD 3 with a Windows box. I'm pretty sure I had similar behaviour with FreeBSD 6.3 as machine #2,, but it was ignored at the time. I've seen the problem with connections to two different ISPs. I can live with having a Web Proxy on FreeBSD # 1, but I am concerned that this issue will crop up someplace else. -- Len On Sun, Jan 25, 2009 at 9:51 PM, Ian Smith wrote: > On Sun, 25 Jan 2009, Len Gross wrote: > > The following configuration works fine _until_ I make a change in MTU > > setting on the link between FreeBSD1 and FreeBSD2 > > > > Internet > > | > > Router x.x.x.x > > 192.168.0.1/16 > > | > > FreeBSD #1 192.168.0.202 /16 > > 6.3 192.168.1.1/ 24 > > | > > FreeBSD #2 192.168.1.2/24 > > 7.0 192.168.1.5/24 > > | > > FreeBSD #3 192.168.5.2/24 > > 7.0 > > > > All connections are Ethernet. > > > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > > work, BUT browsing on FreeBSD3 "fails" (mostly.) > > > > On FreeBSD 3 > > Ping and nslookup work fine from FreeBSD3 > > I can get to Google but virtually no other web sites > > Using tcpdump there is lots of unusual stuff, some relating to > > fragmentation ICMP? > > Do any of these machines have a firewall rule blocking ICMP? You want > to be sure at least icmptypes 3,11 are flowing freely to/from FreeBSD3, > as well as pings (icmptypes 0,8) which are apparently permitted. > > cheers, Ian > > > If I put a Web Proxy on FreeBSD 1, everything works fine. > > > > I have tried putting mtu = 1450 using route change on all the routes, > > but that didn't help. > > When I did this I verified all routes had 1450 mtu via netstat ?arW > > > > So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or ??? > > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > > runs fine there > > > > (There was a thread in October about mtu issues in 7.0 but it didn't > > seem to help my problem.) > > (I run 1450 MTU to support testing of an experimental protocol., but > > all the above is with straight out of the box FreeBSD.) > > > > -- Len > From julian at elischer.org Mon Jan 26 18:27:26 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 26 18:27:34 2009 Subject: networking benchmarks for Vimage Message-ID: <497E6A6F.8060401@elischer.org> I have set up a pair of machines which I can boot into either VIMAGE_GLOBAL or normal kernels (otherwise identical). with GB (bge) interfaces between them. I am looking for suggestions as to what tests I should be doing between these machines to be able to assess whether there are any performance differences between these two setups. I will be doing ttcp tests and flood pings and well as nfs copies and ng_ether_echo timings. I'd also like to get some suggestions from others, as to what tests might be useful. Be specific please i.e. {program + arguments to test). The two machines are identical and will always being the same kernel at the same time. basic cpu specs below.. ===================== CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2788.47-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 3221094400 (3071 MB) avail memory = 3153461248 (3007 MB) ACPI APIC Table: ===================== thanks Julian From ganbold at micom.mng.net Mon Jan 26 18:56:45 2009 From: ganbold at micom.mng.net (Ganbold) Date: Mon Jan 26 18:56:52 2009 Subject: networking benchmarks for Vimage In-Reply-To: <497E6A6F.8060401@elischer.org> References: <497E6A6F.8060401@elischer.org> Message-ID: <497E74A9.3030009@micom.mng.net> Julian Elischer wrote: > I have set up a pair of machines which I can boot into either > VIMAGE_GLOBAL or normal kernels (otherwise identical). > with GB (bge) interfaces between them. > > I am looking for suggestions as to what tests I should be doing > between these machines to be able to assess whether there are any > performance differences between these two setups. > > I will be doing ttcp tests and flood pings and well as > nfs copies and ng_ether_echo timings. > > I'd also like to get some suggestions from others, > as to what tests might be useful. Be specific please > i.e. {program + arguments to test). Maybe something like /usr/ports/benchmarks/iperf But I don't recall options and arguments. Ganbold > > The two machines are identical and will always being the > same kernel at the same time. basic cpu specs below.. > > ===================== > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2788.47-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Features=0xbfebfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX, > FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x4400 > Logical CPUs per core: 2 > real memory = 3221094400 (3071 MB) > avail memory = 3153461248 (3007 MB) > ACPI APIC Table: > ===================== > > thanks > > Julian > > > _______________________________________________ > 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" > > > -- Fess: Well, you must admit there is something innately humorous about a man chasing an invention of his own halfway across the galaxy. Rod: Oh yeah, it's a million yuks, sure. But after all, isn't that the basic difference between robots and humans? Fess: What, the ability to form imaginary constructs? Rod: No, the ability to get hung up on them. -- Christopher Stasheff, "The Warlock in Spite of Himself" From jmaps-fbsdnet at fireburns.net Mon Jan 26 21:38:38 2009 From: jmaps-fbsdnet at fireburns.net (jmaps-fbsdnet@fireburns.net) Date: Mon Jan 26 21:38:44 2009 Subject: Multiple ISP routing by port Message-ID: <20090127051809.GA21017@fireburns.net> I've read through what I could find in this list and also in the top 50 results on google... I can't find anything that'll actually make this work. My DSL ISP is too far away to give me anything faster than 1.5mbps down. In despiration I signed up for comcast to use for bulk traffic. Thus, I want to route critical traffic (22, 25, 53, (maybe) 80, 443) through the DSL provider and the rest through cable. I really feel like this should be possible with PF with something like: nat on $dsl_if from ($int_if:network) to any port $dslports -> ($dsl_if) nat on $cbl_if from ($int_if:network) to any -> ($cbl_if) or pass in quick on $int_if route-to { ($dsl_if $dsl_gw) } proto { tcp udp } from ($int_if:network) to any port $dslports Neither (or both) seem to do it. All traffic ends up getting routed through whichever ISP i have set as the default route. Now, I hear i can go over to linux and just configure both default routes at the same time (trivial with iproute2). But I'd rather avoid that if at all possible. Is there some trick I'm missing? Does quagga (bgpd) allow for this kind of routing scheme? Thanks, Jesse From max at love2party.net Mon Jan 26 22:04:41 2009 From: max at love2party.net (Max Laier) Date: Mon Jan 26 22:04:48 2009 Subject: Multiple ISP routing by port In-Reply-To: <20090127051809.GA21017@fireburns.net> References: <20090127051809.GA21017@fireburns.net> Message-ID: <200901270704.36034.max@love2party.net> On Tuesday 27 January 2009 06:18:09 jmaps-fbsdnet@fireburns.net wrote: > I've read through what I could find in this list and also in the top 50 > results on google... I can't find anything that'll actually make this work. > > My DSL ISP is too far away to give me anything faster than 1.5mbps down. In > despiration I signed up for comcast to use for bulk traffic. > > Thus, I want to route critical traffic (22, 25, 53, (maybe) 80, 443) > through the DSL provider and the rest through cable. > > I really feel like this should be possible with PF with something like: > > nat on $dsl_if from ($int_if:network) to any port $dslports -> ($dsl_if) > nat on $cbl_if from ($int_if:network) to any -> ($cbl_if) > > or > > pass in quick on $int_if route-to { ($dsl_if $dsl_gw) } proto { tcp udp } > from ($int_if:network) to any port $dslports > > Neither (or both) seem to do it. All traffic ends up getting routed through > whichever ISP i have set as the default route. Take a look at: http://www.openbsd.org/faq/pf/pools.html#outgoing You are probably missing the following part of the setup: | To ensure that packets with a source address belonging to $ext_if1 are | always routed to $ext_gw1 (and similarly for $ext_if2 and $ext_gw2), the | following two lines should be included in the ruleset: | | pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \ | to any | pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \ | to any This obviously has to be adapted for you specific setup - but in general this works as expected. > Now, I hear i can go over to linux and just configure both default routes > at the same time (trivial with iproute2). But I'd rather avoid that if at > all possible. > > Is there some trick I'm missing? Does quagga (bgpd) allow for this kind of > routing scheme? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From fox at verio.net Mon Jan 26 22:44:33 2009 From: fox at verio.net (David DeSimone) Date: Mon Jan 26 22:44:40 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> Message-ID: <20090127064419.GC1284@verio.net> Len Gross wrote: > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > work, BUT browsing on FreeBSD3 "fails" (mostly.) You are running into a common TCP methodology in use these days, called "Path MTU Discovery." In this process, both endpoints choose to set the "DF" (Don't Fragment) bit on all their TCP packets, and then they expect all routers along the path to send ICMP "network unreachable" packets with code "needs fragment", informing them of what maximum packet size is allowed along the path. Endpoints start out sending full-size frames and then reduce them in size whenever instructed to do so by ICMP messages. The reception of these ICMP messages is crucial to this process working, and if the frames are not received, the whole communication breaks down. > Using tcpdump there is lots of unusual stuff, some relating to > fragmentation ICMP? These are the messages I referred to. Be aware that, just because you see them arriving or leaving via tcpdump, does not mean that they are being received by the host. For instance, a host using PF or IPF or some other firewall would indeed see the frame arrive, but if its ruleset rejects the frame, it will not have a useful effect. > I have tried putting mtu = 1450 using route change on all the routes, > but that didn't help. > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > runs fine there That is because, since it has a direct interface with a reduced MTU, it already knows to negotiate a smaller initial MSS with any endpoints out on the internet. Hosts behind BSD2 have to learn the Path MTU via the above Discovery process. In another message you mentioned that you have no firewalls in place, but that hardly seems likely. Everyone runs a firewall at some point, because it is too dangerous to leave your systems unprotected on the internet. I suppose you may be thinking that this is a problem that exists only on your local network, but you must realize that Path MTU Discovery works in both directions, from your systems out to the internet, and from those internet systems back to yours. For instance, if your BSD3 box sends a large packet, the BSD2 "router" realizes that it needs to be fragmented, but the DF-bit prevents this. So BSD2 sends a message to BSD3 that it must use a smaller packet size. If you have no firewalls in place, then this message will surely be received and acted upon. However, when web browsing, the more likely scenario is that the web server you've contacted will be the one trying to send large packets back to you. When those packets reach router BSD1, it realizes that the packet is too big, and sends an ICMP message back to the remote server. Does that ICMP message make it through your outbound filters further upstream? Perhaps. Will that message make it thorugh the firewalls that are surely guarding the remote server? Let's hope so! This is something that is not really under your control, so it's difficult to say. Your best method of troubleshooting this might be to test from a host outside your network to see if the ICMP packets from BSD1 are making it through. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From julian at elischer.org Mon Jan 26 23:51:32 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 26 23:51:39 2009 Subject: Multiple ISP routing by port In-Reply-To: <20090127051809.GA21017@fireburns.net> References: <20090127051809.GA21017@fireburns.net> Message-ID: <497EBCFF.5050802@elischer.org> jmaps-fbsdnet@fireburns.net wrote: > I've read through what I could find in this list and also in the > top 50 results on google... I can't find anything that'll actually > make this work. yes this i stricky for several reasons > > My DSL ISP is too far away to give me anything faster than 1.5mbps > down. In despiration I signed up for comcast to use for bulk > traffic. I sympathize. I can only get 800kb/s at 17000 feet.. (1.5Mb/s works *sometimes*) > > Thus, I want to route critical traffic (22, 25, 53, (maybe) 80, > 443) through the DSL provider and the rest through cable. > > I really feel like this should be possible with PF with something > like: > > nat on $dsl_if from ($int_if:network) to any port $dslports -> > ($dsl_if) nat on $cbl_if from ($int_if:network) to any -> ($cbl_if) > well, yes but you are only doing the nat on teh interface AFTER the decision has been made as to which interface it will go out on. > > or > > pass in quick on $int_if route-to { ($dsl_if $dsl_gw) } proto { tcp > udp } from ($int_if:network) to any port $dslports > > Neither (or both) seem to do it. All traffic ends up getting routed > through whichever ISP i have set as the default route. in 7.1 you now have the ability to have multiple routing tables. (in 8.0 you also have multiple defaults) now I'm not a pf person, prefering ipfw but in ipfw you can do: setfib 1 ip from any to any 80,22,25,53 in recv ${inside_if} all other packets will use FIB 0.. and then nat on each interface... the you define two routing tables (FIBs) with different default routes. pf has in 8.0 got multiple fib support but I can't remember if it is in 7.1. you'll have to check > > Now, I hear i can go over to linux and just configure both default > routes at the same time (trivial with iproute2). But I'd rather > avoid that if at all possible. in 8.x you can do that too. > > Is there some trick I'm missing? Does quagga (bgpd) allow for this > kind of routing scheme? > > Thanks, Jesse _______________________________________________ > 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 adamk at voicenet.com Tue Jan 27 06:28:02 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue Jan 27 06:28:10 2009 Subject: iwi doesn't see a wireless network Message-ID: <20090127085941.5d642cde@memory.visualtech.com> I'm trying to get my laptop to connect to the wireless access point at work. It has a Intel Pro Wireless 2200BG minipci card, and can associate with my access point at home. In addition, I can get an Ubuntu 8.10 liveCD to connect to the access point at work via NetworkManager. So there is definitely no incompatibility between the wireless card and access point. Here's my wpa_supplicant.conf file: network={ ssid="Mckella280Front" key_mgmt=WPA-PSK pairwise=TKIP psk="#########" } The preshared key is definitely correct, as it's the one that works with the liveCD. For the sake of testing, I've removed the reference to my wireless AP at home. I'm attaching the output from wpa_supplicant run with -dd. Basically, it keeps scanning but only ever sees the tmobile network. That's actually coming from another person in the building using a tmobile wireless broadband card. If she's not here, the scan never picks up anything. Similarly, 'ifconfig iwi0 list scan' only picks up the tmobile ssid. Yet, if I reboot off the liveCD, it works. Here's the output of 'iwlist eth1 scanning' under the liveCD: eth1 Scan completed : Cell 01 - Address: 00:22:6B:9A:CC:AF ESSID:"Mckella280Front" Protocol:IEEE 802.11bg Mode:Master Frequency:2.457 GHz (Channel 10) Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=50/100 Signal level=-68 dBm IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Extra: Last beacon: 904ms ago And, iwconfig while connected: eth1 IEEE 802.11g ESSID:"Mckella280Front" Mode:Managed Frequency:2.457 GHz Access Point: 00:22:6B:9A:CC:AF Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0 Retry limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=59/100 Signal level=-66 dBm Noise level=-87 dBm Rx invalid nwid:0 Rx invalid crypt:6 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:3 The only thing I can think of is that the AP is using some feature that the iwi driver, or wpa_supplicant, doesn't support. Is there someway to get this working? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- Initializing interface 'iwi0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 2 - start of a new network block ssid - hexdump_ascii(len=15): 4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74 Mckella280Front key_mgmt: 0x2 pairwise: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Line 8: removed CCMP from group cipher list since it was not allowed for pairwise cipher Priority group 0 id=0 ssid='Mckella280Front' Initializing interface (2) 'iwi0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:13:ce:a8:10:ea wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface iwi0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. Setting scan request: 5 sec 0 usec CTRL-EVENT-TERMINATING - signal 2 received Removing interface iwi0 State: SCANNING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 From linimon at FreeBSD.org Tue Jan 27 07:56:06 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jan 27 07:56:13 2009 Subject: kern/131038: [ip6] [panic] kernel panic in ip6_forward Message-ID: <200901271556.n0RFu5nH071113@freefall.freebsd.org> Old Synopsis: kernel panic in ip6_forward New Synopsis: [ip6] [panic] kernel panic in ip6_forward Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jan 27 15:55:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131038 From smithi at nimnet.asn.au Tue Jan 27 08:01:48 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Jan 27 08:01:55 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <27cb3ada0901261803h301c8cd4xbf5dafcde1f6ff7c@mail.gmail.com> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> <20090126164357.F90458@sola.nimnet.asn.au> <27cb3ada0901261803h301c8cd4xbf5dafcde1f6ff7c@mail.gmail.com> Message-ID: <20090128024956.X86094@sola.nimnet.asn.au> On Mon, 26 Jan 2009, Len Gross wrote: > Ian, > > Thanks so much for taking the time to look at this problem. More like a parting shot over the shoulder before bedtime :) > I do not have any firewall running on any of the machines, unless > something "auto enables." The only rc.conf entries are ifconfig and > routing. > > The thing that is most puzzling to me is that everything is fine on > FreeBSD #2 even though it is "behind" a link with 1450 MTU. This > sounds like it must be a "bug" on FreeBSD #2 (version 7.0) routing > from the 1450 route to the 1500 route to FreeBSD 3. But if that were > true, why would running a Web Proxy on FreeBSD #1 work? What if you also set FreeBSD #2's more inside interface to 1450, as on FreeBSD #1? Apart from that I can't say anything as useful as David DeSimone's more detailed coverage of the issues, except that tcpdump on FreeBSD #3 should show what is (and isn't) happening more clearly. cheers, Ian > Some other data. I get the same problem if I replace FreeBSD 3 with a > Windows box. > I'm pretty sure I had similar behaviour with FreeBSD 6.3 as machine > #2,, but it was ignored at the time. I've seen the problem with > connections to two different ISPs. > > I can live with having a Web Proxy on FreeBSD # 1, but I am concerned > that this issue will crop up someplace else. > > -- Len > > On Sun, Jan 25, 2009 at 9:51 PM, Ian Smith wrote: > > On Sun, 25 Jan 2009, Len Gross wrote: > > > The following configuration works fine _until_ I make a change in MTU > > > setting on the link between FreeBSD1 and FreeBSD2 > > > > > > Internet > > > | > > > Router x.x.x.x > > > 192.168.0.1/16 > > > | > > > FreeBSD #1 192.168.0.202 /16 > > > 6.3 192.168.1.1/ 24 > > > | > > > FreeBSD #2 192.168.1.2/24 > > > 7.0 192.168.1.5/24 > > > | > > > FreeBSD #3 192.168.5.2/24 > > > 7.0 > > > > > > All connections are Ethernet. > > > > > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > > > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > > > work, BUT browsing on FreeBSD3 "fails" (mostly.) > > > > > > On FreeBSD 3 > > > Ping and nslookup work fine from FreeBSD3 > > > I can get to Google but virtually no other web sites > > > Using tcpdump there is lots of unusual stuff, some relating to > > > fragmentation ICMP? > > > > Do any of these machines have a firewall rule blocking ICMP? You want > > to be sure at least icmptypes 3,11 are flowing freely to/from FreeBSD3, > > as well as pings (icmptypes 0,8) which are apparently permitted. > > > > cheers, Ian > > > > > If I put a Web Proxy on FreeBSD 1, everything works fine. > > > > > > I have tried putting mtu = 1450 using route change on all the routes, > > > but that didn't help. > > > When I did this I verified all routes had 1450 mtu via netstat ?arW > > > > > > So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or ??? > > > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > > > runs fine there > > > > > > (There was a thread in October about mtu issues in 7.0 but it didn't > > > seem to help my problem.) > > > (I run 1450 MTU to support testing of an experimental protocol., but > > > all the above is with straight out of the box FreeBSD.) > > > > > > -- Len > > > From bzeeb-lists at lists.zabbadoz.net Tue Jan 27 08:20:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Jan 27 08:20:23 2009 Subject: kern/131038: [ip6] [panic] kernel panic in ip6_forward Message-ID: <200901271620.n0RGK5bH087052@freefall.freebsd.org> The following reply was made to PR kern/131038; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, denis@h3q.com Cc: Subject: Re: kern/131038: [ip6] [panic] kernel panic in ip6_forward Date: Tue, 27 Jan 2009 16:11:53 +0000 (UTC) Hi, this looks like it's racing on one of the unlocked global cache variables in the netinet6 code. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From yonyossef.lists at gmail.com Tue Jan 27 08:56:10 2009 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Jan 27 08:56:16 2009 Subject: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available In-Reply-To: <3c1674c90901261212l5432b99fpd77bcff96883bd21@mail.gmail.com> References: <000001c97e23$0d81df20$39ed1aac@mtl.com> <3c1674c90901261212l5432b99fpd77bcff96883bd21@mail.gmail.com> Message-ID: <002201c980a0$25903420$220f000a@mtl.com> > "No buffer space available" is ENOBUFS. This error is > returned when the ifq is full - see IFQ_ENQUEUE in if_var.h. > You'll almost certainly want to set ifq_len to larger than > the default for a 10 gigabit driver. This most likely to be a > combination of ifq_len being too small and inadequate txq > overflow handling. However, without the code to look at I can > only guess. > > Cheers, > Kip ---- my Tx loop is pretty normal (I've removed debug calls and irrelevant parts): while (!IFQ_DRV_IS_EMPTY(&dev->if_snd)) { IFQ_DRV_DEQUEUE(&dev->if_snd, m_head); if (m_head == NULL) break; if ( (err = mtnic_xmit_encap(priv, &m_head, &used)) != 0) { priv->ifp->if_drv_flags |= IFF_DRV_OACTIVE; IFQ_LOCK(&dev->if_snd); IFQ_DRV_PREPEND(&dev->if_snd, m_head); IFQ_UNLOCK(&dev->if_snd); break; } ETHER_BPF_MTAP(dev, m_head); } ---- my ifq_max_len is set to 4096, I believe it's bigger than the other 10GigE drivers (cxgb is using 1K, for instance): dev->if_snd.ifq_drv_maxlen = MTNIC_TX_IFQ_MAXLEN; // = 4096 IFQ_SET_MAXLEN(&dev->if_snd, dev->if_snd.ifq_drv_maxlen); IFQ_SET_READY(&dev->if_snd); ---- there's another strange symptom to this hang: after the 20 minutes I've mentioned (caused by the sender full IFQ) I have to ping the sender from the receiver side in order to retain traffic. During the 20 minutes it will not work, but after it passes a single ping will make the sender IFQ go back to life. Yony From mike at sentex.net Tue Jan 27 10:22:42 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Jan 27 10:22:48 2009 Subject: lagg failover mode and vlans Message-ID: <200901271739.n0RHdGd3047497@lava.sentex.ca> Hi, I noticed a small issue with the way VLANs work and the lagg0 interface in failover mode. I have a simple config of ifconfig lagg0 create up laggproto failover laggport em2 laggport em3 192.168.44.99/24 ifconfig lagg0.100 create 192.168.100.1/24 ifconfig lagg0.102 create 192.168.102.1/24 with em2 on one cisco 3500 and em3 on another cisco 3500 (primary and secondary) on port 32 of each switch interface FastEthernet0/32 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-200,1002-1005 switchport mode trunk spanning-tree portfast ! interface FastEthernet0/32 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-200,1002-1005 switchport mode trunk spanning-tree portfast ! and the switches are linked together with interface GigabitEthernet0/2 switchport trunk encapsulation dot1q switchport mode trunk ! On the freebsd RELENG_7 box lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 192.168.44.99 netmask 0xffffff00 broadcast 192.168.44.255 media: Ethernet autoselect status: active laggproto failover laggport: em3 flags=0<> laggport: em2 flags=5 For the native vlan of 1, if I pull the cable on the master port fa0/32, it works automatically and I barely miss a packet lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 192.168.44.99 netmask 0xffffff00 broadcast 192.168.44.255 media: Ethernet autoselect status: active laggproto failover laggport: em3 flags=4 laggport: em2 flags=1 but if I create some vlan interfaces off lagg0 lagg0.100: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 media: Ethernet autoselect status: active vlan: 100 parent interface: lagg0 lagg0.102: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 media: Ethernet autoselect status: active vlan: 102 parent interface: lagg0 and do the same pulling of the cable, it does not work. BUT, if I do an arp -nda on a machine that is part of vlan102 which is doing the pinging (so an arp-who has gets sent out and a reply answered), it works. The other option is if I send a packet out on the vlan's broadcast address from the server Apart from making a script to watch for interface up/down events on the machine with the lagg0 interface and vlans to do ping to each of the broadcast addresses, is there a way around this ? There was a discussion sort of around this in http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-05/msg00283.html ---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 mav at FreeBSD.org Tue Jan 27 14:36:26 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 27 14:36:46 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <1232806983.00065540.1232794801@10.7.7.3> References: <1232806983.00065540.1232794801@10.7.7.3> Message-ID: <497E1FE6.8050108@FreeBSD.org> Lev Serebryakov wrote: > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: > Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two > providers. ENXIO reported by many netgraph nodes if they receiving data while not configured. I have found small time window in mpd5 operation when interface is UP and configured, but IP flow is not enabled yet. I have made small change in mpd5 CVS which should close that window. I hope it will help you. -- Alexander Motin _______________________________________________ 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 doconnor at gsoft.com.au Tue Jan 27 14:36:28 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Jan 27 14:36:58 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> Message-ID: <200901251537.07249.doconnor@gsoft.com.au> On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: > > I've never used mpd myself, but you might want to try adding the > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > # BEFORE: named > > mpd should also be fixed as the error code being returned is not > approprate. network unreachable is what should be returned. I'm not sure that is the whole problem - I found that it would return device not configured 'permanently' when I was using it. The link would be up (apparently) but nothing passes. Sometimes restarting it would fix it but other times it just persistently said the same thing. It seemed like there was some kernel state that was incorrect and even restarting mpd would not fix it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090127/4999bf11/attachment.pgp From Mark_Andrews at isc.org Tue Jan 27 14:36:37 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue Jan 27 14:37:39 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: Your message of "Sat, 24 Jan 2009 15:10:44 -0800." <497B9FF4.30605@FreeBSD.org> Message-ID: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> In message <497B9FF4.30605@FreeBSD.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.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 smithi at nimnet.asn.au Tue Jan 27 14:36:38 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Jan 27 14:37:53 2009 Subject: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address In-Reply-To: <200901251537.07249.doconnor@gsoft.com.au> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> <200901251537.07249.doconnor@gsoft.com.au> Message-ID: <20090126002703.J90458@sola.nimnet.asn.au> On Sun, 25 Jan 2009, Daniel O'Connor wrote: > On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: Doug Barton wrote: > > > I've never used mpd myself, but you might want to try adding the > > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > > > # BEFORE: named This doesn't help in the case where mpd may take seconds to negotiate with $provider for a link; always the case on ADSL here anyway, moreso for dialup. The rc.d script exits after launching mpd, so named will still start 'right away' while mpd - or ppp - is still negotiating. I 'solved' this chicken-and-egg by adding an ugly sleep 7 after starting (mpd &) before exiting the script. Haven't bothered refining what works once a month or two, but the sleep could be killed by pid from an mpd-up script as soon as there's a working link. (mpd 4.1 if it matters) > > mpd should also be fixed as the error code being returned is not > > approprate. network unreachable is what should be returned. It's not mpd's error, or message; named knows nothing about mpd, but does like its specified listen and *-source addresses to exist. This one looks more like a ill-worded 'no route to host' indication perhaps? Or trying to listen on the address of the (yet to exist) ng interface? > I'm not sure that is the whole problem - I found that it would return device > not configured 'permanently' when I was using it. The link would be up > (apparently) but nothing passes. Sometimes restarting it would fix it but > other times it just persistently said the same thing. > > It seemed like there was some kernel state that was incorrect and even > restarting mpd would not fix it. I've found named requires a proper /etc/rc.d/named stop / start cycle after all required interfaces are up and there's a default route, here, and that sleep 7 obviates that for me .. but it's hardly elegant. cheers, Ian _______________________________________________ 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 bzeeb-lists at lists.zabbadoz.net Tue Jan 27 14:37:30 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Jan 27 14:40:11 2009 Subject: Need testers for a network cleanup patch In-Reply-To: <20090122225404.U45399@maildrop.int.zabbadoz.net> References: <20090122225404.U45399@maildrop.int.zabbadoz.net> Message-ID: <20090126093817.H45399@maildrop.int.zabbadoz.net> On Thu, 22 Jan 2009, Bjoern A. Zeeb wrote: Hi, > while cleaning up protosw things I found that rip6_output was most > likely never called from pr_output and after a short talk with Robert > the conclusion was that the same had been true for rip_output. > > Before I am going to remove the initializations I made the two > rip{,6}_output functions calling panic(). > > I have a patch for HEAD here: > http://people.freebsd.org/~bz/20090122-03-pr_output.diff > > and one for 7-STABLE here (compiled but not booted): > http://people.freebsd.org/~bz/20090122-04-pr_output-7STABLE.diff > > > I am confident it will not panic (at least for HEAD;) but not 100% > sure so you can run this on your test or devel machine but I'd not > run it on a production machine. > > If you are going to use the 7-STABLE patch make sure to have debugging > support in your kernel as well so we could get backtraces in the > unlikely event of panic. > > > Please reply directly to me if you have (un)successfully run the > patch and do NOT to the lists. > In case you think you run it successfully mail me after a > 2-3 days, and _not_ with an "it booted" message! ;-) In case you tested, please let me know. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From sandiegobiker at gmail.com Tue Jan 27 18:01:26 2009 From: sandiegobiker at gmail.com (Len Gross) Date: Tue Jan 27 18:01:32 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <20090127064419.GC1284@verio.net> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> <20090127064419.GC1284@verio.net> Message-ID: <27cb3ada0901271801u6d1db9cfhfb953073355db2d2@mail.gmail.com> David Wow! Thanks for so much help and detail. I guess it is "good news" that this is a result of "common TCP methodology." ;-> It will take me a bit of time (i.e Weekend work) to capture / understand the traffic and run some more tests and read up on Path MTU Discovery. BTW: The only firewall I've found in this setup is a Linksys WiFi Router that that connects to a cable modem. Similar setup at a second location with a WiFI router to DSL. One left over item to ponder. Why does Google work? Do they have a packet size smaller than 1450 by "default"? Thanks again, and I'll send an update when I learn more. -- Len On Mon, Jan 26, 2009 at 10:44 PM, David DeSimone wrote: > Len Gross wrote: >> >> If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU >> on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to >> work, BUT browsing on FreeBSD3 "fails" (mostly.) > > You are running into a common TCP methodology in use these days, called > "Path MTU Discovery." In this process, both endpoints choose to set > the "DF" (Don't Fragment) bit on all their TCP packets, and then they > expect all routers along the path to send ICMP "network unreachable" > packets with code "needs fragment", informing them of what maximum > packet size is allowed along the path. Endpoints start out sending > full-size frames and then reduce them in size whenever instructed to do > so by ICMP messages. > > The reception of these ICMP messages is crucial to this process working, > and if the frames are not received, the whole communication breaks down. > >> Using tcpdump there is lots of unusual stuff, some relating to >> fragmentation ICMP? > > These are the messages I referred to. Be aware that, just because > you see them arriving or leaving via tcpdump, does not mean that they > are being received by the host. For instance, a host using PF or IPF > or some other firewall would indeed see the frame arrive, but if its > ruleset rejects the frame, it will not have a useful effect. > >> I have tried putting mtu = 1450 using route change on all the routes, >> but that didn't help. > >> Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox >> runs fine there > > That is because, since it has a direct interface with a reduced MTU, it > already knows to negotiate a smaller initial MSS with any endpoints out > on the internet. Hosts behind BSD2 have to learn the Path MTU via the > above Discovery process. > > In another message you mentioned that you have no firewalls in place, > but that hardly seems likely. Everyone runs a firewall at some point, > because it is too dangerous to leave your systems unprotected on the > internet. > > I suppose you may be thinking that this is a problem that exists only on > your local network, but you must realize that Path MTU Discovery works > in both directions, from your systems out to the internet, and from > those internet systems back to yours. > > For instance, if your BSD3 box sends a large packet, the BSD2 "router" > realizes that it needs to be fragmented, but the DF-bit prevents this. > So BSD2 sends a message to BSD3 that it must use a smaller packet size. > If you have no firewalls in place, then this message will surely be > received and acted upon. > > However, when web browsing, the more likely scenario is that the web > server you've contacted will be the one trying to send large packets > back to you. When those packets reach router BSD1, it realizes that the > packet is too big, and sends an ICMP message back to the remote server. > Does that ICMP message make it through your outbound filters further > upstream? Perhaps. Will that message make it thorugh the firewalls > that are surely guarding the remote server? Let's hope so! This is > something that is not really under your control, so it's difficult to > say. Your best method of troubleshooting this might be to test from a > host outside your network to see if the ICMP packets from BSD1 are > making it through. > > -- > David DeSimone == Network Admin == fox@verio.net > "I don't like spinach, and I'm glad I don't, because if I > liked it I'd eat it, and I just hate it." -- Clarence Darrow > > > This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. > From sam at freebsd.org Tue Jan 27 19:17:40 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Jan 27 19:17:50 2009 Subject: iwi doesn't see a wireless network In-Reply-To: <20090127085941.5d642cde@memory.visualtech.com> References: <20090127085941.5d642cde@memory.visualtech.com> Message-ID: <497FCE52.9080800@freebsd.org> Adam K Kirchhoff wrote: > I'm trying to get my laptop to connect to the wireless access point at > work. It has a Intel Pro Wireless 2200BG minipci card, and can > associate with my access point at home. In addition, I can get an > Ubuntu 8.10 liveCD to connect to the access point at work via > NetworkManager. So there is definitely no incompatibility between the > wireless card and access point. > > Here's my wpa_supplicant.conf file: > > network={ > ssid="Mckella280Front" > key_mgmt=WPA-PSK > pairwise=TKIP > psk="#########" > } > > The preshared key is definitely correct, as it's the one that works > with the liveCD. For the sake of testing, I've removed the reference to > my wireless AP at home. > > I'm attaching the output from wpa_supplicant run with -dd. Basically, > it keeps scanning but only ever sees the tmobile network. That's > actually coming from another person in the building using a tmobile > wireless broadband card. If she's not here, the scan never picks up > anything. Similarly, 'ifconfig iwi0 list scan' only picks up the > tmobile ssid. > > Yet, if I reboot off the liveCD, it works. Here's the output of 'iwlist > eth1 scanning' under the liveCD: > > eth1 Scan completed : > Cell 01 - Address: 00:22:6B:9A:CC:AF > ESSID:"Mckella280Front" > Protocol:IEEE 802.11bg > Mode:Master > Frequency:2.457 GHz (Channel 10) > Encryption key:on > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s > 48 Mb/s; 54 Mb/s > Quality=50/100 Signal level=-68 dBm > IE: WPA Version 1 > Group Cipher : TKIP > Pairwise Ciphers (1) : TKIP > Authentication Suites (1) : PSK > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : TKIP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > Extra: Last beacon: 904ms ago > > > And, iwconfig while connected: > > eth1 IEEE 802.11g ESSID:"Mckella280Front" > Mode:Managed Frequency:2.457 GHz Access Point: 00:22:6B:9A:CC:AF > Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0 > Retry limit:7 RTS thr:off Fragment thr:off > Power Management:off > Link Quality=59/100 Signal level=-66 dBm Noise level=-87 dBm > Rx invalid nwid:0 Rx invalid crypt:6 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:3 > > The only thing I can think of is that the AP is using some feature that > the iwi driver, or wpa_supplicant, doesn't support. > > Is there someway to get this working? > > You don't indicate a freebsd version. Is your ap configured to hide the ssid? Sam From keramida at ceid.upatras.gr Tue Jan 27 20:16:38 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Tue Jan 27 20:16:44 2009 Subject: Need testers for a network cleanup patch In-Reply-To: <20090126093817.H45399@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 26 Jan 2009 09:39:23 +0000 (UTC)") References: <20090122225404.U45399@maildrop.int.zabbadoz.net> <20090126093817.H45399@maildrop.int.zabbadoz.net> Message-ID: <87ocxsm5xf.fsf@kobe.laptop> On Mon, 26 Jan 2009 09:39:23 +0000 (UTC), "Bjoern A. Zeeb" wrote: > On Thu, 22 Jan 2009, Bjoern A. Zeeb wrote: >> Before I am going to remove the initializations I made the two >> rip{,6}_output functions calling panic(). >> >> I have a patch for HEAD here: >> http://people.freebsd.org/~bz/20090122-03-pr_output.diff >> >> and one for 7-STABLE here (compiled but not booted): >> http://people.freebsd.org/~bz/20090122-04-pr_output-7STABLE.diff > > In case you tested, please let me know. Tested for around 4 days now. No panics :-) From adamk at voicenet.com Wed Jan 28 01:24:06 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Jan 28 01:24:13 2009 Subject: iwi doesn't see a wireless network In-Reply-To: <497FCE52.9080800@freebsd.org> References: <20090127085941.5d642cde@memory.visualtech.com> <497FCE52.9080800@freebsd.org> Message-ID: <20090128042315.6ec604f7@sorrow.ashke.com> On Tue, 27 Jan 2009 19:17:38 -0800 Sam Leffler wrote: > Adam K Kirchhoff wrote: > > I'm trying to get my laptop to connect to the wireless access point at > > work. It has a Intel Pro Wireless 2200BG minipci card, and can > > associate with my access point at home. In addition, I can get an > > Ubuntu 8.10 liveCD to connect to the access point at work via > > NetworkManager. So there is definitely no incompatibility between the > > wireless card and access point. > > > > Here's my wpa_supplicant.conf file: > > > > network={ > > ssid="Mckella280Front" > > key_mgmt=WPA-PSK > > pairwise=TKIP > > psk="#########" > > } > > > > The preshared key is definitely correct, as it's the one that works > > with the liveCD. For the sake of testing, I've removed the reference to > > my wireless AP at home. > > > > I'm attaching the output from wpa_supplicant run with -dd. Basically, > > it keeps scanning but only ever sees the tmobile network. That's > > actually coming from another person in the building using a tmobile > > wireless broadband card. If she's not here, the scan never picks up > > anything. Similarly, 'ifconfig iwi0 list scan' only picks up the > > tmobile ssid. > > > > Yet, if I reboot off the liveCD, it works. Here's the output of 'iwlist > > eth1 scanning' under the liveCD: > > > > eth1 Scan completed : > > Cell 01 - Address: 00:22:6B:9A:CC:AF > > ESSID:"Mckella280Front" > > Protocol:IEEE 802.11bg > > Mode:Master > > Frequency:2.457 GHz (Channel 10) > > Encryption key:on > > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s > > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s > > 48 Mb/s; 54 Mb/s > > Quality=50/100 Signal level=-68 dBm > > IE: WPA Version 1 > > Group Cipher : TKIP > > Pairwise Ciphers (1) : TKIP > > Authentication Suites (1) : PSK > > IE: IEEE 802.11i/WPA2 Version 1 > > Group Cipher : TKIP > > Pairwise Ciphers (1) : CCMP > > Authentication Suites (1) : PSK > > Extra: Last beacon: 904ms ago > > > > > > And, iwconfig while connected: > > > > eth1 IEEE 802.11g ESSID:"Mckella280Front" > > Mode:Managed Frequency:2.457 GHz Access Point: 00:22:6B:9A:CC:AF > > Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0 > > Retry limit:7 RTS thr:off Fragment thr:off > > Power Management:off > > Link Quality=59/100 Signal level=-66 dBm Noise level=-87 dBm > > Rx invalid nwid:0 Rx invalid crypt:6 Rx invalid frag:0 > > Tx excessive retries:0 Invalid misc:0 Missed beacon:3 > > > > The only thing I can think of is that the AP is using some feature that > > the iwi driver, or wpa_supplicant, doesn't support. > > > > Is there someway to get this working? > > > > > You don't indicate a freebsd version. Is your ap configured to hide the > ssid? > > Sam > > Sorry. This is: FreeBSD 7.1-STABLE #1: Fri Jan 23 11:41:10 EST 2009 And no, the AP does not hide the ssid. It shows up in NetworkManager on the LiveCD without any extra configuration (just asking for the key when I select it). But, just to be sure, I've tried setting scan_ssid to 1 in wpa_supplicant.conf, too, but that didn't change anything. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From per.hurtig at kau.se Wed Jan 28 02:49:26 2009 From: per.hurtig at kau.se (Per Hurtig (work)) Date: Wed Jan 28 02:49:33 2009 Subject: TCP gets special treatment? Message-ID: Hi, How differently are TCP packets treated compared to e.g. SCTP packets, while traversing the FreeBSD network stack (up to and including the IP-layer when using ipfw)?. I do not assume that the firewall (ipfw) is explicitly configured to check for established sessions or any TCP specifics. Are there a lot of TCP-specific optimizations conducted by lower layers anyways (besides possible checksum offloading)? BR, Per From emss at free.fr Wed Jan 28 05:32:48 2009 From: emss at free.fr (Eric Masson) Date: Wed Jan 28 05:32:55 2009 Subject: ipsec tunnels & conflicting networks Message-ID: <86eiynd0sp.fsf@srvbsdnanssv.interne.kisoft-services.com> Hello, Has anybody seen this entry on undeadly ? http://undeadly.org/cgi?action=article&sid=20090127205841 Is there some similar feature on FreeBSD (nat on enc0 & support in ike daemon) ? TIA Regards ?ric Masson -- >Sais-tu pourquoi les bidasses n'ont pas le droit de marcher au pas >sur les ponts ? si y'en ? un qui tombe, ils se suivent tous ? -+- Rom in Gnu - Un deux, un deux, un deux, un deuuuuuuuuuu... plouf-+- From eculp at encontacto.net Wed Jan 28 06:31:30 2009 From: eculp at encontacto.net (eculp) Date: Wed Jan 28 06:31:38 2009 Subject: Multiple ISP routing by port In-Reply-To: <200901270704.36034.max@love2party.net> References: <20090127051809.GA21017@fireburns.net> <200901270704.36034.max@love2party.net> Message-ID: <20090128082123.16165k6k6s2ftlgc@econet.encontacto.net> Quoting Max Laier : > On Tuesday 27 January 2009 06:18:09 jmaps-fbsdnet@fireburns.net wrote: >> I've read through what I could find in this list and also in the top 50 >> results on google... I can't find anything that'll actually make this work. >> >> My DSL ISP is too far away to give me anything faster than 1.5mbps down. In >> despiration I signed up for comcast to use for bulk traffic. >> >> Thus, I want to route critical traffic (22, 25, 53, (maybe) 80, 443) >> through the DSL provider and the rest through cable. >> >> I really feel like this should be possible with PF with something like: >> >> nat on $dsl_if from ($int_if:network) to any port $dslports -> ($dsl_if) >> nat on $cbl_if from ($int_if:network) to any -> ($cbl_if) >> >> or >> >> pass in quick on $int_if route-to { ($dsl_if $dsl_gw) } proto { tcp udp } >> from ($int_if:network) to any port $dslports >> >> Neither (or both) seem to do it. All traffic ends up getting routed through >> whichever ISP i have set as the default route. > > Take a look at: http://www.openbsd.org/faq/pf/pools.html#outgoing > I was aware of the round robin load balancing but I, as the poster, am interested in what is referred to "critical traffic" through one ISP and all other through a second. How would that be accomplished with pf and or with Julian's fib's ? Thanks, ed > You are probably missing the following part of the setup: > | To ensure that packets with a source address belonging to $ext_if1 are > | always routed to $ext_gw1 (and similarly for $ext_if2 and $ext_gw2), the > | following two lines should be included in the ruleset: > | > | pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \ > | to any > | pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \ > | to any > > This obviously has to be adapted for you specific setup - but in general this > works as expected. > >> Now, I hear i can go over to linux and just configure both default routes >> at the same time (trivial with iproute2). But I'd rather avoid that if at >> all possible. >> >> Is there some trick I'm missing? Does quagga (bgpd) allow for this kind of >> routing scheme? > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > 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 fox at verio.net Wed Jan 28 10:43:43 2009 From: fox at verio.net (David DeSimone) Date: Wed Jan 28 10:43:50 2009 Subject: MTU or Fragmentation Problems on 7.0? In-Reply-To: <27cb3ada0901271801u6d1db9cfhfb953073355db2d2@mail.gmail.com> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> <20090127064419.GC1284@verio.net> <27cb3ada0901271801u6d1db9cfhfb953073355db2d2@mail.gmail.com> Message-ID: <20090128184339.GD2436@verio.net> Len Gross wrote: > > I guess it is "good news" that this is a result of "common TCP > methodology." ;-> It can be good or bad. Just because it's common doesn't mean it always works. :) > BTW: The only firewall I've found in this setup is a Linksys WiFi > Router that that connects to a cable modem. Similar setup at a second > location with a WiFI router to DSL. Reduced MTU sizes are quite common with DSL setups, and so people using DSL are most likely to run into these issues. I should point out that most of the consumer DSL routers such as the Linksys you mentioned will perform a hack known as "MSS mangling". They will watch for TCP SYN packets being sent, and if the MSS is larger than would be supported by the Path MTU, they will change the MSS value to an acceptable value before forwarding it along. Since this causes the other endpoint to negotiate a smaller initial MSS, the connection "just works" in nearly all cases. This is probably the main reason why there has not been a huge outcry concerning rampant ICMP filtering breaking Path MTU Discovery. In fact, you may even want to investigate how you can start doing some MSS Mangling in your own setup. > One left over item to ponder. Why does Google work? Do they have a > packet size smaller than 1450 by "default"? More likely they use firewalls that forward ICMP traffic correctly, as that would be required. You should snoop on your BSD1 box to see if they are sending larger frames and whether your BSD1 box is sending ICMP responses back to them. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From yann.wanwanscappel at free.fr Wed Jan 28 12:01:08 2009 From: yann.wanwanscappel at free.fr (Yann WANWANSCAPPEL) Date: Wed Jan 28 12:01:16 2009 Subject: SCTP, possible bug in peer authentication key Message-ID: <4980B747.7070400@free.fr> Hi all, I think I found a bug in the SCTP authentication code, in sctp_load_addresses_from_init() in sctp_pcb.c keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + num_chunks + sizeof(*hmacs) + hmacs_len; The keylen calculation assumes the Chunk List Parameter (CHUNKS) vl-param was present in the received INIT packet, which can be false if peer SCTP does not require any chunk to be authenticated (this typically occurs if peer does not support ASCONF). >From RFC 4895, 6.1 * An SCTP endpoint has a list of chunks it only accepts if they are * received in an authenticated way. This list is included in the INIT * and INIT-ACK, and MAY be omitted if it is empty. Since this list * does not change during the lifetime of the SCTP endpoint there is no * problem in case of INIT collision. This case is properly handled later in the build of the key /* append in the AUTH chunks */ if (chunks != NULL) { ..... } I think the calculated keylen should be something like this : keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len; if (chunks != NULL) { keylen += sizeof(*chunks) + num_chunks } This problem results in authenticated packets sent from peer SCTP to be discarded. The problem does not occurs if peer SCTP is modified to send an empty Chunk List Parameter, (eg num_chunks = 0 in the decoding). Br, Yann From alexandre.perrin at epfl.ch Wed Jan 28 15:50:04 2009 From: alexandre.perrin at epfl.ch (Perrin Alexandre) Date: Wed Jan 28 15:50:14 2009 Subject: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Message-ID: <200901282350.n0SNo3of050225@freefall.freebsd.org> The following reply was made to PR kern/128917; it has been noted by GNATS. From: Perrin Alexandre To: bug-followup@FreeBSD.org, kitambi@epicsol.org Cc: Subject: Re: kern/128917: [wpi] [panic] if_wpi and wpa+tkip causing kernel panic Date: Wed, 28 Jan 2009 21:41:41 +0100 --H1spWtNR+x+ondvy Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I also got panic from wpi(4) with a WPA/TKIP network at home. I'm using 7.1-RELEASE on amd64: % uname -a FreeBSD FriBSD630 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Mon Jan 26 01:29:32 CET 2009 toor@FriBSD630:/usr/obj/usr/src/sys/KAWAROU amd64 Regards, Perrin Alexandre --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kgdb.txt" Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffff fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8066353c stack pointer = 0x10:0xffffffffb0004a90 frame pointer = 0x10:0xffffffffb0004bb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 33 (wpi0 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 7h42m19s Physical memory: 1514 MB Dumping 578 MB: 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 (CTRL-C to abort) 99 83 67 (CTRL-C to abort) 51 35 19 3 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /bootdir/boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /bootdir/boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /bootdir/boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff803fecc8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff803ff10c in panic (fmt=0xffffffff806b748f "%s") at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff8063f51c in trap_fatal (frame=0xffffff00012af000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:764 #4 0xffffffff8063f8e4 in trap_pfault (frame=0xffffffffb00049e0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680 #5 0xffffffff806402c2 in trap (frame=0xffffffffb00049e0) at /usr/src/sys/amd64/amd64/trap.c:449 #6 0xffffffff806257b3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffff8066353c in wpi_ops (arg0=Variable "arg0" is not available. ) at /usr/src/sys/dev/wpi/if_wpi.c:2411 #8 0xffffffff80434cbd in taskqueue_run (queue=0xffffff00012d8180) at /usr/src/sys/kern/subr_taskqueue.c:282 #9 0xffffffff80434f82 in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/subr_taskqueue.c:401 #10 0xffffffff803dc0df in fork_exit (callout=0xffffffff80434f10 , arg=0xffffffff80e4a0c0, frame=0xffffffffb0004c80) at /usr/src/sys/kern/kern_fork.c:804 #11 0xffffffff80625b8e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="network-infos.txt" bssid=00:02:cf:xx:xx:xx ssid=Nope id=1 pairwise_cipher=TKIP group_cipher=TKIP key_mgmt=WPA-PSK wpa_state=COMPLETED ip_address=192.168.1.X --y0ulUmNC+osPPQO6-- --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmAwwUACgkQ6rsYM89HSUBZlQCfeEbOEhJ81MuHu9u30iQUnLO+ lfQAn22xBmPwp+TTVRARURSB6t5K7rpq =1mVs -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From wahjava.ml at gmail.com Wed Jan 28 18:04:16 2009 From: wahjava.ml at gmail.com (Ashish SHUKLA) Date: Wed Jan 28 18:04:23 2009 Subject: Creating more than one interfaces pointing to the same gateway. Message-ID: <87bptqki6c.fsf@chateau.d.lf> Hi all, I've 2 ADSL connections (PPPoE) from the same ISP. The gateway (remote-endpoint) which I get after dialing both PPP connections is same, due to which I'm not able to use both connections in FreeBSD simultaneously. Last time, I checked I was using 6.2 and there is no such functionality present. I'm wondering if there is any patch which providing similar functionality exists somewhere waiting to be tested or committed in 8.0-CURRENT or 7.1-STABLE ? TiA -- Ashish SHUKLA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090129/d66f272a/attachment.pgp From linimon at lonesome.com Wed Jan 28 23:37:32 2009 From: linimon at lonesome.com (Mark Linimon) Date: Wed Jan 28 23:37:45 2009 Subject: reminder: bugathon upcoming this weekend Message-ID: <20090129073731.GB8695@soaustin.net> Starting this Friday, we are going to hold a bugathon to work through some of the network-related PRs. More details, and a list of resources, are available at http://wiki.freebsd.org/Bugathons/January2009. I have come up with a page that details a subset of those PRs as a set of suggested PRs: http://people.freebsd.org/~linimon/annotated_prs_bugathon.html Please join us to work through some PRs. Thanks! mcl From Michael.Tuexen at lurchi.franken.de Thu Jan 29 00:23:25 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Thu Jan 29 00:23:32 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: <4980B747.7070400@free.fr> References: <4980B747.7070400@free.fr> Message-ID: Hi Yann, very good catch! You are right. I have committed your patch to Randalls repository, so it will show up in the FreeBSD sources soon (next time he syncs them)... Best regards Michael On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: > Hi all, > > I think I found a bug in the SCTP authentication code, in > sctp_load_addresses_from_init() in sctp_pcb.c > > keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + > num_chunks + > sizeof(*hmacs) + hmacs_len; > > The keylen calculation assumes the Chunk List Parameter (CHUNKS) > vl-param was present in the received INIT packet, which can be false > if > peer SCTP does not require any chunk to be authenticated (this > typically > occurs if peer does not support ASCONF). > >> From RFC 4895, 6.1 > > * An SCTP endpoint has a list of chunks it only accepts if they are > * received in an authenticated way. This list is included in the INIT > * and INIT-ACK, and MAY be omitted if it is empty. Since this list > * does not change during the lifetime of the SCTP endpoint there is no > * problem in case of INIT collision. > > This case is properly handled later in the build of the key > > /* append in the AUTH chunks */ > if (chunks != NULL) { > ..... > } > > I think the calculated keylen should be something like this : > > keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len; > > if (chunks != NULL) { > keylen += sizeof(*chunks) + num_chunks > } > > This problem results in authenticated packets sent from peer SCTP to > be > discarded. > > The problem does not occurs if peer SCTP is modified to send an empty > Chunk List Parameter, (eg num_chunks = 0 in the decoding). > > Br, > Yann > > > > > > > > > > _______________________________________________ > 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 peter.lei at ieee.org Thu Jan 29 09:42:46 2009 From: peter.lei at ieee.org (Peter Lei) Date: Thu Jan 29 09:42:53 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: References: <4980B747.7070400@free.fr> Message-ID: <0EEEB325-C7AF-468F-9374-EFED1BD3B3E4@ieee.org> There's a corresponding change that is needed for pulling the auth info out of the cookie for the other direction (i.e. server side handling). I've committed that into the SCTP project repo, and should also get in with Randall's next commit. --peter On Jan 29, 2009, at 2:23 AM, Michael T?xen wrote: > Hi Yann, > > very good catch! You are right. > > I have committed your patch to Randalls repository, so it will > show up in the FreeBSD sources soon (next time he syncs them)... > > Best regards > Michael > > On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: > >> Hi all, >> >> I think I found a bug in the SCTP authentication code, in >> sctp_load_addresses_from_init() in sctp_pcb.c >> >> keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + >> num_chunks + >> sizeof(*hmacs) + hmacs_len; >> >> The keylen calculation assumes the Chunk List Parameter (CHUNKS) >> vl-param was present in the received INIT packet, which can be >> false if >> peer SCTP does not require any chunk to be authenticated (this >> typically >> occurs if peer does not support ASCONF). >> >>> From RFC 4895, 6.1 >> >> * An SCTP endpoint has a list of chunks it only accepts if they are >> * received in an authenticated way. This list is included in the >> INIT >> * and INIT-ACK, and MAY be omitted if it is empty. Since this list >> * does not change during the lifetime of the SCTP endpoint there is >> no >> * problem in case of INIT collision. >> >> This case is properly handled later in the build of the key >> >> /* append in the AUTH chunks */ >> if (chunks != NULL) { >> ..... >> } >> >> I think the calculated keylen should be something like this : >> >> keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len; >> >> if (chunks != NULL) { >> keylen += sizeof(*chunks) + num_chunks >> } >> >> This problem results in authenticated packets sent from peer SCTP >> to be >> discarded. >> >> The problem does not occurs if peer SCTP is modified to send an empty >> Chunk List Parameter, (eg num_chunks = 0 in the decoding). >> >> Br, >> Yann >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Michael.Tuexen at lurchi.franken.de Thu Jan 29 10:34:19 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Thu Jan 29 10:34:25 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: <0EEEB325-C7AF-468F-9374-EFED1BD3B3E4@ieee.org> References: <4980B747.7070400@free.fr> <0EEEB325-C7AF-468F-9374-EFED1BD3B3E4@ieee.org> Message-ID: <47807A97-0CD3-4E7A-A659-00139086B97F@lurchi.franken.de> Hi Peter, good catch! Best regards Michael On Jan 29, 2009, at 6:29 PM, Peter Lei wrote: > There's a corresponding change that is needed for pulling the auth > info > out of the cookie for the other direction (i.e. server side > handling). I've > committed that into the SCTP project repo, and should also get in with > Randall's next commit. > > --peter > > On Jan 29, 2009, at 2:23 AM, Michael T?xen wrote: > >> Hi Yann, >> >> very good catch! You are right. >> >> I have committed your patch to Randalls repository, so it will >> show up in the FreeBSD sources soon (next time he syncs them)... >> >> Best regards >> Michael >> >> On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: >> >>> Hi all, >>> >>> I think I found a bug in the SCTP authentication code, in >>> sctp_load_addresses_from_init() in sctp_pcb.c >>> >>> keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + >>> num_chunks + >>> sizeof(*hmacs) + hmacs_len; >>> >>> The keylen calculation assumes the Chunk List Parameter (CHUNKS) >>> vl-param was present in the received INIT packet, which can be >>> false if >>> peer SCTP does not require any chunk to be authenticated (this >>> typically >>> occurs if peer does not support ASCONF). >>> >>>> From RFC 4895, 6.1 >>> >>> * An SCTP endpoint has a list of chunks it only accepts if they are >>> * received in an authenticated way. This list is included in the >>> INIT >>> * and INIT-ACK, and MAY be omitted if it is empty. Since this list >>> * does not change during the lifetime of the SCTP endpoint there >>> is no >>> * problem in case of INIT collision. >>> >>> This case is properly handled later in the build of the key >>> >>> /* append in the AUTH chunks */ >>> if (chunks != NULL) { >>> ..... >>> } >>> >>> I think the calculated keylen should be something like this : >>> >>> keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + >>> hmacs_len; >>> >>> if (chunks != NULL) { >>> keylen += sizeof(*chunks) + num_chunks >>> } >>> >>> This problem results in authenticated packets sent from peer SCTP >>> to be >>> discarded. >>> >>> The problem does not occurs if peer SCTP is modified to send an >>> empty >>> Chunk List Parameter, (eg num_chunks = 0 in the decoding). >>> >>> Br, >>> Yann >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 adamk at voicenet.com Thu Jan 29 11:35:25 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Thu Jan 29 11:35:32 2009 Subject: iwi doesn't see a wireless network In-Reply-To: <20090128042315.6ec604f7@sorrow.ashke.com> References: <20090127085941.5d642cde@memory.visualtech.com> <497FCE52.9080800@freebsd.org> <20090128042315.6ec604f7@sorrow.ashke.com> Message-ID: <20090129143414.67a0be59@scroll> On Wed, 28 Jan 2009 04:23:15 -0500 Adam K Kirchhoff wrote: > On Tue, 27 Jan 2009 19:17:38 -0800 > Sam Leffler wrote: > > > Adam K Kirchhoff wrote: > > > I'm trying to get my laptop to connect to the wireless access point at > > > work. It has a Intel Pro Wireless 2200BG minipci card, and can > > > associate with my access point at home. In addition, I can get an > > > Ubuntu 8.10 liveCD to connect to the access point at work via > > > NetworkManager. So there is definitely no incompatibility between the > > > wireless card and access point. > > > > > > Here's my wpa_supplicant.conf file: > > > > > > network={ > > > ssid="Mckella280Front" > > > key_mgmt=WPA-PSK > > > pairwise=TKIP > > > psk="#########" > > > } > > > > > > The preshared key is definitely correct, as it's the one that works > > > with the liveCD. For the sake of testing, I've removed the reference to > > > my wireless AP at home. > > > > > > I'm attaching the output from wpa_supplicant run with -dd. Basically, > > > it keeps scanning but only ever sees the tmobile network. That's > > > actually coming from another person in the building using a tmobile > > > wireless broadband card. If she's not here, the scan never picks up > > > anything. Similarly, 'ifconfig iwi0 list scan' only picks up the > > > tmobile ssid. > > > > > > Yet, if I reboot off the liveCD, it works. Here's the output of 'iwlist > > > eth1 scanning' under the liveCD: > > > > > > eth1 Scan completed : > > > Cell 01 - Address: 00:22:6B:9A:CC:AF > > > ESSID:"Mckella280Front" > > > Protocol:IEEE 802.11bg > > > Mode:Master > > > Frequency:2.457 GHz (Channel 10) > > > Encryption key:on > > > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s > > > 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s > > > 48 Mb/s; 54 Mb/s > > > Quality=50/100 Signal level=-68 dBm > > > IE: WPA Version 1 > > > Group Cipher : TKIP > > > Pairwise Ciphers (1) : TKIP > > > Authentication Suites (1) : PSK > > > IE: IEEE 802.11i/WPA2 Version 1 > > > Group Cipher : TKIP > > > Pairwise Ciphers (1) : CCMP > > > Authentication Suites (1) : PSK > > > Extra: Last beacon: 904ms ago > > > > > > > > > And, iwconfig while connected: > > > > > > eth1 IEEE 802.11g ESSID:"Mckella280Front" > > > Mode:Managed Frequency:2.457 GHz Access Point: 00:22:6B:9A:CC:AF > > > Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0 > > > Retry limit:7 RTS thr:off Fragment thr:off > > > Power Management:off > > > Link Quality=59/100 Signal level=-66 dBm Noise level=-87 dBm > > > Rx invalid nwid:0 Rx invalid crypt:6 Rx invalid frag:0 > > > Tx excessive retries:0 Invalid misc:0 Missed beacon:3 > > > > > > The only thing I can think of is that the AP is using some feature that > > > the iwi driver, or wpa_supplicant, doesn't support. > > > > > > Is there someway to get this working? > > > > > > > > You don't indicate a freebsd version. Is your ap configured to hide the > > ssid? > > > > Sam > > > > > > Sorry. This is: FreeBSD 7.1-STABLE #1: Fri Jan 23 11:41:10 EST 2009 > > And no, the AP does not hide the ssid. It shows up in NetworkManager > on the LiveCD without any extra configuration (just asking for the key > when I select it). But, just to be sure, I've tried setting scan_ssid > to 1 in wpa_supplicant.conf, too, but that didn't change anything. > > Adam If there are no other ideas, I'll go ahead and open up a pr about this. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From steve at ibctech.ca Thu Jan 29 16:25:37 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Jan 29 16:25:44 2009 Subject: Certain traffic not being routed as expected Message-ID: <498248F6.2080806@ibctech.ca> Hi everyone, I have a strange issue, and am hoping that I am just missing something simple. I apologize for the length, but I'm at a complete loss. I learn the IPv4 BOGON from Cymru via BGP, and here is one route currently in my routing table: 192.168.0.0/16 192.168.222.1 UG1 0 408084 disc0 I've been trying to clean up certain leaky private IP space, so to find out if things are being dropped accordingly on the router, I implemented a few counts in IPFW. For the most part, they work ok: Jan 29 18:59:35 lanx kernel: ipfw: 30 Count UDP 208.70.107.130:138 10.0.3.12:138 in via em6 Jan 29 18:59:35 lanx kernel: ipfw: 32 Count UDP 208.70.107.130:138 10.0.3.12:138 out via disc0 However, I have a couple of stubborn prefixes that march their way right through (in one physical interface, and out another): Jan 29 18:59:59 lanx kernel: ipfw: 34 Count TCP 192.168.100.21:3720 208.70.106.58:25 in via em0 Jan 29 18:59:59 lanx kernel: ipfw: 36 Count TCP 192.168.100.21:3720 208.70.106.58:25 out via em4 I can verify that the space is routed properly (via Quagga): lanx# sh ip route 192.168.100.21 Routing entry for 192.168.0.0/16 Known via "bgp", distance 20, metric 0, best Last update 01w3d10h ago * 192.168.222.1, via disc0 ...and if I ping it from my workstation (NAT'd via office gateway, attached to em1 on the router), it is null-routed properly: C:\Documents and Settings\steve>ping 192.168.100.21 Pinging 192.168.100.21 with 32 bytes of data: Control-C ^C Jan 29 19:19:17 lanx-eagle-noc kernel: ipfw: 30 Count ICMP:8.0 208.70.104.100 192.168.100.21 in via em1 Jan 29 19:19:17 lanx-eagle-noc kernel: ipfw: 32 Count ICMP:8.0 208.70.104.100 192.168.100.21 out via disc0 Does anyone have any idea why certain packets with private IP space are not being routed to null correctly? Could this be some form of evasive technique to avoid hitting the kernel route? Steve From steve at ibctech.ca Thu Jan 29 16:36:07 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Jan 29 16:36:13 2009 Subject: Certain traffic not being routed as expected In-Reply-To: <498248F6.2080806@ibctech.ca> References: <498248F6.2080806@ibctech.ca> Message-ID: <49824B6C.4030801@ibctech.ca> Steve Bertrand wrote: > Hi everyone, ...hrm...never mind. I was trying too hard to think again... The traffic was allowed through, obviously because the _destination_ is allowed to be routed. I have no idea why I had such a lapse of sense ;) Sorry for the noise. *hangs head* Steve From Matt.Muggeridge at hp.com Thu Jan 29 17:55:48 2009 From: Matt.Muggeridge at hp.com (Muggeridge, Matt) Date: Thu Jan 29 17:55:55 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: References: <4980B747.7070400@free.fr> Message-ID: > I think I found a bug in the SCTP authentication code, in > sctp_load_addresses_from_init() in sctp_pcb.c I noticed the same calculation appears in sctp_auth.c:sctp_auth_get_cookie_params(). Does this fix also need to be applied there? Cheers, Matt. -----Original Message----- From: Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] Sent: Thursday, 29 January 2009 6:23 PM To: Yann WANWANSCAPPEL Cc: freebsd-net@freebsd.org Subject: Re: SCTP, possible bug in peer authentication key Hi Yann, very good catch! You are right. I have committed your patch to Randalls repository, so it will show up in the FreeBSD sources soon (next time he syncs them)... Best regards Michael On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: > Hi all, > > I think I found a bug in the SCTP authentication code, in > sctp_load_addresses_from_init() in sctp_pcb.c > > keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + num_chunks > + > sizeof(*hmacs) + hmacs_len; > > The keylen calculation assumes the Chunk List Parameter (CHUNKS) > vl-param was present in the received INIT packet, which can be false > if peer SCTP does not require any chunk to be authenticated (this > typically occurs if peer does not support ASCONF). > >> From RFC 4895, 6.1 > > * An SCTP endpoint has a list of chunks it only accepts if they are > * received in an authenticated way. This list is included in the INIT > * and INIT-ACK, and MAY be omitted if it is empty. Since this list > * does not change during the lifetime of the SCTP endpoint there is no > * problem in case of INIT collision. > > This case is properly handled later in the build of the key > > /* append in the AUTH chunks */ > if (chunks != NULL) { > ..... > } > > I think the calculated keylen should be something like this : > > keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len; > > if (chunks != NULL) { > keylen += sizeof(*chunks) + num_chunks } > > This problem results in authenticated packets sent from peer SCTP to > be discarded. > > The problem does not occurs if peer SCTP is modified to send an empty > Chunk List Parameter, (eg num_chunks = 0 in the decoding). > > Br, > Yann > > > > > > > > > > _______________________________________________ > 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 Michael.Tuexen at lurchi.franken.de Fri Jan 30 00:41:54 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Jan 30 00:42:02 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: References: <4980B747.7070400@free.fr> Message-ID: <0D5E2F07-ABE5-46D8-8060-570E4B2AFD71@lurchi.franken.de> Hi Matt, Peter Lei (who wrote the AUTH code) already fixed that in Randalls CVS server. So it will show up when Randall syncs the repositories next time. Thank you for pointing that out. I missed that... Best regards Michael On Jan 30, 2009, at 2:37 AM, Muggeridge, Matt wrote: >> I think I found a bug in the SCTP authentication code, in >> sctp_load_addresses_from_init() in sctp_pcb.c > > I noticed the same calculation appears in > sctp_auth.c:sctp_auth_get_cookie_params(). Does this fix also need > to be applied there? > > Cheers, > Matt. > > -----Original Message----- > From: Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Thursday, 29 January 2009 6:23 PM > To: Yann WANWANSCAPPEL > Cc: freebsd-net@freebsd.org > Subject: Re: SCTP, possible bug in peer authentication key > > Hi Yann, > > very good catch! You are right. > > I have committed your patch to Randalls repository, so it will show > up in the FreeBSD sources soon (next time he syncs them)... > > Best regards > Michael > > On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: > >> Hi all, >> >> I think I found a bug in the SCTP authentication code, in >> sctp_load_addresses_from_init() in sctp_pcb.c >> >> keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + >> num_chunks >> + >> sizeof(*hmacs) + hmacs_len; >> >> The keylen calculation assumes the Chunk List Parameter (CHUNKS) >> vl-param was present in the received INIT packet, which can be false >> if peer SCTP does not require any chunk to be authenticated (this >> typically occurs if peer does not support ASCONF). >> >>> From RFC 4895, 6.1 >> >> * An SCTP endpoint has a list of chunks it only accepts if they are >> * received in an authenticated way. This list is included in the >> INIT >> * and INIT-ACK, and MAY be omitted if it is empty. Since this list >> * does not change during the lifetime of the SCTP endpoint there is >> no >> * problem in case of INIT collision. >> >> This case is properly handled later in the build of the key >> >> /* append in the AUTH chunks */ >> if (chunks != NULL) { >> ..... >> } >> >> I think the calculated keylen should be something like this : >> >> keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len; >> >> if (chunks != NULL) { >> keylen += sizeof(*chunks) + num_chunks } >> >> This problem results in authenticated packets sent from peer SCTP to >> be discarded. >> >> The problem does not occurs if peer SCTP is modified to send an empty >> Chunk List Parameter, (eg num_chunks = 0 in the decoding). >> >> Br, >> Yann >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 bz at FreeBSD.org Fri Jan 30 02:07:56 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Jan 30 02:08:02 2009 Subject: kern/131038: [ip6] [panic] kernel panic in ip6_forward Message-ID: <200901301007.n0UA7tPG064021@freefall.freebsd.org> Synopsis: [ip6] [panic] kernel panic in ip6_forward Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Jan 30 10:07:16 UTC 2009 Responsible-Changed-Why: /* GIANT_REQUIRED; */ /* XXX bz: ip6_forward_rt */ I think I once thought it was mine and we should finally fix this;) http://www.freebsd.org/cgi/query-pr.cgi?pr=131038 From linimon at FreeBSD.org Fri Jan 30 04:06:50 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 30 04:06:57 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200901301206.n0UC6ZbK057797@freefall.freebsd.org> Synopsis: [iwi] iwi doesn't see a wireless network Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 30 12:06:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131153 From francovitali at gmail.com Fri Jan 30 04:44:10 2009 From: francovitali at gmail.com (Franco Vitali) Date: Fri Jan 30 04:44:16 2009 Subject: PPP won t reconnect Message-ID: I search the web for an answer, but i can?t find it. There are only unanswered posts, and some of them tell that there is a bug in PPP. I have a production machine with a RELENG_7 and a connection with the cable provider via PPP. The problem is that, when the connection drops, PPP remains like nothing happens, not even a log (even if i plug the ethernet cable). And, ovbiously, doesn't reconnect. In theory, the daemon must reconnect in "ddial" mode. What I am missing ? The configuration files are as folows: -------------------------------------------------------------------- /etc/rc.conf hostname="vnet01.vnet" gateway_enable="YES" firewall_enable="YES" firewall_type="open" firewall_nat_enable="YES" firewall_nat_interface="tun0" firewall_nat_flags="-f /etc/natd.conf" dummynet_enable="YES" ifconfig_rl0="inet 192.168.2.9 netmask 255.255.255.0" keymap="us.iso" sshd_enable="YES" ........ ddclient_enable="YES" ppp_enable="YES" ppp_mode="ddial" ppp_nat="NO" ppp_profile="bvc" ppp_user="root" -------------------------------------------------------------------- /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command bvc: set device PPPoE:ed0 set authname "******" set authkey "*******" set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 set dial set login enable dns add default HISADDR -------------------------------------------------------------------- /etc/natd.conf interface tun0 use_sockets yes same_ports yes dynamic yes -------------------------------------------------------------------- ifconfig -a ed0: flags=8843 metric 0 mtu 1500 ether 00:00:21:6a:0b:4c media: Ethernet autoselect (10baseT/UTP) rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:e0:7d:e1:52:b4 inet 192.168.2.9 netmask 0xffffff00 broadcast 192.168.2.255 media: Ethernet autoselect (none) status: no carrier plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 metric 0 mtu 1478 inet 190.97.1.31 --> 190.97.1.1 netmask 0xffffff00 Opened by PID 1174 tun1: flags=8010 metric 0 mtu 1500 -------------------------------------------------------------------- netstat -rn Internet: Destination Gateway Flags Refs Use Netif Expire default 190.97.1.1 UGS 1 7591577 tun0 127.0.0.1 127.0.0.1 UH 0 678 lo0 190.97.1.1 190.97.1.31 UGH 1 0 tun0 192.168.2.0/24 link#2 UC 0 0 rl0 -------------------------------------------------------------------- From adamk at voicenet.com Fri Jan 30 05:30:12 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Jan 30 05:30:18 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200901301330.n0UDUBfo019139@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@freebsd.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Fri, 30 Jan 2009 08:05:18 -0500 --Boundary-00=_OsvgJ5oUYAgR+Tz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Though the SSID is not hidden, I have also tried with scan_ssid=1 in my wpa_supplicant.conf file, but the results are the exact same. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary-00=_OsvgJ5oUYAgR+Tz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Though the SSID is not hidden, I have also tried with scan_ssid=1 in my wpa_supplicant.conf file, but the results are the exact same.

Adam


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary-00=_OsvgJ5oUYAgR+Tz-- From adamk at voicenet.com Fri Jan 30 05:59:57 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Jan 30 06:00:04 2009 Subject: atheros 5212 problems on -STABLE Message-ID: <200901300858.12029.adamk@voicenet.com> Since the iwi driver doesn't want to join the wireless network at work (I opened up a pr for it), I decided to try the ath driver instead. The card is an Atheros 5212. Unfortunately, I'm having even more serious problems with this card: ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3302560252 ath0: ath_chan_set: unable to reset channel 52 (5260 Mhz, flags 0x140 hal flags 0x140), hal status 3296823488 ath0: ath_chan_set: unable to reset channel 56 (5280 Mhz, flags 0x140 hal flags 0x140), hal status 0 ath0: ath_chan_set: unable to reset channel 60 (5300 Mhz, flags 0x140 hal flags 0x140), hal status 3304978572 It cycles through various channels till: ath0: device timeout ath0: ath_reset: unable to reset hardware; hal status 3232887468 And then it starts with the "unable to reset channel" errors again. This continues till I run '/etc/rc.d/netif stop ath0' When I go to remove the card, the kernel panics: panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: enter: panic [thread pid 34 tid 100033 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> bt Tracing pid 34 tid 100033 td 0xc4988690 kdb_enter_why(c0b5759f,c0b5759f,c0b591cd,e5070bc4,0,...) at kdb_enter_why+0x3a panic(c0b591cd,3,10,0,c49f91c0,...) at panic+0x136 resource_list_release(c4b6bc04,c494ab80,c49f8900,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c494ab80,c49f8900,3,10,c49f9480) at bus_generic_rl_release_resource+0x77 bus_release_resource(c49f8900,3,10,c49f9480,c49f8900,...) at bus_release_resource+0x67 ath_pci_detach(c49f8900,c48a1858,c0c15b60,c07c8125,4,...) at ath_pci_detach+0xb2 device_detach(c49f8900,e5070cac,e5070cb0,c4988690,e5070cc0,...) at device_detach+0x68 cardbus_detach_card(c494ab80,c48b08e0,c0bd2bfc,0,0,...) at cardbus_detach_card+0xcd cbb_event_thread(c4913800,e5070d38,0,0,0,...) at cbb_event_thread+0x1ac fork_exit(c0661a50,c4913800,e5070d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe5070d70, ebp = 0 --- Just as with the iwi driver, this is on 7.1-STABLE... Built today (with DDB and KDB) but originally pulled from cvsup on January 15th. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gpalmer at freebsd.org Fri Jan 30 08:08:10 2009 From: gpalmer at freebsd.org (Gary Palmer) Date: Fri Jan 30 08:08:16 2009 Subject: PPP won t reconnect In-Reply-To: References: Message-ID: <20090130160808.GG81380@in-addr.com> On Fri, Jan 30, 2009 at 09:16:17AM -0300, Franco Vitali wrote: > I search the web for an answer, but i can?t find it. There are only > unanswered posts, and some of them tell that there is a bug in PPP. > > I have a production machine with a RELENG_7 and a connection with the cable > provider via PPP. > > The problem is that, when the connection drops, PPP remains like nothing > happens, not even a log (even if i plug the ethernet cable). And, ovbiously, > doesn't reconnect. In theory, the daemon must reconnect in "ddial" mode. > What I am missing ? try adding accept lqr enable lqr enable echo set echoperiod 15 to either the default or provider-specific section of ppp.conf to enable ppp to check the link is alive. After so many failed echo or lqr packets it'll drop the connection and redial. The above is copied&pasted from my PPPoE config which definitely does detect the remote end going away and redialing. Regards, Gary From linimon at FreeBSD.org Fri Jan 30 09:52:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jan 30 09:52:11 2009 Subject: kern/131162: [ath] Atheros driver bugginess and kernel crashes Message-ID: <200901301752.n0UHq27f023636@freefall.freebsd.org> Synopsis: [ath] Atheros driver bugginess and kernel crashes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 30 17:51:54 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131162 From bz at FreeBSD.org Fri Jan 30 11:44:18 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Jan 30 11:44:41 2009 Subject: kern/128247: [ip6] [panic] Fatal Trap 12 in ip6_forward = Message-ID: <200901301944.n0UJiHWp011514@freefall.freebsd.org> Synopsis: [ip6] [panic] Fatal Trap 12 in ip6_forward = State-Changed-From-To: open->analyzed State-Changed-By: bz State-Changed-When: Fri Jan 30 19:42:35 UTC 2009 State-Changed-Why: I have been tracking this issue for kern/131038 and the submitter is trying a patch currently. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Jan 30 19:42:35 UTC 2009 Responsible-Changed-Why: I am working on it atm as rwatson had flagged the problem for me in 2008: /* GIANT_REQUIRED; */ /* XXX bz: ip6_forward_rt */ http://www.freebsd.org/cgi/query-pr.cgi?pr=128247 From vwe at FreeBSD.org Fri Jan 30 11:48:56 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 11:49:02 2009 Subject: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections Message-ID: <200901301948.n0UJmt5a011677@freefall.freebsd.org> Synopsis: [tcp] Turning on TCP blackholing causes slow localhost connections State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Fri Jan 30 19:45:46 UTC 2009 State-Changed-Why: Tom, we think this issue either is not related to the tcp stack or not directly related to blackholing connections. It might be an application issue. As we do not think there's something we can work on, we're going to close this PR. If you think there should be something fixed, please put more information into the PR so we can check that. Thank you for reporting this problem. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Fri Jan 30 19:45:46 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=123881 From vwe at FreeBSD.org Fri Jan 30 11:56:07 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 11:56:23 2009 Subject: kern/123617: [tcp] breaking connection when client downloading files from server Message-ID: <200901301956.n0UJu5OC027108@freefall.freebsd.org> Synopsis: [tcp] breaking connection when client downloading files from server State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Fri Jan 30 19:53:56 UTC 2009 State-Changed-Why: Tomasz, can you give us the output of `ifconfig re0`, output of `vmstat -ia` and `devinfo -rv`, `sysctl net`, please? Also, are you using a firewall on your (server-)machine? Do you seen similar problems with or without the firewall being active? http://www.freebsd.org/cgi/query-pr.cgi?pr=123617 From bz at FreeBSD.org Fri Jan 30 12:20:06 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jan 30 12:20:12 2009 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? Message-ID: <200901302020.n0UKK5Qa042215@freefall.freebsd.org> The following reply was made to PR conf/128030; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, lionel.fourquaux+fbsdbug@normalesup.org Cc: Subject: Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? Date: Fri, 30 Jan 2009 20:10:45 +0000 (UTC) Hi, the problem here is that enabling IPsec adds overhead to the entire IPv4/v6 network stack handling. A lot of people are currently working on performnce optimizations for all kinds of different setups. All those would be hurt if IPSEC would be on by default and they wouldn't need it. That's all kinds of various ISP server business for example. If we want to enable IPSEC by default on GENERIC the criteria to fix is "it must not measurably add up to processing times/reduce pps/.." if the connections do not use it. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From adamk at voicenet.com Fri Jan 30 12:40:07 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Jan 30 12:40:23 2009 Subject: kern/131162: [ath] Atheros driver bugginess and kernel crashes Message-ID: <200901302040.n0UKe6Y3058673@freefall.freebsd.org> The following reply was made to PR kern/131162; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@freebsd.org, adamk@voicenet.com Cc: Subject: Re: kern/131162: [ath] Atheros driver bugginess and kernel crashes Date: Fri, 30 Jan 2009 15:28:06 -0500 --Boundary-00=_WL2gJ+Gh8LSctaB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The exact same system (card + laptop) works just fine on my 802.11g network at home. This bug, combined with http://www.freebsd.org/cgi/query-pr.cgi?pr=131153 makes me think that there is some problem with FreeBSD wireless stack when it comes to the Linksys WAP4400N Business Edition. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary-00=_WL2gJ+Gh8LSctaB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

The exact same system (card + laptop) works just fine on my 802.11g network at home. This bug, combined with http://www.freebsd.org/cgi/query-pr.cgi?pr=131153 makes me think that there is some problem with FreeBSD wireless stack when it comes to the Linksys WAP4400N Business Edition.

Adam


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary-00=_WL2gJ+Gh8LSctaB-- From vwe at FreeBSD.org Fri Jan 30 12:59:08 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 12:59:14 2009 Subject: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) Message-ID: <200901302059.n0UKx7q6072651@freefall.freebsd.org> Synopsis: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Fri Jan 30 20:56:25 UTC 2009 State-Changed-Why: Paulo, is your PR still valid? If you, can you please check if it's not an ACPI issue by using `sysctl hw.acpi.handle_reboot`? Personally I've used several ath cards on several mainboards and have never seen your problem. Can you please check that issue with a recent release of freebsd? 6.0 has been EOL'd some time ago. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Fri Jan 30 20:56:25 UTC 2009 Responsible-Changed-Why: -> net@ http://www.freebsd.org/cgi/query-pr.cgi?pr=87758 From vwe at FreeBSD.org Fri Jan 30 14:10:14 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 14:10:20 2009 Subject: kern/116444: [ath] Atheros 5005G (AR5212) miniPCI: unable to attach device hal status 3 Message-ID: <200901302210.n0UMADrf026524@freefall.freebsd.org> Synopsis: [ath] Atheros 5005G (AR5212) miniPCI: unable to attach device hal status 3 State-Changed-From-To: open->suspended State-Changed-By: vwe State-Changed-When: Fri Jan 30 22:06:41 UTC 2009 State-Changed-Why: Stephane, without seeing any details at all (the madwifi ticket URL is also invalid) there's nothing we can do about your issue. Please feel free to give us device specific information like a verbose boot dmesg, pciconf -lv, devinfo -rv and the like. Also if you think your issue should be worked out, please check a more recent relase of FreeBSD. Thank you for reporting! As we think we're unable to do anything for this problem ATM, we're suspending this PR. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Fri Jan 30 22:06:41 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=116444 From vwe at FreeBSD.org Fri Jan 30 14:24:19 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 14:24:26 2009 Subject: kern/119345: [ath] Unsuported Atheros 5424/2424 and CPU speedstep not recognized Message-ID: <200901302224.n0UMOIkd041479@freefall.freebsd.org> Synopsis: [ath] Unsuported Atheros 5424/2424 and CPU speedstep not recognized State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Fri Jan 30 22:22:47 UTC 2009 State-Changed-Why: Veselin, for your est issues, you should check for a BIOS update as your acpi code seems to be broken. I'm wondering if you can show us output of `pciconf -lv`? Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Fri Jan 30 22:22:47 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=119345 From vwe at FreeBSD.org Fri Jan 30 14:34:31 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri Jan 30 14:34:42 2009 Subject: kern/122957: [ath] [patch] ath_hal is too verbose when booting Message-ID: <200901302234.n0UMYUlA050733@freefall.freebsd.org> Synopsis: [ath] [patch] ath_hal is too verbose when booting Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Fri Jan 30 22:34:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122957 From thompsa at FreeBSD.org Fri Jan 30 14:43:46 2009 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Fri Jan 30 14:43:53 2009 Subject: kern/122957: [ath] [patch] ath_hal is too verbose when booting Message-ID: <200901302243.n0UMhjrp058152@freefall.freebsd.org> Synopsis: [ath] [patch] ath_hal is too verbose when booting State-Changed-From-To: open->closed State-Changed-By: thompsa State-Changed-When: Fri Jan 30 22:42:16 UTC 2009 State-Changed-Why: This is needed since the hal is 3rd party in FreeBSD7 and below, this no longer applies to current so closing. http://www.freebsd.org/cgi/query-pr.cgi?pr=122957 From brucec at FreeBSD.org Fri Jan 30 14:48:11 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 14:48:18 2009 Subject: bin/85445: ifconfig(8): deprecated keyword to ifconfig inoperative Message-ID: <200901302248.n0UMmAxR058363@freefall.freebsd.org> Synopsis: ifconfig(8): deprecated keyword to ifconfig inoperative Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 22:47:29 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=85445 From brucec at FreeBSD.org Fri Jan 30 14:49:16 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 14:49:23 2009 Subject: bin/116198: ifconfig(8): ifconfig illegal option -- n dhclient fails Message-ID: <200901302249.n0UMn6Ji058535@freefall.freebsd.org> Synopsis: ifconfig(8): ifconfig illegal option -- n dhclient fails Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 22:48:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116198 From brucec at FreeBSD.org Fri Jan 30 14:49:45 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 14:49:56 2009 Subject: bin/128954: ifconfig(8) deletes valid routes Message-ID: <200901302249.n0UMnhcl058619@freefall.freebsd.org> Synopsis: ifconfig(8) deletes valid routes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 22:49:20 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128954 From brucec at FreeBSD.org Fri Jan 30 14:51:41 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 14:51:55 2009 Subject: kern/115002: [wi] if_wi timeout. failed allocation (busy bit). ifconfig and dhclient issues. kernel panic ensues (backtrace included) Message-ID: <200901302251.n0UMpdIq065490@freefall.freebsd.org> Synopsis: [wi] if_wi timeout. failed allocation (busy bit). ifconfig and dhclient issues. kernel panic ensues (backtrace included) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 22:50:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=115002 From thompsa at FreeBSD.org Fri Jan 30 14:59:29 2009 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Fri Jan 30 14:59:38 2009 Subject: bin/116198: ifconfig(8): ifconfig illegal option -- n dhclient fails Message-ID: <200901302259.n0UMxRPQ065615@freefall.freebsd.org> Synopsis: ifconfig(8): ifconfig illegal option -- n dhclient fails State-Changed-From-To: open->closed State-Changed-By: thompsa State-Changed-When: Fri Jan 30 22:56:02 UTC 2009 State-Changed-Why: The 'ifconfig -n' changes were not merged to sbin/dhclient/dhclient-script until after 6.2 was branched (r1.4.2.5), this is a case of out of sync sources. http://www.freebsd.org/cgi/query-pr.cgi?pr=116198 From brucec at FreeBSD.org Fri Jan 30 15:13:53 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 15:13:59 2009 Subject: kern/115019: [netgraph] ng_ether upper hook packet flow stops on adding ethernet interface to ifconfig bridge Message-ID: <200901302313.n0UNDq8t080315@freefall.freebsd.org> Synopsis: [netgraph] ng_ether upper hook packet flow stops on adding ethernet interface to ifconfig bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 23:13:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=115019 From bz at FreeBSD.org Fri Jan 30 15:15:05 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Jan 30 15:15:11 2009 Subject: kern/129793: [ip6] [patch] Locking related leaks in the kernel (routing handling) Message-ID: <200901302315.n0UNF3Na080893@freefall.freebsd.org> Synopsis: [ip6] [patch] Locking related leaks in the kernel (routing handling) State-Changed-From-To: open->analyzed State-Changed-By: bz State-Changed-When: Fri Jan 30 23:13:14 UTC 2009 State-Changed-Why: Found more new code with the same problems. I have to ponder a bit more on the in6_ifattach.c one before going to commit things. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Jan 30 23:13:14 UTC 2009 Responsible-Changed-Why: I had a look, so handle this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=129793 From brucec at FreeBSD.org Fri Jan 30 15:15:15 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 15:15:26 2009 Subject: bin/82975: route change does not parse classfull network as given in netstat Message-ID: <200901302315.n0UNFCiB080954@freefall.freebsd.org> Synopsis: route change does not parse classfull network as given in netstat Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 23:14:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=82975 From brucec at FreeBSD.org Fri Jan 30 15:15:49 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 15:15:56 2009 Subject: kern/71469: default route to internet magically disappears with multihomed server Message-ID: <200901302315.n0UNFl8Q081034@freefall.freebsd.org> Synopsis: default route to internet magically disappears with multihomed server Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 23:15:29 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=71469 From brucec at FreeBSD.org Fri Jan 30 15:17:29 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 15:17:43 2009 Subject: bin/120060: routed(8) deletes link-level routes in the presence of a /32 alias Message-ID: <200901302317.n0UNHRGU081137@freefall.freebsd.org> Synopsis: routed(8) deletes link-level routes in the presence of a /32 alias Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 23:17:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120060 From brucec at FreeBSD.org Fri Jan 30 15:18:32 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Fri Jan 30 15:18:38 2009 Subject: kern/104851: [inet6] [patch] On link routes not configured when using both IPv6 autoconfiguration and manual configuration Message-ID: <200901302318.n0UNIU4w081202@freefall.freebsd.org> Synopsis: [inet6] [patch] On link routes not configured when using both IPv6 autoconfiguration and manual configuration Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Fri Jan 30 23:18:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=104851 From bz at FreeBSD.org Fri Jan 30 15:29:48 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Fri Jan 30 15:29:59 2009 Subject: conf/128030: [request] Isn't it time to enable IPsec in GENERIC? Message-ID: <200901302329.n0UNTkjV088456@freefall.freebsd.org> Synopsis: [request] Isn't it time to enable IPsec in GENERIC? State-Changed-From-To: open->suspended State-Changed-By: bz State-Changed-When: Fri Jan 30 23:27:32 UTC 2009 State-Changed-Why: Susepend until enough work on fixing IPsec and performance wise integration into the main network stack code flow has been/can be done. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Jan 30 23:27:32 UTC 2009 Responsible-Changed-Why: I'll take it so I'll have it in mind. http://www.freebsd.org/cgi/query-pr.cgi?pr=128030 From morganw at chemikals.org Fri Jan 30 15:30:38 2009 From: morganw at chemikals.org (Wes Morgan) Date: Fri Jan 30 15:30:45 2009 Subject: atheros 5212 problems on -STABLE In-Reply-To: <200901300858.12029.adamk@voicenet.com> References: <200901300858.12029.adamk@voicenet.com> Message-ID: On Fri, 30 Jan 2009, Adam K Kirchhoff wrote: > > Since the iwi driver doesn't want to join the wireless network at work (I opened up a pr for it), I decided to try the ath driver instead. > The card is an Atheros 5212. > > Unfortunately, I'm having even more serious problems with this card: > > ath0: ath_chan_set: unable to reset channel 7 (2442 Mhz, flags 0x480 hal flags 0xc0), hal status 3302560252 > ath0: ath_chan_set: unable to reset channel 52 (5260 Mhz, flags 0x140 hal flags 0x140), hal status 3296823488 > ath0: ath_chan_set: unable to reset channel 56 (5280 Mhz, flags 0x140 hal flags 0x140), hal status 0 > ath0: ath_chan_set: unable to reset channel 60 (5300 Mhz, flags 0x140 hal flags 0x140), hal status 3304978572 > > It cycles through various channels till: > > ath0: device timeout > ath0: ath_reset: unable to reset hardware; hal status 3232887468 > > And then it starts with the "unable to reset channel" errors again. This continues till I run '/etc/rc.d/netif stop ath0' > > When I go to remove the card, the kernel panics: > > panic: resource_list_release: resource entry is not busy > cpuid = 0 > KDB: enter: panic > [thread pid 34 tid 100033 ] > Stopped at kdb_enter_why+0x3a: movl $0,kdb_why > db> bt > Tracing pid 34 tid 100033 td 0xc4988690 > kdb_enter_why(c0b5759f,c0b5759f,c0b591cd,e5070bc4,0,...) at kdb_enter_why+0x3a > panic(c0b591cd,3,10,0,c49f91c0,...) at panic+0x136 > resource_list_release(c4b6bc04,c494ab80,c49f8900,3,10,...) at resource_list_release+0xc2 > bus_generic_rl_release_resource(c494ab80,c49f8900,3,10,c49f9480) at bus_generic_rl_release_resource+0x77 > bus_release_resource(c49f8900,3,10,c49f9480,c49f8900,...) at bus_release_resource+0x67 > ath_pci_detach(c49f8900,c48a1858,c0c15b60,c07c8125,4,...) at ath_pci_detach+0xb2 > device_detach(c49f8900,e5070cac,e5070cb0,c4988690,e5070cc0,...) at device_detach+0x68 > cardbus_detach_card(c494ab80,c48b08e0,c0bd2bfc,0,0,...) at cardbus_detach_card+0xcd > cbb_event_thread(c4913800,e5070d38,0,0,0,...) at cbb_event_thread+0x1ac > fork_exit(c0661a50,c4913800,e5070d38) at fork_exit+0x99 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe5070d70, ebp = 0 --- Are you running sysutils/hal? I've been told it's due to a kernel bug of some kind that is fixed in -current, but hal makes my atheros card do something similar if it scans it. I had to force it to ignore the cardbus device to stop it from happening, but I have other issues with HAL and the new xorg, so I just flat out disabled it. Doesn't seem to be ready for prime time on my laptop. From julian at elischer.org Sat Jan 31 01:07:51 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Jan 31 01:07:58 2009 Subject: Vimage globals vs structures measurements. Message-ID: <498414E5.7020904@elischer.org> anyone who has commands and args for their favourite thing the'd like me to test... send it in.. so far using ttcp I have seem no measureable difference. but I have more tests to do of course.. for example throughput with small packets with ttcp (KB/Sec).... x VIMAGE_GLOBALS + NO_VIMAGE_GLOBALS +-----------------------------------------------------------------+ | + xx | | + xxx + | | + xxx x ++++ | | x + x + + xxxxxxx +++++ | |x + ++ xx xxx + ++++xxx x x x +++++ ***xxxxx ++++++++| | |_____________A______M______| | | |________________AM________________| | +-----------------------------------------------------------------+ N Min Max Median Avg Stddev x 40 48016.01 57361.32 56268.06 54915.582 2554.0133 + 40 48999.66 59646.59 56261.58 56086.798 3119.1782 From ap00 at mail.ru Sat Jan 31 01:15:15 2009 From: ap00 at mail.ru (Anthony Pankov) Date: Sat Jan 31 01:15:22 2009 Subject: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections In-Reply-To: <200901301948.n0UJmt5a011677@freefall.freebsd.org> References: <200901301948.n0UJmt5a011677@freefall.freebsd.org> Message-ID: <1181200296.20090131115834@mail.ru> Here is another demonstration of this bug: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=190401+0+archive/2008/freebsd-net/20080406.freebsd-net Friday, January 30, 2009, 10:48:55 PM, you wrote: vFo> Synopsis: [tcp] Turning on TCP blackholing causes slow localhost connections vFo> State-Changed-From-To: open->closed vFo> State-Changed-By: vwe vFo> State-Changed-When: Fri Jan 30 19:45:46 UTC 2009 vFo> State-Changed-Why: vFo> Tom, vFo> we think this issue either is not related to the tcp stack or not directly vFo> related to blackholing connections. It might be an application issue. vFo> As we do not think there's something we can work on, we're going to close vFo> this PR. vFo> If you think there should be something fixed, please put more information vFo> into the PR so we can check that. Thank you for reporting this problem. vFo> Responsible-Changed-From-To: freebsd-net->vwe vFo> Responsible-Changed-By: vwe vFo> Responsible-Changed-When: Fri Jan 30 19:45:46 UTC 2009 vFo> Responsible-Changed-Why: vFo> track vFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=123881 vFo> _______________________________________________ vFo> freebsd-net@freebsd.org mailing list vFo> http://lists.freebsd.org/mailman/listinfo/freebsd-net vFo> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best regards, Anthony mailto:ap00@mail.ru From julian at elischer.org Sat Jan 31 02:12:46 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Jan 31 02:12:53 2009 Subject: Vimage globals vs structures measurements. In-Reply-To: <498414E5.7020904@elischer.org> References: <498414E5.7020904@elischer.org> Message-ID: <4984241B.5010103@elischer.org> Julian Elischer wrote: > > anyone who has commands and args for their favourite > thing the'd like me to test... send it in.. > > > so far using ttcp I have seem no measureable difference. > > but I have more tests to do of course.. > > for example throughput with small packets with ttcp (KB/Sec).... > > > x VIMAGE_GLOBALS > + NO_VIMAGE_GLOBALS > +-----------------------------------------------------------------+ > | + xx | > | + xxx + | > | + xxx x ++++ | > | x + x + + xxxxxxx +++++ | > |x + ++ xx xxx + ++++xxx x x x +++++ ***xxxxx ++++++++| > | |_____________A______M______| | > | |________________AM________________| | > +-----------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 40 48016.01 57361.32 56268.06 54915.582 2554.0133 > + 40 48999.66 59646.59 56261.58 56086.798 3119.1782 > _______________________________________________ > 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" as I said before mst of my tests have shown no real change but this one has the most change I've seen.. it's 160 byte udp packets sent between two identical machines (both using the same kernel each time). x VIMAGE_GLOBALS + NO_VIMAGE_GLOBALS +-----------------------------------------------------------------+ | + + ++ xx x x | | + + ++ +x++x +xx x x | | + + +++ + +*+**x+xxxx x | | + +++ +++x*++*+**x*x*xx x x x | | + +*+++++x**+*+**x*x*x*xx x x xx | | ++++*++++****+*+**x*x****x xxxx xxx | | + + xx + ++++*++*+****+***********x*xxxxx xxxx x| |+ +*+++ xx++*+*+*+****+****************x***x*xxx*xx x xx x| | |__________A__________| | | |_________A________| | +-----------------------------------------------------------------+ N Min Max Median Avg Stddev x 150 10175.11 11292.11 10763.80 10760.77 200.92124 + 150 10075.64 11019.12 10591.68 10580.059 172.29227 Difference at 95.0% confidence -180.711 +/- 42.3572 -1.67935% +/- 0.393626% (Student's t, pooled s = 187.155) this one showed a 1.7% slowdown where the one above showed a half percent speedup (but not considered significant). The first one shown above was TCP with 1500 byte packets on bge 1G interfaces.. more test ideas appreciated... From vwe at FreeBSD.org Sat Jan 31 02:24:35 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Jan 31 02:24:43 2009 Subject: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor Message-ID: <200901311024.n0VAOY3O024897@freefall.freebsd.org> Synopsis: [ath] doesn't work with my PCI-E X1 wireless network adaptor State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 10:22:17 UTC 2009 State-Changed-Why: Intron, the latest HAL changes have been committed to 7-STABLE with rev 186910. Please update your source tree. Also please note this PR is a DUP of kern/115226 (we're closing this PR, please file any followups to the other PR). Thank you! Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 10:22:17 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=126564 From will at firepipe.net Sat Jan 31 02:30:06 2009 From: will at firepipe.net (Will Andrews) Date: Sat Jan 31 02:30:16 2009 Subject: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Message-ID: <200901311030.n0VAU5aG028587@freefall.freebsd.org> The following reply was made to PR bin/118987; it has been noted by GNATS. From: Will Andrews To: bug-followup@freebsd.org Cc: Subject: Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Date: Sat, 31 Jan 2009 03:29:52 -0700 --001636c5986450f9c20461c4cdef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a patch that fixes this problem (it also fixes the problem for address families besides "ether"). I'm not sure if the method used is the best approach for "ether", but it does at least match some other usage within ifconfig. Unfortunately I don't seem to be able to attach patches correctly for GNATS, so here's a link: http://firepipe.net/ifconfig.c.118987-diff2.txt --Will. --001636c5986450f9c20461c4cdef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a patch that fixes this problem (it also fixes the problem for addr= ess families besides "ether").  I'm not sure if the meth= od used is the best approach for "ether", but it does at least ma= tch some other usage within ifconfig.  Unfortunately I don't seem = to be able to attach patches correctly for GNATS, so here's a link:
--001636c5986450f9c20461c4cdef-- From vwe at FreeBSD.org Sat Jan 31 02:33:55 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Jan 31 02:34:01 2009 Subject: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Message-ID: <200901311033.n0VAXr6R037246@freefall.freebsd.org> Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 State-Changed-From-To: open->analyzed State-Changed-By: vwe State-Changed-When: Sat Jan 31 10:31:59 UTC 2009 State-Changed-Why: Will has created a patch for evaluation http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 From vwe at FreeBSD.org Sat Jan 31 03:12:25 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Jan 31 03:12:31 2009 Subject: kern/103059: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch) Message-ID: <200901311112.n0VBCODf065139@freefall.freebsd.org> Synopsis: [bce] [patch] "Error mapping mbuf into TX chain!" (tentative patch) State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 11:09:15 UTC 2009 State-Changed-Why: Michael, we think this issue is fixed by r159411 and r164327. If you think this issue is still one, please check your problem with a more recent release as 6.1 has been EOL'd. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 11:09:15 UTC 2009 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=103059 From bz at FreeBSD.org Sat Jan 31 05:40:04 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Jan 31 05:40:13 2009 Subject: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 Message-ID: <200901311340.n0VDe3Gd074350@freefall.freebsd.org> The following reply was made to PR kern/118880; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, jau@iki.fi Cc: Subject: Re: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 Date: Sat, 31 Jan 2009 13:25:20 +0000 (UTC) Hi, see kern/122039 which seems to be a ``duplicate'' of this one but has a comment for discussion. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Sat Jan 31 05:44:41 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Sat Jan 31 05:44:48 2009 Subject: kern/113842: [ip6] PF_INET6 proto domain state can't be cleared without a reboot Message-ID: <200901311344.n0VDieph081427@freefall.freebsd.org> Synopsis: [ip6] PF_INET6 proto domain state can't be cleared without a reboot State-Changed-From-To: open->analyzed State-Changed-By: bz State-Changed-When: Sat Jan 31 13:42:49 UTC 2009 State-Changed-Why: The problem has been analyzed a few months back. A workaround for what I think the submitter has asked for was presented; yet an rc sscript and the kernel has to be fixed. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Jan 31 13:42:49 UTC 2009 Responsible-Changed-Why: I'll take care of this. http://www.freebsd.org/cgi/query-pr.cgi?pr=113842 From mav at FreeBSD.org Sat Jan 31 05:54:35 2009 From: mav at FreeBSD.org (mav@FreeBSD.org) Date: Sat Jan 31 05:54:43 2009 Subject: kern/123200: [netgraph] Server failure due to netgraph mpd and dhcpclient Message-ID: <200901311354.n0VDsYUC088546@freefall.freebsd.org> Synopsis: [netgraph] Server failure due to netgraph mpd and dhcpclient State-Changed-From-To: feedback->closed State-Changed-By: mav State-Changed-When: Sat Jan 31 13:52:36 UTC 2009 State-Changed-Why: Patches fixing crashes/freezes on VPN routing loop were merged to 7-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=123200 From vwe at FreeBSD.org Sat Jan 31 06:25:22 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sat Jan 31 06:25:29 2009 Subject: kern/118880: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 Message-ID: <200901311425.n0VEPLEw011168@freefall.freebsd.org> Synopsis: [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented for IPv6 State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sat Jan 31 14:23:06 UTC 2009 State-Changed-Why: kern/122039 is a DUP of this PR but we're closing this in favour of kern/122039 as it does contain some more information. Thank you for your report. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: vwe Responsible-Changed-When: Sat Jan 31 14:23:06 UTC 2009 Responsible-Changed-Why: assign closed PR to bz as it seems to be of interest to him http://www.freebsd.org/cgi/query-pr.cgi?pr=118880 From thompsa at FreeBSD.org Sat Jan 31 13:59:49 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Jan 31 14:00:03 2009 Subject: lagg failover mode and vlans In-Reply-To: <200901271739.n0RHdGd3047497@lava.sentex.ca> References: <200901271739.n0RHdGd3047497@lava.sentex.ca> Message-ID: <20090131213354.GA29777@citylink.fud.org.nz> On Tue, Jan 27, 2009 at 12:39:26PM -0500, Mike Tancsa wrote: ... > > but if I create some vlan interfaces off lagg0 > > lagg0.100: flags=8843 metric 0 mtu 1500 > options=3 > ether 00:30:48:90:4c:fe > inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 > media: Ethernet autoselect > status: active > vlan: 100 parent interface: lagg0 > lagg0.102: flags=8843 metric 0 mtu 1500 > options=3 > ether 00:30:48:90:4c:fe > inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 > media: Ethernet autoselect > status: active > vlan: 102 parent interface: lagg0 > > and do the same pulling of the cable, it does not work. BUT, if I do an > arp -nda on a machine that is part of vlan102 which is doing the pinging > (so an arp-who has gets sent out and a reply answered), it works. The > other option is if I send a packet out on the vlan's broadcast address from > the server Can you verify that em2, em3 and all the lagg* interfaces have the same mac address. Andrew From bz at FreeBSD.org Sat Jan 31 14:26:06 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Sat Jan 31 14:26:13 2009 Subject: kern/123066: [ipsec] [panic] kernel trap with ipsec Message-ID: <200901312226.n0VMQ5ws071710@freefall.freebsd.org> Synopsis: [ipsec] [panic] kernel trap with ipsec Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: bz Responsible-Changed-When: Sat Jan 31 22:25:12 UTC 2009 Responsible-Changed-Why: kern/124609 seems linked to this one and you handled that; could you check if both PRs are the same? http://www.freebsd.org/cgi/query-pr.cgi?pr=123066 From jroberson at jroberson.net Sat Jan 31 15:20:23 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Sat Jan 31 15:20:30 2009 Subject: mbuf revision, testers/comments wanted. Message-ID: <20090131125100.N983@desktop> http://people.freebsd.org/~jeff/mbuf_ref2.diff Hello, I have been experimenting with different revisions to the mbuf api to improve performance and simplify code. This patch is the first of several proposed steps towards those goals. The aim of this patch is two fold; 1) Revising the reference counting system so that we can eliminate reference uma zones and the significant uma_find_refcnt() costs in some workloads. This is done by making all mbufs reference counted and using the owning mbuf's ref for the ext_ref. In this model we never reference data, we only reference other mbufs owning the data. 2) Improve allocation and free performance by reducing the special cases in the format and using inlines when appropriate. In particular, the simplification of the m_ext structure yields less code and confusion for dealing with external storage on free. The ctor/dtor mbuf routines are no longer used. A zone pointer and length was added to struct mbuf to simplify free and size calculations. A number of routines were made much, much simpler by the addition of a 16bit size field. Previously we dependend on calculating the size by figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, this patch moves us closer to having a size agnostic mbuf which we can use to experiment with different allocation sizes or even backending to malloc for dynamically sized mbufs. I would appreciate testing feedback from varied workloads to make sure there are no bugs before I go forward with this. I have tested only host oriented networking with a few drivers. It is not anticipated that there will be any significant incompatibilities introduced with this round but there is always that possibility. Thanks, Jeff From mmitar at gmail.com Sat Jan 31 16:37:44 2009 From: mmitar at gmail.com (Mitar) Date: Sat Jan 31 16:37:51 2009 Subject: read() returns ETIMEDOUT In-Reply-To: References: Message-ID: Hi! I have found also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108670 http://lists.freebsd.org/mailman/htdig/freebsd-net/2007-February/013095.html I am using FreeBSD 7.0-STABLE. Mitar From mike at sentex.net Sat Jan 31 16:47:01 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Jan 31 16:47:08 2009 Subject: lagg failover mode and vlans In-Reply-To: <20090131213354.GA29777@citylink.fud.org.nz> References: <200901271739.n0RHdGd3047497@lava.sentex.ca> <20090131213354.GA29777@citylink.fud.org.nz> Message-ID: <200902010046.n110kwg5076330@lava.sentex.ca> At 04:33 PM 1/31/2009, Andrew Thompson wrote: > > > > and do the same pulling of the cable, it does not work. BUT, if I do an > > arp -nda on a machine that is part of vlan102 which is doing the pinging > > (so an arp-who has gets sent out and a reply answered), it works. The > > other option is if I send a packet out on the vlan's broadcast > address from > > the server > >Can you verify that em2, em3 and all the lagg* interfaces have the same >mac address. > Looks to be from the server side. I dont have them hooked up to the switch right now, but will Monday em2: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255 media: Ethernet autoselect status: no carrier lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:fe inet 192.168.44.99 netmask 0xffffff00 broadcast 192.168.44.255 media: Ethernet autoselect status: no carrier laggproto failover laggport: em3 flags=0<> laggport: em2 flags=1 lagg0.100: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 media: Ethernet autoselect status: no carrier vlan: 100 parent interface: lagg0 lagg0.102: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:90:4c:fe inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 media: Ethernet autoselect status: no carrier vlan: 102 parent interface: lagg0 >Andrew From mmitar at gmail.com Sat Jan 31 16:51:03 2009 From: mmitar at gmail.com (Mitar) Date: Sat Jan 31 16:51:11 2009 Subject: read() returns ETIMEDOUT Message-ID: Hi! Is there any progress on this error reported: http://freebsd.monkey.org/freebsd-net/200805/msg00026.html I have the same or very similar issue. On my server large HTTP uploads are failing because there are only one direction data transmissions (when reading/receiving a request) and kernel drops connections after some time with ETIMEDOUT returning from read() even if transmissions are doing just fine with steady speed, tested at different speeds. Is there any workaround currently known? Mitar From linimon at FreeBSD.org Sat Jan 31 17:34:46 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Jan 31 17:34:51 2009 Subject: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL Message-ID: <200902010134.n111YjLp018369@freefall.freebsd.org> Synopsis: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Feb 1 01:33:56 UTC 2009 State-Changed-Why: Is this easily reproducible? And, if so, do you have a corefile available that can be posted on the web somewhere? http://www.freebsd.org/cgi/query-pr.cgi?pr=129719 From dnelson at allantgroup.com Sat Jan 31 18:42:41 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Sat Jan 31 18:42:47 2009 Subject: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL In-Reply-To: <200902010134.n111YjLp018369@freefall.freebsd.org> References: <200902010134.n111YjLp018369@freefall.freebsd.org> Message-ID: <20090201023118.GG75802@dan.emsphone.com> In the last episode (Feb 01), linimon@FreeBSD.org said: > Is this easily reproducible? And, if so, do you have a corefile > available that can be posted on the web somewhere? I've only had it happen once, but I still have the corefile if it might help. -- Dan Nelson dnelson@allantgroup.com